- Les pratiques particulières de Debian découlent des choix accumulés par un grand système d’exploitation généraliste vieux de 30 ans pour préserver dans la durée la qualité, la sécurité et les principes du logiciel libre
- Debian vise à être une distribution généraliste adaptée à la plupart des personnes et des usages, plutôt qu’une distribution spécialisée ; l’inclusion des paquets dépend avant tout de leur caractère libre et de la qualité de leur maintenance
- La constitution, le contrat social et les DFSG sont apparus après que le fonctionnement plus souple des débuts a montré ses limites, afin d’institutionnaliser une prise de décision démocratique et des pouvoirs de direction limités
- Le principe de compilation autonome et l’évitement des bibliothèques embarquées constituent une stratégie de maintenance qui permet des correctifs de sécurité urgents, des recompilations et des portages vers de nouvelles architectures sans dépendre de dépôts externes ni de dépendances dupliquées
- Le processus d’admission des membres, les noms de code des versions et la lenteur assumée des changements sont la manière dont un projet avec des milliers de paquets et des dizaines de millions d’installations gère la confiance, le coût du mirroring et le coût du consensus
Le système d’exploitation que Debian cherche à être
- Debian vise un système d’exploitation de haute qualité, sécurisé et polyvalent, composé uniquement de logiciels libres et open source fonctionnant sur la plupart des ordinateurs réellement utilisés
- Cet objectif de système d’exploitation généraliste signifie que Debian doit convenir à la plupart des personnes pour la plupart des usages
- Il ne peut pas être adapté à toutes les situations, mais cela reste un objectif qui vaut la peine d’être poursuivi
- Cela conduit à des choix différents de ceux des distributions centrées sur un usage précis, comme le bureau, les serveurs, le jeu ou la recherche scientifique
- La décision de packager ou non un logiciel dépend davantage des critères suivants que de son usage
- si le logiciel est un logiciel libre
- si Debian peut le maintenir comme un paquet de haute qualité
Constitution et gouvernance
- Debian est proche d’une organisation open source explicitement démocratique
- ses procédures de décision sont bien définies
- le Debian Project Leader est élu chaque année
- les pouvoirs du chef de projet sont strictement limités, et de nombreuses prérogatives généralement associées à la direction sont explicitement déléguées à d’autres personnes
- Les premiers Debian Project Leaders étaient, en pratique, proches de dictateurs tout-puissants jusqu’à leur propre départ
- Après qu’un chef de projet a franchi la ligne rouge, il a dû partir sous la pression, ce qui a conduit à l’introduction de la démocratie
- Debian définit les règles du projet dans sa constitution officielle
- Le système de règles actuel découle du constat, au début de son histoire, que moins de règles et moins de bureaucratie ne fonctionnaient pas bien chez Debian
Contrat social et Debian Free Software Guidelines
- Au milieu des années 1990, le terme « open source » n’avait pas encore été introduit, et l’expression « free software », définie par la Free Software Foundation, laissait une large place à l’interprétation
- Debian a voulu des règles plus claires et a donc créé les Debian Free Software Guidelines (DFSG), qu’il a intégrées au contrat social
- Le contrat social est le document de référence par lequel Debian définit ce qu’il est et ce qu’il promet au monde
- les DFSG en font partie
- la constitution de Debian rend volontairement difficile la modification du contrat social
- Des règles plus détaillées permettent de préciser ce que Debian accepte et de simplifier les discussions à ce sujet
- Les DFSG ont ensuite servi de base à l’Open Source Definition
Le principe des compilations autonomes
- Debian tient au principe self-contained
- tout ce que Debian package doit pouvoir être compilé uniquement avec des dépendances présentes dans Debian
- tout ce qui est dans Debian doit être compilé directement par Debian
- Ce principe peut créer beaucoup de travail supplémentaire
- les outils des langages de programmation actuels supposent souvent qu’on télécharge des dépendances depuis des dépôts en ligne au moment de la compilation
- dans Debian, cette approche n’est pas autorisée
- La raison principale est que des dépendances externes peuvent disparaître plus tard
- Debian ne contrôle pas les dépôts de paquets tiers
- si un paquet ou un dépôt entier disparaît, Debian peut ne plus être capable de recompiler le paquet concerné
- Une recompilation est nécessaire lors d’une mise à niveau de compilateur, d’un correctif de sécurité, d’un portage vers une nouvelle architecture ou d’une correction de bug
- Sans autonomie complète, Debian devrait pouvoir compter sur la disponibilité de dizaines de milliers de paquets et de toutes leurs dépendances au moment d’un correctif de sécurité urgent ; Debian préfère donc packager elle-même toutes les dépendances
Pourquoi Debian évite les bibliothèques embarquées
- Debian évite d’utiliser des copies de bibliothèques ou d’autres dépendances incluses directement dans les logiciels qu’elle package
- Beaucoup de projets upstream trouvent plus simple de regrouper leurs dépendances ou de les vendoriser
- Du point de vue de Debian, cela peut créer de multiples copies d’une bibliothèque populaire
- si une faille de sécurité ou un problème grave apparaît dans cette bibliothèque, il faut retrouver et corriger toutes les copies
- en cas d’urgence de sécurité, cela fait perdre un temps précieux
- Dans le cas de zlib, Debian a trouvé des dizaines de copies embarquées de zlib dans l’archive et a dû fournir un effort important pour que les paquets Debian n’utilisent que la version de zlib packagée par Debian
- Debian préfère donc faire ce travail dès l’étape de packaging, avant qu’une urgence n’arrive, afin que les paquets de Debian utilisent les versions de bibliothèques déjà packagées dans Debian
- Les développeurs upstream préfèrent parfois ne gérer que la version embarquée qu’ils ont eux-mêmes validée, ce qui peut occasionnellement créer des frictions avec Debian
Le processus de validation des membres
- Debian est un système d’exploitation de grande taille, complexe et largement utilisé ; il doit donc pouvoir faire confiance à ses membres
- Cette confiance est particulièrement importante pour les personnes qui envoient de nouveaux paquets
- En raison des limites techniques de Linux dans les années 1990, tous les paquets Debian disposaient d’un accès root complet pendant l’installation
- tous les développeurs Debian pouvaient donc, en théorie, devenir root sur n’importe quelle machine exécutant Debian
- c’est un pouvoir considérable, étant donné que Debian tourne sur des dizaines de millions de machines
- Les nouveaux membres sont vérifiés de plusieurs façons
- idéalement, ils doivent avoir participé suffisamment longtemps à la communauté des développeurs Debian pour être connus des autres
- ils doivent gagner la confiance de la communauté
- Ce processus peut être assez frustrant pour les personnes qui veulent contribuer à Debian, en particulier celles habituées à des projets open source plus petits
Les noms de code des versions
- Debian attribue un nom de code à chaque version majeure
- Cette pratique est née à l’origine pour réduire le coût du mirroring de l’archive des paquets Debian
- Au milieu des années 1990, lors de la préparation de Debian 1.0, les répertoires étaient nommés avec les numéros de version et non avec des noms de code
- comme le développement d’une nouvelle version prend du temps, un répertoire « 1.0 » était créé à l’avance
- un éditeur de CD-ROM a produit en masse trop tôt des disques étiquetés « 1.0 », avant que Debian 1.0 ne soit réellement prête
- les personnes ayant reçu ces CD-ROM Debian 1.0 ont donc reçu quelque chose qui n’était pas la vraie 1.0
- La solution simple aurait été de préparer la version dans un répertoire comme « 1.0-not-released », puis de le renommer en « 1.0 » une fois la sortie finalisée
- Mais si le nom du répertoire changeait, tous les miroirs devaient retélécharger la version complète, ce qui représentait un coût important à l’échelle de Debian à l’époque
- à ce moment-là, on parlait d’« centaines de paquets » et de « dizaines de Mo »
- Plus tard, l’archive Debian a adopté la structure pool
- les fichiers de toutes les versions se trouvent dans la même arborescence, et des fichiers de métadonnées indiquent quels fichiers appartiennent à quelle version
- cette structure facilite davantage le mirroring
- Aujourd’hui, il serait peut-être possible d’abandonner les noms de code au profit des seules versions, mais rien ne dit que Debian ait envie de le faire
Pourquoi Debian change lentement
- Debian est un projet très vaste, et les grands projets évoluent lentement
- Les changements qui affectent de nombreux paquets peuvent nécessiter le travail de centaines de bénévoles, ce qui rend difficile toute progression rapide
- Certaines tâches peuvent être gérées par un petit nombre de personnes, et Debian dispose de procédures qui le permettent
- par exemple, lorsqu’une nouvelle version du GNU C compiler est envoyée, l’identification des correctifs nécessaires dans les autres paquets peut généralement être prise en charge par un petit groupe
- Si les changements prennent du temps, c’est aussi parce qu’il faut construire un consensus
- cela demande des discussions larges
- et ces discussions prennent du temps, qu’on ne peut qu’exceptionnellement raccourcir
- Les développeurs Debian ont tendance à être conservateurs dans leurs décisions techniques
- ils préfèrent souvent des solutions qui n’exigent pas de changements de grande ampleur
1 commentaires
Avis de Hacker News
Self-contained et absence de bibliothèques groupées sont des concepts importants qu’une partie de l’écosystème a écartés parce qu’elle les jugeait trop contraignants.
Ce n’est qu’après avoir de nouveau subi les problèmes qui en découlent qu’on leur a donné des termes comme « chaîne d’approvisionnement logicielle », et comme Debian a dès le départ fonctionné de manière à éviter ce genre de problèmes, elle souffre moins des mêmes maux.
Si l’on veut distribuer un logiciel sur plusieurs distributions et systèmes d’exploitation, le bundling des dépendances est rationnel ; du point de vue du maintien d’une distribution, les bibliothèques partagées, où il suffit d’appliquer une seule fois les correctifs de sécurité, sont clairement préférables.
On voit émerger des tendances comme Nix et Silverblue au niveau du système d’exploitation, et Snaps ou Flatpak au niveau applicatif ; je ne sais pas quelle est la solution, mais Debian devra probablement faire quelque chose assez bientôt.
Utiliser une autre version demande des tests rigoureux et la correction des bugs découverts ; je ne sais pas si Debian dispose des ressources pour cela. Au final, cela revient à utiliser des combinaisons de bibliothèques non validées en espérant que tout se passe bien, mais il y a peu de chances que ce soit le cas.
Depuis longtemps, les firmwares publics provenant du dépôt linux-firmware ne sont pas construits depuis les sources : seuls les binaires sont distribués, et il doit exister d’autres cas similaires dans l’archive.
Debian ne supprime pas non plus systématiquement les fichiers générés de tous les tarballs pour les régénérer ; en particulier du côté IA/ML, il est très probable qu’on ne puisse même pas obtenir les données d’entraînement, et que le coût de l’entraînement soit de toute façon difficile à assumer.
https://wiki.debian.org/EmbeddedCopies
Certaines organisations open source ne sont pas seulement un peu impressionnantes : elles sont étonnantes au point de montrer que, dans la manière dont les gens collaborent, elles peuvent être largement supérieures au modèle d’entreprise classique.
J’utilise Debian depuis très longtemps, mais je connaissais mal son organisation, et cet article en donne une bonne introduction.
L’IETF est aussi une organisation qui a quasiment créé Internet, mais elle n’a pas de membres et fonctionne simplement comme ça ; je trouve surprenant que ce type d’organisation ne soit pas mieux connu.
Les guerres des protocoles, où le monde de l’entreprise a tenté de prendre le contrôle du fonctionnement d’Internet en rivalisant avec l’IETF, sont également intéressantes : https://en.wikipedia.org/wiki/Protocol_Wars
Il fut un temps où l’OSI annonçait chaque mois des projets visant à remplacer des parties d’Internet, comme TCP, par des protocoles X., mais à peu près seul X.509 a survécu et prospéré.
Je me demande si ce type d’organisation démocratique et collaborative est réellement bien supérieur au modèle d’entreprise traditionnel.
En termes de taille économique, les revenus de l’IETF ou de Debian ne sont pas comparables à ceux des entreprises, mais du point de vue des contributeurs et des créateurs, on finit par se demander : « qui en profite ? », tandis que les contributeurs tiennent tant bien que mal.
Il me semble que le modèle à la IETF ou Debian mérite d’être expérimenté face au modèle d’entreprise, et dans les guerres des protocoles, il a effectivement fonctionné une fois.
Les groupes de travail de l’IETF comptent beaucoup d’ingénieurs de fournisseurs privés qui collaborent pour l’interopérabilité, tandis que l’ISO ressemble davantage à une organisation traditionnelle descendante, pilotée par les gouvernements.
Après environ 13 ans sous Ubuntu, je suis passé cette année à Debian, et j’en suis plutôt satisfait.
Avant, je trouvais que le modèle de packaging avec mises à jour globales rendait difficile de comprendre ce qui se passait, et provoquait parfois des conflits de versions ; je ne le voyais donc pas comme l’approche techniquement la plus solide.
Mais avec le temps, j’ai fini par beaucoup apprécier la stabilité de Debian et la bonne volonté du projet.
Parfois, l’objectif et les finalités d’un projet comptent davantage que la supériorité technique.
Certains choix techniques me déplaisent, comme le démarrage automatique des démons après installation, mais les avantages apportés par la cohérence générale des paquets et des mises à niveau l’emportent.
Apt est aussi un excellent gestionnaire de paquets.
Il est rapide même par défaut, et prend en charge des scénarios assez exigeants, comme garder le système en stable tout en utilisant uniquement une version plus récente de Nginx depuis les backports.
J’aime l’idée de ne recevoir de nouvelles fonctionnalités que pour un ou deux paquets auxquels je tiens, tout en gardant le reste stable et ennuyeux.
La principale raison est que Debian utilise des technologies ennuyeuses et anciennes, mais qui fonctionnent bien, et que je n’ai plus à voir netplan, snapd ni systemd-resolver.
À moins d’aller chercher des paquets dans Sid ou de faire des choses amusantes comme mettre à jour libc6, si tout a été installé via apt, les conflits de versions ne devraient normalement pas apparaître.
LIW a omis un point majeur : Debian est une organisation de bénévoles, donc personne ne peut forcer un bénévole à faire quelque chose qu’il ne veut pas faire.
Des personnes non contraintes y mettent en place une structure démocratique souple et tournante pour prendre des décisions, et son autosuffisance issue d’un usage prudent des ressources semble être au cœur de l’organisation.
Pour moi, ce conflit a changé durablement l’idée même de ce qu’est Debian, et savoir si c’était une bonne ou une mauvaise chose dépend de la personne à qui l’on pose la question.
Même dans ce type d’organisation, si l’on ne fait pas ce que les autres demandent, on finit évidemment par se retrouver dehors.
Il m’arrive d’imaginer que j’ai tellement d’argent que je n’ai plus du tout à m’en soucier
Dans ces moments-là, je réfléchis toujours aux projets open source auxquels je donnerais, et Debian fait toujours partie des premiers candidats
Il ne manque plus que l’argent, même si bien sûr je fais déjà des dons à Debian entre-temps
Ce serait beaucoup plus amusant
Debian peut être excellent, mais il y a un problème de prise en charge des pilotes, et le projet semble ne le reconnaître qu’à demi-mot
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
« Nous reconnaissons que certains utilisateurs ont besoin de programmes qui ne respectent pas les Debian Free Software Guidelines. Pour ces logiciels, nous avons créé des sections contrib et non-free dans l’archive FTP. »
Il y a un ou deux ans, j’ai fait tourner Debian sur quelques machines ; après une mise à jour du Wi-Fi, tout est tombé en panne, et après avoir regardé les possibilités de retour arrière, je suis simplement passé à Ubuntu — en fait Kubuntu — et là tout fonctionnait bien, sans problème
Debian 12 a même créé un dépôt non-free-firmware dédié, pour que les puristes du logiciel libre puissent faire une concession au moins sur les pilotes non libres nécessaires à l’utilisation du matériel
Sur un système déjà installé, activer le dépôt non-free et installer linux-firmware, ou un paquet firmware-* plus spécifique au matériel, devrait régler le problème
J’ai travaillé avec Ian Murdock à Purdue à l’époque de la toute première version
Lui était administrateur système et développeur, moi j’étais web designer pour la bibliothèque
Il croyait sincèrement à l’approche GNU/Linux et au logiciel libre comme « liberté d’expression »
L’élan initial venait des difficultés liées au packaging et à la gestion des paquets, et c’est probablement sa plus grande contribution
Il était aussi passionné par une idée proche d’une infrastructure P2P appelée Network-of-Workstations, ou NOW, mais cela n’a jamais vraiment pris
Bruce Perens, à qui il a passé le relais, est le dirigeant autoritaire dont il est question dans l’article
Je l’apprécie ; il a un style de gestion à l’ancienne, façon Linus Torvalds, et dans un grand projet complexe avec beaucoup de bénévoles, ce style fonctionne
L’époque de Linux et Debian, autrefois, était vraiment agréable, et même si je ne m’y suis pas autant plongé que d’autres, elle me manque
Aujourd’hui, trop de gens attirés par l’argent sont arrivés, mais bon, c’est comme ça
Le manifeste de Ian explique tout : https://www.debian.org/doc/manuals/project-history/manifesto...
Je n’en ai jamais entendu parler, et Google n’aide pas
Son parcours après son départ et jusqu’à sa mort semble assez instable
Il est plus vieux que moi
Debian, c’est un peu comme Toyota
Fiable, mais ennuyeux, et en plus fabriqué par des bénévoles
À cause de la politique de Debian, il arrive qu’une version très limitée de RetroArch soit fournie au lieu de la vraie version
RetroArch dispose de sa propre fonction de gestion de paquets, appelée « Core Updater », qui télécharge et installe des émulateurs sous forme de fichiers de bibliothèque ; Debian l’interdit au motif que cela contourne tout le système de gestion des paquets
Cela dit, en installant les dépendances du paquet source Debian puis en compilant le code source original, on peut compiler soi-même une version complète de RetroArch
Je l’ai appris à mes dépens en essayant de faire tourner Kodi et RetroArch, mais pour le reste c’est un excellent système d’exploitation
Personnellement, j’aime Debian et je l’utilise pour ses principes et sa stabilité
J’ai entendu des utilisateurs d’autres distributions, ainsi que certains projets upstream, se plaindre du fait que Debian « modifie » les paquets
Je voudrais savoir si c’est vraiment le cas et, si oui, en comprendre les raisons, qui doivent sûrement être bonnes
Premièrement, les patchs qui font en sorte que le logiciel se comporte comme Debian le souhaite : stocker la configuration dans
/etc/, ne pas effectuer de téléchargements supplémentaires à l’exécution, utiliser les bibliothèques système plutôt que des bibliothèques embarquées, etc.Deuxièmement, les backports de sécurité
Debian fige les fonctionnalités au moment de la publication et ne fournit ensuite que des mises à jour de sécurité, mais aujourd’hui, beaucoup de logiciels intègrent aussi les correctifs de sécurité dans de nouvelles versions qui apportent également de nouvelles fonctionnalités
Quand ces deux catégories se combinent, l’écart entre la 1.2 de Debian et la « vraie » 1.2 devient important, et le traitement des rapports de bugs se complique
Par exemple, on reçoit un rapport de bug pour la 1.2-Debian, alors que le projet upstream ne prend en charge que la « vraie » 1.4, avec un ensemble de bibliothèques mises à jour
Troisièmement, une pratique aujourd’hui beaucoup plus rare : Debian patche un logiciel parce qu’elle estime pouvoir l’améliorer
Cela a parfois provoqué des problèmes, comme la suppression de l’aléa dans les clés SSH : https://github.com/g0tmi1k/debian-ssh
L’une est le modèle de versions incrémentales, comme Chrome, où il n’existe pratiquement pas de versions séparées ne contenant que des corrections de bugs, celles-ci étant incluses dans les nouvelles versions
L’autre est un modèle centré sur les versions majeures, comme avec le versionnement sémantique : il y a une version 1 et une version 2, et même après la version 2, une 1.1 peut sortir avec uniquement des corrections de bugs appliquées à la version 1
Debian fonctionne fondamentalement bien uniquement avec le second modèle
Comme elle maintient la stabilité des API, elle s’accorde mal avec les logiciels développés selon le premier modèle
Pour contourner cela, Debian rétroporte les « correctifs » de la version 3 vers la version 1 et crée sa propre 1.debian-2
Le problème, c’est que le projet upstream reçoit alors des bugs concernant un comportement qu’il n’a jamais publié
Debian a la liberté de le faire, mais les projets upstream ont aussi la liberté de se plaindre de la charge de travail supplémentaire que Debian leur impose
Si nécessaire, elle patche les projets upstream qui ne correspondent pas à ces attentes, et le fait de pouvoir précisément le faire est au cœur du logiciel libre
Il suffit de voir https://www.debian.org/security/2008/dsa-1571