Check the new version here

Popular channels

Linus Torvalds y los sistemas de paquetes

por Eugenio M. Vigo






Esta entrada es un poco continuación de la anterior, en la que ya me refería a ciertas opiniones de Linus Torvalds sobre Linux en el escritorio. La semana pasada Torvalds respondió a las preguntas de los asistentes en la DebConf14, la edición de este año del prestigioso congreso anual de la comunidad Debian, y, entre otras cosas, se refirió al problema de distribuir paquetes para Linux como uno de los obstáculos que Linux tiene superar para poder ser un mejor sistema de escritorio. Aquí van algunas reflexiones sobre este tema en particular.

El problema que expone Linus Torvalds en el vídeo es que para Subsurface (un programa que sirve para analizar estadísticas de ordenadores de buceo), en la página del proyecto, solo hay paquetes binarios para Windows y OS X mientras que para Linux lo que proveen son paquetes de código fuente que tendrá que compilar el usuario por su cuenta debido a la dificultad que entraña tener que mantener distintos paquetes para distintas distribuciones en formatos de paquete tan diferentes.

Como bien apunta Torvalds, uno no "empaqueta para Fedora", por ejemplo, sino para cada una de las distintas versiones de la distribución, porque las bibliotecas y las dependencias son distintas y el programa puede fallar si uno no rehace el empaquetado específicamente para una versión en concreto. Y aún si utilizaramos paquetes con las bibliotecas incrustadas de forma estática (esto es, fusionando la biblioteca dentro del binario), esto no solucionaría el problema de que crear un buen DEB o un buen RPM es difícil y que exige tener conocimientos para, al menos, dos formatos diferentes.
 
El diagnóstico es muy certero. Lo que es más discutible es la solución que él propone, que viene a ser algo como lo que hace hoy en día Android, pero algo mejor: las distribuciones solo se deberían dedicar al mantenimiento del sistema base y, sobre ese sistema, utilizar algún mecanismo común a todas las distribuciones para instalar aplicaciones desde un único formato de paquetes e intentar utilizar al máximo las bibliotecas estáticas. De esta manera, defiende Torvalds, todo el mundo podría utilizar la última versión de las aplicaciones sin tener que hacer cosas extrañas con la configuración del sistema o miedo a que una nueva versión de un paquete no pueda funcionar en la distribución porque no es compatible con la biblioteca dinámica que está disponible en los repositorios.


La solución tal y como la plantea Torvalds tiene un problema grande: exigiría por parte de todas las distribuciones ser muy cuidadosas al distinguir exactamente qué es parte del sistema base y qué no. Pongamos por ejemplo una biblioteca como GnuTLS que no es crítica para el funcionamiento del sistema en sí mismo, pero sí es fundamental que se mantenga actualizada para cerrar posibles vulnerabilidades. Si decidimos que es parte del sistema base, entonces habrá que obligar a los desarrolladores a que sus programas no incorporen de forma estática esta biblioteca (una biblioteca estática no se actualiza hasta que se actualice el programa que la incluye, porque está integrada dentro de este), pero si otra distribución decide que GnuTLS no debe ser parte del sistema base, si no que debe ser incorporada en cada programa, el proyecto en cuestión, para poder hacer un único paquete que funcione en ambos casos, tendrá que incrustar la biblioteca de forma estática, con el evidente riesgo de seguridad que puede significar eso.

Existen otras razones contra el uso de bibliotecas estáticas, además. Una de las razones de por qué Windows utiliza peor la memoria que los sistemas Linux es justamente porque los ejecutables tienden a utilizar bibliotecas estáticas para simplificar la distribución. En cuanto se ejecutan dos programas que incrustan estáticamente la misma biblioteca, el resultado es que en la memoria se estarán guardando dos copias del mismo código y mientras más popular sea la biblioteca, más probabilidades hay de que esto suceda. En un sistema Linux, en cambio, la mayoría de los programas están vinculados dinámicamente a sus bibliotecas (es decir, la biblioteca es un archivo distinto al cual accede el programa; son los archivos .so en un sistema Linux). Esto quiere decir que el código de la biblioteca se carga una sola vez en memoria, de manera que si otro programa también la necesita, utilizará la misma versión que aquel que la cargó por primera vez. Otras ventajas se refieren a la modularidad, al hecho de que los ejecutables son menos pesados (recordemos que las distribuciones utilizan repositorios y reducir el ancho de banda puede ser importante), entre otras.

En mi opinión, y es una de las razones de por qué es mi distribución de cabecera, es que, en mi opinión, la solución más equilibrada es la de Arch, por curioso que pueda parecer, dada su fama de distribución "peligrosa". Sin embargo, si Arch es un poco difícil de manejar no es tanto por su forma de distribuir los paquetes, sino más bien por otras razones como por ejemplo el hecho de que su instalación base es extremadamente minimalista y es el usuario el que tiene que construir su sistema desde esa base. El único factor que sí puede ser desestabilizante, y al cual me referiré más abajo, es el hecho de que Arch busca actualizar los paquetes esenciales de la misma forma que los que no lo son y eso, a veces, produce problemas que se suelen avisar por las listas de correo y la página oficial de la distribución.

