La discusión sobre systemd y los sistemas de inicio clásicos (SysVinit y compañía) lleva más de una década instalada en la comunidad Linux. En la práctica, systemd se convirtió en el estándar de facto en la mayoría de distribuciones generalistas. Pero el debate no se cerró: se transformó en una conversación más interesante —y más técnica— sobre hasta dónde debe llegar PID 1 y qué compromisos se aceptan a cambio de integración, automatización y consistencia.
La foto de 2026 ayuda a entender por qué el tema no muere. Aunque el ecosistema se ha alineado en gran medida alrededor de systemd, todavía hay un grupo de distribuciones que arrancan sin systemd por defecto o que ofrecen “init freedom” como parte de su identidad. Devuan, por ejemplo, lo resume como un intento de “restaurar un enfoque sensato de PID 1” y declara explícitamente que usa sysvinit por defecto, con alternativas como OpenRC y runit.
El verdadero centro del choque: “un init” o “una capa de sistema”
La parte pro-systemd suele defenderlo por motivos muy pragmáticos: arranca rápido, maneja dependencias, supervisa servicios y ofrece una experiencia coherente en entornos complejos. De hecho, la documentación oficial lo define como “un gestor de sistema y servicios” que, cuando se ejecuta como PID 1, actúa como init y pone en marcha el resto del sistema.
El bando crítico, en cambio, no discute solo el rendimiento: discute la superficie de control. Con el tiempo, systemd no se limitó a iniciar procesos: su ecosistema incluye servicios como journald (registro centralizado) y resolved (resolución de nombres/DNS) , entre otros componentes. Esto da potencia y coherencia, pero también alimenta la sensación de “monolito”: si algo va mal en una capa compartida, el impacto puede ser transversal.
Embebidos y “boots predecibles”: el contexto lo cambia todo
En sistemas embebidos e industriales —SoCs ARM como NXP i.MX, NVIDIA Jetson, TI Sitara, o Raspberry Pi Compute Modules— la discusión suele bajar a tierra: cada MB cuenta y el arranque debe ser predecible. En ese mundo, algunos ingenieros describen systemd con una metáfora que se repite: “vas a por una estantería y sales con la casa entera amueblada”. Es una forma coloquial de decir que systemd puede ser brillante… pero sobredimensionado para ciertos perfiles de dispositivo.
Aun así, incluso en embebidos no hay dogmas. En un kiosco de pago o un equipo desplegado con soporte y monitorización de terceros, muchas veces pesa más el coste operacional: herramientas, expectativas del equipo y compatibilidad con el estándar. En contenedores minimalistas o dispositivos muy ajustados, alternativas como OpenRC o runit siguen siendo atractivas por simplicidad y huella.
15 distribuciones destacadas que pueden funcionar sin systemd en 2026
La lista cambia con el tiempo y no todas son “systemd-free” en sentido estricto (algunas lo ofrecen como opción). Pero estas 15 distribuciones son referencia habitual cuando se habla de arrancar sin systemd por defecto o de ofrecer alternativas reales:
| Distribución | init por defecto (o principal) | Alternativas / notas |
|---|---|---|
| Gentoo | OpenRC (común en perfiles “sin systemd”) | Puede usarse con systemd según perfil |
| Alpine | OpenRC | Muy común en contenedores/edge |
| Void Linux | runit | Enfoque simple y supervisión |
| Artix | OpenRC / runit / s6 / dinit | Elección de init al instalar |
| Devuan | sysvinit (por defecto) | Alternativas: OpenRC, runit |
| Slackware | sysvinit (con scripts estilo BSD) | Tradición y control manual |
| Chimera Linux | dinit | Supervisa servicios al estilo moderno |
| antiX | sysvinit (por defecto) / runit | Enfoque “systemd-free” |
| MX Linux | sysvinit (por defecto), opción systemd | Históricamente “dual init” |
| Hyperbola | OpenRC / runit | Orientación a software libre |
| Parabola | systemd (por defecto), soporta otros inits | Importante: no es systemd-free por defecto |
| Obarun | s6 (con herramientas “66”) | Arch-like sin systemd |
| Adélie Linux | OpenRC (por defecto) | Enfoque POSIX/musl, soporte OpenRC |
| Guix System | Shepherd | Init y servicios en Guile/Scheme |
| KISS Linux | BusyBox init (por defecto) | Minimalismo extremo y framework propio |
Tabla comparativa: diferencias prácticas entre init systems
| Init / gestor | Filosofía | Supervisión de servicios | Puntos fuertes | Puntos débiles típicos |
|---|---|---|---|---|
| systemd | Suite integrada, unidades y dependencias | Sí (nativo) | Integración, tooling homogéneo, journald/resolved, etc. | Complejidad, “blast radius”, curva de aprendizaje |
| SysVinit + scripts (incl. estilo BSD) | Tradición, scripts y runlevels | No “moderna” por defecto | Simplicidad conceptual, predecible, fácil de auditar | Menos automatización, menos supervisión |
| OpenRC | Dependencias + scripts, enfoque modular | No nativa “tipo systemd” | Ligero, popular en Alpine/Gentoo | Menos “todo integrado”, más pegamento |
| runit | Simplicidad + supervisión | Sí (nativo) | Muy simple, supervisión fuerte, rápido | Menos “features” integradas |
| s6 (+ 66 en Obarun) | Supervisión avanzada, composición | Sí (nativo) | Potente, robusto, configurable | Curva de aprendizaje alta |
| dinit | Supervisor + init moderno | Sí (nativo) | Modelo moderno, claro, sin “suite” enorme | Ecosistema menor que systemd |
| Shepherd (Guix) | Servicios declarativos en Scheme | Sí (nativo) | Extensible, coherente con Guix | Nicho fuera de Guix/GNU |
| BusyBox init (KISS) | Minimalismo | Depende (KISS lo combina con utilidades tipo runit) | Huella mínima, control absoluto | Más trabajo manual, menos “comodidad” |
La conclusión que suele funcionar en producción
La forma menos polémica —y más útil— de cerrar la discusión es admitir que ambos bandos pueden tener razón a la vez:
- En servidores, puestos corporativos y entornos con tooling moderno, systemd reduce fricción y es lo que la mayoría espera.
- En embebidos, contenedores minimalistas o sistemas donde la huella y la previsibilidad mandan, alternativas como OpenRC, runit, s6 o dinit pueden ser mejores por diseño.
- Y si la organización tiene que elegir una batalla: casi siempre sale más rentable discutir observabilidad, hardening y recuperación que discutir “religión de init”.
