Flatpak pasará a depender de systemd

• Flatpak ha promocionado como una de sus ventajas el “crear apps para todas las distribuciones”, pero en su próxima versión principal es cada vez más probable que aparezca una dependencia de systemd
• Flatpak Next o Flatpak 2.0 se perfila más como una reescritura para superar las limitaciones de un diseño de hace décadas en la línea 1.x actual, y todavía está en etapa de planificación
• El nuevo servicio systemd-appd asumirá un papel clave al almacenar identificadores de apps y permisos para que otros componentes puedan consultarlos, además de habilitar el sandboxing anidado
• Para distribuciones sin systemd existía la posibilidad de una implementación de daemon independiente, como elogind, pero tras crecer la controversia parece haberse debilitado la disposición de los desarrolladores a contemplarlo
• Si la dependencia de systemd se vuelve estricta, usar Flatpak en distribuciones como Void, Guix y Alpine podría volverse difícil, y también podría debilitarse su neutralidad frente a distribuciones

---

Posible cambio en la neutralidad de Flatpak frente a distribuciones

• El sitio web de Flatpak presenta como primera ventaja “Build for every distro: create one app and distribute it to the entire Linux desktop market.”, y en la lista de distribuciones compatibles incluye también distribuciones como Void Linux, Guix y Alpine, que usan sistemas de init distintos de systemd
• En la actualidad, Flatpak no obliga al usuario a preocuparse por qué sistema de init utiliza, pero en su próxima versión principal aumenta la posibilidad de una dependencia de systemd
• Si este cambio se implementa de verdad, el punto clave será si las distribuciones que no usan systemd podrán seguir ofreciendo Flatpak

Flatpak Next y la dirección del rediseño

• Arian Vovk y Sebastian Wick realizaron una presentación en Linux App Summit sobre el futuro de Flatpak
• La versión actual de Flatpak seguirá recibiendo mejoras, pero cada vez resulta más difícil sortear las limitaciones de un diseño de hace décadas
• El trabajo conocido como Flatpak Next o Flatpak 2.0 se acerca en la práctica a una reescritura que refleja la experiencia acumulada desde Flatpak 1.x
• El nuevo diseño está planteado para aprovechar tecnologías e ideas modernas que se consolidaron después del diseño inicial de Flatpak
• Lo presentado sigue en etapa de planificación, y como todavía no se ha escrito ni una sola línea de código, el resultado podría cambiar mucho durante los próximos años de desarrollo

systemd-appd y el traslado de la gestión de permisos

• Un cambio central en la dirección de desarrollo de Flatpak es mover la gestión de permisos desde el interior de Flatpak hacia una capa de servicios
• El nuevo servicio systemd-appd asignará identificadores a las aplicaciones, almacenará permisos y permitirá que otros componentes del sistema consulten esos datos
• Esta estructura hará posibles varias funciones, y una de las más importantes es el subsandboxing
• El plan actual es incorporar esta función a la versión actual de Flatpak, lo que como resultado introduciría una dependencia de systemd en Flatpak

Espacio para distribuciones sin systemd

• Según la explicación de Vovk, existía la intención de ser “muy considerados” con las distribuciones y usuarios que no usan systemd
• Un modelo previsible sería similar al caso de systemd-logind, que se separó como el daemon independiente elogind, permitiendo que distribuciones con otros sistemas de init también puedan usar entornos de escritorio que dependen de systemd-logind
• Parece que los desarrolladores de Flatpak también intentaron dejar el mayor margen realista posible para que systemd-appd pudiera tener una implementación similar como daemon independiente
• Si ese enfoque se hubiera mantenido, Flatpak podría haber seguido estando disponible en distribuciones que no usan systemd

Crece la polémica y cambia la respuesta de los desarrolladores

• Usuarios de distribuciones como Void o Alpine plantearon su preocupación de que, si Flatpak pasa a depender fuertemente de systemd, podría dejar de funcionar en sus sistemas
• Las preguntas se dirigieron a una persona que no participaba técnicamente en el desarrollo de Flatpak, y sus respuestas en algunos casos fueron poco útiles, insultantes o provocadoras
• A medida que más gente asumió erróneamente que esa persona participaba en el desarrollo de Flatpak, la situación empeoró al mezclarse preguntas serias y amistosas con reacciones airadas de corte anti-systemd
• Como resultado, los desarrolladores de Flatpak llegaron a mostrar una respuesta en el sentido de que no querían dedicar tiempo a contemplar a distribuciones y usuarios que no usan systemd
• Si esta tendencia continúa, la dependencia de systemd podría volverse aún más estricta, y una implementación de daemon independiente que replique las funciones de systemd-appd podría resultar mucho más difícil de lo previsto originalmente

Resultados probables y su significado

