systemd en postmarketOS

Hace poco los desarrolladores del proyecto postmarketOS, dieron a conocer mediante una publicación de blog la noticia de la introducción de systemd a las compilaciones del sistema. La razón principal para implementar el soporte de systemd es la dificultad de mantener una pila de inicialización basada en OpenRC frente a la creciente dependencia de GNOME y KDE de los componentes de systemd.

La disponibilidad de utilizar systemd como administrador del sistema llega despues de un año de trabajo y se han preparado y puesto a disposición de pruebas un montaje prototipo en el que se utiliza systemd en lugar del sistema de inicialización OpenRC.

Se menciona que a pesar de la incorporación de systemd, se seguirá brindando soporte para la creación de compilaciones basadas en OpenRC en postmarketOS, al menos mientras este sistema siga siendo utilizado en Alpine Linux. La opción de seleccionar OpenRC estará disponible al crear imágenes de postmarketOS utilizando pmbootstrap. Además, OpenRC continuará siendo utilizado por los desarrolladores de ensamblajes que trabajan con el shell gráfico Sxmo (Simple X Mobile), basado en el administrador compuesto Sway.

Por otro lado, las compilaciones con systemd seguirán basándose en el paquete base de Alpine Linux, a pesar de que esta distribución no cuenta con compatibilidad oficial con systemd y utiliza la biblioteca Musl C en lugar de Glibc C, la cual es compatible con systemd. Los desarrolladores de postmarketOS están implementando parches adicionales para integrar systemd con Musl C y tienen planes de colaborar con los desarrolladores de systemd para simplificar esta integración en el futuro.

Por supuesto, esta no es una tarea fácil, uno de los principales obstáculos que encontramos a medida que colaboramos más estrechamente con los desarrolladores de KDE y GNOME es que tienen dificultades con nuestra pila basada en OpenRC. Para que KDE y GNOME funcionen, utilizamos muchos polyfills de systemd además de OpenRC. Entonces, aunque técnicamente «no usamos systemd», en la práctica ya usamos una gran parte de sus componentes para ejecutar KDE y GNOME, solo versiones diferentes de esos componentes

Para garantizar la funcionalidad de GNOME y KDE basados en systemd, se requería mantener varias capas adicionales, ademas de que el trabajar sin systemd implicaba mantener estas capas de manera adecuada y sincronizarlas con el desarrollo de GNOME y KDE, lo que planteaba desafíos significativos y cierta incertidumbre en el mantenimiento continuo por parte de los desarrolladores.

Además de ello, los desarrolladores mencionan que se implementaron diversas capas y paquetes para garantizar la compatibilidad con servicios con nombre de host, localizados y con fecha y hora en postmarketOS. Esto incluyó el uso de openrc-settingsd para la compatibilidad con servicios con nombre de host, eudev en lugar de udev para la gestión de dispositivos, elogind en lugar de logind para la gestión de sesiones de usuario, y logbookd en lugar de journald para la gestión de registros y se empleó el paquete superd para proporcionar funcionalidad similar a «systemd –user» y reemplazar systemd.timer con waked.

Sin embargo, el mantenimiento y soporte adecuado solo se garantizan para openrc-settingsd y eudev. Proyectos como elogind, logbookd y superd aún requieren mejoras, ya que carecen de algunas características necesarias, y waked no ha recibido mantenimiento durante aproximadamente un año. Además, los desarrolladores de KDE Plasma Mobile expresaron su interés en utilizar systemd-coredumpd para simplificar la depuración, pero su reemplazo, corecollector, no ha recibido mantenimiento desde 2020.

Estos servicios son necesarios para diversas funciones en GNOME y otras aplicaciones. Por ejemplo, la API D-Bus proporcionada por hostnamed, localed y timedated se utiliza en GNOME para cambiar configuraciones regionales y de zona horaria. Udev se requiere para administrar dispositivos conectados, mientras que logind, «systemd –user» y journald se utilizan para gestionar sesiones de usuario en gnome-session. GNOME Clock utiliza systemd.timer para sus funcionalidades.

En términos de nuevas características que pueden implementarse con compilaciones basadas en systemd, se incluye la administración granular de privilegios, el uso de funciones avanzadas para garantizar la seguridad y administrar dependencias entre servicios, la integración completa con cgroups, la activación de socket para iniciar servicios según sea necesario (por ejemplo, CUPS puede iniciarse solo al acceder al puerto de red), y la disponibilidad de herramientas integradas para analizar el proceso de arranque.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.