¿Está roto el sistema de distribución de software?

He leído un par de comentarios en el foro de Ubuntu México de @chilicuil, quién evidentemente posee excelentes conocimientos técnicos; en ellos sostiene que: “El sistema de distribución de software está roto”, obviamente hablando de las distribuciones GNU / Linux.

Se refiere por supuesto al hecho que es prácticamente imposible que un paquete que puede ser instalado en una distribución dada, pueda ser traspasado a otra, incluso a una versión distinta de la misma, con sencillez y transparencia.

¿Entonces cuál es el problema?

Actualmente cualquier distribución se construye seleccionando los programas (y las versiones específicas de cada uno de ellos) que la integran, comenzando por los más básicos: El Kernel Linux y la librería madre libc.

A partir de esta elección se van agregando los que tienen el siguiente nivel en la jerarquía: Servidores y demonios. En este punto se incluyen el gestor del sistema (systemd, o initV o UpStart o lo que se decida), el servidor dns y otras muchas cosas que son “las tripas” del sistema operativo.

Luego se seleccionan las cosas que le permiten trabajar al usuario, aunque no las vea, luego el escritorio y sus utilerías y por último los programas de usuario (Navegador, Suite de Oficina, etc).

Esto que parece tan obvio, en realidad es el principio de lo que podría entenderse como el problema. Cada vez que se elige un programa (versión incluida) se está fijando en ese nivel una forma de comportamiento, que debe primero ajustarse a lo que proporciona el nivel superior y enseguida fija los recursos con los que pueden contar los programas del siguiente nivel.

Casi todo el software está construido en base a un programa “principal” y a un conjunto de programas auxiliares, las llamadas bibliotecas (común y erróneamente mencionadas como “librerías”). Y en las distribuciones la gran mayoría de estas se comparten entre muchos otros programas. Esto evita la necesidad de inventar la rueda mil veces.

Por supuesto esto permite que por una parte los programadores tengan una “vida más fácil” ya que pueden “usar” las bibliotecas de otro software y así se pueden dedicar por completo al desarrollo específico de su propio software. Pongámoslo así: Hay un software que tiene una biblioteca que permite sumar dos cantidades. Otro programa que necesite hacer sumas, no necesita volver a programar esto, simplemente “llama” a esa biblioteca y la usa. Esto por supuesto es un ejemplo muy simple y burdo pero ilustra.

Así una distribución GNU / Linux sin importar cuantos programas se le instalen, nunca ocupará tanto espacio como la referencia obvia de W$, donde cada programa tiene que crear desde cero sus propias bibliotecas ya que ni puede usar (por cuestiones legales) las de otro programa y por encima de todo, no tiene idea de que hacen, como lo hacen y como se usan las bibliotecas de otro software.

Pero como decía mi madre: “No se puede ser rico y guapo a la vez”. El sistema de bibliotecas compartidas tiene la desventaja de ser más estático. Cuando se crea una versión de un programa, se supone y se espera que las bibliotecas compartidas se comporten se cierta forma, reciban datos así y no asá, y entregue resultados de x manera, y por supuesto se llamen (tengan el nombre) en la forma esperada. Además se debe hacer la suposición que están colocadas en el lugar adecuado.

Pero como es natural, las bibliotecas van evolucionando con el tiempo, es decir que van cambiando; a eso se le llama una nueva versión. Como todo opera como una cascada, cada programa que usa una biblioteca debe con el tiempo adaptarse para usar la nueva versión de esta. Por esta razón las distribuciones “congelan” la paquetería en algún momento durante el desarrollo de cada nueva versión. Es muy difícil asegurar que todo el software que cambia continuamente en la cadena esté hablando (por decirlo así) el mismo lenguaje. Es evidente que mientras mayor sea el nivel de la biblioteca, mayor es la afectación de cualquier cambio. Por ejemplo: Una modificación seria a libc “pone de cabeza” a todos.

