Reemplazando systemd con OpenRC en Debian

Por qué reemplazar systemd / necesidad de competencia

• Muchos sostienen que systemd se ha vuelto demasiado dominante, creando una monocultura de facto y dificultando el despliegue de alternativas.
• Preocupaciones: proliferación de dependencias en muchos componentes de bajo nivel, complejidad accidental y mantenedores que desestiman los problemas de compatibilidad.
• Otros responden que systemd les funciona bien, resuelve problemas de init de larga data y que las alternativas serias siguen incompletas o son de nicho.

Comparaciones técnicas: systemd frente a OpenRC y otros inits

• OpenRC se presenta como un gestor de servicios ligero con ordenación de dependencias, supervisión (supervise-daemon), inicio paralelo e integración con cgroups.
• Algunos señalan que los archivos de unidades de systemd y los archivos de servicios de OpenRC son estructuralmente bastante similares para casos básicos.
• Hay debate sobre si los scripts de init basados en shell son intrínsecamente frágiles frente al enfoque declarativo y basado en binarios de systemd.

Debian, Devuan y las decisiones de las distribuciones

• Contexto histórico: Debian evaluó systemd, Upstart y OpenRC; OpenRC se consideró poco desarrollado en el momento de la decisión de Debian.
• Debian inicialmente dio soporte a múltiples sistemas de init, pero más tarde se estandarizó en systemd debido a la carga de mantenimiento.
• Devuan se menciona como “Debian sin systemd”, pero difiere de simplemente cambiar el init en Debian estándar (repositorios separados, parches).
• Algunos argumentan que una distro debería elegir un solo init; la “elección” debería hacerse a nivel de la distro, no dentro de cada distro.

El alcance de systemd y la “OS-ificación”

• Systemd ahora abarca init, registros, red, bootloader, autodetección de particiones, instaladores, funciones estilo contenedor, etc.
• A los defensores les gusta la capa de “OS” coherente e integrada y las APIs unificadas que simplifican herramientas como Cockpit.
• Los críticos ven esto como una extralimitación, con riesgo de bloqueo y de hacer más difícil intercambiar componentes.

Sistemas inmutables y control

• Discusión sobre stacks inmutables basados en systemd y una empresa centrada en sistemas cerrados “amutables”.
• Algunos ven los sistemas inmutables y controlados centralmente como beneficiosos para los proveedores (por ejemplo, consolas, dispositivos de consumo).
• Otros temen que estos mecanismos, una vez estandarizados a nivel de init/OS, puedan facilitar el bloqueo de usuarios o la exclusión de distros no-systemd, especialmente si se combinan con políticas de secure boot.

Verificación de edad / preocupaciones de privacidad

• Un campo planificado de edad/fecha de nacimiento en systemd provoca reacciones fuertes.
• Los críticos lo ven como una forma de “olfateo de edad”, alineada con leyes intrusivas y la recopilación de datos; la intención de cumplir la normativa se considera con suspicacia.
• Los defensores señalan que es un campo opcional de metadatos, puede compilarse fuera o dejarse sin establecer, y puede evitar que cada servicio reimplemente su propio mecanismo.
• Desacuerdo sobre si los desarrolladores deberían cumplir esas leyes, ignorarlas o resistirse activamente como casos de prueba.

Usabilidad, fiabilidad y errores

• Algunos informan que systemd es robusto y está completo en funciones desde hace años, especialmente en comparación con el SysV clásico.
• Otros relatan errores graves del pasado (por ejemplo, carreras de apagado vía D-Bus, pérdida de datos de journald, picos de CPU, incompatibilidades de supervisión) y los ven como fallos de diseño, no como simples errores de implementación.
• Se reconoce que tanto el init de estilo sysv como systemd han roto sistemas en producción; la base de código mucho más grande de systemd se ve por algunos como una mayor “superficie de ataque” para errores.

Fragmentación frente a estandarización

• Las voces a favor de systemd enfatizan la reducción de la fragmentación entre distros, una mejor consistencia entre distros y empaquetado más sencillo.
• Las voces anti-monocultura valoran la diversidad (Gentoo, Alpine, Void, Devuan) y se preocupan cuando escritorios (GNOME/KDE) o herramientas asumen systemd sin avisar.
• Algunos señalan que POSIX buscó suavizar la portabilidad, pero los escritorios modernos y la integración profunda del sistema necesitan más que solo POSIX.

Alternativas y distros “plan B”

• Gentoo + OpenRC, Alpine (con OpenRC), Void y otros sistemas inspirados en supervisión se citan como विकल्प viables sin systemd.
• Se informa que Alpine funciona bien como escritorio (por ejemplo, con i3 o KDE), especialmente en hardware de bajo consumo.
• Existen herramientas para convertir unidades de systemd a otros formatos, pero mantener la compatibilidad semántica se considera no trivial.

Meta: cultura, política y ley

• El hilo toca la desconfianza hacia la influencia corporativa (Red Hat/IBM, grandes tecnológicas) y el temor de que sus incentivos diverjan de los de los usuarios centrados en la privacidad.
• Hay debate sobre si combatir las malas leyes mediante la política, los tribunales o la no cooperación técnica.
• Algunos caracterizan la crítica a systemd como emocional o cuasi tribal; otros sostienen que están respondiendo a problemas técnicos y de gobernanza reales.