# La guerra de los init: SysV, Upstart, systemd y OpenRC
- **Publicado el:** 2026-08-12
- **Categoría:** Noticias
- **Página original:** https://linuxgratis.com/articulos/la-guerra-de-los-init
SysV, Upstart, systemd y OpenRC se disputaron el PID 1 de Linux. Repasamos la historia, la votación de Debian de 2014 y las alternativas que siguen vivas.
---
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](/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
Lennart Poettering, que junto a Kay Sievers presento systemd en 2010 con el manifiesto "Rethinking PID 1". · Imagen: Harald Hoyer / CC BY-SA 3.0 · Wikimedia Commons
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](/fedora) se convirtió en la primera gran distribución en activar systemd por defecto, en lugar de Upstart. [openSUSE](/opensuse) y otras siguieron el camino. El golpe definitivo llegó con [Debian](/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](/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
La arquitectura de systemd: una suite integral que absorbe funciones antes repartidas en programas independientes, el centro del debate filosofico. · Imagen: ScotXW, based on https://wiki.tizen.org/wiki/File:Systemd_arch.PNG / CC BY-SA 3.0 · Wikimedia Commons
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](/gentoo).
- **runit**, una suite ligera de supervisión de procesos inspirada en daemontools, es el corazón de [Void Linux](/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](/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.
