A inicios de mes compartimos con ustedes aquí en el blog la noticia de la votación general que se genero con la finalidad de decidir sobre si el sistema soportara múltiples sistemas de inicialización esto a raíz de que, en 2014, el Comité Técnico aprobó la transferencia de la distribución por defecto a systemd, pero no desarrolló la solución con respecto al soporte de varios sistemas de inicialización.
El líder del comité recomendó que los encargados del paquete mantengan el apoyo sysvinit como un sistema de inicialización alternativo, pero indicó que no podía imponer su punto de vista y que en cada caso la decisión debería tomarse de manera independiente.
Después de eso, algunos desarrolladores intentaron celebrar una votación general, pero una votación preliminar mostró que no había necesidad de decidir sobre el uso de varios sistemas de inicialización.
Hace unos meses, después de problemas con la inclusión del paquete elogind (necesario para que Gnome funcione sin systemd) en la rama de prueba debido a un conflicto con libsystemd, el líder del proyecto Debian volvió a plantear la pregunta, ya que los desarrolladores no podían estar de acuerdo y su comunicación se convirtió en una confrontación y termino en darle una solucion al respecto con la votacion general.
Ahora, los resultados de dicha votación se dieron a conocer en la fecha que se estipulo (el 28 de diciembre) donde se vieron involucrados en el mantenimiento de paquetes y el mantenimiento de la infraestructura sobre el tema de soportar sistemas de inicialización múltiple.
Y la opción ganadora fue el segundo elemento («B») en la lista, el cual describe que
«systemd sigue siendo el preferido, pero la posibilidad de soportar sistemas de inicialización alternativos permanece. Las tecnologías, como elogind, que le permiten ejecutar aplicaciones enlazadas al sistema en entornos alternativos, se consideran importantes. Los paquetes pueden incluir archivos init para sistemas alternativos.»
La votación se llevó a cabo mediante el método Condorcet, en el que cada votante clasifica todas las opciones en el orden de su preferencia y al calcular el resultado, cuántos votantes prefieren una opción a otra.
La opción ganadora reconoce que las unidades de servicio systemd son la forma preferida de configurar demonios y servicios para que se ejecuten, pero supone que existen entornos en los que los desarrolladores y usuarios pueden crear y aplicar sistemas de inicialización alternativos y alternativas funcionales a las características de systemd.
Los desarrolladores de soluciones alternativas deben proporcionar recursos para su trabajo y formateo de paquetes. Las soluciones alternativas, como elogind, utilizadas para organizar el lanzamiento de aplicaciones vinculadas a interfaces específicas del sistema, siguen siendo importantes para el proyecto.
Apoyar tales iniciativas requiere asistencia en áreas en las que las tecnologías alternativas que se desarrollan se cruzan con el resto del proyecto, por ejemplo, retrasar la revisión de parches y discusiones es inaceptable.
Está permitido incluir archivos de unidad systemd y scripts de inicio en los paquetes para iniciar los servicios. Los paquetes pueden usar cualquiera de las características de systemd a solicitud del responsable del paquete, siempre que estas características cumplan con los requisitos de las reglas de Debian y no estén vinculadas a características experimentales o no compatibles en Debian de otros paquetes.
Además de systemd, los paquetes también pueden incluir soporte para sistemas de inicialización alternativos y proporcionar componentes para reemplazar interfaces específicas de systemd. El personal acompañante toma las decisiones para habilitar los parches como parte de los procedimientos regulares
Debian se compromete a trabajar con distribuciones derivadas que han elegido otros sistemas de inicialización para sí mismos, pero la interacción se basa en el nivel de los mantenedores, sobre los cuales se toman decisiones sobre ello.
Finalmente, este resultado no fue del agrado de muchos, pues en redes mostraron su descontento pues muchos comentan que esto no difiere a lo que es en la actualidad, ya que básicamente transfieren toda la responsabilidad a los mantenedores.
Si quieres conocer más al respecto, puedes consultar la publicación de los resultados en el siguiente enlace.
«Finalmente, este resultado no fue del agrado de muchos […] pues muchos comentan que esto no difiere a lo que es en la actualidad […]»
No esperaba otra cosa de Debian. En la última década no ha sido más que mucho ruido y pocas «luces» (no por nada la gente de Devuan se les abrió).
De nuevo, el problema nunca fue q systemd fuera un reemplazo a init. El problema siempre fue que se hiciera a systemd meter las narices en absolutamente todo, con el consiguiente código superfluo, casi espurio, un nivel de complicación absurdamente inútil, bugs y vectores de ataque a granel. Y acá estamos, con un «Linux» cada vez menos «Linux» y cada vez más un «Wind*ws» de 2da.
Ahora usar una distro sin systemd es casi un chiste pues solo se reemplaza a systemd por algún otro método de carga… pero systemd sigue extendido en todo el sistema como un cáncer (aunque se diga q se mantiene solo por un tema de satisfacer dependencias y no se halla en ejecución).
En fin, parece q Linux tampoco escapará a la máxima de Matrix: «Everything that has a beginning… has an end».