Opinión: ¿Por qué es una mala idea utilizar exclusivamente paquetes AppImage, Flatpak o Snap?
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…