El post que buscas se encuentra eliminado, pero este también te puede interesar

Sobre los ciclos de lanzamiento

porEugenio M. Vigo


Sobre los ciclos de lanzamiento




Leyendo sobre la pésima relación que existe entre el equipo de desarrollo de Arch Linux y el de Manjaro, me encontré con las durísimas críticas por parte de Allan Mcrae (de Arch) al ciclo de lanzamiento de Manjaro, que consiste, básicamente, en retrasar la entrada de los paquetes llegados de Arch para probarlos. Esa decisión produce una serie de consecuencias nefastas en que Mcrae tiene razón, pero detrás de este debate está el eterno debate entre tener lo más nuevo y ser más estable, que hoy se traduce entre distribuciones de lanzamiento continuo (rolling releases) o no-continuo.
El enfado monumental de Mcrae contra Manjaro se basa en lo siguiente. Manjaro es una distribución que, en esencia, lo que intenta hacer es crear una Ubuntu del mundo Arch. Toma los paquetes de Arch y los va probando antes de hacerlos disponibles a los usuarios de la distribución. Con ello, se supone, que uno se puede evitar problemas desagradables que el público objetivo de Manjaro, en principio, no debería por qué tener que resolver manualmente. 

Pero, ¿qué pasa cuando se descubre una vulnerabilidad en un programa y su equipo de desarrollo lanza una nueva versión que la resuelve? En el caso de una distribución "tradicional", con lanzamientos no-continuos, se lanzaría una actualización de seguridad que parche el paquete antiguo (hasta la siguiente versión de la distribución, en la que se incorporaría la nueva versión del programa).

Por ejemplo, Debian utiliza un repositorio específico de seguridad para distribuir esos paquetes parcheados (y para fallos que no son de seguridad, están las "point-releases" o lanzamientos menores). En el caso de una distribución al estilo de Arch, simplemente se incorporaría el paquete a los repositorios y ya estaría listo. En ambos casos la vulnerabilidad se cerraría en no más de 48 horas de haber sido resuelta por los desarrolladoes.

En cambio, Manjaro haría lo siguiente: introduciría en la rama inestable el paquete (desde Arch) y lo probaría, por un mes para el repositorio Core (el que incluye los paquetes más relevantes para mantener un sistema), hasta que el equipo de desarrollo de la distribución lo acepte como "estable". En resumen: puede pasar hasta un mes para que la distribución logre cerrar una vulnerabilidad. Seguramente no es lo usual, pero la existencia de la posibilidad es un problema grave.

Es cierto, Debian "testing" tiene exactamente el mismo problema, pero con la pequeña salvedad de que es una distribución en pruebas que no está diseñada para uso "normal" (otra cosa es que haya gente que lo haga, porque funciona, pero para ello lo recomendable es saber hacer backports desde la rama inestable). El equipo encargado de la rama "testing" advierte una y otra vez de que esa rama no está soportada por el equipo de seguridad y de que es la rama a la que los parches llegan más tarde (a Debian "unstable" le llegan los paquetes directamente desde los proyectos).

Antes que me lluevan críticas, aviso que el artículo de Wikipedia "Rolling release" enumera una buena cantidad de tipos diferentes de lanzamientos continuos en función del tipo de lanzamiento, si es opcional o no, etc. En mi opinión, lo que realmente interesa para el análisis son aquellas distribuciones de lanzamiento continuo "de verdad"; es decir, aquellas que hacen disponibles en repositorios oficiales propios las versiones actuales de los proyectos. Cualquier tipo de retraso (à la Manjaro) es pernicioso, ya que es un sistema híbrido que combina lo peor de los dos sistemas, y aquellos sistemas basados en una base no-continua combinada con una que sí lo es no son más que sistemas basados en el concepto de "backporting" y que se limitan tan solo a un nicho muy específico de programas.

Tampoco interesan realmente las distribuciones del tipo aptosid que intentan "estabilizar" una rama de desarrollo de una distribución no-continua, porque implica, básicamente, entrar a parchear código sin el extenso periodo de pruebas que llevan a cabo las distribuciones más tradicionales.

Esta es una de las cosas que todos los usuarios de una distribución Linux deben tener en cuenta en su elección de sistema operativo y en las cuales no se suele incidir demasiado. En primer lugar, hay que saber reconocer si la distribución está haciendo bien o mal las cosas; el ejemplo de Manjaro es uno de los malos, porque retrasa innecesariamente la llegada de arreglos a los usuarios. El criterio eliminatorio, en mi opinión, tiene que ser justamente ese: si el método de lanzamiento es capaz de distribuir rápida y fácilmente las actualizaciones urgentes a todos sus usuarios. Otro ejemplo de pésima gestión de  lanzamiento de actualizaciones, incluso de seguridad, es la de Android cuando miramos más allá del idílico mundo de los dispositivos Nexus y Google Play Edition.

Sin embargo, lo que interesa es qué pasa entre las distribuciones que gestionan bien su "base de código" (codebase), donde las diferencias no definen qué es mejor o peor en términos absolutos, sino qué es lo mejor o peor para diferentes tipos de usuarios.

