Snap: vientos de cambio

Parece que regresan los buenos tiempos para Ubuntu y sus usuarios; después del transcurrir de muchas versiones en las que realmente no pasó gran cosa, con la llegada de la versión LTS de este año (16.04 Xenial Xerus) asoman características que vuelven a ilusionar a todos los seguidores de la distribución sudafricana.

Hemos visto como se ha cambiado el Centro de Software, se han modificado las posibilidades de Unity, incluso hemos sido testigos de la irrupción de parte de Ubuntu dentro del propio W$ 10. Y esta semana se anunció en forma bastante formal que será posible usar los paquetes Snap en la LTS en algún punto de este mismo año (presumiblemente en el otoño).

He revisado y comparado las distribuciones Rolling Release buscando un equilibrio entre la estabilidad y la modernidad y por desgracia, tarde que temprano me he encontrado con situaciones en las que sencillamente no puedo recomendar con confianza una distro RR a un usuario medio. En definitiva su público objetivo son los usuarios mas avanzados.

Del mismo modo he navegado entre las distribuciones de ciclo fijo y al final siempre encuentro los mismos problemas: Se hacen viejas muy pronto ya que no permiten instalar software reciente con sencillez, y por encima de todo tienen el problema de que deben ser sustituidas por una versión más reciente con una frecuencia intolerable para el común de los mortales.

Las Semi Rolling, especialmente las que usan una base LTS se han mostrado como las opciones más razonables, queda sin embargo a criterio de cada distro la selección de que partes de su paquetería son las que se actualizan en forma continua y cuales son las que permanecen estáticas. Obviamente al final no se obtiene un producto que satisfaga, ya no digamos a todos, ni siquiera a un porcentaje mayoritario de los usuarios. Dicho de otra forma la elección de la paquetería Rolling se hace una por una y no por categorías.

En el artículo ¿Está roto el sistema de distribución de software? Intenté explicar (espero que con sencillez) cuál es la problemática que se tiene en este apartado. Ahí mismo ya escribía de un proyecto de Ubuntu para cambiar esta situación. Hoy está casi al alcance de la mano.

Con una hasta ahora desconocida prudencia, Canonical – Ubuntu a hecho énfasis en que este nuevo sistema de paquetes estará disponible en paralelo a los tradicionales paquetes de formato DEB, y que estos seguirán estando disponibles incluso en versiones posteriores de Ubuntu. Esto sin duda motivado porque el líder de Debian ya había mostrado “preocupación” porque la aparición de este nuevo sistema de empaquetado podría traer descuido a los paquetes DEB que salen de Debian.

El formato de los paquetes es un tema espinoso entre las distribuciones y sus programadores e incluso entre algunos usuarios geek. De los primeros lo entiendo, a final de cuentas su trabajo es empaquetar para distribuir el software. A mí por muy geek que sea, me parece un asunto de la mayor intrascendencia; al final solamente me importan dos cosas: que los programas que necesito estén disponibles y que sirvan. Durante más de 10 años he usado casi todos los sistemas de paquetes y hablando estrictamente como usuario no he encontrado diferencias que valga mencionar a este nivel. En cambio mi elección de distribución desde siempre ha estado condicionada en primer lugar por que se pueda usar en mi hardware, después por la disponibilidad de ciertas aplicaciones, y por las versiones de las mismas que ofrecen.

Snap es lo que llegará, pero. ¿Qué son los paquetes Snap?

En pocas palabras los paquetes Snap son aplicaciones completas (incluyendo sus dependencias) en un solo paquete. Explicado en cristiano: Un paquete Snap ignorará la cadena de dependencias de la distribución en la que se instale. Y deberá incluir sus propias dependencias, esto no necesariamente quiere decir que deben ser partes más recientes, puede ocurrir al contrario.

¿Cuál es el beneficio de los paquetes Snap?

