¿Por qué Debian es como es hoy?
(blog.liw.fi)- Las prácticas particulares de Debian surgen de decisiones acumuladas por un sistema operativo de propósito general a gran escala con 30 años de historia para sostener durante mucho tiempo la calidad, la seguridad y los principios del software libre
- No aspira a ser una distribución para un uso específico, sino una distribución de propósito general adecuada para la mayoría de las personas y propósitos; para incluir un paquete, los criterios centrales son que sea software libre y que pueda mantenerse con calidad
- La constitución, el contrato social y las DFSG son mecanismos surgidos después de que la operación inicial, más informal, mostrara sus límites; institucionalizan la toma de decisiones democrática y una autoridad limitada para el líder
- Las compilaciones autocontenidas y evitar bibliotecas incluidas en paquetes son una estrategia de mantenimiento que permite aplicar correcciones urgentes de seguridad, recompilar y portar a nuevas arquitecturas sin quedar a merced de repositorios externos o dependencias duplicadas
- La evaluación de miembros, los nombres clave de los lanzamientos y el ritmo lento de cambio son formas en que un proyecto con miles de paquetes y una base instalada de decenas de millones de equipos gestiona la confianza, los costos de espejado y los costos de consenso
El sistema operativo al que aspira Debian
- Debian aspira a ser un sistema operativo de alta calidad, seguro y de propósito general, compuesto solo por software libre y de código abierto que funcione en la mayoría de las computadoras de uso activo
- El objetivo de ser un sistema operativo de propósito general significa que Debian debe ser adecuado para la mayoría de las personas en la mayoría de los propósitos
- No puede ajustarse a todas las situaciones, pero es un objetivo válido al que apuntar
- Conduce a decisiones distintas de las de distribuciones enfocadas en un propósito específico, como escritorio, servidores, juegos o investigación científica
- La decisión de empaquetar o no algo depende más de los siguientes criterios que del uso del software
- Si el software es software libre
- Si Debian puede mantenerlo como un paquete de alta calidad
Constitución y gobernanza
- Debian se parece a una organización open source explícitamente democrática
- Sus procesos de toma de decisiones están bien definidos
- Cada año elige a un Debian Project Leader
- La autoridad del líder del proyecto está estrictamente limitada, y muchos poderes normalmente asociados al liderazgo se delegan explícitamente en otras personas
- Los primeros Debian Project Leaders eran, en la práctica, más cercanos a dictadores con poderes casi totales hasta que decidían retirarse
- Después de que un líder del proyecto cruzara una línea, renunció ante la reacción en contra, y como resultado se introdujo la democracia
- Debian define las reglas del proyecto mediante una constitución oficial
- El sistema de reglas actual surge de una experiencia temprana en la historia del proyecto: menos reglas y menos burocracia no funcionaron bien en Debian
Contrato social y Debian Free Software Guidelines
- A mediados de la década de 1990 aún no se había introducido el término “open source”, y “free software” estaba definido por la Free Software Foundation, pero dejaba mucho margen de interpretación
- Debian quería reglas más claras y creó las Debian Free Software Guidelines (DFSG), que incorporó como parte de su contrato social
- El contrato social es el documento base en el que Debian promete qué es y qué hace frente a sí mismo y al mundo
- Las DFSG son parte de él
- La constitución de Debian hace que el contrato social sea intencionalmente difícil de modificar
- Las reglas más detalladas dejan más claro qué aceptará Debian y simplifican las discusiones relacionadas
- Las DFSG luego se convirtieron en la base de la Open Source Definition
Principio de compilaciones autocontenidas
- Debian insiste en el principio de ser autocontenido (self-contained)
- Todo lo que Debian empaqueta debe compilarse usando solo dependencias dentro de Debian
- Todo lo que está dentro de Debian debe ser compilado directamente por Debian
- Este principio puede generar mucho trabajo adicional
- Las herramientas actuales de lenguajes de programación muchas veces asumen que, al compilar, se descargarán dependencias desde repositorios en línea
- En Debian, esa forma de trabajar no está permitida
- La razón principal es que las dependencias externas pueden desaparecer más adelante
- Debian no controla los repositorios de paquetes de terceros
- Si desaparece un paquete o un repositorio completo, Debian podría no poder volver a compilar ese paquete
- Para actualizar a un nuevo compilador, corregir problemas de seguridad, portar a una nueva arquitectura o incorporar correcciones de bugs, se necesitan recompilaciones
- Si no fuera autocontenido, al momento de una corrección urgente de seguridad tendrían que estar disponibles decenas de miles de paquetes y todas sus dependencias, por lo que Debian elige empaquetar todas las dependencias
Por qué evita las bibliotecas incluidas en paquetes
- Debian evita usar copias de bibliotecas u otras dependencias incluidas dentro del software que empaqueta
- Muchos proyectos upstream consideran más fácil incluir sus dependencias junto con el proyecto o hacerles vendoring
- Desde la perspectiva de Debian, eso puede crear varias copias de una biblioteca popular
- Si esa biblioteca tiene un problema de seguridad o un problema grave, hay que encontrar y corregir todas las copias
- En un incidente urgente de seguridad, esto hace perder tiempo valioso
- En el caso de zlib, Debian encontró decenas de copias incluidas de zlib dentro del archivo, y dedicó un esfuerzo considerable a hacer que los paquetes de Debian usaran solo la versión de zlib empaquetada en Debian
- Por eso Debian hace el trabajo por adelantado en la etapa de empaquetado, antes de que llegue una emergencia, para que los paquetes dentro de Debian usen la versión de la biblioteca empaquetada en Debian
- A veces este enfoque genera fricciones con Debian, porque los desarrolladores upstream pueden querer tratar solo con la versión incluida que ellos mismos verificaron
Proceso de evaluación de miembros
- Como sistema operativo, Debian es grande, complejo y ampliamente utilizado, por lo que necesita confiar en sus integrantes
- Es especialmente importante confiar en quienes suben nuevos paquetes
- Debido a las limitaciones técnicas de Linux en la década de 1990, todos los paquetes de Debian tienen acceso completo de root durante el proceso de instalación
- Todo desarrollador de Debian puede, potencialmente, convertirse en usuario root en cualquier máquina donde se ejecute Debian
- Dado que Debian se ejecuta en decenas de millones de máquinas, ese es un poder considerable
- Los nuevos integrantes se verifican de varias maneras
- Idealmente, deberían haber participado lo suficiente en la comunidad de desarrollo de Debian como para ser conocidos por otras personas
- Deben construir confianza dentro de la comunidad
- Este proceso puede resultar bastante frustrante para quienes quieren participar en Debian, especialmente para quienes están acostumbrados a proyectos open source más pequeños
Nombres clave de los lanzamientos
- Debian asigna nombres clave a cada lanzamiento principal
- Esta práctica surgió originalmente para reducir el costo de espejar el archivo de paquetes de Debian
- A mediados de la década de 1990, cuando se preparaba el lanzamiento de Debian 1.0, no se usaban nombres clave y se creaban directorios con el nombre de la versión
- Como desarrollar un nuevo lanzamiento toma tiempo, se creó por adelantado un directorio “1.0”
- Una editorial de CD-ROM produjo anticipadamente, y en gran volumen, discos etiquetados como “1.0” antes de que Debian 1.0 estuviera terminado
- Como resultado, quienes recibieron CD-ROM de Debian 1.0 recibieron algo que no era el verdadero 1.0
- Una solución simple habría sido preparar todo en un directorio como “1.0-not-released” y, una vez completado el lanzamiento, renombrarlo a “1.0”
- Pero si cambiaba el nombre del directorio, todos los espejos tenían que volver a descargar el lanzamiento, y para el tamaño de Debian en ese momento eso era costoso
- En esa época, la escala era de “cientos de paquetes” y “decenas de MB”
- Más adelante se agregó una estructura pool al archivo de Debian
- Los archivos de todos los lanzamientos están en el mismo árbol de directorios, y los archivos de metadatos especifican qué archivos pertenecen a cada lanzamiento
- Esta estructura facilita el espejado
- Hoy quizá sería posible abandonar los nombres clave y usar solo versiones, pero no está claro si a Debian le interesaría
Por qué Debian cambia lentamente
- Debian es un proyecto muy grande, y los proyectos grandes cambian lentamente
- Los cambios que afectan a muchos paquetes pueden requerir el trabajo de cientos de voluntarios, por lo que es difícil avanzar rápido
- Algunas tareas pueden ser manejadas por pocas personas, y Debian tiene procedimientos que lo permiten
- Por ejemplo, cuando se sube una nueva versión del GNU C compiler, la tarea de encontrar los cambios necesarios en otros paquetes normalmente puede hacerla un grupo pequeño
- Otra razón por la que los cambios tardan es la necesidad de construir consenso
- El consenso requiere una discusión amplia
- Ese tipo de discusiones toma tiempo y solo rara vez puede acortarse
- Los desarrolladores de Debian suelen ser conservadores en sus decisiones técnicas
- A menudo prefieren soluciones que no exijan cambios a gran escala
1 comentarios
Opiniones de Hacker News
Autocontenido y sin bibliotecas empaquetadas en bundle son conceptos importantes que parte del ecosistema descartó por considerarlos demasiado engorrosos.
Solo después de volver a sufrir los problemas que eso provoca se les puso términos como “cadena de suministro de software”, y como Debian desde el principio ha hecho las cosas de una forma que evita estos problemas, ha sufrido menos ese mismo dolor.
Si se quiere distribuir software entre varias distribuciones y sistemas operativos, empaquetar dependencias en bundle es razonable; desde la perspectiva de mantener una distribución, claramente son mejores las bibliotecas compartidas, porque basta con aplicar los parches de seguridad una sola vez.
Están surgiendo tendencias como Nix y Silverblue a nivel de sistema operativo, y Snaps y Flatpak a nivel de aplicaciones. No sé cuál sea la solución, pero parece que Debian también tendrá que hacer algo pronto.
Para usar otra versión habría que probarla con cuidado y corregir los bugs encontrados; no sé si Debian tenga recursos para eso. Al final, es como usar combinaciones de bibliotecas no verificadas y esperar que todo salga bien, pero no creo que vaya a ser así.
Desde hace mucho, el firmware público tomado del repositorio linux-firmware no se compila desde el código fuente, sino que se distribuye solo como binarios, y probablemente haya más casos similares dentro del archivo.
Debian tampoco elimina y regenera sistemáticamente los archivos generados en todos los tarballs; en especial, en el área de IA/ML es muy probable que ni siquiera se puedan obtener los datos de entrenamiento, y los costos de entrenamiento también serían difíciles de asumir.
https://wiki.debian.org/EmbeddedCopies
Algunas organizaciones de software de código abierto no son simplemente un poco impresionantes, sino asombrosas, al punto de mostrar que pueden ser muy superiores al modelo empresarial típico como forma de colaboración entre personas.
He usado Debian durante muchísimo tiempo, pero no sabía mucho sobre la organización, y este artículo fue una buena introducción.
La IETF también es una organización que prácticamente creó Internet, pero no tiene miembros y simplemente funciona; sorprende que organizaciones así no sean muy conocidas.
También son interesantes las guerras de protocolos, en las que el mundo corporativo compitió con la IETF para tomar el control de cómo funciona Internet: https://en.wikipedia.org/wiki/Protocol_Wars
Hubo una época en la que OSI anunciaba cada mes proyectos para reemplazar partes de Internet, como TCP, con protocolos X.; pero lo único que sobrevivió y prosperó fue más o menos X.509.
Me pregunto si estas organizaciones democráticas de colaboración son realmente muy superiores al modelo empresarial tradicional.
Vistas por escala económica, los ingresos de la IETF o Debian no se comparan con los de las empresas, pero desde el punto de vista de contribuyentes y creadores surge la pregunta: “¿quién se beneficia?”, y los contribuyentes apenas se sostienen.
Parece que vale la pena experimentar si el modelo tipo IETF o Debian puede competir con el modelo empresarial; en las guerras de protocolos, de hecho, funcionó una vez.
En los grupos de trabajo de la IETF hay muchos ingenieros de proveedores empresariales que quieren colaborar por la interoperabilidad, mientras que ISO se parece más a una organización tradicional, jerárquica e impulsada por los gobiernos.
Usé Ubuntu durante unos 13 años, este año me pasé a Debian y me gusta bastante.
Antes pensaba que el modelo de empaquetado con actualizaciones globales hacía difícil saber qué estaba pasando y a veces generaba conflictos de versiones, así que no lo veía como el enfoque técnicamente más sólido.
Pero con el tiempo llegué a valorar mucho la estabilidad de Debian y la buena fe del proyecto.
A veces, el propósito y los objetivos de un proyecto importan más que la superioridad técnica.
Tengo quejas sobre algunas decisiones técnicas, como que los demonios se inicien automáticamente después de la instalación, pero los beneficios de la consistencia general de los paquetes y las actualizaciones pesan más.
Apt también es un gestor de paquetes realmente excelente.
Es rápido incluso en su estado básico y soporta escenarios bastante exigentes, como mantener el sistema en stable mientras se usa solo Nginx en una versión más nueva desde backports.
Me gusta la sensación de poder recibir funciones nuevas solo en uno o dos paquetes que me importan, mientras el resto se mantiene estable y aburrido.
La razón principal es que usa tecnología aburrida y vieja, pero que funciona bien, y ya no tengo que ver netplan, snapd ni systemd-resolver.
A menos que traigas cosas de Sid o hagas algo divertido como actualizar libc6, si todo lo instalaste con apt, normalmente no deberías ver conflictos de versiones.
LIW omitió una parte importante: Debian es una organización de voluntarios, así que nadie puede obligar a un voluntario a hacer algo que no quiere hacer.
Personas no coaccionadas crean una estructura democrática flexible y rotativa para tomar decisiones, y la autosuficiencia que surge del uso cuidadoso de los recursos parece ser central para la organización.
Para mí, ese conflicto cambió permanentemente el concepto de “qué es Debian”, y si eso fue bueno o malo depende de a quién escuches.
Incluso en organizaciones así, si no haces lo que otras personas te dicen que hagas, obviamente terminas en la calle.
A veces me imagino que llego a tener tanto dinero que ya no tendría que preocuparme por eso en absoluto.
En esos momentos siempre planeo a qué proyectos de código abierto donaría, y Debian siempre está entre mis primeros candidatos.
Ahora solo falta tener el dinero; claro, mientras tanto también estoy donando a Debian.
Eso sería mucho más divertido.
Debian puede ser excelente, pero tiene problemas de soporte de drivers, y parece reconocerlo solo de forma pasiva.
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
“Reconocemos que algunos usuarios necesitan programas que no cumplen con las Debian Free Software Guidelines. Para este software, hemos creado áreas contrib y non-free en el archivo FTP”.
Hace 1 o 2 años usé Debian en varias máquinas, pero una actualización de WiFi las dejó inutilizables; después de mirar opciones como hacer rollback, simplemente me cambié a Ubuntu, en realidad a Kubuntu, y funcionó bien y sin problemas.
Debian 12 incluso creó un repositorio non-free-firmware dedicado para que los puristas del software libre puedan ceder al menos en los drivers no libres necesarios para usar su hardware.
Si es un sistema ya instalado, activar el repositorio non-free e instalar linux-firmware, o algún paquete firmware-* más específico para tu hardware, debería resolverlo.
Trabajé con Ian Murdock en Purdue en la época del primer lanzamiento.
Él era administrador de sistemas y desarrollador, y yo era diseñador web de la biblioteca.
Creía de verdad en la forma GNU/Linux y en el software libre de “libertad como libertad de expresión”.
El impulso inicial vino de lo difícil que eran el empaquetado y la gestión de paquetes, y probablemente esa haya sido su mayor contribución.
También le apasionaba una idea parecida a una infraestructura P2P llamada Network-of-Workstations, o NOW, pero nunca llegó a consolidarse.
Bruce Perens, a quien él le pasó el mando, es el líder autoritario del que habla el artículo.
Me cae bien, y tiene un estilo de gestión de la vieja guardia, como Linus Torvalds; en un proyecto grande y complejo con muchos voluntarios, ese estilo funciona.
Los viejos tiempos de Linux y Debian fueron realmente divertidos y, aunque yo no me metí tan de lleno como otros, extraño esa época.
Hoy hay demasiada gente que huele a dinero metida en esto, pero bueno, así son las cosas.
El manifiesto de Ian lo explica todo: https://www.debian.org/doc/manuals/project-history/manifesto...
Nunca escuché la historia y Google no ayuda.
Su trayectoria desde que se retiró hasta su muerte parece bastante inestable.
Es incluso más viejo que yo.
Debian es como Toyota.
Confiable pero aburrido, y encima lo hacen voluntarios.
Por la política de Debian, a veces se ofrece una versión de RetroArch muy limitada, no la versión real.
RetroArch tiene su propia función de gestión de paquetes llamada “Core Updater”, que descarga e instala emuladores en forma de archivos de biblioteca, pero Debian la prohíbe porque considera que eso elude todo el sistema de gestión de paquetes.
Sin embargo, si instalas las dependencias del paquete fuente de Debian y luego compilas el código fuente original, puedes compilar tú mismo un RetroArch con todas las funciones.
Lo aprendí a las malas intentando usar Kodi y RetroArch, aunque por lo demás es un gran sistema operativo.
Personalmente, me gusta Debian y lo uso por sus principios y estabilidad.
He escuchado a usuarios de otras distribuciones y a algunos proyectos upstream quejarse de que Debian “modifica” los paquetes.
Quisiera saber si eso es realmente así y, de serlo, seguramente habrá una buena razón; me gustaría escuchar la explicación.
Primero, parches que hacen que el software se comporte de la forma que Debian espera: guardar la configuración en /etc/, no hacer descargas adicionales durante la ejecución y usar bibliotecas del sistema en lugar de bibliotecas incluidas en el paquete.
Segundo, backports de seguridad.
Debian congela las funcionalidades al momento del lanzamiento y solo ofrece actualizaciones de seguridad, pero hoy mucho software agrupa también las correcciones de seguridad en nuevos lanzamientos junto con nuevas funciones.
Cuando estos dos tipos se combinan, la diferencia entre la versión 1.2 de Debian y la 1.2 “real” se vuelve grande, y gestionar reportes de bugs se vuelve difícil.
Por ejemplo, reciben un reporte de bug de 1.2-Debian, pero el proyecto upstream solo da soporte a la 1.4 “real”, junto con un conjunto actualizado de bibliotecas.
El tercer tipo, que hoy ha desaparecido en gran medida, es cuando Debian parchea el software porque considera que puede mejorarlo.
Esto llegó a causar problemas como la eliminación de la aleatoriedad en las claves SSH: https://github.com/g0tmi1k/debian-ssh
Una es el modelo de versiones incrementales, como Chrome, donde prácticamente no hay lanzamientos separados solo para corregir bugs y las correcciones vienen incluidas en versiones nuevas.
La otra es un modelo centrado en versiones principales: como en el versionado semántico, existen las versiones 1 y 2, y aun después de la versión 2 sale una 1.1 que aplica solo correcciones de bugs a la versión 1.
Debian básicamente solo funciona bien con el segundo modelo.
Como mantiene la estabilidad de la API, no encaja con software desarrollado bajo el primer modelo.
Para sortear esto, Debian hace backport de las “correcciones” de la versión 3 a la versión 1 y crea su propia 1.debian-2.
El problema es que ahora el proyecto upstream empieza a recibir bugs sobre un comportamiento que nunca lanzó.
Debian tiene la libertad de hacerlo, pero el proyecto upstream también tiene la libertad de estar molesto por la carga de trabajo adicional que Debian le impone.
Si hace falta, parchea proyectos upstream que no se ajustan a esas expectativas, y poder hacer precisamente eso es la esencia del software libre.
Basta ver https://www.debian.org/security/2008/dsa-1571.