Diversidad de los Sistemas de Inicio en peligro en Debian afecta a otras distros

Una posible mancha ocupara la libertad de elección de usuarios avanzados para la distro madre: Debian; uno que respete la diversidad y la libertad de elección a nivel de «Sistemas de Inicio (Init), todo debido a la futura Resolución General del Proyecto DEBIAN sobre como la gran Distro Madre debe abordar la Diversidad existente sobre los Sistemas de Inicio.
Resumiendo hay 3 resoluciones que eliminan las libertades de diversidad, dejando solo el "systemd", de allí el que mas gente odie a systemd, a todo esto se le denomina "un enfoque sano de PID1" en el argot técnico.
Sus consecuencias: muerte/obstrucción al trabajo de otras distros mediante carga de trabajo extra debido a que solo existirá systemd: Devuan y MXLinux entre otras.



Hablamos sobre la Resolución General Debian 2019-002 sometida a su Sistema de Votación interna (solo para Debian mantainers) existente sobre los «Sistemas de Inicio». Este Tema que se puede reforzar, leyendo alguno de los muchos artículos anteriores en el Blog DesdeLinux sobre dicho asunto.

Consecuencias e importancia:

Su resultado puede cambiar radicalmente el panorama de las distro mas importantes derivadas de Debian, es decir, el tema de este articulo es crear conciencia sobre una posible mancha en la libertad de elección de los usuarios avanzados y desarrolladores a nivel de Sistemas de Inicio (Init), que se debate en la futura Resolución General a tomarse.
Tenemos los siguientes problemas acerca de esa situación que hacen pensar en la clara desventaja de los interesados:

1. Este es una propuesta donde la comunidad no tiene cabida!
2. Solo los integrantes mas internos de Debian pueden votar!
3. Este contenido no esta en español, dado es una votación interna
4. Es la segunda vez que el systemd causa problemas en otros desarrolladores
5. Esto podría causar un nuevo exodo (como el que dio origen a Devuan)

Resumiendo, el contenido del artículo a leerse, hay 3 resoluciones que eliminan las libertades que garantizan la diversidad, dejando solo el “Systemd”, de allí el que más gente odie a “Systemd”. A todo esto se le denomina “un enfoque sano de PID1” en el argot técnico. Sus consecuencias: Muerte de otras Distros derivadas mediante carga de trabajo extra debido a que solo existirá “Systemd”. Por ejemplo, Devuan y MX-Linux podrían desaparecer.

Resumen de las opciones

De las opciones de votación (que ya dijimos que aunque sean internas podemos hacer presión social) tenemos 3 que destruyen la libertad y solo dos que las protegen, la A, B, y C son las destructivas y la E algo flexible, solo la D es la que permite real libertad. Esto es traducción y resumen de https://www.debian.org/vote/2019/vote_002 tal como se indico en la sección anterior.

Propuesta A: la diversidad de inicio es importante e INMUable

Menciona el poder ejecutar sistemas Debian con sistemas init que no sean systemd sigue siendo algo que el proyecto valora. Con una excepción de que todos los paquetes que lo deban, deban incluir scripts para los inits del momento en uso. Refuerza el que la política actual dice que los paquetes no deben incluir una unidad de servicio sin un script de inicio. EL problema es que las reglas de política es confusa ya que deben incluirlo pero al mismo tiempo es opcional.

Propuesta B: Systemd pero apoyamos la exploración de alternativas

Este dice que en resumen (y que es la detonante) systemd es obligatorio causando dependencias no necesarias, es decir que permite que coexista y se apoye otros inits pero lo que obliga (sin decirlo) que software como elogind deba incluir dependencia de systemd. Ademas esta propuesta es ambigua y propensa a cambia en el futuro.

Propuesta C: centrarse en systemd para el sistema y todo

Esta es la propuesta mas destructiva, dice que proporcionar soporte para múltiples sistemas de inicio o para alternativas a otras interfaces proporcionadas por systemd no es una prioridad del proyecto en este momento y que las dependencias a systemd aun si ser necesarias son obligatorias.

Propuesta D: admite sistemas que no son del sistema, sin bloquear el progreso

ESTA ES LA QUE REALMENTE SOLVENTA EL PROBLEMA, el detonante es que los desarrolladores que son a favor de systemd forzaban y obstruían el progreso de otras soluciones, especialmente en el escritorio del Icaza que a tal grado había que des-instalarlo y volverlo instalar.

Menciona con especial enfatices que los paquetes deberían ser completamente funcionales con todos los sistemas init. Esto significa (por ejemplo) que los demonios deben enviar scripts de inicio tradicionales o utilizar otros mecanismos para garantizar que se inicien sin systemd. También significa que el software de escritorio debe ser instalable e idealmente completamente funcional, sin systemd.

Propuesta E: se requiere diversidad de iniciación pero excluyente