Hasta el día de hoy todo programa que se instale en una distribución, necesariamente debe sujetarse a lo que la propia distribución pone a disposición del programador de aplicaciones. Esto afecta por igual a todo tipo de distros, por ejemplo es muy común que en una distro RR algún paquete instalado “por fuera” (por ejemplo desde AUR en Arch y derivadas o desde el KCP de KaOS) quede inútil con alguna actualización y habrá que esperar a que se genere un nuevo paquete externo (si es que ocurre) para el programa vuelva ser operable.

En el caso de las distros de ciclo fijo pueden agregarse repositorios adicionales que incluyen las dependencias adicionales necesarias, pero en muchos casos éstas sustituyen a las que tiene “out of de box” la propia distro y puede en mayor o menor medida generar inestabilidades o puede romper por completo la distribución; incluso es posible que otros programas dejen de trabajar correctamente. Esto es lo que se hace por ejemplo con los PPA de Ubuntu, o Pakman de OpenSuSe. Por regla general: la cantidad de programas externos instalados es inversamente proporcional a la estabilidad de la distro.

Los paquetes Snap no cambian nada de la distribución donde se instalan, la dejan en la forma en que fue pensada por sus mantenedores, que por regla general es excelente. Así la primera gran ventaja es que se pueden instalar sin temor de causar caos en el sistema operativo.

Como los paquetes Snap no modifican a la distribución, también pueden ser eliminados sin riesgo de que en el proceso “nos carguemos” algo de vital importancia, que es uno de los problemas del sistema de paquetes actual, donde a veces resulta más económico volver a instalar la distro completa antes que arreglarla.

Del mismo modo, usando paquetes Snap es posible instalar software cuyos requisitos difieran de la versión que se encuentra instalada o disponible en los repositorios oficiales, es decir se pueden instalar programas de versión más reciente, “ir a la última” situación a veces deseable, o incluso se pueden revivir algunos muertos que han sido abandonados por la propia distribución “por obsoletos” y aunque no se crea suele ocurrir.

Ya que los paquetes Snap son estáticos para sí mismos es muy posible que los programadores de aplicaciones, incluso empresas de software se interesen ahora sí en crear y/o transportar sus creaciones a los sistemas operativos Linux de escritorio. Uno de los mayores obstáculos con los que se topan los programadores es que tienen forzosamente que estar modificando su software para hacerlo compatible con este o con aquel cambio en las distros, especialmente con los de cada versión de la propia distro. Esto por supuesto sin contar con que además deben hacerlo no solamente para una distro, necesitan hacerlo para varias, ya que cada distro suele estar construida con versiones diferentes de cada una de las piezas que la componen. En un producto comercial el principal trabajo de los programadores es corregir bugs e implementar nuevas características; y puedo asegurar que con eso ya tienen bastante.

Es por esto que muchos de los programas que no se encuentran en los repositorios y para los cuales aún hay que recurrir al viejo método de descargar desde un sitio web, solamente tienen paquetes para pocas distribuciones (de compilar las fuentes mejor ni hablar, eso no lo hace el usuario medio), por lo general para la LTS de Ubuntu y algún genérico RPM, que en los foros de este tipo de distros invariablemente desaconsejan ya que las distros RPM suelen diferir mucho más entre ellas que las que usan DEB.

De hecho según se anunció, este es el primer objetivo de los paquetes Snap: los programas de pago que se pueden obtener en Ubuntu, recuérdese que Ubuntu es prácticamente la única distribución de escritorio que ofrece esta posibilidad, aunque también hay distros para servidores que cuentan con este servicio.

Los paquetes Snap mejoran la seguridad. En primer lugar deben ser firmados por sus creadores, es decir no cualquier porquería debería poder colarse a los repositorios Snap. En segundo lugar se ejecutan en forma aislada al resto del sistema y se atienen a AppArmor en forma obligada de tal suerte que es a nivel del kernel donde se vigila y protege a todo el sistema operativo de comportamientos indeseables de los programas que se ejecuten bajo Snap.

