Linux RedHat 7.3 y disco SATA

[Juan Carlos Inostroza]

On Mon, 2005-05-16 at 22:51 -0400, Horst von Brand wrote:
> > Lo estaba viendo desde el lado de desarrolladores/empaquetadores, no del
> > lado del instalador (sabiendo a priori que el instalador promedio hara
> > algunos pocos chequeos...)
> 
> No lo veo, sorry.

...

> > (quizas con algo de tiempo, sacar algunas estadisticas no sera nada de
> > malo en pro de la discusion...)
> 
> Buena suerte! Nadie se ha dado el trabajo, que yo sepa. El problema es que
> tomar una distribucion "in the wild" (o varias) como base introduce demasiadas
> variables incontrolables, e igual no tienes la menor idea de cuantas pifias
> hay en paquete-x.y.z-de-la-distro.

La idea seria:
* tomar las versiones base de los paquetes al momento de ser lanzado 
(nota : aqui podrian estar hasta los instaladores en CD v.1.0, puede ser
FC1 o bien Debian 3.0 Woody)
* ver los cambios y que cambios se han hecho
* compararlos con las versiones actuales (numero version)

La idea seria tomar valores de tiempo versus el grado de vulnerabilidad.
Se suman y se saca cual esta mas "pifiada".

Quien se ofrece con Fedora? :D


> > Los hobbistas cuentan en este punto, ojo :)
> > (no es acaso el escrutinio de miles de ojos el proceso de revision [no
> > QA] del FLOSS?)
> 
> Si. Pero en la practica los "miles de ojos" es porque hay miles tratando de
> entenderlo para modificarlo. Hay que considerar que miles de ojos que no
> tienen el entrenamiento para encontrar pifias no sirven mayormente. Y
> tambien importan miles de monos corriendo el cuento en decenas de miles de
> formas marcianas, que al desarrollador no se le ocurririan ni en sus
> suen~os psicodelicos mas extremos, y que reportan los tortazos resultantes.

Si, eso es cierto. Considerar que los miles de ojos tendran el mismo
nivel de expertise promedio es bastante arriesgado :-/

Y muchos personajes reportan fallos en bugzilla que, como lei en un
foro, "son fallas del piloto" :)


> Nuevamente, buena suerte! Hay demasiadas variables sin posible control en
> eso.

Por algo dije si alguien me pegaba una mano en parametrizar...

> > No es que se unen a la masa de prueba?
> 
> No. Porque no estan probando la version que importa aca, la estable. Que yo
> pruebe Fedora Core a matar cuando mucho tiene interes anecdotico para quien
> depende de OpenBSD. Si sera relevante (posiblemente) algun dia en el futuro
> no especificado para quien corra RHEL, pero no afecta en nada a quien lo
> usa hoy.

Lo que pasa es que el termino "estable" es muy _vago_ en el sentido del
software. Quizas armar una distro, con una cantidad de paquetes,
suficientemente revisadas (contra el tiempo) y paf! nacio GHT Linux
estable. Mientras tanto, los labs estaran jugando con versiones nuevas
de las librerias para incluir mas y mas caos a la mezcla. (o bien mas
orden, siempre veo el vaso a medio vaciar :D )

O no es asi el proceso de lanzamiento de las distros? :-/


> > (de hecho, Sid es mucho mas quebrable que Sarge)
> 
> Menuda sorpresa...

Pero para escritorios, si no se es fanatico del apt-get upgrade, puede
durar semanas :D

> >                                                Pero hace un par, nica.
> > (cuando prometieron el primer freeze, cuando Sarge ya seria la ilusion
> > del Stable...)
> 
> Tu lo dijiste: "ilusion" de stable. Mientras quienes tienen la decision no
> hayan dicho oficialmente que se ha hecho lo posible por tener una version
> estable, recomendada para todo uso, bueno, /no/ se puede responsablemente
> considerar suficientemente estable para uso general. Si, ya se que es una
> idea radical, casi impensable.

Ahora precisamente se estan chicoteando (azotando o flagelando) a los
responsables de cualquier tropiezo para el lanzamiento. Segun se, Sarge
va. Luego. 

> > Creo que por algo esta la rama de experimental y unstable en Debian.
> 
> Pero /no estan para ser usadas en serio/.

En serio serio, no. En serio, para ver donde hubo un ranazo, reportar en
el sistema de errores (http://bugs.debian.org), corregir typos del
empaquetador, etc.

Ahora, de que Debian cuenta con un nutrido laboratorio de QA...creo que
son los usuarios. Sera el mejor QA? Ni idea. La idea ha funcionado hasta
el momento (pero ni yo creo que sea el mejor QA).


> > > > Cual de las dos prefieren? Ante un ciclo de desarrollo mucho mas radical
> > > > (como el de FC) es preferible el primero.
> 
> > > No veo la diferencia, a decir verdad.
> 
> > Hay una. 
> > El apuro por sacar versiones nuevas (dependiendo de algun criterio a la
> > mano) versus el apuro de sacar versiones "estables" (zarro bugs)...
> 
> No veo ninguna diferencia. Se trata de sacar versiones nuevas, estables
> dentro de lo razonablemente posible. No se de ningun proyecto OSS que
> simplemente saque cualquier basura porque "llego la hora de liberar".
> P.ej. Gnome tiene sus politicas, si un paquete/version no esta listo para
> la fecha de liberacion, queda fuera. Ya le tocara su turno la proxima
> vuelta. Y FC a su vez integra paquetes cuando se han estabilizado. 

Efectivamente. El problema esta en la jerarquia de los paquetes. 
Un paquete en Required es demasiado sensible. Si cambia de version, lo
mas probable es que afecte a una tracalada de paquetes que dependen de
el (dependiendo ademas de la sintaxis de reglas, como numero de version
requerida para la construccion, etc).

Un paquete Optional nadie lo echara de menos (broma aparte).

(nota : la jerarquia es Required, Important, Standard, Optional,Extra).

> > ...es mi idea o este tema esta empezando a derivar en control de calidad
> > del software?
> 
> Ese ha sido el tema desde el comienzo.

Al menos la discusion se torno un poco mas interesante :D

--jci