Linux RedHat 7.3 y disco SATA

[Juan Carlos Inostroza]

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

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

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

> 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?)

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


> > > 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?
(de hecho, Sid es mucho mas quebrable que Sarge)

> 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. Pero hace un par, nica.
(cuando prometieron el primer freeze, cuando Sarge ya seria la ilusion
del Stable...)

> > > Bah... para mi, "hacer un release" es precisamente ver que no se hayan
> > > colado bugs y eliminar las ultimas pifias.
> 
> > Siempre se va a colar un bug. 
> 
> Y?

Errar humanum est :)


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

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

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

Saludos!

--jci