Otra medida de seguridad de la que poco se ha hablado y que considero de la mayor importancia es que estos paquetes se van a instalar en donde se debe, es decir dentro del espacio de la raíz y no dentro del espacio del usuario (/home). Entonces solamente un usuario con privilegios administrativos podrá instalarlos, y por ello todos los usuarios registrados podrán accederlos como cualquier otro programa que se instale usando el sistema de paquetes que se use preferentemente.

Por más que las distribuciones no estén hablando de ello (al menos no para el gran público) es una realidad que muchos programadores se están hartando del caótico sistema de paquetes y ya hay a disposición de los usuarios muchos programas autocontenidos al estilo Snap, pero sin los beneficios de la seguridad que ofrece un sistema de repositorios. Quizá el mayor nicho actual de este tipo de programas son los que sirven para contenido multimedia tipo streaming y que la mayoría de las distribuciones no quieren ni ver porque la legalidad de sus servicios (y la estabilidad y durabilidad) está en entredicho; me refiero por supuesto programas tipo PocornTime y similares. Dado el éxito que están teniendo no me extrañaría que otro tipo de programas sigan pronto su ejemplo.

Pero no todo puede ser ganancia. ¿Qué no es bueno en los paquetes Snap?

En primer lugar el tamaño. Un paquete autocontenido puede llegar a ocupar mucho más espacio del disco duro que uno que se atenga al sistema tradicional de dependencias. Si se instalan pocos paquetes Snap no debería ser un problema ya que cualquier distribución ocupa para el sistema mucho (realmente mucho) menos espacio que un sistema operativo como W$. Pero si se instalan suficientes un usuario podría encontrarse con sencillez con que el espacio que ha dedicado a su partición / (raíz) es insuficiente. De hecho es muy probable que en la medida que vayan apareciendo paquetes Snap (y no tengo duda de que lo harán) será necesario redefinir los tradicionales tamaños de particiones que se dedican a una instalación de Ubuntu.

Se gastará más ancho de banda en la instalación y actualización de los paquetes Snap. El sistema Snap contempla actualizaciones de tipo Delta, esto quiere decir que solamente se actualizarán los archivos que hayan sufrido alguna modificación y no la totalidad del paquete, con esto se pretende disminuir el consumo en este rubro, pero dependerá del contenido de cada paquete para ver como realmente esto puede ser de ayuda.

Los paquetes Snap pueden aumentar en forma explosiva el gasto de memoria y de otros recursos de la PC. Supongamos el siguiente escenario: Se instalan 3 paquetes Snap que usan tres diferentes versiones de la biblioteca “A”, llamémoslas A.1 A.2 y A.3. Además el propio sistema operativo tiene en uso su propia versión de la misma biblioteca a la que llamaremos A.0.

Bajo el sistema actual solamente habría una instancia de “A” (A.0) usando los recursos del sistema y todos los programas harían uso de ella. Bajo el modelo Snap cuando se ejecutasen en forma simultanea los tres paquetes Snap, serían 4 instancias de “A” las que estarían usado los recursos del PC (A.0, A.1, A.2 y A.3) cuadruplicando el gasto de recursos del sistema completo. Si tienes Google Chrome/Chromium instalado (aunque por diferentes razones) puedes ver el impacto de esto en tu sistema. Multiplica esto por la totalidad de partes antes compartidas ahora independientes y te darás una mejor idea. A la larga esto podría causar un aumento en las requisitos mínimos y recomendados para una distro, ya que de otra forma todo el sistema operativo podría resultar ralentizado.

No se ha dicho nada en claro pero todo parece indicar que además de que lo lógico sería tener repositorios separados para los Snap (más trabajo para la distro, más espacio de almacenamiento y ancho de banda), también debería haber un método diferente para el mantenimiento de estos paquetes (instalación, actualización y remoción) e incluso Centros de Software por separado, muy al estilo de lo que tiene hoy en día W$ 10 donde las actualizaciones del sistema se hacen por un lado y las de aplicaciones por otro en la W$ Store. Esto no sería extraño para los que lleguen de W$ pero sí para los usuarios actuales. Además con seguridad duplicaría el habitual proceso de actualización de los repositorios que muchas distros hacen en forma automática nada más al iniciar la sesión.

