Pocas discusiones han partido a la comunidad Linux como la del sistema de init. Detrás de un tecnicismo de apariencia menor —qué programa arranca primero al encender el ordenador— había un choque de filosofías sobre cómo debe construirse un sistema operativo. Esta es la historia de esa guerra.
¿Qué es exactamente un sistema init?
Cuando el kernel de Linux termina de cargarse, lanza un único proceso y le asigna el identificador PID 1. Ese proceso, el sistema init, es el padre de todos los demás: monta los sistemas de ficheros, levanta los servicios de red, arranca los demonios y mantiene el sistema en marcha hasta que lo apagas. Si muere, el kernel entra en pánico. Por eso elegir el init no es un detalle trivial: define cómo arranca, cómo se gestiona y cómo se comporta toda la máquina.
SysV init: la vieja escuela
Durante décadas el estándar fue el init de System V, heredado del UNIX comercial de los años ochenta. Su modelo era sencillo y predecible: una serie de scripts de shell ejecutados en secuencia, organizados en runlevels (niveles de ejecución). Distribuciones como Slackware lo mantuvieron como bandera de simplicidad.
La virtud de SysV era su transparencia: quien supiera leer un script de shell podía entender y modificar el arranque. Su defecto era la lentitud. Al ejecutar los scripts uno tras otro, sin paralelizar, los arranques se eternizaban a medida que crecía el número de servicios. En la era de los SSD y de los portátiles que debían encender en segundos, ese modelo empezó a quedarse corto.
Upstart: el intento de Canonical
En 2006 Canonical presentó Upstart, escrito por Scott James Remnant. Llegó con Ubuntu 6.10 “Edgy Eft” para sustituir a sysvinit, y proponía otra manera de hacer las cosas: en vez de seguir un orden rígido, Upstart reaccionaba a eventos (un disco montado, la red disponible, hardware detectado) para arrancar o parar servicios sobre la marcha. La idea acortaba los tiempos de arranque y manejaba mucho mejor el hardware conectado en caliente.
Upstart tuvo recorrido: fue el init por defecto de Red Hat Enterprise Linux 6 y de Chrome OS. Pero arrastraba un lastre político. El acuerdo de cesión de derechos (CLA) de Canonical obligaba a los colaboradores a ceder la potestad de relicenciar el código, algo que buena parte de la comunidad Debian veía con recelo. Ese roce acabaría pesando.
systemd: el ganador que dividió aguas
En 2010, Lennart Poettering y Kay Sievers, entonces en Red Hat, publicaron un manifiesto titulado “Rethinking PID 1” y presentaron systemd. Su propuesta era de las que no se quedan a medias: no un simple init, sino una suite completa que arrancaba servicios en paralelo mediante activación por sockets y se ocupaba además del registro de logs, los dispositivos, la red, las sesiones y mucho más, todo bajo un mismo paraguas.
La adopción fue rápida. En mayo de 2011, Fedora se convirtió en la primera gran distribución en activar systemd por defecto, en lugar de Upstart. openSUSE y otras siguieron el camino. El golpe definitivo llegó con Debian: tras un debate encendido entre octubre de 2013 y febrero de 2014, su Comité Técnico decidió por un margen muy estrecho adoptar systemd como init por defecto de Debian 8 “Jessie”. A partir de ahí, Ubuntu abandonó su propio Upstart y migró a systemd en la versión 15.04.
La votación de Debian fue tan reñida que dejó cicatrices. En 2014 se lanzó incluso una campaña pública de boicot, y el propio Linus Torvalds expresó reservas sobre la actitud de algunos desarrolladores de systemd hacia los usuarios y los informes de errores.
La filosofía UNIX en el banquillo
El núcleo del conflicto no era técnico, sino filosófico. La tradición UNIX predica “haz una sola cosa y hazla bien”: herramientas pequeñas, especializadas y combinables. systemd, al absorber funciones que antes vivían en programas independientes, parecía ir contra ese principio. Sus defensores respondían que la integración aportaba coherencia, velocidad y capacidades que el viejo modelo no daba; sus críticos veían un monolito que concentraba demasiado poder en un solo proyecto.
Las alternativas que resisten
systemd ganó la guerra de las grandes distribuciones, pero no la dio por zanjada. Sobreviven varias alternativas con comunidades fieles:
- OpenRC, init basado en dependencias y que mantiene la compatibilidad con sysvinit, es el predeterminado de Gentoo.
- runit, una suite ligera de supervisión de procesos inspirada en daemontools, es el corazón de Void Linux.
- s6 y el más reciente dinit ofrecen enfoques minimalistas para quienes quieren control fino sin la huella de systemd.
Y luego está Devuan: una bifurcación de Debian nacida precisamente para ofrecer la robustez del proyecto madre sin systemd, con sysvinit, OpenRC y runit a elegir. Que exista demuestra que, en el software libre, ninguna decisión es del todo definitiva: siempre habrá quien coja el código y construya otra cosa.
La guerra de los init ya no acapara titulares, pero su legado sigue ahí cada vez que tu máquina llega al PID 1. La diversidad de opciones, lejos de ser un problema, es la mejor garantía de que Linux seguirá siendo tuyo para configurarlo a tu manera.