La creación de un paquete en Arch está mediada a través de un script bastante sencillo, llamado PKGBUILD, que determina desde dónde descargar las fuentes, cómo compilarlas y cómo empaquetarlas. El truco consiste en que la fuente se descarga directamente desde el repositorio del proyecto y no desde una copia de un repositorio de fuentes como en el caso de la mayoría de distribuciones (incluso Debian "inestable", en las cuales el código fuente se incorpora en la distribución e inicia su periplo de pruebas hasta que se libera la siguiente versión del sistema operativo.

Ahora bien, ese mecanismo funciona a la perfección cuando se permite a los usuarios marcar cuándo un paquete está desactualizado, como de hecho hace Arch Linux en su interfaz web de paquetes. Al marcarse de esta manera, el sistema le avisa al mantenedor del paquete de que debe modificar el PKGBUILD y eso es sumamente rápido: salvo casos extraños en los que un proyecto decida cambiar ubicaciones de instalación o forma de compilar, una vez creado el PKGBUILD para un proyecto, tan solo se trata de cambiar el número de versión al de la última versión y ejecutar makepkg para que se descarguen las últimas fuentes, se compile el código y se cree el paquete en formato TAR con compresión xz.

Hay un segundo pilar de este sistema: el Repositorio de Usuarios de Arch o AUR, por sus siglas en inglés. Si bien la distribución no considera AUR como parte oficial de los repositorios, la verdad es que no se puede concebir Arch sin AUR. Este repositorio permite que cualquiera pueda subir un PKGBUILD para lo que sea, incluidos los creadores de proyectos que quieran ver su aplicación disponible en Arch.

Estas dos vertientes acercan la distribución al ritmo de los desarrolladores, tal y como quiere Torvalds, pero sin dejar de lado las obvias ventajas de un sistema de distribuciones tal y como lo tenemos hoy en día. La razón de por qué las distribuciones Linux funcionan tan bien es justamente porque hay un control del usuario sobre qué es seguro instalar o qué está probado que funciona y qué no, por el aval que significa un repositorio oficial (en el caso de AUR cada paquete es fácilmente auditable, pero eso es tema para otro día).

Claro, no faltará quien diga que Arch no es una distribución para novatos. No, no lo es, pero ahí está Antergos, que simplifica bastante la instalación y configuración sin cometer el error de Manjaro de intentar un modelo híbrido que pasa por sus propios repositorios. La fama de inestable que tiene Arch es totalmente falsa: se compone de paquetes estables, por muy nuevos que sean. Y lo mismo vale para KaOS, que sigue una filosofía similar a Arch/Antergos, aunque no sea de la familia (usa pacman, pero OpenSUSE usa RPM y no tiene nada que ver con Fedora). Evidentemente, es una distribución Linux y, si uno quiere, uno puede desestabilizarla todo lo que uno quiera, pero eso no solo ocurre en esta distribución en concreto, sino en cualquier otra. Sin mucho esfuerzo, uno puede destrozar un sistema basado en Debian "estable" sin ningún problema.

Quizás lo interesante sería intentar una especie de modelo Arch más "calmado" donde los paquetes que en Arch se encuentran en el repositorio core (los elementos más importantes) pasen un tiempo más largo de prueba, ignorando nuevas versiones si cabe (en Arch los paquetes de core deben pasar por un repositorio llamado testing, pero si saliera justo una nueva versión mientras se prueba, esta ha de reemplazar la que estuviera en testing en ese momento). Eso implicaría, simplemente, no permitir cambiar el número de versión del PKGBUILD hasta que se decida soportar una nueva versión de un componente esencial y guardar solo el código fuente de esos paquetes, que no son más que 370 (contando cada para 32 y 64 bits). Para actualizaciones que sean exclusivamente de seguridad se usarían parches y algún sistema de notificación diferente, al menos para esos paquetes esenciales (en Arch no tiene sentido distinguirlas, pero en una distribución como la que propongo sí para evitar el "Efecto Manjaro"). El resto puede funcionar exactamente como en Arch: apenas alguien notificara que hay una nueva versión de una aplicación, el responsable actualizaría el script y ya está. Y por supuesto, se habilitaría un repositorio de usuarios al estilo AUR para dotar de más flexibilidad a la distribución, aunque no sea una parte oficial de la misma.

Con un modelo así, se puede evitar el tener que estar compilando las aplicaciones estáticamente y los proyectos, simplemente, tendrían que subir su código fuente sin tener que preocuparse en absoluto del empaquetado. Los usuarios gozarían de la ventaja de poder tener las aplicaciones actualizadas y de poder contribuir a la comunidad a través del repositorio de usuarios, pero con la garantía de que los componentes más esenciales no se moverán tanto como para provocar problemas. Creo que es una idea que podría funcionar bastante bien y que respetaría un poco más la historia de las distribuciones Linux que la solución propuesta por Torvalds.

Por último, por favor, no dejéis de ver el vídeo de Linus Torvalds en la DebConf14. Siempre es un placer escucharle, aunque sea en un vídeo, porque, sin duda, es una de las personas más interesantes en el mundo de la informática hoy en día. Pensad que antiguamente era imposible poder tener acceso a una charla así si no era presenciándola, así que aprovechad.


   
0
0
0
0No comments yet