Poder ejecutar sistemas Debian con sistemas init que no sean systemd sigue siendo de gran valor para el proyecto. Todos los paquetes DEBEN funcionar con pid1 ! = Systemd, a menos que haya sido diseñado por upstream para funcionar exclusivamente con systemd y no esté disponible el soporte para ejecutarse sin systemd.
Pero tiene algo que no es del todo democrático: No se debe considerar software que solo trabaje con systemd simplemente porque upstream no proporciona, y / o no aceptará, un script de inicio. Esto pareciera tiranizar y no es muy democrático, aunque tiene sentido porque proporciona trabajo extra.

RESUMEN Y CONCLUSIONES A CONSIDERAR PARA TODOS:

Este articulo deslumbra por dar una visión general del problema actual con respecto la «Diversidad» existente sobre los «Sistemas de Inicio». Aclarara sus consecuencias según las decisiones tomadas, ya que hay que tener en cuenta que es la segunda vez que “Systemd” provoca y causa problemas “no técnicos” dentro de la comunidad… todos sabemos quienes rigen “Systemd” y porque quieren este tan difundido.
El inicio de toda esta Resolución General empieza con el correo de agosto del 2019, Primer borrador de Resolución General, bajo el sub-tópico llamado “Init System Diversity” donde Sam Hartman, líder del Proyecto DEBIAN, le preocupaba las luchas entre los inits, haciendo notar el poco espacio que dejaban los empaquetadores de “Systemd” y el como dificultaban el trabajo de los demás, sobre todo, mediante dependencias forzadas.
Los usuarios que desean realizar lo que las libertades de software libre menciona coo derivar y copiar para mejorar el software, están siendo coartados por medio de carga extra de trabajo, los desarrolladores de systemd desean directamente matar el trabajo de otros perturbando su inclusión en las distribuciones linux grandes.
No se engañen a si mismos.. grupos como https://t.me/nosystemd están super inactivos respecto esto argumentando "no nos afecta" pues están equivocados..  si un proyecto como elogind no se usa lo suficiente su mantenedor no tendrá razón de seguir en una lucha (desarrollo) sin propósito. Ejemplo de esto es el software Hiawatta web server donde el desarrollador pauso el desarrollo activo obviamente dado su servidor web es digamos no muy usado.. si no es muy usado estaba desperdiciando su tiempo.
Como en al novela de Soilet Green, el futuro los va alcanzar si solo se quedan viendolo.... para mas informacion tenemos los siguientes grupos:

• https://t.me/devuan_es Devuan en español telegram
• https://t.me/DevuanMX Devuan Mexico pero ahora mas internacional
• https://t.me/DebianLatinoamerica Debian latinoamerica
• https://mastodon.social/@proyectotictac Proyecto tic tac en Mastodon
• https://t.me/grupo_telegram_proyectotictac Grupo tic tac en telegram
• https://groups.google.com/forum/m/#!forum/venenuxsarisari Grupo Venenux Devel

ANEXO: Traduccion de la propuesta D la mas correcta

En esta sección incluiremos la traducción completa de las propuestas que permiten coexistir y trabajar libremente

Opción D: admite sistemas que no son del sistema, sin bloquear el progreso

ESTA ES LA QUE REALMENTE SOLVENTA EL PROBLEMA, el detonante es que los desarrolladores que son a favor de systemd forzaban y obstruian el progreso de otras soluciones, especialmente en el escritorio del Icaza que a tal grado había que desinstalarlo y volverlo instalar.

PRINCIPIOS

1. Deseamos continuar admitiendo múltiples sistemas init en el futuro previsible. Y queremos mejorar nuestro soporte systemd. Estamos decepcionados de que esto haya tenido que involucrar a otro GR.
2. Es principalmente para las comunidades en cada ecosistema de software mantener y desarrollar su software respectivo, pero con el apoyo activo de otros mantenedores y guardianes cuando sea necesario. (es decir colaborar en vez de forzar la dependencia)

DEPENDENCIAS DEL SYSTEMD

3. Idealmente, los paquetes deberían ser completamente funcionales con todos los sistemas init. Esto significa (por ejemplo) que los demonios deben enviar scripts de inicio tradicionales o utilizar otros mecanismos para garantizar que se inicien sin systemd. También significa que el software de escritorio debe ser instalable e idealmente completamente funcional, sin systemd.
4. Por lo tanto, no es compatible con los sistemas que no son del sistema, donde no hay tal soporte disponible, es un error. Pero es * no * un error de lanzamiento crítico. Si el requisito para systemd se registra como un error formal en el sistema de errores de Debian, cuando no hay parches disponibles, depende del responsable.
5. Cuando un paquete tiene una funcionalidad reducida sin systemd, esto generalmente no debe documentarse como un (directo o indirecto) Depende o recomienda en systemd-sysv. Esto se debe a que con tales dependencias, la instalación de dicho paquete puede intentar cambiar el sistema init, que no es lo que el usuario quería. Por ejemplo, un demonio con solo un script de archivo de unidad systemd aún debería ser instalable en un sistema no systemd, ya que podría iniciarse manualmente.
Una consecuencia de esto es que en sistemas no systemd puede ser posible instalar software que no funcionará, o no funcionará correctamente, debido a una dependencia no declarada en systemd. Esto es lamentable, pero intentar cambiar el sistema de inicio del usuario es peor.Esperamos que se puedan desarrollar mejores enfoques técnicos para abordar esto.
6. Reconocemos que algunos mantenedores consideran que las secuencias de comandos de inicio son una carga y esperamos que la comunidad pueda encontrar formas de facilitar la adición de soporte para sistemas de inicio no predeterminados. Las discusiones sobre el diseño de tales sistemas deben ser amigables y cooperativas, y si se desarrollan los arreglos adecuados, deben ser respaldados de la manera habitual dentro de Debian.

