Systemd a través de los ojos de un mantenedor de una distribución musl
El movimiento de Linux hacia systemd como gestor dominante de init y servicios es elogiado por elevar el nivel en fiabilidad, manejo de dependencias y funciones modernas, pero criticado por crear un monocultivo frágil y entrelazar muchas funciones del sistema bajo un mismo paraguas. Los comentaristas destacan puntos de dolor concretos —desde el registro binario y las peculiaridades de systemd-resolved hasta la complejidad, la superficie de seguridad y el mal encaje en entornos pequeños o embebidos—, aunque reconocen que su integración estrecha a menudo “simplemente funciona” en entornos de escritorio y empresariales dinámicos. Se mencionan alternativas como OpenRC, s6 y nosh, pero muchos señalan que las dependencias del ecosistema y las decisiones de gobernanza de los proyectos dificultan que enfoques competidores ganen tracción real.
Monocultivo, gobernanza y competencia
- Muchos coinciden en que systemd resolvió problemas reales (paralelismo en el arranque, supervisión, dependencias), pero temen que su dominio cree un monocultivo que bloquee alternativas y obligue a la compatibilidad con errores.
- Otros sostienen que la “multicultura” anterior a systemd era caótica e inferior; systemd simplemente superó a la competencia.
- Algunos ven la forma en que las distros hicieron systemd de facto obligatorio (especialmente en Debian) como un fracaso de gobernanza y una fuente de resentimiento duradero.
- Unos pocos creen que dar soporte a múltiples sistemas init es viable, pero requiere recursos e interés; se cita Gentoo como prueba.
Alcance de PID 1 y arquitectura
- Debate sobre lo que PID 1 “debería” hacer: un programa mínimo del primer espacio de usuario vs un orquestador central para procesos, montajes, red y más.
- Algunos defienden poner la gestión de procesos en PID 1 por las garantías fuertes; otros ven la acumulación de funciones (NVMe-over-TCP, etc.) como una hinchazón de “cajón de sastre”.
Gestión de servicios y experiencia de administración
- Muchos administradores elogian systemd por su tooling estandarizado, las dependencias entre servicios/montajes/sockets, el descenso de privilegios más sencillo y la agregación de logs por unidad de journald.
- Otros reportan problemas: tiempos de espera durante el arranque/apagado, dificultad para interrumpir unidades fallidas e instancias por usuario confusas (linger, loginctl).
- La activación por socket y los diseños al estilo inetd dividen opiniones: algunos ven los listeners centrales como más seguros y simples; otros consideran los super-servidores un anti-patrón y un riesgo de DoS.
Registro (journald) y complejidad
- Los journals binarios con metadatos ricos se consideran potentes para el registro centralizado, pero:
- Son más difíciles de usar con herramientas de texto tradicionales (grep/rsync).
- Son más lentos y a veces se corrompen, lo que lleva a afirmar que están “reinventando una base de datos”.
- Los muchos tipos de unidades y rutas de búsqueda de systemd mejoran la flexibilidad, pero perjudican la “localidad del comportamiento”, haciendo que los sistemas sean más difíciles de razonar.
DNS y red (systemd-resolved)
- resolved recibe críticas significativas: problemas con DNSSEC, comportamiento frágil en configuraciones no triviales y confusión sobre su preparación para producción.
- Sus partidarios destacan funciones como DNS dividido vinculado a interfaces/VPN y la integración estrecha con otros componentes de systemd; los críticos señalan que configuraciones similares son posibles con dnsmasq, aunque con más pegamento.
Alternativas y reescrituras
- Se mencionan varias alternativas: OpenRC, s6/66suite, runit, dinit, nosh y reimplementaciones en Rust que buscan compatibilidad parcial con systemd.
- Algunos creen que con el tiempo podría surgir un sucesor más limpio al estilo de PipeWire, pero temen que el ritmo de systemd y el bloqueo del ecosistema lo hagan difícil hoy.