Otra situación que se comenta mucho menos es que durante los últimos años las distribuciones han estado continuamente cambiando la estructura de sus directorios. Es decir se ha estado cambiando el lugar donde se colocan las diferentes piezas de software que la constituyen. Y además ¡Cada distribución lo hace a su manera! Un ejemplo claro (y hasta dramático) ocurrió en Chakra hace poco.

En este punto entran en juego los personajes conocidos como empaquetadores. Estos se dedican a recolectar el software necesario, prueban si funciona con las versiones que usa la distribución. Si es software libre y es necesario modifican el código para que pueda trabajar (pasa frecuentemente con software abandonado por sus creadores originales, y que aún es necesario) y lo compilan para que cumpla tanto con las dependencias, es decir es software que toman de otro (aquí las mentadas bibliotecas compartidas) y crean el paquete que pone cada pieza en el directorio correspondiente.

Desde las distribuciones.

Los usuarios tenemos la idea que las distribuciones son simplemente una colección de software, pero desde el punto de vista de la propia distribución, no es exacto. Cada distribución se considera a sí misma como un sistema operativo independiente (y en efecto lo son) y sus únicas similitudes radican en el uso del kernel, la filosofía de software libre y algunas menudencias más.

Cada distribución se esmera en conseguir las partes necesarias, cuando no existen las crea, y además lo hace todo usando el sistema de distribución de software que considera más adecuado. Así vemos que Debian y sus derivadas usan los paquetes DEB y como gestor a apt, en tanto que Mageia usa paquetes RPM y a urpmi como gestor. Cada distribución lo hace a su manera.

Las distribuciones vistas desde dentro consideran que hacen todo el trabajo necesario (y posible de acuerdo a los recursos con que cuentan) para ofertar a los usuarios el conjunto completo de lo que a su real parecer y entender se necesita para trabajar. En otras palabras: Esto es lo que hay, y si no te satisface, no la uses.

En resumen, para las distros el sistema de distribución de software, no está roto; es un asunto de estabilidad y de falta de recursos, y como los recursos nunca pueden superar a las necesidades, lo único que se puede hacer es avanzar por el camino.

¿Y los programadores?

Cuando se hace un programa, y especialmente uno de software libre, lo menos que su creador espera es que se use en alguna parte, muchas veces no hablamos de un solo individuo, hay casos en que se trata de una comunidad completa. Pero para que el producto de su trabajo llegue a una distribución se necesitan muchas cosas. Además de cumplir con todo lo explicado anteriormente, se debe contar con la buena voluntad y tiempo de los empaquetadores, con un buen “timing”, es decir que el software esté listo y adecuadamente probado de modo que se ajuste a los tiempos de integración de las distros y por supuesto ajustarse al uso de las dependencias que ya ha marcado la distribución.

Por supuesto cada programador está en libertad de ofrecer paquetes para las distribuciones (y de hecho lo hacen al menos para algunas). Pero por Dios hay tantas, tan distintas entre sí, y con una variedad tan enorme de sistemas de distribución, que simplemente no pueden hacerlo para cubrir todos los casos posibles. A pesar de que a nivel binario el software es compatible con cualquier distribución, ya que todas se basan en Linux.

Los desarrolladores se quejan (y no sin razón) que en muchas ocasiones el fruto de su trabajo no llega a los usuarios. Pongamos por ejemplo a Debian. Un usuario x de la versión 7 empezó y terminó con un Gnome 3.4. al pasar a Debian 8 se ha encontrado con un Gnome 3.14. Es decir ni por asomo vio nada menos que 4 versiones del DM del pie desnudo. Incluso el todo poderoso kernel Linux padece de esto.

Para empeorar las cosas, los empaquetadores pueden (y lo hacen) mutilar el producto de su trabajo, ya sea por razones de compatibilidad, de espacio, de licencias, de políticas internas, y no me gusta ser mal pensado, a veces simplemente porque sí. Recuerdo un par de ejemplos en Debian (y en consecuencia en todas sus derivadas): Handbrake y TORCS.

