Por qué systemd genera tanta polémica en el mundo Linux

systemd lleva activo como PID 1 en la mayoría de distribuciones Linux desde 2015. A estas alturas gestiona el arranque de tu sistema, los logs, la resolución DNS, las sesiones de usuario, el reloj, los dispositivos de hardware y bastantes cosas más. Y si llevas año y medio en Linux ya habrás notado que en cualquier foro donde alguien lo mencione, aparece alguien a recordarte que es la ruina del ecosistema.

La pregunta razonable es: ¿por qué? No es propietario. Funciona. ¿De qué va todo esto?

#Qué hace realmente un init system

Para entender la polémica hay que saber qué problema resuelve un sistema init. Cuando el kernel arranca, lo primero que ejecuta es un único proceso con PID 1. Ese proceso es el padre de todo lo demás: arranca los servicios del sistema, gestiona las dependencias entre ellos y supervisa que no se caigan. Si algo muere sin que deba, PID 1 lo nota.

Durante décadas ese proceso fue SysVinit, un sistema basado en scripts de shell ordenados numéricamente. Arrancar la red antes que el sistema de ficheros, arrancar el sistema de ficheros antes que los servicios que lo necesitan… todo se gestionaba con scripts que el administrador podía leer y modificar con cualquier editor de texto.

Era lento porque era secuencial. Era predecible porque era simple. Y era un cacharrito de los años 80.

#Qué propuso systemd en 2010

En abril de 2010, Lennart Poettering, ingeniero de Red Hat, publicó un post titulado «Rethinking PID 1» donde explicaba por qué SysVinit era una reliquia y presentaba systemd como su sucesor.

Las promesas iniciales eran concretas: arranque paralelo de servicios (en vez de secuencial), gestión declarativa de dependencias, reintentos automáticos si un servicio muere, y una interfaz unificada para controlar todo mediante systemctl. Nada de esto era descabellado. El arranque en paralelo es una mejora real y visible para cualquiera que haya cronometrado el boot de un servidor.

El problema es lo que vino después.

#El problema real: absorción progresiva de funciones

systemd empezó como un gestor de servicios. Hoy incluye, entre otras cosas:

• systemd-journald — logging del sistema en formato binario
• systemd-resolved — resolución DNS
• systemd-networkd — configuración de red
• systemd-logind — gestión de sesiones de usuario
• systemd-udevd — gestión de dispositivos de hardware
• systemd-boot — gestor de arranque UEFI
• systemd-homed — gestión de directorios home de usuario
• systemd-timesyncd — sincronización NTP

Cada uno de esos componentes antes lo cubría una herramienta separada, independiente, reemplazable. rsyslog para los logs. dnsmasq o resolv.conf directo para DNS. NetworkManager o scripts para la red. ntpd para el reloj. El principio Unix de que cada herramienta hace una sola cosa bien, y que puedes encadenarlas o sustituirlas a tu gusto.

systemd absorbió todo eso en un sistema acoplado. No es que los componentes sean malos por separado — muchos funcionan correctamente. La crítica es que están diseñados para funcionar juntos, y separar uno del resto se vuelve cada vez más complicado. Cuando una distro adopta systemd, tiende a adoptar el ecosistema completo porque es lo que los paquetes esperan encontrar.

«systemd viola el principio de hacer una sola cosa bien. Hace demasiadas cosas, y cuando algo falla en esa cadena integrada, el debugging se convierte en una expedición por capas de abstracción que nadie pidió.»

#El asunto de journald y los logs binarios

Este es el punto que más enfada a los administradores de sistemas con experiencia. Y tiene cierta razón de ser.

Antes de systemd, los logs del sistema eran ficheros de texto plano en /var/log/. Para ver qué pasó a las 3 de la mañana en un servidor hacías grep "error" /var/log/syslog y listo. Sin dependencias. Sin herramienta específica. Con cualquier editor, con cat, con awk, con lo que tuvieras a mano en un sistema de recuperación sin interfaz gráfica.

systemd-journald guarda los logs en formato binario. Para leerlos necesitas journalctl. Si el journal se corrompe — cosa que ocurre con más frecuencia de lo que debería ante un corte de luz o un fallo de disco — la recuperación se complica.

Los defensores de journald señalan con razón que el formato binario permite indexación completa, filtrado por campo, compresión nativa y sellado criptográfico de logs para auditoría. Son ventajas reales. Pero para alguien que lleva 20 años debuggeando sistemas con tail -f y grep, sentirse obligado a aprender una nueva herramienta para leer logs — una función que antes era trivial — genera el tipo de irritación que no se olvida fácilmente.

