Flatpak se autodenomina “el futuro de la distribución de aplicaciones”. No soy fan. Voy a describir aquí algunos de los problemas técnicos, de seguridad y de usabilidad con Flatpak y de otros sistemas. Intentaré evitar abordar los problemas “solucionables” (como la integración con el tema gráfico) y me centraré en los problemas fundamentales inherentes a su diseño. Mi objetivo es convencer de que este tipo de forma de distribución de aplicaciones no son el futuro de las aplicaciones de escritorio en Linux.
#4 No mucho. Te comento siguiendo los puntos del articulista.
Tamaño:
Flatpak separa runtimes y aplicaciones, se comparte espacio en disco y en memoria que con otras soluciones se estaría malgastando. Se queja de que se separen runtimes y aplicaciones porque dice que cada nueva versión de runtime va a ocupar más espacio y blablablá... obvia que compartiendo runtimes si se corrige un bug, ese bug ya no afecta a ninguna de las aplicaciones y que tener más de una rama o versión de un runtime permite cosas como testear varias versiones de una misma aplicación sin que se peleen o se causen conflictos. Igualmente, las apps se desarrollan sobre la rama de test y se publican sobre la rama estable de un runtime, no vas a tener mil runtimes salvo que quieras, lo normal es que tus apps usen todas la rama estable, y por lo tanto, sólo un runtime común. Lo que el autor del artículo ve como una desventaja (porque lo enfoca mal adrede para que el punto que quiere vender parezca algo gordo), en realidad son sus puntos fuertes: flexibilidad, deduplicación, seguridad y eficiencia.
Espacio en disco es barato:
Sigue con la perorata del tamaño y compara la misión apolo con el estado actual de las cosas, ignorando que por ejemplo, linux con todas las aplicaciones y utilidades básicas (incluso estando flatpakeadas o snapeadas, toma una fedora silverblue o ubuntu por ejemplo) ocupa la mitad que un windows pelado sin nada. Pero tener las aplicaciones flatpakeadas es el problema... quizá el problema es querer usar flatpak para sistemas empotrados ¿a quién se le ocurriría eso?. Cada cosa tiene su ámbito, y desde luego la misión de flatpak no es sustituír ni eliminar los sistemas de empaquetado normales de las distribuciones linux tradicionales (del mismo modo que tú no eliges la misma distribución para una estación científica, un ordenador de escritorio casero, un centro multimedia o un servidor web, aunque puedas hacerlo). Otra vez está retorciendo las cosas para hacer ver que tiene razón con sus argumentos.
El uso de memoria y tiempo de arranque de aplicaciones:
Evidentemente no es lo mismo que una aplicación a pelo. Pero la diferencia no es tan grande en ninguno de los dos casos y las ventajas (aislamiento, protección del sistema, control fino de permisos y accesos, etc) compensan grandemente. Luego vuelve a quejarse de que en sistemas con pocos recursos es inadecuado su uso, olvidándose de los tiempos de carga. Resula curioso que exista un sistema operativo completo pensado para ordenadores con pocos recursos y sistemas educacionales en escuelas con pocos recursos, enfocado al uso de flatpak ¿no es una contradicción? ¿por qué alguien iba a apostar por un sistema que según el articulista debería ser del todo inadecuado? igual alguien está exagerando cosas para quedar bien...:
Igualmente, habla de la mala experiencia de ubuntu y sus snaps, pero mete en el saco a flatpak, del que no dice nada. También de manera evidente, si sólo tienes una aplicación que usa un runtime, si hay un espacio extra ocupado (de disco y de memoria) y tarda un extra en cargar (por cargar y cachear unas librerías que no estaban en memoria), pero desde que tengas dos o más, ya ese espacio en disco y memoria es compartido y no aumenta, sólo el espacio y memoria que consuman las aplicaciones, y los tiempos de arranque en frío ya se limitan a los tiempos de arranque de las aplicaciones porque para lo demás ya tiran de caché o ya está en memoria.
Drivers:
El chico obvia el "The idea here is that if your system uses an OpenGL driver that does not ship with the regular runtime (i.e. Mesa), or needs a more recent version of it, then you can create your own runtime with this name and get your drivers into the runtime." del propio enlace que usa para documentar su argumentación. O sea, lo normal es usar mesa, el driver de sistema. Los problemas vienen, como siempre, de los drivers privativos y la implementación de características que no están en los drivers libres. Por ejemplo, es muy normal que muchos juegos o aplicaciones usen drivers aún no publicados o estables cuando hay alguna característica muy novedosa y aún no estandarizada (por ejemplo, raytracing). Aquí no se trata de que haya problemas con los drivers, como siempre, se trata de dar la facilidad de empaquetar todo lo necesario por una aplicación en caso de que no haya alternativas. Y estamos hablando de la parte de usuario (que es las interfaces con las aplicaciones), no se toca la parte del kernel para nada (que es las interfaces con el hardware). El articulista lo presenta como un grave problema, confunde las extensiones, que están hechas para cosas como:
"An app can only depend on one runtime, and everything not in the runtime must be bundled with the application. There is (by design) no way to depend on multiple runtimes, or have runtimes depend on each other. However, there is something called runtime extensions. Extensions are a way to split off and make optional parts of the runtime and recombine them at runtime."
con una chapuza, cuando en su ejemplo es más bien un: "en mi runtime añado un driver privativo o libre que soporta estas características avanzadas; si el runtime local (o sea, las librerías nativas de toda la vida en /usr/lib) no lo hace, existe la posibilidad de sustituírlo por uno que si las tenga, permitiendo la ejecución de la aplicación. Son mecanismos que hacen más robustas y compatibles las aplicaciones empaquetadas y no problemas como tales y que ni siquiera son obligatorias, son extensiones que se pueden ignorar. Es similar al chequeo que hacen las apps de windows al ejecutarse, si no tienes la última versión de DX, tiran del instalador y te la instalan (con la diferencia de que las extensiones, como los runtimes, son compartidas y reutilizadas entre muchas apps).
Seguridad:
Actualmente, la seguridad depende mucho de cómo estén configurados los flatpaks por parte de los empaquetadores. Si los flatpaks son actuales y están bien empaquetados, es la forma más segura de usar aplicaciones que puede haber en linux (aparte, con aplicaciones como flatseal o a manoplas, puedes regular los permisos de manera fina por aplicación, añadir rutas de disco alcanzables si quieres que la app pueda acceder a otros discos o rutas, etc). En principio, sólo deberían acceder a tu home y para acceder a cualquier otro recurso existen los portales (son APIs para que no accedas directamente a los recursos, forman parte del sandbox-ado de las aplicaciones). El único problema es que aún no existen portales para todo, si para las cosas más comunes. Poco a poco van creándose las tecnologías necesarias para ello (por ejemplo, hasta hace nada no estaba pipewire listo y los portales para capturar audio o video no estaban funcionales, lo que hacía que hubiera que hacer algunos trucos sucios que una aplicación en sandbox no debería usar para permitir estas cosas). Muchos de los problemas que se achacan a wayland es porque aún no se habían creado o estaban maduros los interfaces para acceder de manera segura a ciertos recursos y por lo tanto tampoco estaban listos los portales necesarios para ello (wayland y flatpak van a la par en estas cosas por motivos obvios).
"Suppose libjpeg has a zero-day remote code execution vulnerability. You open a seemingly innocuous JPEG in Flatpak GIMP and it drops its payload set to autostart in your home folder. How did the sandbox help here? The behaviour of this virus is identical regardless of whether GIMP is sandboxed. The only differences are that a) the libjpeg in the alternate runtime is likely to stay out-of-date longer than the one from your Linux distribution; and b) the virus is more likely to work against the sandboxed app because all installations will be using the exact same binary of libjpeg."
La respuesta es que la app o cualquier cosa que se lance con ella no debería estar accediendo directamente a tu home. El flatpak de gimp debe estar mal configurado, la aplicación no debería ver sino un fake root y sólo el diálogo de archivos debería poder acceder a tu home en busca de archivos (a través del portal correspondiente). No sé si el ejemplo es real o se lo ha inventado este tipo.
¡Es mejor que nada!:
Si estoy de acuerdo que la falsa sensación de seguridad permite a los usuarios meter la pata más que si siente que no hay seguridad ninguna. Pero no dice en qué no es seguro flatpak para dejar caer la insinuación velada de que es inherentemente inseguro.
Permisos y portales:
Se queja de que los portales son manejados por los toolkits y no por las aplicaciones, y es lógico. Tú tiras de librerías que te abstraen de lo que haya debajo, tiras de gtk, de kde, de pipewire, etc. Mientras puedes hacerlo tú directamente, lo lógico, por rapidez, funcionalidad, integración y seguridad es no reinventar la rueda ¿no? después se queja de que se duplican las librerías, pero no de que haya librerías que hacen lo mismo (que es duplicar trabajo y esfuerzo, además de espacio y memoria).
Por otro lado, fedora (¿core? simplemente fedora) funciona como cualquier distro. Fedora silverblue por otro lado, si usa todas las apps flatpakeadas porque es otro concepto (precisamente, el mismo que usará la steam deck) donde el sistema está bloqueado/congelado, es inmutable, y las apps están todas aisladas en su propio sandbox. ¿Por qué no van a flatpakear todas sus aplicaciones si tienen una distro hecha para eso? y tú ya eliges qué quieres hacer y cómo eligiendo la distro que prefieras, si core o silverblue.
Choques de identificadores:
Dos empaquetadores empaquetan el mismo software, unos dan por hecho que hay un cierto runtime y otros no, uno ocupa menos y el otro más... ¿qué problema tiene este hombre? puede elegir... y no es cuestión de "quien tiene el nombre de la app registrada" o similar, es cuestión de quién es el que empaqueta esa aplicación y cómo.
#6 Eso que comentas de que arreglas un fallo pones otro pasa también en las aplicaciones autocontenidas (en el software en general), así que como argumento a favor de estas últimas es un poco flojo.
Respecto a lo de las librerías duplicadas en RAM: ¿para qué añadir KSM si YA se hace con librerías normales? ¿Por qué añadir otra capa más (y más) de complejidad al ya complejo de por sí software actual?
Lo de la velocidad de lanzamiento: claro que solo para el primero. Pero esa “solución” es del sistema operativo, que cachea, no del software en sí, así que el argumento vuelve a brillar por flojedad.
Finalmente, en el propio artículo pone más información sobre lo ”barato” que creéis algunos que es el espacio en disco y la RAM.
Y, como conclusión, vuelvo a principio: no merece la pena en que haya CINCO “estándares” para autocontener aplicaciones en Linux. Ojalá todo ese esfuerzo hubiera ido a mejorar la gestión de librerías, que funcionan de forma excelente, tanto en la práctica como en su diseño.
"The rest is all redundant libraries that are already on my system. I just ran the kcalc binary straight out of its Flatpak install path unsandboxed and let it use my native libraries. It ran just fine, because all of the libraries it uses are backwards compatible."
Cherry picking: Igual en este caso funciona, pero en muchos otros no.
Este debate ya está muy trillado: las librerías compartidas empezaron a usarse cuando el almacenamiento era caro y escaso. Hoy la cosa ha cambiado mucho y, excepto en sistemas puntuales, sobra espacio para sistema operativo, librerías y aplicaciones. Las librerías compartidas tienen sus propias desventajas, y empaquetar las apps con las versiones exactas que utilizan y con las que han sido probadas soluciona todas esas, y además son más seguras porque las aplicaciones pueden correr en un sandbox. El precio a pagar en espacio para mí merece la pena.
Yo todavía estoy esperando a tener problemas de espacio por usar snap en lugar de apt siempre que puedo, y creo que no va a pasar nunca. Lo que ocupa el SO con aplicaciones y librerías hoy en día es un porcentaje mínimo de lo que se almacena. Mis archivos con el email de los últimos diez años ya ocupa más, no te digo nada si guardas fotografías y videos.
Los informáticos obsesionados con el espacio a mí me recuerdan a los ciclistas de fin de semana obsesionados con el peso, que se creen que por gastarse 500 euros en unos pedales 100 gramos más ligeros van a ganar algo. En la alta competición igual importan, pero en el día a día es del todo irrelevante.
#1 Pues opino lo mismo que el artículo. Desperdiciar recuros a cascoporro es una puta mierda, y no solo habla de el despilfarro en RAM y disco, también el empeoramiento del rendimiento, 7 segundos para abrir una puta calculadora de mierda.
Flatpack, Snap, todos esos sistemas de empaquetamiento de librerias redundantes son basura, en rendimiento y en seguridad, porque ¿como sabes que las librerías que están utilizando tiene todos los parches actualizados? de hecho, no los tienen porque son "soluciones" para poder utilizar librerías viejas, un remedio para desarrolladores vagos.
#1 Siento decirte que las librerías (o bibliotecas) no se inventaron solo para ahorrar espacio cuando este era caro (sigue siendo caro, porque los requerimientos de espacio se han multiplicado en estos años), sino que también para compartir código entre aplicaciones. Es decir, que podía haber un fallo en una aplicación que en realidad estaba en una librería, se solucionaba el problema en la librería, y tu aplicación funcionaría bien si ningún cambio y sin recompilar.
Además, el uso de librerías compartidas tiene impacto en el uso de memoria RAM, no solo espacio en disco. El disco puede que sea barato, pero la RAM no, y está limitada. Si para ejecutar la calculadora cago todas sus librerías en RAM y para cargar el Sudoku cargo exactamente las mismas librerías pero en otro espacio de memoria no compartida (porque para eso están empaquetadas), estamos desperdiciando memoria y memoria.
Estos problemas de librerías compartidas que comentas se pueden solucionar de muchas formas. De hecho, existe versionado dentro de las propias librerías (versionado de símbolos), versionado de librerías en sí mismas, paso de mensajes en lugar de enlace dinámico, RPC, DBus, etc. De hecho, si todo el esfuerzo que se está gastando en crear aplicaciones autocontenidas se hubiese usado para mejorar las versiones de librerías, seguro que ahora no habría ni siquiera esta discusión.
No hablemos ya de los tiempos de inicio. Iniciar un Snap tarda un orden de magnitud más (10x) que la aplicación instalada de apt, por ejemplo. Que, por cierto, Snap (y Flatpak) también tiene problemas de versiones, de ahí que tengas snaps llamados core10, core18, core20, gnome-3-38, gnome-3-40… y cada paquete snap a su core. Vamos, que son los mismos problemas de siempre pero, encima, duplicando código y usando montones de espacio adicional (del propio artículo, para lanzar la calculadora se necesita casi un gigabyte).
Finalmente, como digo, no es cuestión de estar obsesionado con el espacio, es cuestión de hacer las cosas bien. Tener un GB para lanzar una calculadora, lo mires por done lo mires, no es una cosa bien hecha.
#3 "Es decir, que podía haber un fallo en una aplicación que en realidad estaba en una librería, se solucionaba el problema en la librería, y tu aplicación funcionaría bien si ningún cambio y sin recompilar."
Precisamente ese es uno de los problemas recurrentes de las librerías compartidas: actualizas la librería para arreglar un problema con una aplicación e inadvertidamente creas otro en otra aplicación que usa la misma librería. Y esto es algo que pasa continuamente.
Y lo de la velocidad en el arranque es cierto pero sólo para el primer lanzamiento, después el caché hace la diferencia prácticamente inexistente, y de todas maneras lo del 10x me parece una exageración que será cierto para algún caso puntual pero no creo que sea un promedio ni una moda.
Evidentemente habrá casos en los que todo esto sea un problema, pero para un uso normal de un ordenador de escritorio o un portátil, son desventajas asumibles que en mi opinión se ven compensadas de sobra con las ventajas que aportan.
Por supuesto habrá casos específicos en que no compense, pero en general lo hace, al menos basándome en mi propia experiencia que es la única que tengo. Otros tendrán otra...
#2 Flatpak no es redundante, flatpak separa aplicaciones y runtimes para que si tienes varias aplicaciones que usan el mismo runtime lo compartan (sólo tienes 1 runtime, si se parchea por una vulnerabilidad, todas las apps quedan protegidas). Otros sistemas de empaquetado si cuelan los runtimes en el mismo empaquetado que la aplicación, lo que lleva a que si el empaquetador no actualiza, los problemas de seguridad por un runtime desactualizado nunca se solucionen.
Comentarios
esta bien argumentado el artículo, si las distribuciones mantuviesen cierta compatibilidad está aberración nunca habría hecho falta
#4 No mucho. Te comento siguiendo los puntos del articulista.
Tamaño:
Flatpak separa runtimes y aplicaciones, se comparte espacio en disco y en memoria que con otras soluciones se estaría malgastando. Se queja de que se separen runtimes y aplicaciones porque dice que cada nueva versión de runtime va a ocupar más espacio y blablablá... obvia que compartiendo runtimes si se corrige un bug, ese bug ya no afecta a ninguna de las aplicaciones y que tener más de una rama o versión de un runtime permite cosas como testear varias versiones de una misma aplicación sin que se peleen o se causen conflictos. Igualmente, las apps se desarrollan sobre la rama de test y se publican sobre la rama estable de un runtime, no vas a tener mil runtimes salvo que quieras, lo normal es que tus apps usen todas la rama estable, y por lo tanto, sólo un runtime común. Lo que el autor del artículo ve como una desventaja (porque lo enfoca mal adrede para que el punto que quiere vender parezca algo gordo), en realidad son sus puntos fuertes: flexibilidad, deduplicación, seguridad y eficiencia.
Espacio en disco es barato:
Sigue con la perorata del tamaño y compara la misión apolo con el estado actual de las cosas, ignorando que por ejemplo, linux con todas las aplicaciones y utilidades básicas (incluso estando flatpakeadas o snapeadas, toma una fedora silverblue o ubuntu por ejemplo) ocupa la mitad que un windows pelado sin nada. Pero tener las aplicaciones flatpakeadas es el problema... quizá el problema es querer usar flatpak para sistemas empotrados ¿a quién se le ocurriría eso?. Cada cosa tiene su ámbito, y desde luego la misión de flatpak no es sustituír ni eliminar los sistemas de empaquetado normales de las distribuciones linux tradicionales (del mismo modo que tú no eliges la misma distribución para una estación científica, un ordenador de escritorio casero, un centro multimedia o un servidor web, aunque puedas hacerlo). Otra vez está retorciendo las cosas para hacer ver que tiene razón con sus argumentos.
El uso de memoria y tiempo de arranque de aplicaciones:
Evidentemente no es lo mismo que una aplicación a pelo. Pero la diferencia no es tan grande en ninguno de los dos casos y las ventajas (aislamiento, protección del sistema, control fino de permisos y accesos, etc) compensan grandemente. Luego vuelve a quejarse de que en sistemas con pocos recursos es inadecuado su uso, olvidándose de los tiempos de carga. Resula curioso que exista un sistema operativo completo pensado para ordenadores con pocos recursos y sistemas educacionales en escuelas con pocos recursos, enfocado al uso de flatpak ¿no es una contradicción? ¿por qué alguien iba a apostar por un sistema que según el articulista debería ser del todo inadecuado? igual alguien está exagerando cosas para quedar bien...:
https://endlessos.com/es/
Igualmente, habla de la mala experiencia de ubuntu y sus snaps, pero mete en el saco a flatpak, del que no dice nada. También de manera evidente, si sólo tienes una aplicación que usa un runtime, si hay un espacio extra ocupado (de disco y de memoria) y tarda un extra en cargar (por cargar y cachear unas librerías que no estaban en memoria), pero desde que tengas dos o más, ya ese espacio en disco y memoria es compartido y no aumenta, sólo el espacio y memoria que consuman las aplicaciones, y los tiempos de arranque en frío ya se limitan a los tiempos de arranque de las aplicaciones porque para lo demás ya tiran de caché o ya está en memoria.
Drivers:
El chico obvia el "The idea here is that if your system uses an OpenGL driver that does not ship with the regular runtime (i.e. Mesa), or needs a more recent version of it, then you can create your own runtime with this name and get your drivers into the runtime." del propio enlace que usa para documentar su argumentación. O sea, lo normal es usar mesa, el driver de sistema. Los problemas vienen, como siempre, de los drivers privativos y la implementación de características que no están en los drivers libres. Por ejemplo, es muy normal que muchos juegos o aplicaciones usen drivers aún no publicados o estables cuando hay alguna característica muy novedosa y aún no estandarizada (por ejemplo, raytracing). Aquí no se trata de que haya problemas con los drivers, como siempre, se trata de dar la facilidad de empaquetar todo lo necesario por una aplicación en caso de que no haya alternativas. Y estamos hablando de la parte de usuario (que es las interfaces con las aplicaciones), no se toca la parte del kernel para nada (que es las interfaces con el hardware). El articulista lo presenta como un grave problema, confunde las extensiones, que están hechas para cosas como:
"An app can only depend on one runtime, and everything not in the runtime must be bundled with the application. There is (by design) no way to depend on multiple runtimes, or have runtimes depend on each other. However, there is something called runtime extensions. Extensions are a way to split off and make optional parts of the runtime and recombine them at runtime."
con una chapuza, cuando en su ejemplo es más bien un: "en mi runtime añado un driver privativo o libre que soporta estas características avanzadas; si el runtime local (o sea, las librerías nativas de toda la vida en /usr/lib) no lo hace, existe la posibilidad de sustituírlo por uno que si las tenga, permitiendo la ejecución de la aplicación. Son mecanismos que hacen más robustas y compatibles las aplicaciones empaquetadas y no problemas como tales y que ni siquiera son obligatorias, son extensiones que se pueden ignorar. Es similar al chequeo que hacen las apps de windows al ejecutarse, si no tienes la última versión de DX, tiran del instalador y te la instalan (con la diferencia de que las extensiones, como los runtimes, son compartidas y reutilizadas entre muchas apps).
Seguridad:
Actualmente, la seguridad depende mucho de cómo estén configurados los flatpaks por parte de los empaquetadores. Si los flatpaks son actuales y están bien empaquetados, es la forma más segura de usar aplicaciones que puede haber en linux (aparte, con aplicaciones como flatseal o a manoplas, puedes regular los permisos de manera fina por aplicación, añadir rutas de disco alcanzables si quieres que la app pueda acceder a otros discos o rutas, etc). En principio, sólo deberían acceder a tu home y para acceder a cualquier otro recurso existen los portales (son APIs para que no accedas directamente a los recursos, forman parte del sandbox-ado de las aplicaciones). El único problema es que aún no existen portales para todo, si para las cosas más comunes. Poco a poco van creándose las tecnologías necesarias para ello (por ejemplo, hasta hace nada no estaba pipewire listo y los portales para capturar audio o video no estaban funcionales, lo que hacía que hubiera que hacer algunos trucos sucios que una aplicación en sandbox no debería usar para permitir estas cosas). Muchos de los problemas que se achacan a wayland es porque aún no se habían creado o estaban maduros los interfaces para acceder de manera segura a ciertos recursos y por lo tanto tampoco estaban listos los portales necesarios para ello (wayland y flatpak van a la par en estas cosas por motivos obvios).
"Suppose libjpeg has a zero-day remote code execution vulnerability. You open a seemingly innocuous JPEG in Flatpak GIMP and it drops its payload set to autostart in your home folder. How did the sandbox help here? The behaviour of this virus is identical regardless of whether GIMP is sandboxed. The only differences are that a) the libjpeg in the alternate runtime is likely to stay out-of-date longer than the one from your Linux distribution; and b) the virus is more likely to work against the sandboxed app because all installations will be using the exact same binary of libjpeg."
La respuesta es que la app o cualquier cosa que se lance con ella no debería estar accediendo directamente a tu home. El flatpak de gimp debe estar mal configurado, la aplicación no debería ver sino un fake root y sólo el diálogo de archivos debería poder acceder a tu home en busca de archivos (a través del portal correspondiente). No sé si el ejemplo es real o se lo ha inventado este tipo.
¡Es mejor que nada!:
Si estoy de acuerdo que la falsa sensación de seguridad permite a los usuarios meter la pata más que si siente que no hay seguridad ninguna. Pero no dice en qué no es seguro flatpak para dejar caer la insinuación velada de que es inherentemente inseguro.
Permisos y portales:
Se queja de que los portales son manejados por los toolkits y no por las aplicaciones, y es lógico. Tú tiras de librerías que te abstraen de lo que haya debajo, tiras de gtk, de kde, de pipewire, etc. Mientras puedes hacerlo tú directamente, lo lógico, por rapidez, funcionalidad, integración y seguridad es no reinventar la rueda ¿no? después se queja de que se duplican las librerías, pero no de que haya librerías que hacen lo mismo (que es duplicar trabajo y esfuerzo, además de espacio y memoria).
Por otro lado, fedora (¿core? simplemente fedora) funciona como cualquier distro. Fedora silverblue por otro lado, si usa todas las apps flatpakeadas porque es otro concepto (precisamente, el mismo que usará la steam deck) donde el sistema está bloqueado/congelado, es inmutable, y las apps están todas aisladas en su propio sandbox. ¿Por qué no van a flatpakear todas sus aplicaciones si tienen una distro hecha para eso? y tú ya eliges qué quieres hacer y cómo eligiendo la distro que prefieras, si core o silverblue.
Choques de identificadores:
Dos empaquetadores empaquetan el mismo software, unos dan por hecho que hay un cierto runtime y otros no, uno ocupa menos y el otro más... ¿qué problema tiene este hombre? puede elegir... y no es cuestión de "quien tiene el nombre de la app registrada" o similar, es cuestión de quién es el que empaqueta esa aplicación y cómo.
Complejidad:
Habla de problemas que tuvo
#6 Eso que comentas de que arreglas un fallo pones otro pasa también en las aplicaciones autocontenidas (en el software en general), así que como argumento a favor de estas últimas es un poco flojo.
Respecto a lo de las librerías duplicadas en RAM: ¿para qué añadir KSM si YA se hace con librerías normales? ¿Por qué añadir otra capa más (y más) de complejidad al ya complejo de por sí software actual?
Lo de la velocidad de lanzamiento: claro que solo para el primero. Pero esa “solución” es del sistema operativo, que cachea, no del software en sí, así que el argumento vuelve a brillar por flojedad.
Finalmente, en el propio artículo pone más información sobre lo ”barato” que creéis algunos que es el espacio en disco y la RAM.
Y, como conclusión, vuelvo a principio: no merece la pena en que haya CINCO “estándares” para autocontener aplicaciones en Linux. Ojalá todo ese esfuerzo hubiera ido a mejorar la gestión de librerías, que funcionan de forma excelente, tanto en la práctica como en su diseño.
"The rest is all redundant libraries that are already on my system. I just ran the kcalc binary straight out of its Flatpak install path unsandboxed and let it use my native libraries. It ran just fine, because all of the libraries it uses are backwards compatible."
Cherry picking: Igual en este caso funciona, pero en muchos otros no.
Este debate ya está muy trillado: las librerías compartidas empezaron a usarse cuando el almacenamiento era caro y escaso. Hoy la cosa ha cambiado mucho y, excepto en sistemas puntuales, sobra espacio para sistema operativo, librerías y aplicaciones. Las librerías compartidas tienen sus propias desventajas, y empaquetar las apps con las versiones exactas que utilizan y con las que han sido probadas soluciona todas esas, y además son más seguras porque las aplicaciones pueden correr en un sandbox. El precio a pagar en espacio para mí merece la pena.
Yo todavía estoy esperando a tener problemas de espacio por usar snap en lugar de apt siempre que puedo, y creo que no va a pasar nunca. Lo que ocupa el SO con aplicaciones y librerías hoy en día es un porcentaje mínimo de lo que se almacena. Mis archivos con el email de los últimos diez años ya ocupa más, no te digo nada si guardas fotografías y videos.
Los informáticos obsesionados con el espacio a mí me recuerdan a los ciclistas de fin de semana obsesionados con el peso, que se creen que por gastarse 500 euros en unos pedales 100 gramos más ligeros van a ganar algo. En la alta competición igual importan, pero en el día a día es del todo irrelevante.
#1 Pues opino lo mismo que el artículo. Desperdiciar recuros a cascoporro es una puta mierda, y no solo habla de el despilfarro en RAM y disco, también el empeoramiento del rendimiento, 7 segundos para abrir una puta calculadora de mierda.
Flatpack, Snap, todos esos sistemas de empaquetamiento de librerias redundantes son basura, en rendimiento y en seguridad, porque ¿como sabes que las librerías que están utilizando tiene todos los parches actualizados? de hecho, no los tienen porque son "soluciones" para poder utilizar librerías viejas, un remedio para desarrolladores vagos.
#1 Siento decirte que las librerías (o bibliotecas) no se inventaron solo para ahorrar espacio cuando este era caro (sigue siendo caro, porque los requerimientos de espacio se han multiplicado en estos años), sino que también para compartir código entre aplicaciones. Es decir, que podía haber un fallo en una aplicación que en realidad estaba en una librería, se solucionaba el problema en la librería, y tu aplicación funcionaría bien si ningún cambio y sin recompilar.
Además, el uso de librerías compartidas tiene impacto en el uso de memoria RAM, no solo espacio en disco. El disco puede que sea barato, pero la RAM no, y está limitada. Si para ejecutar la calculadora cago todas sus librerías en RAM y para cargar el Sudoku cargo exactamente las mismas librerías pero en otro espacio de memoria no compartida (porque para eso están empaquetadas), estamos desperdiciando memoria y memoria.
Estos problemas de librerías compartidas que comentas se pueden solucionar de muchas formas. De hecho, existe versionado dentro de las propias librerías (versionado de símbolos), versionado de librerías en sí mismas, paso de mensajes en lugar de enlace dinámico, RPC, DBus, etc. De hecho, si todo el esfuerzo que se está gastando en crear aplicaciones autocontenidas se hubiese usado para mejorar las versiones de librerías, seguro que ahora no habría ni siquiera esta discusión.
No hablemos ya de los tiempos de inicio. Iniciar un Snap tarda un orden de magnitud más (10x) que la aplicación instalada de apt, por ejemplo. Que, por cierto, Snap (y Flatpak) también tiene problemas de versiones, de ahí que tengas snaps llamados core10, core18, core20, gnome-3-38, gnome-3-40… y cada paquete snap a su core. Vamos, que son los mismos problemas de siempre pero, encima, duplicando código y usando montones de espacio adicional (del propio artículo, para lanzar la calculadora se necesita casi un gigabyte).
Finalmente, como digo, no es cuestión de estar obsesionado con el espacio, es cuestión de hacer las cosas bien. Tener un GB para lanzar una calculadora, lo mires por done lo mires, no es una cosa bien hecha.
/cc #2
#3 "Es decir, que podía haber un fallo en una aplicación que en realidad estaba en una librería, se solucionaba el problema en la librería, y tu aplicación funcionaría bien si ningún cambio y sin recompilar."
Precisamente ese es uno de los problemas recurrentes de las librerías compartidas: actualizas la librería para arreglar un problema con una aplicación e inadvertidamente creas otro en otra aplicación que usa la misma librería. Y esto es algo que pasa continuamente.
Lo de las librerías duplicadas en RAM se puede evitar con el KSM (https://sinfallas.wordpress.com/2014/05/08/ksm-que-es-y-como-aplicarlo/), en cualquier caso la RAM también es más barata hoy en día que hace años.
Y lo de la velocidad en el arranque es cierto pero sólo para el primer lanzamiento, después el caché hace la diferencia prácticamente inexistente, y de todas maneras lo del 10x me parece una exageración que será cierto para algún caso puntual pero no creo que sea un promedio ni una moda.
Evidentemente habrá casos en los que todo esto sea un problema, pero para un uso normal de un ordenador de escritorio o un portátil, son desventajas asumibles que en mi opinión se ven compensadas de sobra con las ventajas que aportan.
Por supuesto habrá casos específicos en que no compense, pero en general lo hace, al menos basándome en mi propia experiencia que es la única que tengo. Otros tendrán otra...
#2 Flatpak no es redundante, flatpak separa aplicaciones y runtimes para que si tienes varias aplicaciones que usan el mismo runtime lo compartan (sólo tienes 1 runtime, si se parchea por una vulnerabilidad, todas las apps quedan protegidas). Otros sistemas de empaquetado si cuelan los runtimes en el mismo empaquetado que la aplicación, lo que lleva a que si el empaquetador no actualiza, los problemas de seguridad por un runtime desactualizado nunca se solucionen.