Para los programadores, el sistema de distribución de software está roto y necesita ser revisado a fondo; como todo cambio es necesariamente lento, deberían haber empezado hace años.

Nosotros los usuarios

La gran mayoría de nosotros terminamos por enterarnos de la aparición de nuevas versiones de programas. Es cierto que la inmensa mayoría nos resultan indiferentes, por ejemplo yo no me dedico a la producción de vídeo y ni siquiera tengo la más vaga idea de como se hace. De tal suerte que la presentación de una versión nueva de Cinelerra no pasa de ser un dato para mi anecdotario personal. Pero digamos que hoy aparece una versión nueva de Epoptes que incluya una función nueva que he estado deseando por años. Como en la escuela usamos un xBuntu LTS, y seguramente lo seguiremos haciendo al menos hasta que se presente una nueva LTS y además termine el ciclo escolar, habré de esperar hasta entonces (si hay suerte).

Y vienen las odiosas comparaciones: En los sistemas operativos cerrados no existe esta limitación. Una nueva versión se instala y trabaja punto. Si se obtiene gratis, se copia ilegalmente o se paga por ella es harina de otro costal. Y para mayor frustración pasa hasta con el software libre. GIMP, VLC, SMPlayer y muchos otros pueden ser instalados y actualizados versión a versión, y muchas veces (la mayoría) a lo largo de muchas de las versiones de los sistemas operativos cerrados.

Por supuesto tiene sus consecuencias, los sistemas se hacen lentos, la seguridad es prácticamente nula, muchas veces incluso se rompen y hay que volver a instalar todo y otras lindezas por el estilo.

Para los usuarios el sistema de distribución de software funciona mas o menos, podría ser mejor, pero no hay mucho que decir, al fin y al cabo es gratis.

¿El futuro?

El hecho simple es que hoy mas que nunca tenemos dos posiciones encontradas y de pronto no hay una solución sencilla. A lo largo del tiempo se han presentado varias “formas alternativas” de atacar esta situación. La primera interesante que recuerdo fue Klic, que pretendió ser un sistema universal de distribución de software. Que a pesar de lo bien que pueda sonar, termina por amenazar el propio sistema de distribuciones y su diferenciación. Klic feneció sin pena ni gloria.

Otra forma son los llamados paquetes portables, en resumidas cuentas es software autocontenido que ni siquiera necesita instalarse, simplemente se ejecuta. Con muchas limitaciones por su propia naturaleza, por encima de todo, puede terminar convirtiéndose en un riesgo para la seguridad, bastión de las distribuciones; aún existe pero su uso es mínimo.

La forma más usual hoy en día es usar repositorios de terceros: AUR, KCP, PPA’s, etc. Pero nada mas hay que ver las advertencias (muchas veces fundadas) acerca de su uso. La mayoría tienen un gran letrero: “Cuidado con el perro”, y si en realidad no se tiene mucha idea de lo que se hace y no se lee bastante, terminamos mordidos.

Hoy en día estamos en presencia del nacimiento de una nueva forma (pero no de una única manera) de cambiar el status quo: La distribución de paquetes que se ejecuten en mini máquinas virtuales. Click de Ubuntu es el sistema que ya tiene nombre, pero desde luego ni es el único, ni es la única distribución que está considerando una solución similar.

Esta nueva forma lo que implica es cambiar en forma radical el sistema de dependencias. Así una distribución podría mantener su propio Core de diseño y funcionamiento y usar software que al ser instalado en estas mini MV estaría aislado del resto del sistema. La ventaja es que al no estar comprometida la seguridad, cada una de estas partes podría actualizarse a cualquier ritmo, sin importar que tan desigual fuera. Podría también quitarse y ponerse software sin que el resto del sistema se viera afectado. Hoy en día instalar es sencillo, quitar puede convertirse en una pesadilla que te deje en una situación tal que resulte más económico volver a instalar todo el sistema operativo antes que tratar de arreglarlo. Este camino es tan revolucionario que incluso M$ ha manifestado su interés en su implementación (otra cosa es que lo haga).

