Linux RedHat 7.3 y disco SATA

[Juan Carlos Inostroza]

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.

Falta el "como" en la frase ;)

> 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.
Una cosa es corregir un programa (cambiarlo de minorminorminor version)
es distinto a implementarle algun cachureo nuevo.

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

Y agregar nuevos. :D

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

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

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

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

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.

Saludos!

--jci