SE ACEPTARÁN CONTRIBUCIONES DE APOYO NO SISTEMA

7. Si no se admiten sistemas que no sean del sistema cuando dicho soporte esté disponible o se ofrezca en forma de parches (o paquetes), * debe * ser tratado como un error crítico de la versión. Por ejemplo: los scripts de inicio * no deben * eliminarse simplemente porque en su lugar se proporciona una unidad systemd; Los parches que contribuyen con el soporte para otros sistemas init (sin un efecto sustancial en las instalaciones de systemd) deben archivarse como errores con gravedad `` grave ''.
El objetivo es proporcionar una ruta ligera pero efectiva para garantizar que se pueda proporcionar un soporte razonable a los usuarios de Debian, incluso cuando las prioridades del mantenedor se encuentren en otro lugar. (Invocar al Comité Técnico sobre parches individuales no es sensato).
Si los parches son en sí mismos RC-buggy (en opinión de, inicialmente, el mantenedor y, en última instancia, el equipo de lanzamiento), por supuesto, el informe de error debe degradarse o cerrarse.
8. Los mantenedores de los componentes de systemd u otros controladores de acceso (incluidos otros mantenedores y el equipo de lanzamiento) a veces tienen que evaluar las contribuciones técnicas destinadas a apoyar a los usuarios que no pertenecen al sistema. La aceptación por parte de los usuarios de los sistemas init no predeterminados, de los riesgos de calidad de tales contribuciones, es una cuestión para los encargados de mantener los sistemas init no predeterminados y la comunidad circundante. Pero tales contribuciones no deberían imponer riesgos no triviales a los usuarios de la configuración predeterminada (systemd con Recommends instalado).

INSTALACIONES DECLARADORAS SISTEMÁTICAS NO RELACIONADAS CON INIT

9. systemd proporciona una variedad de instalaciones además del inicio del demonio. Por ejemplo, crear usuarios del sistema o directorios temporales. Los enfoques actuales de Debian a menudo se basan en scripts de debhelper.
En general, los enfoques más declarativos son mejores. Dónde

• systemd proporciona dicha facilidad
• existe una especificación de la instalación (o subconjunto adecuado)
• la instalación es mejor que los otros enfoques disponibles en Debian, por ejemplo, al ser más declarativa
• Es razonable esperar que los desarrolladores de sistemas que no son de sistema, incluidos los sistemas que no son Linux, lo implementen
• incluyendo consideración de la cantidad de trabajo involucrado

la instalación debe documentarse en la Política de Debian (por incorporación textual, no por referencia a un documento externo). La transición debe ser fluida para todos los usuarios. A la comunidad que no pertenece al sistema se le debe dar al menos 6 meses, preferiblemente al menos 12 meses, para desarrollar su implementación. (Lo mismo ocurre con cualquier mejora futura).
Si no se puede llegar a un consenso sobre políticas en una instalación de este tipo, el Comité Técnico debe decidir en función de los deseos del proyecto tal como se expresan en este GR.

SER EXCELENTE EL UNO AL OTRO

10. En general, los mantenedores de software competidor, incluidos los mantenedores de los diversos sistemas init competidores, deben adaptarse a las necesidades de los demás. Esto incluye las necesidades y la conveniencia de los usuarios de configuraciones razonables no predeterminadas.
11. Se desaconsejan los comentarios generales negativos sobre el software y sus comunidades, incluidos tanto sobre systemd en sí como sobre los sistemas init que no son systemd. Ni los mensajes que expresan disgusto general de systemd, ni las predicciones de la desaparición de sistemas no systemd, son apropiados para los foros de comunicación de Debian; asimismo, referencias a errores que no son relevantes para el tema en cuestión.
Las comunicaciones en foros de Debian sobre estos asuntos deberían ser alentadoras y agradables, incluso cuando se discuten problemas técnicos. Pedimos que los propietarios de los foros de comunicación hagan cumplir estrictamente esto.
12. Solicitamos respetuosamente a todos los contribuyentes de Debian, incluidos los encargados de mantenimiento, los Editores de políticas, el Equipo de publicación, el Comité técnico y el Líder del proyecto, que persigan estos objetivos y principios en su trabajo, y los incluyan en documentos, etc. (Esta resolución es una declaración de posición bajo s4.1 (5).)