También en teoría las distros ganarían en estabilidad ya que el Core podría quedar completamente aislado de cualquier biblioteca o programa que pueda afectar su desempeño. Permanecería intacto a no ser por las propias actualizaciones que se manden desde la distribución, que se supone no afectarán la estabilidad del todo.

Tiene su lado desagradable, al romper el sistema de bibliotecas compartidas, y con él de las dependencias, aumentará necesariamente el espació requerido para el software, puesto que cada pieza de programación seguramente incluirá en su mini VM las librerías que necesite en las versiones que use, obteniendo como resultado la tan temida duplicación de recursos.

Claro que estamos en la segunda década del siglo XXI, PC con cantidades ingentes de RAM, Teras y más Teras de espacio en los discos duros, que además serán de estado solido con enormes velocidades de acceso y que están disponibles para su uso el día de hoy, con una caída impresionante en los precios. Este sistema de mini VM seguramente requerirá de mayores recursos del procesador, pero desde hace unos años el hardware (en términos generales) es muy superior al software.

“Ventajas” adicionales: Cada distribución podrá seguir siendo diferente a las demás. Cada una podrá seguir eligiendo en que forma implementa sus mini MV, que software usa para ello y los mecanismos de control y seguridad que las regirán. Se reducirá el ancho de banda necesario para las actualizaciones ya que podrán hacerse del tipo delta, es decir solo se actualizarían las partes que cambien y no todo el paquete

En teoría la seguridad debe seguir al menos en el mismo nivel actual. Los que impulsan este modelo sostienen que se incrementará ya que cada paquete se ejecuta en un espacio independiente a todos los demás. Yo con humildad tengo mis dudas al respecto porque de cualquier modo estos seguirán teniendo que comunicarse entre si, aunque sea a través de procesos intermedios. Dicho de otra manera deberá ser posible al menos copiar y pegar entre distintos programas. ¿O no?

Los programadores tendrán la esperanza de que sus obras estén a la disposición de los usuarios mucho más rápido, pero seguirán dependiendo de los empaquetadores y de estos nunca hay suficientes, ya no hablemos de sus habilidades.

De este modo todas las distribuciones que adopten este sistema se transformarán de hecho en Rolling Release, lo que las hará diferentes será una cuestión de grado. De la misma forma en que Arch es extrema y PCLinuxOS se toma los cambios con más calma.

Y al final los usuarios tal vez encontremos alguna ventajas en todo ello. Lamento eso sí que muy probablemente tengamos mas usuarios de esos que no se toman la molestia de siquiera intentar aprender algo nuevo, cada vez más usuarios del tipo Aceptar, Aceptar, Aceptar…

¿Está roto el sistema de distribución de software? Todo depende de quien responda, recuérdese que: Nada es verdad y nada es mentira, todo depende del color del cristal con que se mira.

Anuncios

3 pensamientos en “¿Está roto el sistema de distribución de software?

  1. sería una marivalla que se unieran entodo en fin de crear un “instalador universal” que funcione en todas las distros, es interesante ver como se desarrolla esto, ayudaría mucho a que haya mas variedad en linux y no estar perdiendo tiempo en hacer paquetes para suse, fedora, arch, debian, etc

    Me gusta

    • Hola:

      Probablemente lo sería. Pero más allá de la fantasía que al menos las distribuciones mayores se pusieran de acuerdo en “cualquier cosa”. Las preguntas que me vienen a la mente son: ¿Cuál es entonces el propósito de tantas distribuciones?
      ¿Quién sería el encargado de dar mantenimiento al software de empaquetado y distribución?
      ¿Valdría la pena que todas las distros siguieran teniendo sus propios repositorios, y si no fuera así quién se sería el encargado de tenerlos y operarlos?
      ¿Estarían siquiera dispuestas a considerarlo las distros que son mantenidas, patrocinadas o incluso comercializadas por corporaciones con intereses no meramente altruistas?

      Me gusta

  2. Pingback: Snap: vientos de cambio | El Gato con Linux

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s