En esto, el viejo mantra es que el mundo Linux se divide entre los que buscan estabilidad y aquellos que buscan lo más nuevo, pero creo que es una visión muy simplista y muy equivocada que puede llevar a más de algún novato a error. En primer lugar, novedad y estabilidad no tienen por qué estar completamente reñidas y, en segundo, la distinción se trata más bien en quién necesita estabilidad sacrificando novedad y quién puede darse el lujo de poder de beneficiarse de código recién lanzado directamente desde los proyectos a costa de un poco menos de estabilidad. Lo que no existe es distribución cuya versión final sea absolutamente inestable: la oposición "estable-viejo vs. inestable-nuevo" es un falso dilema. Pensad que Arch, esa distribución tan temida, solo funciona con paquetes de versiones estables y no versiones de desarrollo (salvo que uno use los paquetes *-git del AUR, pero eso es otra historia).

Esto no quiere decir que una distribución de lanzamiento continuo como Arch o KaOS sea para todo el mundo, más que nada porque exige la responsabilidad de estar atentos a cualquier problema que pudiera surgir. Exige, por tanto, conocimientos (en especial sobre cómo y dónde preguntar las dudas), tiempo para mantener el sistema y, en especial, tener el tacto sobre cuándo actualizar qué. En definitiva, un lanzamiento continuo exige una atención continua porque los paquetes van llegando en un ritmo imparable y que pueden producir cambios que, más que malos, son inesperados.

Los usuarios finales que no tengan esa base de conocimientos o no puedan darse el lujo de atender constantemente su sistema operativo, necesitan delegar en un equipo de desarrollo la decisión de cómo se deben llevar a cabo los cambios y las transiciones entre versiones.

Lo que no tiene mucho sentido en el caso de los usuarios de escritorio es utilizar una distribución como Debian, donde uno puede quedar atrás en términos de funcionalidades muy rápidamente. Sí, la seguridad está cubierta y los fallos se van resolviendo, pero los foros están llenos de novatos que instalan Debian y que, como quieren que funcione como Ubuntu o Linux Mint, acaban habilitando montones de repositorios de terceros que llevan a que el sistema de inestabilice de formas impredecibles.

Una distribución como Debian solo tiene sentido en un entorno donde se necesita un sistema que arranque y funcione sin ningún tipo de sorpresas porque importa más que se mantenga funcionando con las funcionalidades que se tienen hasta que no den abasto (por eso el atractivo de un Debian 6.0 LTS, como comentaba en la entrada pasada).

Algunos llaman "versionitis" a la obsesión por tener la última versión, pero en un proyecto bien gestionado, tener la última versión tiene sentido porque supondrá mejoras por ejemplo en fallos menores pero que pueden afectar la usabilidad de un programa y para el que nunca recibirán un parche "de urgencia" en una distribución de lanzamientos discretos hasta la nueva versión de la distribución.

Por supuesto, una nueva versión de un programa puede ser mala (véase cuando salió a la luz GNOME 3.0) y alguien tiene que tomar la decisión de si le interesa o no: en el caso de una distribución que no es continua, el equipo de desarrollo puede tomar la decisión de esperar a que salga una versión mejor y en el de una continua, es el usuario quien debe decidir y evaluar si admite pasar por esa actualización o espera a que la siguiente sea mejor o cambia a una alternativa.

Finalmente, se ha de tener en cuenta el tamaño de la comunidad y del equipo de desarrollo. Para un equipo pequeño, el modelo de lanzamiento continuo bien ejecutado es lo más sencillo: el equipo simplemente tendrá que mantener los repositorios y el sistema base que se use para instalar el sistema. En cambio, todo aquello que implique pruebas, parches e intentos de modificar el código para atajar problemas entre versiones implicará tener un mayor número de personas trabajando en la distribución para poder hacer frente a las diversas tareas.

Por eso es que lo mejor es recomendar a los que comenzáis en Linux distribuciones con un buen peso específico y un equipo de un tamaño significativo: esas distribuciones suelen cargar sobre sus hombros la creación de un sistema bien integrado (a costa del poder de elección de los usuarios, a veces) y pueden garantizar su existencia justamente por el tamaño del equipo de desarrollo. Si en cambio, el equipo es pequeño, conviene más que actúen de "distribuidores" de programas en una distribución simple y actualizada a lo último y no que prometan lo que difícilmente podrán cumplir.



  

Anuncios

6 comentarios - Sobre los ciclos de lanzamiento

@ForobardoCosmico -4
El día que Linux sea fácil, intuitivo y práctico, la gente de Windows la va a pasar mal. Hasta entonces, a darle duro con Win.
@ForobardoCosmico
@elbuglione Cuando Windows 7 deje de recibir soporte calculo que me pasaré a 8.1, está muy bueno y el menú Metro se desactiva con una serie de tweaks.
@elbuglione
@ForobardoCosmico
por ejemplo: usar Firefox, Chrome, VLC, LibreOffice, Steam, thunderbird, Gimp, etc...
todos programas multiplatafora.
luego, hacer el cambio, se te vuelve muy fácil. de hecho, el único cambio que vas a notar, es el de la interfaz. (Linux y mac tienen una interfaz gráfica muy pulida)
@elbuglione
@ForobardoCosmico
me parece muy bien, que no quieras cambiar... quizás es porque no usaste mucho tiempo Windows, como para odiarlo hasta la médula (como es mi caso).
pero bueno... lo veo como una perdida de tiempo, seguir aprendiendo y usando un sistema que va muriendo.
@fedeqwer +2
-Buen post loco!... Aguante MANJARO!
@Kik1n +1
Tsss y yo en Arch y Debian Testing.
Arch Rules
@Sacadodelamorgue +2
Muy buen artículo, luego de haberlo leído puedo decir que tengo una nueva percepción tanto de Debian como de Arch, lo malo es que ahora me siento vulnerable por usar Debian Testing cuando antes era todo lo contrario.