Lennart Poettering ha publicado un interesante artículo en el que nos muestra su visión sobre la organización de las distribuciones linux, en particular todo lo referente a simplificar el empaquetado y gestión de software.
La idea de Lennart es facilitar la instalación de programas independiente de la distribución utilizada, superando la habitual relación que se establece entre los desarrolladores upstream que crean el software y los desarrolladores de la distro que se encargan de empaquetarlo, habitualmente en dpkg o RPM, algo que tiene sus ventajas en cuanto a seguridad o solución de bugs, pero también algunos inconvenientes.
Entre ellos la dificultad de coordinar el ciclo de liberación de productos entre los desarrolladores upstream y el de las distribuciones, o la necesidad de construir diferentes paquetes para cada distribución (con sus dependencias asociadas) y comprobar que funcionan correctamente.
La solución que propone el creador de systemd, es similar a las tiendas de aplicaciones que dominan en iOS o Android. Los usuarios finales serían capaces de instalar los mismos paquetes independientemente de la distribución que estén usando.
Algo similar a lo que ya están haciendo de forma parcial soluciones como Ubuntu Apps, Docker, Software Collections, ChromeOS y CoreOS, ahora se llevaría a cabo de forma integral gracias al uso intensivo del sistema de subvolúmenes de los archivos Btrfs y el espacio de nombres de archivos de linux.
Una solución unificada que permitiría actualizar e instalar versiones de sistemas completos, Linux containers, bibliotecas, frameworks o aplicaciones de usuario final, criptográficamente verificable y segura para el usuario.
En una primera propuesta habría 6 subvolúmenes con las siguientes características:
- usr:<vendorid>:<architecture>:<version> Esto se refiere al «árbol» del un proveedor de un sistema operativo completo
org.fedoraproject.FedoraWorkstation: x86_64: 23.4
- root:<name>:<vendorid>:<architecture> Este subcontenedor se refiere a una instancia de un sistema operativo.
org.fedoraproject.FedoraWorkstation: x86_64
- runtime:<vendorid>:<architecture>:<version> en este caso se refiere a un vendedor runtime (tiempo de ejecución). Aquí podrían entrar el conjunto de bibliotecas para ejecutar aplicaciones.
runtime:org.gnome.GNOME3_20:3.20.1
- framework:<vendorid>:<architecture>:<version> contiene todas las herramientas de compilación y desarrollo, permitiendo ejecutar frameworks
framework:org.gnome.GNOME3_20:3.20.1
- app:<vendorid>:<runtime>:<architecture>:<version> En este caso encapsula un paquete de aplicaciones
App: org.libreoffice.LibreOffice: GNOME3_20: x86_64: 133
- .home:<user>:<uid>:<gid> Se refiere al directorio home de un usuario específico
home:kate:1000:1000
En total serían varios subvolúmenes de Btrfs que actuarían como bloques para formar el sistema operativo o mejor incluso porque tal como explica Lennard:
permite instalar no sólo múltiples aplicaciones de usuario final en el mismo volumen Btrfs, sino también varios sistemas operativos, varias instancias del sistema, múltiples tiempos de ejecución, múltiples marcos de trabajo.
Es decir… para poner un ejemplo, podríamos tener openSUSE, Debian y Arch instalados con diversas ediciones de KDE o GNOME, y ejecutando diferentes versiones de Firefox, que se podrían combinar todo a gusto del usuario.
Una ventaja que tiene Btfrs es la posibilidad de revertir cualquier tipo de cambio fácilmente gracias a sus copias de seguridad instantáneas, aunque los desarrolladores de systemd tienen la intención en un futuro de dar cobertura también sistemas de archivos como ext4 o xfs, con lo cual sin duda se eliminarían unas cuantas reticencias al respecto.
Es un proyecto ambicioso que llevará tiempo, porque supone una revolución en cuanto al funcionamiento de las distribuciones y obviamente depende del interés de estas para poderse realizar (a menos que a Poettering le de por crear su propia distro, claro), y del que si queréis conocer más, como siempre os remito al artículo original donde está todo técnicamente mucho mejor explicado.
Imagen | rore (CC BY-SA 2.0)
Enciendo una vela en favor de esta iniciativa. Ya era hora de que alguien con influencia pusiera sobre la mesa este debate. Me parece fundamental para animar a más desarroladores a implementar aplicaciones para GNU/Linux.
Si se pusiera en marcha una iniciativa crowdfunding para respaldar un proyecto de estas características, yo sería el primero en colaborar.
Hum no me parece una cosa fácil de hacer, pero seria muy interesante creo.
Del creador de proyectos que nos han dado tantos problemas como pulseaudio y systemd, viene la idea de instalar varios GNU/ Linux en tu sistema para que corran a la vez y puedas navegar al mismo tiempo en el Firefox de OpenSuSE y en el de Arch Linux…
Yo no le veo sentido, claro que ni soy informático ni soy experto en GNU/ Linux. LXC puede arrancar programas pertenecientes a otro GNU/ Linux instalados en contenedores, lo que acabaría con el problema de que un programa no esté en tu distro, y Gnome está aislando cada aplicación, lo que daría más seguridad y estabilidad; más allá de eso, ¿para qué quiero estar corriendo dos sistemas a la vez?
Si queremos que GNU/Linux triunfe creo que no hay que hacer «frikadas complejas» con el pretexto de que el usuario instale aplicaciones de forma sencilla. Muon, Yast y ubuntu store son sencillisimos, más que windows.
No les ves sentido porque no lo tiene para el usuario final. ¿Para que coño quiere el usuario final varios sistemas operativos y varias versiones del mismo programa? Un programador SI, un usuario NO.
a) Que las cosas funcionen.
b) Más funcionalidades, hacer más cosas.
c) interoperabilidad
Este invento se suma a la versionitis de APIs, librerias/frameworks o la madre que las parió que hace que los programadores no nos den a los usuarios mejoras sino nuevas versiones con nuevas librerias. Pues vale.
mal vamos programadores mios…. eso si pronto QT 6,3 y GTK 4.7.34 que será la hostia! ¿para programar?
Más razón que un santo y no puedo estar más de acuerdo.
Opino igual..
ea, para cuando LennartOS?
Esto huele a lennartOS. Ya lo leí en los irc cuando nació systemd, sobre todo a los developers de centos que aun al no ser empleados no tenían que ser complacientes. Estas cosas me lo confirman, el paso siguiente sera a partir desde sistema implementar rpm o algún empaquetado que el creará
Pues si él es el que le da la patada a los «fragmentadores», lo encumbro como mi ídolo.
Pingback: El creador de systemd propone una nueva forma d...
Hola. Leí de alguien comentar, que el sistema de archivos Btrfs haría más lento el sistema, a diferencia de Ext4. ¿Qué de cierto?
¿Qué tal va el elegir Btrfs al instalar openSUSE 13.1? usuario nuevo.
Y la seguridad, camaradas, la seguridad donde queda con semejante arborescencia?
Exacto.
No entiendo mucho, pero si entiendo que SystemD se mete donde no tiene que hacerlo. Que puede comprometer la seguridad-privacidad del sistema independientemente de lo segura que sea nuestra distribución. Y lo va a dominar una sola empresa Redhat. La NSA no había metido las zarpas en Redhat?
Más que el creador de systemd, todos lo recordaremos por haber creado el mal más grande de linux, pulseaudio. Ya no me fío de este hombre.
El problema de PulseAudio no es el el servicio en si, que sobre el papel es muy bueno y de hecho ha ayudado a automatizar muchas cosas, de hecho aun recuerdo cuando tenía que silenciar los altavoces del portátil para darle volumen a los externos cuando usaba ALSA, que funcionaba mejor, pero era un puñetero dinosaurio.
El problema de PulseAudio es que Red Hat se empecinó en implementarlo cuando estaba aun muy verde y claro, se llevaron por delante la mayoría del soporte para tarjetas de sonido en GNU/Linux, y luego se tuvo que improvisar y ahora da muchos problemas en tarjetas que no sean muy recientes, porque tiene gracia que mi netbook, el ordenador que peor suena de todos los que tengo, el único donde da cero problemas.
Con systemd están midiendo mejor los pasos, quizá debido al desastre de PulseAudio. No puedes meter por cojones como estable un software que no se puede decir que esté ni en beta, sino en alfa, como pasó con PulseAudio.
El problema que tiene GNU/Linux es que le ha costado aprender de que no se pueden ir metiendo cambios a diestro y siniestro, porque si, a lo mejor en sí mismo el software es mejor, pero también tienes que medir los daños colaterales, cosa que nunca se ha hecho. Ahora se mira un poquitín, aunque no sea mucho, pero antes a los desarrolladores les importaba un carajo mandarlo todo al diablo si con sus cambios demostraban que la tenían más larga que nadie.