Debian o Ubuntu Server para Servidor?

[Germán Póo-Caamaño]

On Wed, 2009-04-15 at 20:55 -0400, Aldrin Martoq wrote:
> On Wed, 2009-04-15 at 18:02 -0400, Alvaro Herrera wrote:
> > Germán Póo-Caamaño escribió:
> > > On Wed, 2009-04-15 at 16:58 -0400, Franco Catrin L. wrote:
> > > > Para que no se vuelva una discusión inútil, la idea es aclarar que los
> > > > ciclos de Debian son más impredecibles que los de Ubuntu LTS.  Hace poco
> > > > tiempo fue liberada oficialmente la versión de Debian estable y antes de
> > > > eso los paquetes de Debian estable oficial eran del año de la cocoa.  
> > > > 
> > > > Lo mismo va a volver a pasar en un tiempo más y el problema de fondo es
> > > > que no se sabe a ciencia exacta cuando será el release oficial del
> > > > próximo, o estoy mal?
> > > No.  Tanto así como el tiempo de la cocoa no.  22 meses entre una
> > > versión y otra no es mucho tiempo.  Y Debian intentar ir por un período
> > > de 18 meses entre versiones, con un margen de hasta 24 meses.
> 
> > Y para cuando necesitas paquetes más nuevos para una versión estable que
> > es "algo vieja", siempre puedes usar backports ...
> 
> Y ahi perdemos toda la gracia de Debian y usas algo con ciclos mas
> cortos mejor. He visto millones de Debian (e incluso Ubuntu) stables
> pichicateados con urls alienijenas porque les falto tal o cual feature
> que no tiene el paquete de hace 4 an~os (o 6 meses en el caso de
> Ubuntu!)... Y rompen toda la estabilidad que tenia el sistema.

No mezcles.  Creo que Alvaro se refiere particularmente a
http://www.backports.org/ los cuales, aunque lo añadas en tu
sources.list no se instalarán, porque tienen la menor de las
prioridades.

Esto es sí y sólo si requieres un paquete especial en una versión dada
no disponible en el momento de salir la versión estable.  Y el esquema
es tal, que no rompe una actualización de sistema, disminuyendo el
riesgo que configuraciones alienígenas podrían dar.

En lo personal, uso estable y sólo con 'main'.  'contrib' podría ser un
caso muy especial.  'volatile' en aquellos donde se requieren los
patrones de antivirus/spam actualizados y 'backports' cuando una
característica en el programa (no en el paquete) se resolvió a partir de
una versión próxima.

Sin embargo, si recuerdas la época de Unix (Aix, Slowlaris, HP/UX,
DG/UX, Ultrix, etc), lo que tenemos hoy es una delicia.  Así que ponerse
demasiado quisquilloso, sería como comprarse un 4x4 y reclamar porque
las rueditas se ensuciaron con un poco de tierra.

> [...]
> Lo que comentaba Alvaro de que "va a estar listo cuando este listo" que
> traducido  significa "nos demoramos porque estamos asegurandonos que no
> tenga bugs" es un error. Todo software tiene errores, en particular una
> nueva version; Atrasar el proceso eternamente no ayuda a minimizar el
> problema (porque resolver es imposible)... de hecho siempre Debian ha
> liberado la version x.0.1 en uno o dos meses.

No. La semántica de "va a estar listo cuando este listo" es distinta a
como lo planteas.  Si para la versión X+1 se ha definido que tenga Y
característica, entonces no se va a liberar hasta que dicha
característica se implemente de forma satisfactoria, no que esté libre
de errores.  Y la idea de dicho discurso, es no apurarse en parchando
discrecionalmente, sino con claridad respecto a la solución que en ese
momento se cree mejor.

Con los ciclos definidos claramente, cambias el enfoque y abres la
posibilidad que si característica Y no está lista, entonces puedes
retrasarla para la siguiente.  Salvo en casos muy particulares, como la
primera versión LTS de Ubuntu, que no le daba para ser considerada LTS y
es por ello que se retrasó en 2 meses.

El inconveniente del segundo enfoque es te mueves en un péndulo en donde
las cotas son 'estabilidad' e 'innovación', con tendencia hacia la
'estabilidad' que a la 'innovación'.

-- 
Germán Póo-Caamaño
Concepción - Chile
http://www.calcifer.org/