#8 El concepto es sencillo: Mete una app y todas las dependencias que tenga empezando por el sistema operativo, en un único archivo, como si fuera una imagen para una máquina virtual. Eso sí, sólo puedes publicar en puertos para que te llamen y puedes acceder a puertos para acceder a otras imágenes. Una vez se pare la imagen, si había algo guardado en disco se "perderá", es todo temporal a no ser que durante el arranque de la imagen especifiques algún directorio de mapeo.
Resumen: soy desarrollador y puedo tener varios MySQL de distintas versiones ejecutando a la vez en mi máquina con lo que puedo desarrollar distintas aplicaciones y/o hacer mantenimientos correctivos que necesiten versiones específicas de MySQL sin mayor problema. A partir de ahí, saltar de Docker a Docker Compose y de ahí a Kubernetes aumentando en complejidad.
Si te interesa el tema te recomiendo este vídeo como crash-course rápido para ver qué hace y un poco funcionamiento general sin entrar en los miles de detalles:
#6 Míralo desde otro punto de vista. Más que el sueldo de un desarrollador, los costes de automatizar y gestionar la creación de flatpaks para un software (que se hace una vez y ya te lo genera y publica "para siempre").
#18 Si, dentro de las aplicaciones que usen flatpak y un mismo runtime (evidentemente, necesitan estar aisladas de las librerías del sistema). Al fin y al cabo, si sólo ejecutas simultaneamente una única aplicación, el uso de recursos es ligeramente mayor.
Pero piensa en sistemas como fedora silverblue (o sin ir más lejos, el futuro steamos 3 de la steam deck) que funcionan como un sistema operativo de sólo lectura (no tocable por el usuario directamente, protegido ante cosas del exterior, sólo actualizable de manera atómica y segura) y todo lo demás funcionando desde flatpaks: ahí el ahorro es abismal porque todo tenderá a usar el mismo runtime, sería como usar las librerías nativas del sistema, los problemas de seguridad del sistema se arreglarían simplemente actualizando el runtime (las aplicaciones ni se enterarían y muchas ni se tendrían que actualizar salvo que salgan versiones nuevas, lo cual es ideal para juegos o aplicaciones de terceros). Otros sistemas de empaquetado si duplican cosas (como los que usó apple de meter en el mismo fichero tanto el software de dos arquitecturas distintas durante su transición de power a intel o los que meten sus runtimes dentro del mismo empaquetado que la aplicación, donde los que mantienen la aplicación tienen que actualizar cada vez que hay un problema de seguridad en alguna de esas librerías de sistema).
#15 personalmente he probado flatpak y snap y cada uno tiene sus inconvenientes
Valoré poner en un portátil de un familiar algunos paquetes por snap por aquello de que se actualizan solos. Pero al final me decanté por incluir un par de repositorios específicos para esas apps (como Chrome) y tirar de unattended updates.
Siempre que se pueda mejor deb/rpm, etc. Incluso instalación local en ~/.local o /opt
#19 La diferencia es que quedas a expensas del mantenedor de la distribución (que puede tardar más o menos en actualizar, puede integrar mejor o peor las cosas en el sistema, etc). Los flatpaks tienen la ventaja de que son los propios creadores de las aplicaciones los que actualizan y la mantienen al día (y al tener los runtimes separados, se evitan tener que estar al loro y actualizar todo el paquete, se desentienden porque lo lleva el mantenedor de los runtimes).
#1 los snaps están para lo que están. Cosas sencillas que no necesitan una gran profesionalidad. Se actualiza solo, la instalación es sencilla y ayuda a la gente a usar linux para sus soluciones.
Si lo que quieres es mantener un servidor de grandes prestaciones te toca hacerlo a "mano"
#2 hay aplicaciones "profesionales" que solo funcionan bien en su formato snap. Por ejemplo yo tengo pycharm en snap y me da cáncer cuando lo abro. Las otras versiones no las tenían actualizadas y/o tenían bugs. Pero lo de "facilitar" supongo que te lo compro. Aunque yo nunca tuve problemas para instalar debs. Quizás es para evitar añadir repositorios pero eso no es dificultad es vaguería no hacerlo.
#1 son dos formas de afrontar el mismo problema, ambos hacen lo mismo, empaquetar programa y dependencias en un mismo paquete. No entiendo porqué Red Hat no elabora un rpm para su distribución. Debería estandarizarse el sistema de paquetes en uno único para todas las distribuciones.
#5 No, en flatpak las dependencias van aparte. El concepto de runtimes separados de la aplicación permite:
a) ahorrar espacio en disco: si tienes instaladas cuatro aplicaciones y todas dependen del mismo runtime, sólo te roba espacio el runtime una vez.
b) al compartir runtimes, puedes mantener y actualizar el runtime independientemente de la aplicación; o lo que es lo mismo: los del aplicativo no tienen que rehacer el paquete cada vez que hay una actualización de seguriad o hay que corregir cualquier cosa que no tenga que ver con su software, se limitan a mantener su programa actualizado.
Red hat ya lo hace (¿te suena fedora silverblue? el concepto es claro: un sistema operativo "que no se puede modificar" y todo el ecosistema de aplicaciones de usuario funcionando desde flatpaks).
#1 En realidad, lo mismo podría decirse de Docker, exactamente lo mismo (no digo que Docker y ésto sean lo mismo porque no tienen la misma finalidad). Pero llega un momento en que prevalecen ciertos requermientos sobre otros y en donde todo tiene cabida. En algunos casos querrás hacer las cosas manualmente para tenerlo afinado como un violín y en otras, dar un botón y que se haga todo ello solito con los valores por defecto más comunes ya preestablecidos.
#20 Creo que toda la peña que instala aplicaciones como HomeAssistant, por poner un ejemplo muy común, estaría en desacuerdo con esa afirmación tan rotunda. La gente está descubriendo que hay aplicaciones (headless) que requieren mucha preinstalación de dependencias (Python con versiones específicas por ejemplo). y que es mucho más sencillo ejecutar un único comando para hacer correr esas aplicaciones:
$docker run -d --name homeassistant -v /home/user/haconfig:/config --network=host ghcr.io/home-assistant/home-assistant:stable
#1 ¿Qué recursos? ¿disco? ¿memoria? ¿cpu? ¿todos los anteriores? ¿los gasta innecesariamente o aporta algo a cambio? ¿merece la pena lo que aporta respecto al gasto que supone?
#13 memoria ram, disco y cpu sí. Memoria ram porque carga en memoria librerías que pueden estar ya cargadas en memoria y más cosas. Negligible en ese primer aspecto. Disco porque ocupa bastante más que una aplicación normal. Eso no es negligible en mi caso. CPU (y memoria) porque tiene que montar cada aplicación como si fuera un sistema de archivos independiente para que cada proceso esté montado independientemente. Eso en CPU podría ser negligible también y puede que en RAM también, no lo sé seguro, no he podido comprobar la misma aplicación.
¿Ventajas? Pues garantía de que funciona, sin embargo que no funcionen otros paquetes indica que los que los hacen son unos chapuzas o unos vagos o ambas (la mayor parte de veces). Depende. En mi caso para pycharm sólo pude instalarlo con un snap. Yo sí creo que consume más CPU y memoria que una aplicación normal. Pero es un poco como usar una aplicación basada en Electron (es decir un chrome por debajo). Gasta bastante, pero si hay que usarlo porque no hay más opción...
En cuanto a ventajas, se supone que son aplicaciones más seguras.
#14
RAM y DISCO:
No tiene por qué cargar en ram librerías que ya están cargadas en memoria. Si sólo abres una aplicación en flatpak usando un runtime, si; si hay más de una tirando del mismo runtime, no porque ya se están compartiendo recursos. Por lo demás, lo que consuma normalmente la aplicación. Otros sistemas de empaquetado como snap no sé cómo van y si puede ser que sean más gordotes.
CPU:
Puede que tenga un cierto aumento de uso de CPU de manera marginal, probablemente si más tiempo de arranque, pero prácticamente nada en el uso normal de la aplicación.
Ventajas:
Por lo pronto, aparte de que al tener un runtime probado donde puedes asegurar que la aplicación funcione, estés en la máquina en la que estés, las aplicaciones funcionan en un sandbox; puedes gestionar los permisos y accesos a los recursos de la máquina de manera fina para cada aplicación (la aplicación flatseal te permite hacerlo cómoda y gráficamente), puedes controlar y limitar mejor los recursos que puedes darle a una aplicación, puedes tener en memoria distintas instancias de versiones diferentes de la misma aplicación sin problemas para testear, etc.
Electrón es algo diferente (sutilmente, si quieres), simplemente se usa porque es, no sólo un runtime para que la aplicación funcione como tal, sino todo un entorno completo que aisla todo el acceso a los recursos del SO para poder realizar todo tipo de aplicaciones de manera completamente independiente del mismo. Electrón casi llega a ser un sistema operativo dentro de otro sistema operativo (en realidad los navegadores ya casi lo son y es lo que hace que puedas ejecutar aplicaciones web "en cualquier lado"), en cierto modo es hasta más pesado que una máquina virtual. Sería casi como la diferencia entre un simulador y un emulador, las máquinas virtuales replican los dispositivos de un ordenador, su funcionamiento, etc, mientras que un navegador los emula o abstrae para ser usados a su modo desde dentro.
#17 Sí, en flatpak no sé si es mejor. De hecho no sabía que se comparten recursos. Pero en todo caso se comparten recursos de aplicaciones que usan flatpak ¿no?
Qué interesante todo lo que me has contado, yo sé más o menos eso, pero no a tanto nivel de detalle, me ha resultado instructivo. Gracias.
Comentarios
Me está gustando el meneame linuxero del 2022.
¡Que siga así!
#4 La gente normal ha salido en nochevieja y aún está de resaca, por eso dominan los informáticos la página en estos momentos .
#9 Pues yo anoche estuve hasta las 5 de la mañana jugando al Dark Soul 3 y me he levantado hace un rato
#8 El concepto es sencillo: Mete una app y todas las dependencias que tenga empezando por el sistema operativo, en un único archivo, como si fuera una imagen para una máquina virtual. Eso sí, sólo puedes publicar en puertos para que te llamen y puedes acceder a puertos para acceder a otras imágenes. Una vez se pare la imagen, si había algo guardado en disco se "perderá", es todo temporal a no ser que durante el arranque de la imagen especifiques algún directorio de mapeo.
Resumen: soy desarrollador y puedo tener varios MySQL de distintas versiones ejecutando a la vez en mi máquina con lo que puedo desarrollar distintas aplicaciones y/o hacer mantenimientos correctivos que necesiten versiones específicas de MySQL sin mayor problema. A partir de ahí, saltar de Docker a Docker Compose y de ahí a Kubernetes aumentando en complejidad.
Si te interesa el tema te recomiendo este vídeo como crash-course rápido para ver qué hace y un poco funcionamiento general sin entrar en los miles de detalles:
han donado algo así como 1 mes del salario del lead dev
ufff, que generosos en la corporación red hat
#6 IBM
#6 Míralo desde otro punto de vista. Más que el sueldo de un desarrollador, los costes de automatizar y gestionar la creación de flatpaks para un software (que se hace una vez y ya te lo genera y publica "para siempre").
#18 Si, dentro de las aplicaciones que usen flatpak y un mismo runtime (evidentemente, necesitan estar aisladas de las librerías del sistema). Al fin y al cabo, si sólo ejecutas simultaneamente una única aplicación, el uso de recursos es ligeramente mayor.
Pero piensa en sistemas como fedora silverblue (o sin ir más lejos, el futuro steamos 3 de la steam deck) que funcionan como un sistema operativo de sólo lectura (no tocable por el usuario directamente, protegido ante cosas del exterior, sólo actualizable de manera atómica y segura) y todo lo demás funcionando desde flatpaks: ahí el ahorro es abismal porque todo tenderá a usar el mismo runtime, sería como usar las librerías nativas del sistema, los problemas de seguridad del sistema se arreglarían simplemente actualizando el runtime (las aplicaciones ni se enterarían y muchas ni se tendrían que actualizar salvo que salgan versiones nuevas, lo cual es ideal para juegos o aplicaciones de terceros). Otros sistemas de empaquetado si duplican cosas (como los que usó apple de meter en el mismo fichero tanto el software de dos arquitecturas distintas durante su transición de power a intel o los que meten sus runtimes dentro del mismo empaquetado que la aplicación, donde los que mantienen la aplicación tienen que actualizar cada vez que hay un problema de seguridad en alguna de esas librerías de sistema).
#15 personalmente he probado flatpak y snap y cada uno tiene sus inconvenientes
Valoré poner en un portátil de un familiar algunos paquetes por snap por aquello de que se actualizan solos. Pero al final me decanté por incluir un par de repositorios específicos para esas apps (como Chrome) y tirar de unattended updates.
Siempre que se pueda mejor deb/rpm, etc. Incluso instalación local en ~/.local o /opt
Os recomiendo esta lectura
https://ludocode.com/blog/flatpak-is-not-the-future
#19 La diferencia es que quedas a expensas del mantenedor de la distribución (que puede tardar más o menos en actualizar, puede integrar mejor o peor las cosas en el sistema, etc). Los flatpaks tienen la ventaja de que son los propios creadores de las aplicaciones los que actualizan y la mantienen al día (y al tener los runtimes separados, se evitan tener que estar al loro y actualizar todo el paquete, se desentienden porque lo lleva el mantenedor de los runtimes).
Los snaps son una mierda que gasta recursos innecesarios. Aún no he probado ningún flatpak, pero no creo que sea muy diferente.
#1 los snaps están para lo que están. Cosas sencillas que no necesitan una gran profesionalidad. Se actualiza solo, la instalación es sencilla y ayuda a la gente a usar linux para sus soluciones.
Si lo que quieres es mantener un servidor de grandes prestaciones te toca hacerlo a "mano"
#2 hay aplicaciones "profesionales" que solo funcionan bien en su formato snap. Por ejemplo yo tengo pycharm en snap y me da cáncer cuando lo abro. Las otras versiones no las tenían actualizadas y/o tenían bugs. Pero lo de "facilitar" supongo que te lo compro. Aunque yo nunca tuve problemas para instalar debs. Quizás es para evitar añadir repositorios pero eso no es dificultad es vaguería no hacerlo.
#1 son dos formas de afrontar el mismo problema, ambos hacen lo mismo, empaquetar programa y dependencias en un mismo paquete. No entiendo porqué Red Hat no elabora un rpm para su distribución. Debería estandarizarse el sistema de paquetes en uno único para todas las distribuciones.
#5 No, en flatpak las dependencias van aparte. El concepto de runtimes separados de la aplicación permite:
a) ahorrar espacio en disco: si tienes instaladas cuatro aplicaciones y todas dependen del mismo runtime, sólo te roba espacio el runtime una vez.
b) al compartir runtimes, puedes mantener y actualizar el runtime independientemente de la aplicación; o lo que es lo mismo: los del aplicativo no tienen que rehacer el paquete cada vez que hay una actualización de seguriad o hay que corregir cualquier cosa que no tenga que ver con su software, se limitan a mantener su programa actualizado.
Red hat ya lo hace (¿te suena fedora silverblue? el concepto es claro: un sistema operativo "que no se puede modificar" y todo el ecosistema de aplicaciones de usuario funcionando desde flatpaks).
#1 En realidad, lo mismo podría decirse de Docker, exactamente lo mismo (no digo que Docker y ésto sean lo mismo porque no tienen la misma finalidad). Pero llega un momento en que prevalecen ciertos requermientos sobre otros y en donde todo tiene cabida. En algunos casos querrás hacer las cosas manualmente para tenerlo afinado como un violín y en otras, dar un botón y que se haga todo ello solito con los valores por defecto más comunes ya preestablecidos.
#7 entiendo. Aún no he aprendido docker.
#7 Solo que docker tiene su nicho en servidores, no en el escritorio.
#20 Creo que toda la peña que instala aplicaciones como HomeAssistant, por poner un ejemplo muy común, estaría en desacuerdo con esa afirmación tan rotunda. La gente está descubriendo que hay aplicaciones (headless) que requieren mucha preinstalación de dependencias (Python con versiones específicas por ejemplo). y que es mucho más sencillo ejecutar un único comando para hacer correr esas aplicaciones:
$docker run -d --name homeassistant -v /home/user/haconfig:/config --network=host ghcr.io/home-assistant/home-assistant:stable
#21 Eso es un servicio para correr en un servidor Que esté en tu casa corriendo en un pc viejo no lo hace una aplicación de escritorio.
#1 ¿Qué recursos? ¿disco? ¿memoria? ¿cpu? ¿todos los anteriores? ¿los gasta innecesariamente o aporta algo a cambio? ¿merece la pena lo que aporta respecto al gasto que supone?
#13 memoria ram, disco y cpu sí. Memoria ram porque carga en memoria librerías que pueden estar ya cargadas en memoria y más cosas. Negligible en ese primer aspecto. Disco porque ocupa bastante más que una aplicación normal. Eso no es negligible en mi caso. CPU (y memoria) porque tiene que montar cada aplicación como si fuera un sistema de archivos independiente para que cada proceso esté montado independientemente. Eso en CPU podría ser negligible también y puede que en RAM también, no lo sé seguro, no he podido comprobar la misma aplicación.
¿Ventajas? Pues garantía de que funciona, sin embargo que no funcionen otros paquetes indica que los que los hacen son unos chapuzas o unos vagos o ambas (la mayor parte de veces). Depende. En mi caso para pycharm sólo pude instalarlo con un snap. Yo sí creo que consume más CPU y memoria que una aplicación normal. Pero es un poco como usar una aplicación basada en Electron (es decir un chrome por debajo). Gasta bastante, pero si hay que usarlo porque no hay más opción...
En cuanto a ventajas, se supone que son aplicaciones más seguras.
#14
RAM y DISCO:
No tiene por qué cargar en ram librerías que ya están cargadas en memoria. Si sólo abres una aplicación en flatpak usando un runtime, si; si hay más de una tirando del mismo runtime, no porque ya se están compartiendo recursos. Por lo demás, lo que consuma normalmente la aplicación. Otros sistemas de empaquetado como snap no sé cómo van y si puede ser que sean más gordotes.
CPU:
Puede que tenga un cierto aumento de uso de CPU de manera marginal, probablemente si más tiempo de arranque, pero prácticamente nada en el uso normal de la aplicación.
Ventajas:
Por lo pronto, aparte de que al tener un runtime probado donde puedes asegurar que la aplicación funcione, estés en la máquina en la que estés, las aplicaciones funcionan en un sandbox; puedes gestionar los permisos y accesos a los recursos de la máquina de manera fina para cada aplicación (la aplicación flatseal te permite hacerlo cómoda y gráficamente), puedes controlar y limitar mejor los recursos que puedes darle a una aplicación, puedes tener en memoria distintas instancias de versiones diferentes de la misma aplicación sin problemas para testear, etc.
Electrón es algo diferente (sutilmente, si quieres), simplemente se usa porque es, no sólo un runtime para que la aplicación funcione como tal, sino todo un entorno completo que aisla todo el acceso a los recursos del SO para poder realizar todo tipo de aplicaciones de manera completamente independiente del mismo. Electrón casi llega a ser un sistema operativo dentro de otro sistema operativo (en realidad los navegadores ya casi lo son y es lo que hace que puedas ejecutar aplicaciones web "en cualquier lado"), en cierto modo es hasta más pesado que una máquina virtual. Sería casi como la diferencia entre un simulador y un emulador, las máquinas virtuales replican los dispositivos de un ordenador, su funcionamiento, etc, mientras que un navegador los emula o abstrae para ser usados a su modo desde dentro.
#17 Sí, en flatpak no sé si es mejor. De hecho no sabía que se comparten recursos. Pero en todo caso se comparten recursos de aplicaciones que usan flatpak ¿no?
Qué interesante todo lo que me has contado, yo sé más o menos eso, pero no a tanto nivel de detalle, me ha resultado instructivo. Gracias.