Linux RedHat 7.3 y disco SATA

[Horst von Brand]

Juan Carlos Inostroza <jci en tux.cl> dijo:
> On Mon, 2005-05-16 at 17:43 -0400, Horst von Brand wrote:
> > Juan Carlos Inostroza <jci en tux.cl> dijo:
> > > Considerando la poca cantidad de paquetes (Woody v/s Sarge), claro que
> > > se sabe que parchar.

> > No veo que relevancia pueda tener la totalidad de paquetes disponibles. Lo
> > que importa es lo que tienes instalado, que sera mas o menos lo mismo
> > independiente de la distribucion exacta que uses.

> 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.

> > Quiza. Y (mucho mas importante) falto el "quien se preocupa de seguir los
> > reportes y estudiar como parchar, aplicar los parches y verificar que el
> > problema se corrige sin introducir problemas nuevos (o reintroducir
> > problemas ya corregidos)". A lo que le llaman "QA" y "seguridad".
> > Perfectamente puedes ser tu mismo (para un conjunto limitado de cosas,
> > obviamente).

> Claro. Pero solo para una cantidad (mas bien limitadisima). El espectro
> se acorta dependiendo de la experticia del instalador.

Exacto.

> > > Yo creo que es perfectamente valido.

> > Disculpa, pero no te la creo. Mira p.ej. sendmail: Hace /mucho/ que no hay
> > exploits que te dan root remoto con sendmail, que en su epoca era la rana
> > de la semana. Igual MSIE. Hay ranas en PHP 4 que se corrigieron en PHP 5, y
> > que no tenian vuelta en 4. Etc. Hay al menos suficientes contraejemplos
> > para saber que simplemente no es verdad a lo ancho. Si es o no verdad en un
> > sentido de "promedio estadistico" es un tema completamente diferente, para
> > el cual no he visto /nada/ en termino de datos concretos.

> Efectivamente hay contraejemplos de versiones nuevas/funcionalidades
> nuevas. Pero partiendo de la base que una version nueva, para arreglar
> pifias viejas (como PHP)...

> ...simplemente dificil tomar el tema. Y se me hace dificil no justificar
> el mismo ejemplo. Quizas con un poco de memoria...

> (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.

> > Cierto. Y un cachureo nuevo /puede/ significar nuevos problemas, pero no es
> > /necesariamente/ asi. En OSS si se agrega algun cachirulo es porque
> > "alguien" esta interesado en usarlo, no simplemente para agregar "30 nuevas
> > caracteristicas! Chame Cha, y llevese !!gratis!! una licencia para escribir
> > email en letras lila!".  Ergo, hay usuarios a quienes les interesa/sirve.

> 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.

> [snip]
> > por el otro
> > lado una version vieja (y poco usada) es un blanco menos promisorio (pero
> > /nunca/ falta el perejil que intenta exploits de hace 2 an~os, asi que...).

> Seria ideal tener una estadistica de lanzamiento/rana/correccion/cambio
> de version. Si supiera parametrizar esto, y quizas hurgueteando en la
> misma debian-security...

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

> > > > Haz una rapida encuesta aca, y veras que los que corren la version
> > > > estable de Debian estan en una infima minoria.

> > > Es cosa de ver cuantos corren Sid para maquinas de escritorio
> > > solamente...

> > Y por tanto se restan a la masa de gente que lo prueba. Exactamente lo que
> > dije.

> 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.

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

Menuda sorpresa...

> > Pero mientras tanto livianamente recomiendan correr Debian "testing" en
> > produccion. A mi eso me parece irresponsable.

> Hace un a~o atras igual lo habria recomendado.

Ver arriba.

>                                                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.

[...]

> > ... todas cosas que se pueden descubrir en pruebas alpha ("unstable",
> > "rawhide", "cooker") o beta ("testing"), en la esperanza que ya no esten
> > cuando se libere.

> Creo que por algo esta la rama de experimental y unstable en Debian.

Pero /no estan para ser usadas en serio/.

> > > 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. 

> ...es mi idea o este tema esta empezando a derivar en control de calidad
> del software?

Ese ha sido el tema desde el comienzo.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513