Linux RedHat 7.3 y disco SATA

[Horst von Brand]

Juan Carlos Inostroza <jci en tux.cl> dijo:
> On Sun, 2005-05-15 at 16:48 -0400, Horst von Brand wrote:
> > Exacto. Mas bien todo lo contrario, ya que la rearquitectura por problemas
> > de seguridad (y otros) que significo el ir a nuevas versiones no esta.

> Efectivamente.

> > No. Sea lo que sea lo que usas, si instalas lo justo y necesario sabras
> > exactamente "que parchar".

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

> Falta el "como" en la frase ;)

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


> > Presupones que nuevas versiones tienen mas ranas que las antiguas... 

> Logico.

> > y no
> > creo que eso sea valido a rajatabla. 

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

> Una cosa es corregir un programa (cambiarlo de minorminorminor version)
> es distinto a implementarle algun cachureo nuevo.

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.

> > Al menos una razon fundamental de
> > "nuevas versiones" es precisamente eliminar errores. 

> Y agregar nuevos. :D

Insisto: Tienes estadisticas confiables sobre cuantos errores se introducen
al agregar caracteristicas? Sobre que tantas ranas nuevas se introducen al
/solo/ reparar pifias? Ranas nuevas introducidas al aplicar soluciones para
versiones nuevas, vastamente divergentes, sobre un programa antiguo? Y eso
todavia no se acerca a poder crear un modelo de que tan expuesto estas con
c/u de las alternativas... falta numero de usuarios (que detectan +
reportan problemas), numero (y experticia, etc) de desarrolladores, numero
de personas que /realmente/ leen el codigo (una de las razones mas
importantes es precisamente estudiarlo para ver como agregar cachirulos, y
sobre la version an~eja a nadie le interesa hacer eso), etc; 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...).

> > Sin considerar que
> > trabajar sobre una version antigua no es nada sexy, y atrae a pocos
> > desarrolladores expertos

> Totalmente de acuerdo.

> >  (es uno de los grandes problemas de siempre con el
> > nucleo Linux: La version 2.4 esta abandonada para todos los efectos
> > practicos, aunque muchos reclaman que a 2.6 le falta demasiado en
> > estabilidad para uso en serio, y /tanto/ tiempo no ha pasado...)

> Un par de a~os?

Asi es. Pero el efecto se noto en cuanto se abrio 2.5: 2.4 quedo
practicamente desierto (salvo algunos patriotas como Marcelo y Alan) casi
inmediatamente. Es una de las razones por las que Linus no quiere sacar una
serie 2.7, y nunca se comprometera a abrir una bajo condiciones fijadas.

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

> > Cierto. Pero eso es completamente irrelevante para la discusion actual.
> > Nadie en su sano juicio usa Fedora rawhide, o cooker de Madriva, o apache
> > de CVS para uso en aplicaciones de alguna importancia.

> A no ser que sea un hobbista o bien un fanatico del bleeding-edge...
> (y seria un suicidio correrlo en aplicaciones de produccion)

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

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

> Ahora depende que bug. Las pruebas de control de calidad para este tipo
> de software (perdon, para todo tipo de software) siempre van a ser
> insuficientes. Quizas un typo en un script de inicio, quizas un problema
> con una libreria inexistente, quizas un error en el codigo del
> programa...

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

> puede estar alojado en cualquier parte. Los mantenedores de los paquetes
> no son enteramente responsables de los problemas del paquete, sino _de
> arreglarlos cuando estos ocurran_. O bien, estar pendientes 24/7 a que
> el paquete que mantienen no tenga ningun bug.
> 
> 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.
-- 
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