• En la situación actual, es alta la posibilidad de que Flatpak termine adquiriendo una dependencia de systemd en los próximos años
• También es posible que desaparezca la consideración de dejar facilidades para crear un daemon independiente que sustituya las funciones de systemd-appd en distribuciones sin systemd
• Si eso ocurre, a Flatpak le resultará difícil seguir defendiendo su neutralidad frente a distribuciones como argumento de que permite distribuir una sola app para todas ellas
• Como Flatpak es una herramienta con demanda real sin importar qué sistema de init use el usuario, este cambio tendría un impacto directo en el alcance de distribución de aplicaciones de escritorio en Linux

[GN⁺]

Opiniones en Lobste.rs

• No entiendo por qué odian tanto a systemd. En lo personal, me parece que ofrece funciones útiles gracias a una API fácil de manejar y una gestión de dependencias y conflictos razonable
  Quienes lo odian muchas veces solo dan razones vagas como “no es Unix”, “está centralizado” o “el formato de archivo de systemd-journald no es texto plano”
  Si se oponen, me gustaría que dijeran razones concretas, soluciones y por qué otros sistemas init son mejores. Entonces se podría explicar por qué los scripts rc son hacks terriblemente desordenados

  • Gran parte de la discusión enlazada en Mastodon, en esencia, no es tanto anti-systemd como anti-centralización. Si Flatpak pasa a depender de systemd, las variantes de Linux que usan otros sistemas init perderán acceso a Flatpak
    La filosofía de Linux, al menos para mí, siempre ha sido fundamentalmente sobre la elección, y si Flatpak requiere un sistema init específico, los usuarios tendrán menos opciones al configurar su sistema para obtener el resultado que quieren
  • Uso systemd sin problema, pero en un caso como Flatpak entiendo la resistencia. Flatpak, en esencia, se trata de “hacer que funcione en cualquier distribución Linux”, así que depender de systemd reduce un poco su utilidad
  • Mi queja concreta con systemd sería más o menos esta: la implementación de journald no me convence, aunque la idea en sí está bien, y en la cola de trabajos, que es la abstracción real con la que systemd gestiona unidades, hay casos límite raros que no están documentados o son difíciles de encontrar
    Debería ser más fácil meterlo en imágenes de contenedor, y el systemd de usuario debería tener acceso por API de lectura a la instancia del sistema para al menos poder programar unidades con cosas como After y Requires
    Aun así, creo que es lo mejor que le ha pasado a Linux desde la eliminación de HAL, e incluso una vez le di la mano a Lennart para agradecerle por el proyecto
  • Quienes de verdad implementan una pila alternativa confiable, como Chimera, no se dedican a difundir FUD y son amables y humildes. En cambio, la turba furiosa en línea explícitamente no tiene una solución, ni la va a tener
    Lo que estos “opositores” realmente plantean, en la práctica, se parece más a que no debería existir ninguna solución. Actúan como una HOA de Linux, y me parecen más bien una política reaccionaria que estorba el progreso de sistemas reales, sólidos, utilizables y competitivos que podrían desplazar a los sistemas operativos monopólicos
  • No odio systemd si solo se usa en sistemas destinados a servir una página web o mostrar una página en un navegador con GUI. Tampoco me molesta usar directamente unidades de systemd para desplegar cosas en un VPS, y si hubiera sido SysV init o upstart, tampoco habría tenido grandes quejas
    Pero en una laptop quiero otra cosa. Tengo una idea de cómo quiero que funcione mi entorno personal, quiero ciertas comodidades que el usuario común de Linux no quiere, y no quiero que pasen cosas que no pedí explícitamente. Me molesta mucho más el esfuerzo de “hacer que no ocurra” que el de “hacer que funcione”
    La razón principal por la que dejé NixOS por systemd fue su alcance cada vez mayor y sus valores predeterminados fuertemente opinados. A medida que se integraron la gestión de energía y el inicio de sesión, tuve que volver a corregir una y otra vez comportamientos como que cerrar la tapa siempre suspendiera el equipo; los cambios en el alcance permitido de linger rompieron nohup y screen, que POSIX exige; y una gestión más estricta de VT obligó a rediseñar al estilo systemd cosas como “iniciar sesión una vez y ejecutar varias instancias de Xorg” o “capturar un VT”
    Al final decidí que era mejor sinit, un init mínimo, y no tener supervisión de servicios, así que escribí mis propios scripts de arranque en shell e implementé algunas funciones del sistema en shell y otras en Common Lisp. En una laptop, algo como PostgreSQL, una vez que arranca, sigue corriendo; si se detiene, me doy cuenta, y si basta con reiniciarlo, es simple; y si no basta, tampoco un supervisor de servicios va a ayudar
    Entre los casos que rompieron mi confianza están una vez en que journald en un HDD, con la caché fría, tardó minutos sin mostrar nada aunque esperé a que imprimiera los logs; haber sufrido personalmente https://github.com/systemd/systemd/issues/2913 ; y que no tuvieran reparos en romper nohup
    También durante el desarrollo me hizo perder confianza la actitud de https://github.com/systemd/systemd/issues/437, que se siente como “damos buenos valores predeterminados, pero si son malos la distribución puede corregirlos”, así como una actitud como la de http://lists.freedesktop.org/archives/systemd-devel/…, reacia a prometer una API estable
    Dicho eso, estas quejas son viejas. Después de ver que systemd resolvía ciertos problemas mientras creaba otros, y que ninguno de los dos era un problema que yo tuviera originalmente, en mi laptop me pasé a scripts de arranque en shell, y ahora el costo de mantenerme así es tan bajo que no tengo motivo para volver a probar systemd. En VPS sí uso systemd dentro del alcance conocido de Debian