Visto lo bueno y lo no tanto. ¿Qué es lo feo de Snap?

En primerísimo lugar es el que ha sido Canonical – Ubuntu quien lo ha hecho. Es en definitiva una medida valiente y a mi parecer necesaria. Pero mi experiencia me dice que pocas o tal vez ninguna otra distro vaya a implementarlo simplemente por este hecho. Así de absurdo como suena. Incluso si Snap tiene éxito como todo parece indicar, ya puedo ver como se crean métodos similares para otras distros y volveremos de nuevo a la absurda división, ahora decuplicada por el número de sistemas alternativos que surjan. Los pobres creadores de aplicaciones ahora tendrán muchos más motivos (tantos como sistemas distintos) para literalmente “mandar al demonio” a las distribuciones. Esto será malo para el grueso del mundo Linux y de paso seguramente afianzará a Ubuntu como el sistema operativo alternativo a W$.

Los puristas del “Linux way” con seguridad ya están poniendo el grito en el cielo porque Snap sencillamente rompe con el sistema tradicional; plantea una revisión a fondo del sistema de dependencias y por encima de todo pone a prueba el rol del empaquetador de programas. Ningún cambio es fácil y este no tiene porque serlo. Ya puedo oír las voces de los que lo llamarán “La windolización de Linux”.

Si como en un párrafo anterior suponía comienzan a llegar por la vía de Snap aplicaciones comerciales y de código cerrado. Los ultras del software libre se abalanzarán sobre la totalidad del método y lo atacarán como un todo. Nuevamente el que sea Ubuntu su impulsor será un clavo ardiente ya que es bien sabido el poco afecto que se le tiene por ser permisivo al software propietario.

Yo creo con firmeza en el software libre, pero con igual fuerza creo en la libertad que tiene cada quien para elegir. Y desgraciadamente la libertad humana siempre está acotada (como bien recuerdo de mis muy lejanas clases de filosofía).

Hace poco escribí que prefería la existencia de 1000 distribuciones a una o a unas pocas porqué así se le daba el máximo de oportunidades a toda clase de proyectos. De igual forma estoy convencido que de la misma forma en que la totalidad de las distros están de acuerdo en que su kernel es Linux, y que la mayoría han convertido a systemd en su control de inicio, pueden ponerse de acuerdo en otro método que es esencialmente útil para todos. De cualquier modo todas las distribuciones estarán en control de lo que contengan sus propios repositorios Snap, y nunca podrán controlar lo que cada usuario en forma independiente haga con su instalación particular del sistema operativo.

A nosotros los usuarios nos queda la oportunidad de hacer toda la presión posible, en las redes sociales, en los blogs, en los foros y en cualquier otro lugar a nuestro alcance y de nuestra preferencia para que si Snap resulta tan bueno como pinta, sea aceptado por el mayor número de distribuciones posibles.

¿Y a ti te gusta Snap?

Anuncios

