policiatux

Mientras en Tierras de Canonical lanzaban su última arma para conquistar el territorio linuxero (aka la paquetería Snap); los poderosos desarrolladores de Gnome contraatacaban con toda su artillería puesta en su contraarma, la paquetería Flatpak. Así contarán los cronistas como empezaron las segundas guerras por el control de la paquetería en GNU/Linux.

Hace unos días, Ubuntu presentaba la novedad de la paquetería Snap para distintas distros (Arch, Fedora y alguna otra; además de Ubuntu) y anteayer se presentaba también Flatpak por parte de los desarrolladores de Gnome, con disponibilidad en Fedora, Arch Linux y Ubuntu, entre otras. Estos dos desarrollos tienen una historia paralela, en la que intentan resolver dos problemas por todos conocidos, el uso de programas actualizados en distros LTS y la escasez de software third-party, es decir, fundamentalmente privativo.

Ambos problemas, curiosamente, se producen por la misma causa, la gestión de dependencias. Como todos sabemos (o deberíamos, y no estoy mirando a nadie) en GNU/Linux, las bibliotecas del sistema son todas compartidas por todos los programas que lo necesiten. Esto implica que todos los programas disponibles tienen que adecuarse a trabajar con el mismo estado de las bibliotecas. Ventajas de este sistema, sencillez de mantenimiento por parte de los creadores y mantenedores de la distribución y menor consumo de recursos. Desventajas, fundamentalmente que la habitual descoordinación entre creadores de bibliotecas y programadores de aplicaciones, y de estes con los mantenedores, acaba haciendo que muchos programas tengan dependencias obsoletas o demasiado actualizadas. Un ejemplo clásico, actualizar Fedora o Ubuntu y perder un programa porque tal o cual biblioteca ya no se mantiene por demasiado obsoleta.

Si este problema se encuentra en los propios programas de Linux, ya no hablemos de si queremos que funcione un programa de un tercero privativo. En este caso, los desarrolladores suelen ser aún más perezosos, empleando bibliotecas normalmente obsoletas. Como en MacOS y en Windows la instalación descarga sus propias librerías, acostumbrarlos ahora a un sistema en el que tienen que estar constantemente parcheando parece exigirles mucho. Y bueno, somos nosotros, en teoría, los que queremos su software en nuestra plataforma y no al revés, así que facilitarles la vida podría ser un camino a ver a Adobe, Autodesk u otras desarrollando para GNU/Linux.

Y con esta y otras ideas (las posibilidades modernas de sandboxing que proporciona el núcleo y los futuros Wayland y Mir), han sido varios los que han desarrollado sistemas de paquetería que permiten una instalación conjunta de las bibliotecas que necesita cada programa. Y tal y como Wayland y Mir son semejantes pero distintos, las soluciones de Flatpak y Snap también lo son.

Hay varias diferencias técnicas, Flatpak deduplica las bibliotecas, lo que hace que si ya las tienes instaladas en el equipo no se instalen dos veces y el proceso de sandboxing es ligeramente distinto. Pero la fundamental es que depende una de Wayland y la otra de Mir. Y eso, junto los famosos CLA’s de Canonical que muchos desarrolladores (y con razón) se niegan a firmar, el hecho que Canonical se reserva la tienda (y por tanto la distribuición de software) y que de momento no está implementada como software libre, frena su futuro crecimiento en otras distros.

¿Cuál es el escenario futuro? Pues Flatpak cuenta con buena parte de la comunidad (Gnome ya soporta instalaciones desde Gnome Software, y KDE va a ponerse con el soporte seguramente a partir de Plasma 5.7), con que el soporte de Wayland estará mucho más extendido que el de Mir entre las distros, y con que todo el software que liberan de momento es libre y reimplementable. En frente a eso, Ubuntu cuenta con mayor difusión y cuota de mercado (hoy en día, si quieres algo privativo, para Ubuntu lo hay seguro y para las demás distros ya veremos), lo cual puede decantar a muchos desarrolladores por los paquetes Snap.

Y al final, es lo que cuenta. Al fin y al cabo, es la historia de siempre. GNU/Linux es superior a Windows en muchas caracterísiticas, cuenta con muchísima gente detrás que desarrolla gracias a que es software libre y se puede retocar lo que se quiera. Pero el sistema de Microsoft tiene la cuota de mercado.

Por suerte, usar uno no excluye de otro sistema. Así que en el peor escenario posible (una competición feroz entre ambos formatos) simplemente los tendremos duplicados. Por lo menos podremos usar al sustituto de RPM junto al sustituto de DEB. Y ese es un gran avance desde las primeras guerras de la paquetería linuxera.

21
Deja una respuesta

avatar
21 Hilos de comentario
0 Respuestas de hilo
0 Seguidores
 
Comentario más reaccionado
El hilo de comentarios más caliente
4 Autores de comentarios
FiliprinoMiguel Mayol TurNoeldalmemail Autores de comentarios recientes
  Suscribirse  
Los más recientes Los más antiguos Más votados
Notificarme las
trackback

[…] Snap, Flatpak y las segundas guerras de la paquetería lignuxera […]

trackback

[…] Si bien la respuesta de Canonical ha sido ejemplar y rápida, este suceso pone el foco en como se acepta software en la tienda de Snap. De momento, lo existente son controles automáticos, que por lo que se ve no están preparados para encontrar este tipo de fallas. Quizás sea momento de que en Canonical empiecen a primar la calidad sobre la cantidad en esta guerra que se traen por la supremacía del empaquetado de apps en Linux. […]

trackback

[…] Si bien la respuesta de Canonical ha sido ejemplar y rápida, este suceso pone el foco en como se acepta software en la tienda de Snap. De momento, lo existente son controles automáticos, que por lo que se ve no están preparados para encontrar este tipo de fallas. Quizás sea momento de que en Canonical empiecen a primar la calidad sobre la cantidad en esta guerra que se traen por la supremacía del empaquetado de apps en Linux. […]

trackback

[…] esta disponible el archivo en formato Flatpak para las distribuciones […]

trackback

[…] esta disponible el archivo en formato Flatpak para las distribuciones […]