• Me frustra que todo esto lo iniciara alguien que no es desarrollador de Flatpak con información incorrecta, provocara una reacción emocional y, mientras avanzaba el hilo original, se fueran sumando expresiones más fuertes hasta que la gente se le fuera encima al proyecto Flatpak y a la reputación de sus desarrolladores
  Como resultado, tampoco sorprende que los desarrolladores reales de Flatpak se vieran afectados emocionalmente y quisieran tomar distancia de la turba furiosa
  Ojalá todos se calmaran y no hicieran crecer más esto. Si hay sospechas o preocupaciones, deberían hablar con los mantenedores reales, mostrar apoyo a encontrar un punto medio y demostrar que esto es un incidente aislado de ciertas personas, no algo que represente a toda la comunidad
  Así como la idea de depender de systemd no era algo decidido sino una propuesta, tampoco creo que esté cerrada la posibilidad de que los mantenedores reconsideren dar soporte a una mayor variedad de proyectos

• Ojalá la gente se lleve lo bastante bien como para que se pueda seguir dando soporte a sistemas que no corren sobre systemd. Flatpak y otros métodos basados en contenedores ayudan a los usuarios a ejecutar paquetes que no se pueden compilar fácilmente para la plataforma de destino, y estaría bien poder correr Flatpak sobre esos sistemas cuando se necesita cierto software
  Los contenedores cumplen una función parecida, pero hacer que algo como x11docker funcione bien en configuraciones lo suficientemente inusuales es molesto y sorprendentemente complicado

  • Llevo más de 10 años usando Void con satisfacción. Ni siquiera recuerdo la última vez que me preocupé por el sistema init o la integración con systemd. Gracias por todo el trabajo puesto en Void

• Uso Void en mi laptop; es eficiente para trabajar y la documentación está bastante bien. Gracias por todo el trabajo que han hecho los desarrolladores, y ojalá que el cambio de Flatpak no termine siendo una carga demasiado grande.

• “Esto es el Linux moderno, y solo queda systemd.”
  Me recuerda con claridad que la comunidad Linux se parece más a WeWork que a una comunidad. Mientras todos a tu alrededor cobran su sueldo dependiendo de la existencia de Red Hat, alguien está hackeando GNU readline gratis.

  • No me parece difícil decir que el texto acierta en esta parte: lo de “atrae a fanáticos anti-systemd y conspiranoicos de Red Hat (y peores)”.

• A estas alturas, parece demasiado pronto para afirmar categóricamente que “pasará a depender de eso”; suena muy especulativo.

• Es interesante que el título sea mucho más tajante que el cuerpo del texto. Muchos comentarios claramente están reaccionando solo al título y, por suerte, no todos, pero esto no es nada nuevo en internet.
  Últimamente también me preocupa ver en lobste.rs que la gente reacciona solo al título o a una sola frase dentro de un comentario largo. Casi nunca dejan espacio para otras posibilidades aparte de la primera interpretación que se les ocurre, que a menudo es agresiva.
  Al leer el texto, parece que algo parecido pasó también en la conversación sobre Flatpak 2.0. Da la impresión de que intentaron dejar abierta la puerta para otros sistemas de init, pero el discurso alrededor se volvió hostil tan rápido que en la práctica lo abandonaron.

• Desde la perspectiva de alguien que usa un sistema de init alternativo, esto es realmente frustrante. Tengo una laptop corriendo Alpine Linux y he estado usando Flatpak para ejecutar software que solo funciona con glibc. Este cambio va a hacer que abandone ese entorno.
  No odio systemd. Todos mis sistemas Gentoo usan systemd. Lo que no me gusta es la manera en que systemd hace que el software libre y de código abierto dependa cada vez más de GNU/Linux.