6 pensamientos en “Snap: vientos de cambio

  1. Hola Gato, había comentado en tu entrada anterior que era mejor olvidarse de Xenial Xerus, por lo irrelevante de sus novedades. Claro que, como de costumbre, me equivocaba. No había caído en la trascendencia de los archivos snap. Veo en ellos cosas muy buenas y otras que me suscitan dudas. Como bien apuntas, estas dudas tienen que ver con la seguridad y también con el consumo de recursos, que se dispararía irremediablemente. La ganancia vendría por el lado de los desarrolladores de aplicaciones, que seguro se mostrarán más proclives a programar para Ubuntu. Ahora mismo no sabría pronunciarme sobre qué prevalecería a largo plazo, si lo bueno o lo malo…

    Sin embargo, desde mi desconocimiento, me planteo si el sistema de las PPAs no podría modernizarse y así suplir de ese modo el precoz envejecimiento de las aplicaciones. Me imagino un centro de software al uso, desde el que instalar las aplicaciones de los repositorios, complementado por una opción del tipo “Añadir PPA” o “Instalar versión actualizable”, con el correspondiente aviso de que ese programa es menos “seguro”. Si se aplicara el sistema de PPAs solo a las LTS los desarrolladores tampoco tendrían tanto lío. Digo yo.

    Gran artículo, amigo. Un saludo.

    Me gusta

    • Hola Iván:

      En efecto los paquetes Snap son desde el punto de vista de los usuarios de la versión para PC, el avance mas notable de Xenial. Desde luego para los desarrolladores es también un cambio muy notable al dejar de tener la necesidad expresa de contar con la buena voluntad y tiempo de los empaquetadores.

      Por desgracia los PPA tienen límites muy claros que de hecho no han resuelto el problema, solamente han sido un paliativo y hasta cierto punto.

      Tomemos por ejemplo un programa muy sencillo, pero de esos que causan mucho interés: Corebird, un cliente de Twitter que en su última versión fue muy promocionado. Sin embargo su principal dependencia es Gnome 3.18 o posterior. Si se tratara de incluir esta dependencia en la LTS actual 14.04 simplemente no se podría porque no hay forma de poner esa versión de Gnome sin romper por completo con toda la distro que está basada en la 3.10.

      Todos los PPA tienen de hecho un gran letrero de Cuidado con el Perro porque además que están limitados “hacia adelante” de muchas formas, a cada empaquetador le resultaría imposible saber que otras dependencias han sido sustituidas por otros PPA que se hayan instalado.

      Los gestores de paquetes (apt en este caso) siempre actualizan a la última versión y no hay una forma de crear y sobre todo mantener un sistema de dependencias que pueda contemplar todas estas posibilidades. Imagina que cada PPA que se creara tendría que pasar por este proceso de revisión.

      Además que se tomaría mucho tiempo, al final no habría ninguna garantía que un nuevo PPA viniera a replantear todo.

      Los paquetes no tienen la misma importancia para usuarios diferentes. A mí nunca se me ha ocurrido instalar Cinellera y mucho menos por un PPA, pero supongamos que lo hiciera y eso dañara digamos la parte que me permite incrustar vídeos en LibreOffie; en mi caso sería un desastre. Pero a un usuario profesional tal vez no le importaría porque su negocio está con Cinellera y nunca hace presentaciones.

      Además como no es posible tocar el Core de las distros (sin romperlas) los PPA se tienen que limitar a los alcances máximos de cada distro.

      Los Snap no tienen ninguno de esos problemas. No son perfectos, pero solucionan una de las quejas más sentidas de los programadores y también de los usuarios.

      Le gusta a 1 persona

      • Gracias, Gato, por tus aclaraciones. Hay bastante consenso entre los expertos en la necesidad de modernizar el sistema de paquetes en GNU/Linux. Por fin voy entendiendo que el sistema actual es más bien un obstáculo para el crecimiento de este OS. Admito que mis prejuicios venían precisamente porque el cambio viene impulsado por Canonical, a quienes otorgo intereses demasiado comerciales. Lo que está claro es que sin Ubuntu GNU/Linux no hubiera alcanzado la popularidad que goza en la actualidad, y me temo que si los snap triunfan asistiremos a un lento declive de muchas distribuciones si no se suman al cambio, aunque sea con un sistema de paquetes similar.

        Parece que también Red Hat está desarrollando un sistema de paquetes autocontenido, por lo que el cambio parece inevitable. Lamentar que, una vez más, no haya consenso en implantar un formato universal.

        En fin, me pregunto qué opinión les merecerá todo esto a la comunidad de Debian.

        Saludos

        Me gusta

  2. Pingback: La escalera de la confianza | 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