#El origen político: Red Hat, Debian y la guerra del init

Buena parte del odio a systemd no es técnico. Es político, en el sentido de «quién decide qué entra en Linux».

systemd fue diseñado y liderado por ingenieros de Red Hat. Red Hat es una empresa, y una de las más influyentes del ecosistema Linux. Cuando systemd empezó a ganar tracción, muchos en la comunidad lo percibieron como una empresa imponiendo sus decisiones de diseño al resto del ecosistema, no como un proyecto nacido del consenso comunitario.

El momento de mayor tensión fue 2014, cuando el Comité Técnico de Debian votó adoptar systemd como init predeterminado. El debate fue tan acalorado — con acusaciones cruzadas y renuncias de miembros del comité — que un grupo de desarrolladores creó Devuan, un fork de Debian diseñado explícitamente para mantenerse libre de systemd. Existe todavía hoy y tiene usuarios activos.

Ubuntu, que en aquel momento usaba su propio sistema init llamado Upstart (desarrollado por Canonical), anunció ese mismo año que abandonaría Upstart y adoptaría systemd. El cambio llegó con Ubuntu 15.04 en 2015. En cuestión de meses, las principales distribuciones del mundo habían migrado.

#GNOME y la dependencia que nadie pidió

Hay otro factor que radicalizó posturas: GNOME declaró systemd como dependencia obligatoria. Si quieres usar GNOME — el entorno de escritorio más extendido en distribuciones Linux de escritorio — necesitas systemd, o al menos systemd-logind para la gestión de sesiones.

Esto cerró la puerta a usuarios que querían GNOME con OpenRC o runit. No es técnicamente imposible de parchear, pero sí supone un trabajo de mantenimiento constante. La sensación de muchos fue que el ecosistema se estaba diseñando activamente para hacer inviable la alternativa. Eso genera rencor duradero.

#Las alternativas que siguen vivas

El debate no mató a los sistemas init alternativos. Hay distribuciones que los mantienen como primera opción:

• OpenRC — usado por Gentoo y Alpine Linux. Script-based, modular, maduro. Es la alternativa más accesible para alguien que viene del mundo SysV.
• runit — minimalista y muy rápido. Lo usan Void Linux y Artix Linux. Su codebase tiene menos de 40.000 líneas.
• s6 — el más técnicamente riguroso en supervisión de procesos. Muy usado en contenedores y entornos embebidos. Curva de aprendizaje considerable.
• dinit — más moderno, con gestión de dependencias similar a systemd pero sin la acumulación de componentes extra.

Si quieres explorar sin comprometerte con una distro entera, Artix Linux te deja elegir el init en la instalación. Misma base que Arch, sin systemd.

#¿Merece la pena el drama?

Depende de qué seas.

Si llevas año y medio en Linux y usas Ubuntu o Fedora para tu escritorio o para aprender, systemd no es tu enemigo. Aprende systemctl, aprende journalctl, y sigue adelante. El 99% de la documentación que encontrarás asume systemd. La compatibilidad de software es masivamente mejor en distribuciones systemd. Y si algo falla, la comunidad que puede ayudarte es mucho más grande.

Si administras servidores, sobre todo en entornos donde la predictibilidad importa — pienso en servidores con alta disponibilidad donde un reinicio de systemd-resolved puede dejarte sin DNS durante diez segundos — entonces las críticas de complejidad y acoplamiento cobran otro peso. En esos contextos he visto a gente de sistemas perfectamente razonable elegir Alpine con OpenRC por razones que tienen muy poco que ver con la ideología y mucho con el comportamiento real del sistema bajo presión.

Las críticas filosóficas de violación del principio Unix son legítimas. El diseño de systemd va en la dirección contraria a lo que la tradición Unix enseñó durante 40 años. Eso no lo convierte en malo — Windows tampoco sigue la filosofía Unix y funciona — pero explica por qué los usuarios más veteranos lo miran con suspicacia estructural.

Lo que es difícil de defender es el nivel de toxicidad del debate original. Parte del odio a systemd no viene de sus defectos técnicos sino de cómo se manejaron públicamente las críticas en 2013 y 2014. Algunas de esas discusiones en listas de correo quedarán para los anales de cómo no se gestiona un proyecto de software libre con impacto masivo. El daño reputacional de aquella época todavía flota.

Lo que sí tiene sentido es entender los argumentos. No para sumarte al drama, sino porque saber por qué el ecosistema tomó las decisiones que tomó te hace mejor administrador de sistemas, uses systemd o no.