• Esto claramente es algo bueno.
  systemd está compuesto por demonios con APIs estables y bien definidas, así que cualquier parte de systemd de la que Flatpak pase a depender podría reimplementarse limpiamente desde cero si alguien le dedicara el esfuerzo.
  Es el mejor resultado posible. Se reduce la fragmentación, y la gente con necesidades particulares obtiene un objetivo estable para reimplementar.

  • Al principio empecé a leer pensando que era sarcasmo, pero no lo era.
    Las APIs de systemd suelen estar definidas de forma ambigua en las páginas man, y como del lado de systemd no esperan otras implementaciones, tampoco son estables ni versionadas en ambos sentidos.
    En el caso del API del socket notify, en realidad solo es estable en la dirección contraria. Agregar soporte para vsock rompió en la práctica a los demonios implementados sin depender de libsystemd. La razón por la que esta rotura no es muy conocida es que vsock se usaba sobre todo para comunicación entre systemd a través de fronteras de virtualización. Si hubiera estado bien diseñado, lo habrían hecho como una extensión usada solo en ese límite.
    Se habla de “demonios”, pero en la práctica casi todo es logind y systemd, y como esos dos exponen toda la superficie del API, las posibilidades de combinación son limitadas. Lo hacen mediante algunas interfaces DBus, ahora también varlink, y una sola biblioteca.
    Para reemplazar systemd, o bien hay que reemplazarlo completo y hacer el difícil trabajo de adaptar el modelo interno para exponer APIs al estilo systemd, o primero hay que desarmar las decisiones de diseño de las APIs de systemd y crear una capa intermedia con backends conectables.
    Llevo años lidiando con este problema. Me parecen válidos muchos de los principios de diseño de systemd, pero el diseño actual pone al frente una complejidad que la mayoría de la gente no necesita. Se podría hacer un diseño más modular e intercambiable, y también es relativamente fácil imaginar o reutilizar diseños de interfaces simples y separables.
    Pero el problema es el software que elige depender de las APIs de systemd. Para hacerlo funcionar con otra cosa, hay que lograr que upstream acepte parches que separen el soporte de funciones atadas a libsystemd completo, o agregar soporte para nuevos APIs individuales; lo primero nunca ha funcionado, y lo segundo es difícil de aceptar por la carga de mantenimiento de APIs minoritarios o previos al lanzamiento.
    O también se puede implementar solo el API que usa el software. Por ejemplo, usando un servicio DBus login1 que no implemente la mayoría de las APIs. Pero entonces eso entra en conflicto con otras implementaciones que intenten reemplazar otras partes del API, y termina habiendo que implementar tres variantes: el API original limpio, el API DBus de logind/systemd y el API para varlink.
    A largo plazo, una posible solución sería un router que implemente toda el API de systemd o logind y por detrás lo conecte con APIs separadas. Pero el diseño actual tiene una redundancia extrema y una especificidad hacia systemd tan metida de fondo que hacerlo bien es muy complejo.
    No sé si esa era la intención, pero por lo que dicen los desarrolladores de systemd, como mínimo fue un problema que decidieron no atender. Crear una capa intermedia compleja o hacer un reemplazo de systemd sin reescribir systemd es muy difícil, y aunque una aplicación dependa solo de una parte del API que podría ofrecerse como piezas aisladas, en la práctica es casi imposible reemplazar limpiamente una sola parte de systemd.
  • ¿De verdad sigue siendo cierto hoy que se puede reimplementar limpiamente desde cero una parte de systemd? El texto pone a elogind como ejemplo.

• No me gusta la forma en que Red Hat tiene demasiado control sobre el ecosistema Linux.

  • A mí tampoco, pero hoy en día no tengo claro cuánto control tiene realmente Red Hat sobre systemd.
  • Es bien contradictorio. Centralizar el control es malo, pero pagarle a la gente para que haga software libre y de código abierto es bueno. Y buena parte del control que obtienen viene precisamente de pagarle a la gente para que haga software libre y de código abierto.
    Aun así, el hecho de que Red Hat haya adoptado el software libre sí ayuda a aliviar en parte las preocupaciones por su influencia. Si miras las tecnologías que compró a lo largo de los años, en algunos casos incluso creó por su cuenta un upstream libre y de código abierto para cosas que antes ni siquiera lo tenían. Me vienen a la mente especialmente Dogtag PKI y 389 Directory Server.
    En términos generales, no me parece que haya sido algo especialmente malo para el ecosistema; diría que lo ha hecho avanzar más de lo que lo ha perjudicado.

• No tengo nada en juego directamente en esta discusión, pero aquí no hay nada que reduzca la inquietud por la complejidad y abstracción innecesarias que no dejan de crecer en los sistemas Linux.
  Linux se está convirtiendo rápidamente en el Java de los sistemas operativos. Es realmente triste.