Uno de los motivos por los cuales se crearon so contenedores como AppImage, Flatpak y Snap fue para resolver los problemas de dependencias de aplicaciones, principalmente las basadas sobre NodeJS y Electrón. Resulta que algunas aplicaciones requerían algunos módulos de NodeJS que eran incompatibles con otras aplicaciones o hacían conflicto con los módulos que requerían otras aplicaciones. Por tanto resulta muy conveniente para los desarrolladores de aplicaciones de 3este tipo el utilizar AppImage, Flatpak o Snap para distribuir su software.

La solución de los programadores patra resolver el denominado «infierno de dependencias» fue aplicar el enfoque «¡Es que en mi máquina sí funciona!» empaquetando en los formatos AppImage, Flatpak y Snap. Éstos paquetes contenedores incluyen la aplicación junto con todas sus dependencias específicas de éste. Se sacrifica espacio de almacenamiento para el usuario final, pero el desarrollador puede vivir tranquilo sabiendo que su aplicación con «infierno de dependencias» va a funcionar en todos lados igual que en su máquina personal.

El principal problema de usar estos contenedores ―como ya lo mencioné― es que utilizan mucho espacio de almacenamiento debido a que contienen docenas de bibliotecas compartidas que sirven para cubrir las dependencias de las aplicaciones incluidas. Es decir, cada paquete AppImage, Flatpak o Snap incluye sus propias dependencias. Básicamente TODO lo que requiere la aplicación para ejecutarse, excepto bibliotecas compartidas como glibc, libgcc y ―en algunas casos― libstdc++.

Cuando en otros escenarios la instalación de un paquete implicaba 10 MB, usando AppImage, Flatpak o Snap implica descargar e instalar paquetes de más de 100 MB e incluso mucho más.

El segundo problema consiste en que como básicamente es similar a compilar estáticamente las aplicaciones, cuando surge una vulnerabilidad grave en alguna biblioteca compartida o algún otro componente incluido en el paquete, implica que hay que volver a empaquetar la aplicación para incluir las bibliotecas compartidas y componentes actualizados con las correcciones de seguridad correspondientes, aún si la aplicación en si tuvo un mínimo o nulo cambio en su código

Por ejemplo: vulnerabilidad en Go o Rust implica tener que volver a empaquetar TODO lo que use Go o Rust.

Ahora, cuando se utilizan muchas aplicaciones basadas sobe Electrón, que de manera obligada implica usar AppImage, Flatpak o Snap, el problema se vuelve inmenso, en términos de datos de almacenamiento utilizados.

Una vulnerabilidad en electrón o algún componente de uso común para NodeJS implica tener que volver a empaquetar todos los paquetes dependientes de Electrón o de ese componente en común de NodeJS. Y justamente recién fue anunciada una vulnerabilidad GRAVE en Electron.

Electron es un componente muy complicado de mantener y ―sobre todo― de empaquetar para poder ser incluido en las distribuciones Linux o cualquier otro sistema operativo. Es por tal motivo que prácticamente ninguna distribución Linux incluye paquetes de Electron.

Actualmente hay muchas aplicaciones utilizando Electron, así que va a implicar MILES de paquetes AppImage, Flatpak o Snap de aplicaciones basadas sobre Electron que van a tener que actualizarse para incluir al menos una versión corregida de Electron. Ésto, claro, en el escenario donde los desarrolladores de software son personas responsables y con un mínimo necesario de interés en la seguridad de los usuarios de sus productos.

Para los seguidores de aplicaciones Electron, va a implicar tener que descargar y reinstalar todas su aplicaciones basadas sobre Electron.

Caso conocido es el de elementaryOS, que se subió al barco de Flatpak pese a las recomendaciones y críticas y ahora tenemos un SO que utiliza dos a tres veces más espacio de almacenamiento del que se hubiera necesitado usando paquetes nativos. Cuando surja un problema de seguridad grave en algo como cairo, glib, gtk, pango, openssl, etc., va a ser un momento épico ―de ésos «que no tienen precio»― cuando los desarrolladores de elementaryOS se vean obligados a tener que volver a empaquetar TODO lo involucrado con una vulnerabilidad determinada y obligar a sus usuarios descargar 2 o 3 GB de paquetes en una sola actualización.

Linux Mint abandonó la idea de usar Flatpak por ese mismo motivo.

Para dejar claro el tema y evitar que me acuses de propagar Duda, incertidumbrfe y Miedo en contra de AppImage, Flatpak y Snap: estoy a favor de utilizar AppImage, Flatpak y Snap para aplicaciones con dependencias complicadas y que suelen ser excluidas de las distribuciones Linux. Con con lo que estoy en desacuerdo es con utilizar exclusivamente aplicaciones AppImage, Flatpak y Snap en un sistemas que bien podría utilizar paquetes nativos.