- Debians besondere Praxis ist das Ergebnis von Entscheidungen, die ein 30 Jahre altes, großes Universal-Betriebssystem angesammelt hat, um Qualität, Sicherheit und die Prinzipien freier Software langfristig zu bewahren
- Debian versteht sich nicht als Distribution für einen bestimmten Einsatzzweck, sondern als universelle Distribution für die meisten Menschen und Zwecke; ob ein Paket aufgenommen wird, hängt vor allem von freier Software und der Qualität der Pflege ab
- Verfassung, Gesellschaftsvertrag und DFSG entstanden, nachdem sich die Grenzen einer anfangs lockeren Organisation gezeigt hatten, und institutionalisieren demokratische Entscheidungsfindung sowie begrenzte Befugnisse der Leitung
- Das Prinzip selbstenthaltener Builds und die Vermeidung gebündelter Bibliotheken sind eine Wartungsstrategie, die es ermöglicht, Notfall-Sicherheitskorrekturen, Rebuilds und Portierungen auf neue Architekturen durchzuführen, ohne von externen Repositories oder doppelten Abhängigkeiten abhängig zu sein
- Mitgliederprüfung, Release-Codenamen und das langsame Tempo von Veränderungen sind Wege, mit denen ein Projekt mit tausenden Paketen und einer Installationsbasis von vielen Millionen Systemen Vertrauen, Spiegelkosten und Konsenskosten steuert
Das Betriebssystem, auf das Debian abzielt
- Debian strebt ein hochwertiges, sicheres und universelles Betriebssystem an und möchte ausschließlich aus freier und Open-Source-Software bestehen, die auf den meisten aktiv genutzten Computern läuft
- Das Ziel eines universellen Betriebssystems bedeutet, dass Debian für die meisten Menschen und die meisten Zwecke geeignet sein sollte
- Es kann nicht zu jeder Situation passen, ist aber ein sinnvolles Leitbild
- Das führt zu anderen Entscheidungen als bei Distributionen, die sich auf bestimmte Zwecke wie Desktop, Server, Gaming oder wissenschaftliche Forschung konzentrieren
- Ob Software paketiert wird, hängt stärker von den folgenden Kriterien ab als von ihrem Einsatzzweck
- ob die Software freie Software ist
- ob Debian sie als hochwertiges Paket pflegen kann
Verfassung und Governance
- Debian kommt einer ausdrücklich demokratischen Open-Source-Organisation nahe
- Die Entscheidungsverfahren sind klar definiert
- Jedes Jahr wird ein Debian Project Leader gewählt
- Die Befugnisse der Projektleitung sind streng begrenzt, und viele Rechte, die man üblicherweise mit Führung verbindet, sind ausdrücklich an andere delegiert
- Die frühen Debian Project Leader waren faktisch eher Diktatoren mit umfassender Macht, bis sie von sich aus zurücktraten
- Nachdem ein Projektleiter zu weit gegangen war, trat er infolge des Widerstands zurück, und daraufhin wurde Demokratie eingeführt
- Debian definiert die Projektregeln in einer offiziellen Verfassung
- Das heutige Regelwerk geht auf frühe Erfahrungen in der Geschichte zurück, in denen weniger Regeln und weniger Bürokratie bei Debian nicht gut funktionierten
Gesellschaftsvertrag und Debian Free Software Guidelines
- Mitte der 1990er Jahre war der Begriff „open source“ noch nicht eingeführt, und „free software“ war zwar von der Free Software Foundation definiert, ließ aber viel Interpretationsspielraum
- Debian wollte klarere Regeln und schuf deshalb die Debian Free Software Guidelines (DFSG) als Teil des Gesellschaftsvertrags
- Der Gesellschaftsvertrag ist das grundlegende Dokument, in dem Debian sich selbst und der Welt gegenüber zusagt, was es ist und was es tut
- Die DFSG sind ein Teil davon
- Die Debian-Verfassung macht es absichtlich schwierig, den Gesellschaftsvertrag zu ändern
- Detailliertere Regeln machen klarer, was Debian akzeptiert, und vereinfachen entsprechende Diskussionen
- Die DFSG wurden später zur Grundlage der Open Source Definition
Das Prinzip selbstenthaltener Builds
- Debian hält am Prinzip der Selbstenthaltenheit (self-contained) fest
- Alles, was Debian paketiert, muss sich ausschließlich mit Abhängigkeiten aus Debian bauen lassen
- Alles in Debian muss von Debian selbst gebaut werden
- Dieses Prinzip kann viel zusätzliche Arbeit verursachen
- Moderne Werkzeuge für Programmiersprachen gehen oft davon aus, dass Abhängigkeiten zur Build-Zeit aus Online-Repositories heruntergeladen werden
- In Debian ist eine solche Vorgehensweise nicht erlaubt
- Der Hauptgrund ist, dass externe Abhängigkeiten später verschwinden können
- Debian kontrolliert keine Paket-Repositories von Drittanbietern
- Wenn ein Paket oder ein ganzes Repository verschwindet, kann Debian das betreffende Paket womöglich nicht mehr neu bauen
- Rebuilds sind nötig bei neuen Compiler-Upgrades, der Behebung von Sicherheitsproblemen, Portierungen auf neue Architekturen und beim Einpflegen von Bugfixes
- Ohne Selbstenthaltenheit müssten bei einer dringenden Sicherheitskorrektur zehntausende Pakete und all ihre Abhängigkeiten verfügbar sein; deshalb entscheidet sich Debian dafür, alle Abhängigkeiten zu paketieren
Warum Debian gebündelte Bibliotheken vermeidet
- Debian vermeidet die Nutzung von mitgelieferten Bibliothekskopien oder anderen kopierten Abhängigkeiten in der zu paketierenden Software
- Viele Upstream-Projekte finden es einfacher, Abhängigkeiten mitzuliefern oder zu vendoren
- Aus Debians Sicht kann das viele Kopien beliebter Bibliotheken erzeugen
- Wenn diese Bibliothek ein Sicherheitsproblem oder einen schweren Fehler hat, müssen alle Kopien gefunden und korrigiert werden
- Bei dringenden Sicherheitsproblemen verschwendet das wertvolle Zeit
- Im Fall von zlib fand Debian dutzende gebündelte zlib-Kopien im Archiv und investierte erheblichen Aufwand, damit Debian-Pakete nur die in Debian paketierte zlib-Version verwenden
- Deshalb erledigt Debian die Arbeit bereits beim Paketieren im Voraus, damit Pakete innerhalb von Debian die in Debian paketierten Bibliotheksversionen nutzen, bevor ein Notfall eintritt
- Upstream-Entwickler möchten manchmal nur mit der von ihnen validierten gebündelten Version arbeiten, weshalb dieser Ansatz gelegentlich zu Reibungen mit Debian führt
Der Prüfprozess für Mitglieder
- Debian ist als Betriebssystem groß, komplex und weit verbreitet, daher muss es seinen Mitgliedern vertrauen können
- Besonders wichtig ist Vertrauen in Personen, die neue Pakete hochladen
- Wegen technischer Grenzen von Linux in den 1990er Jahren hatten alle Debian-Pakete während der Installation vollständigen root-Zugriff
- Alle Debian-Entwickler können potenziell auf jeder Maschine, auf der Debian läuft, root werden
- Angesichts der Tatsache, dass Debian auf vielen Millionen Maschinen läuft, ist das eine große Macht
- Neue Mitglieder werden auf mehrere Arten überprüft
- Im Idealfall haben sie lange genug in der Debian-Entwicklergemeinschaft mitgewirkt, um anderen bekannt zu sein
- Sie müssen Vertrauen innerhalb der Community aufbauen
- Dieser Prozess kann für Menschen, die bei Debian mitmachen wollen, ziemlich frustrierend sein, besonders für jene, die kleinere Open-Source-Projekte gewohnt sind
Release-Codenamen
- Debian vergibt Codenamen für jede Hauptveröffentlichung
- Diese Praxis entstand ursprünglich, um die Kosten für das Spiegeln des Debian-Paketarchivs zu senken
- Als Mitte der 1990er Jahre Debian 1.0 vorbereitet wurde, verwendete man keine Codenamen, sondern Verzeichnisnamen mit Versionsnummern
- Da die Entwicklung eines neuen Releases Zeit braucht, wurde das Verzeichnis „1.0“ vorab angelegt
- Ein CD-ROM-Verlag produzierte vorzeitig in großer Stückzahl Datenträger mit der Bezeichnung „1.0“, bevor Debian 1.0 fertig war
- Dadurch erhielten Menschen mit einer Debian-1.0-CD-ROM etwas, das in Wirklichkeit nicht 1.0 war
- Die einfache Lösung wäre gewesen, die Vorbereitung in einem Verzeichnis wie „1.0-not-released“ vorzunehmen und es nach Abschluss des Releases in „1.0“ umzubenennen
- Aber wenn sich ein Verzeichnisname änderte, mussten alle Mirrors das Release erneut herunterladen, was bei der damaligen Größe von Debian teuer war
- Die damalige Größenordnung lag bei „hunderten Paketen“ und „zig MB“
- Später kam im Debian-Archiv die pool-Struktur hinzu
- Die Dateien aller Releases liegen im selben Verzeichnisbaum, und Metadateien legen fest, welche Dateien zu welchem Release gehören
- Diese Struktur erleichtert das Spiegeln
- Heute wäre es vielleicht möglich, auf Codenamen zu verzichten und nur Versionen zu verwenden, aber ob Debian daran Interesse hätte, ist unklar
Warum Debian sich langsam verändert
- Debian ist ein sehr großes Projekt, und große Projekte verändern sich langsam
- Änderungen, die viele Pakete betreffen, können die Arbeit von hunderten Freiwilligen erfordern und lassen sich daher nur schwer schnell umsetzen
- Manche Aufgaben können von wenigen Personen erledigt werden, und Debian hat Verfahren, die das ermöglichen
- Wenn zum Beispiel eine neue Version des GNU C compiler hochgeladen wird, können die nötigen Anpassungen in anderen Paketen meist von wenigen Personen identifiziert werden
- Ein weiterer Grund für langsame Veränderungen ist die Notwendigkeit, Konsens zu bilden
- Konsens erfordert breite Diskussionen
- Solche Diskussionen brauchen Zeit und lassen sich nur selten verkürzen
- Debian-Entwickler sind bei technischen Entscheidungen eher konservativ
- Sie bevorzugen oft Lösungen, die keine groß angelegten Änderungen erfordern
1 Kommentare
Hacker-News-Kommentare
Self-contained und keine gebündelten Bibliotheken sind wichtige Konzepte, die Teile des Ökosystems als zu umständlich abgetan haben.
Erst nachdem man die daraus entstehenden Probleme erneut durchlitten hatte, wurden Begriffe wie „Software Supply Chain“ dafür geprägt. Debian hat von Anfang an auf eine Weise gearbeitet, die solche Probleme vermeidet, und leidet daher weniger unter denselben Schmerzen.
Wenn man Software über mehrere Distributionen und Betriebssysteme hinweg ausliefern will, ist Dependency Bundling vernünftig; aus Sicht der Wartung einer Distribution sind Shared Libraries, bei denen man Sicherheits-Patches nur einmal einspielen muss, eindeutig besser.
Auf Betriebssystemebene entstehen Strömungen wie Nix und Silverblue, auf Anwendungsebene Snaps und Flatpak. Ich kenne die Lösung nicht, aber Debian muss wohl bald etwas tun.
Wenn man eine andere Version verwenden will, muss man sorgfältig testen und gefundene Bugs beheben. Ich weiß nicht, ob Debian dafür die Ressourcen hat; am Ende nutzt man eine nicht validierte Kombination von Bibliotheken und hofft, dass es gutgeht — aber danach sieht es nicht aus.
Schon seit Langem wird öffentliche Firmware aus dem linux-firmware-Repository nicht aus dem Quellcode gebaut, sondern nur als Binary ausgeliefert, und im Archiv dürfte es weitere ähnliche Fälle geben.
Debian entfernt auch nicht systematisch aus jedem Tarball generierte Dateien und erzeugt sie neu; besonders im AI/ML-Bereich ist es sehr wahrscheinlich, dass man nicht einmal an die Trainingsdaten kommt, und die Trainingskosten wären ebenfalls schwer zu stemmen.
https://wiki.debian.org/EmbeddedCopies
Einige Open-Source-Softwareorganisationen sind nicht einfach nur ein bisschen beeindruckend, sondern so erstaunlich, dass sie zeigen, wie Zusammenarbeit zwischen Menschen dem klassischen Unternehmensmodell weit überlegen sein kann.
Ich nutze Debian schon sehr lange, wusste aber wenig über die Organisation, und dieser Artikel war eine gute Einführung.
Auch die IETF hat das Internet praktisch miterschaffen, hat aber keine Mitglieder und läuft einfach so; es ist überraschend, wie wenig bekannt solche Organisationen sind.
Interessant sind auch die Protokollkriege, in denen die Unternehmenswelt versuchte, die Funktionsweise des Internets unter ihre Kontrolle zu bringen und mit der IETF konkurrierte: https://en.wikipedia.org/wiki/Protocol_Wars
Es gab eine Zeit, in der OSI monatlich Projekte ankündigte, Teile des Internets wie TCP durch X.-Protokolle zu ersetzen, aber im Grunde hat nur X.509 überlebt und ist gewachsen.
Ich frage mich, ob solche demokratischen Kooperationsorganisationen traditionellen Unternehmensmodellen in der Praxis wirklich deutlich überlegen sind.
Gemessen an wirtschaftlicher Größe können die Einnahmen der IETF oder von Debian nicht mit Unternehmen mithalten; aus Sicht der Beitragenden und Schöpfer stellt sich aber die Frage: „Wer profitiert davon?“, und die Beitragenden halten sich gerade so über Wasser.
Es scheint sich zu lohnen, zu erproben, ob Modelle wie IETF oder Debian mit dem Unternehmensmodell konkurrieren können; in den Protokollkriegen hat es tatsächlich schon einmal funktioniert.
In IETF-Arbeitsgruppen gibt es viele Ingenieure von Unternehmensanbietern, die für Interoperabilität zusammenarbeiten wollen, während ISO eher eine traditionelle, von oben nach unten staatlich getriebene Organisation ist.
Ich habe etwa 13 Jahre Ubuntu genutzt, bin dieses Jahr zu Debian gewechselt und mag es ziemlich.
Früher hielt ich das Paketierungsmodell mit globalen Updates technisch nicht für die solideste Methode, weil schwer zu erkennen war, was passiert, und es gelegentlich auch Versionskonflikte gab.
Mit der Zeit habe ich aber die Stabilität von Debian und die guten Absichten des Projekts immer mehr zu schätzen gelernt.
Manchmal sind Zweck und Ziele eines Projekts wichtiger als technische Überlegenheit.
Mit einigen technischen Entscheidungen, etwa dass Daemons nach der Installation automatisch gestartet werden, bin ich unzufrieden, aber die Vorteile der Konsistenz bei Paketen und Upgrades insgesamt überwiegen.
Auch Apt ist ein wirklich hervorragender Paketmanager.
Er ist schon im Grundzustand schnell und unterstützt auch ziemlich anspruchsvolle Szenarien, etwa das System auf stable zu lassen, aber nur Nginx in einer neueren Version aus backports zu nutzen.
Mir gefällt das Gefühl, nur für ein oder zwei Pakete, die einem wichtig sind, neue Funktionen zu bekommen, während der Rest stabil und langweilig bleibt.
Der Hauptgrund ist, dass es langweilige und alte, aber gut funktionierende Technik verwendet, und ich netplan, snapd und systemd-resolver nicht mehr sehen muss.
Solange man nicht Dinge wie Pakete aus Sid zu ziehen oder ein libc6-Upgrade macht, sollte man Versionskonflikte normalerweise nicht sehen, wenn alles per apt installiert wurde.
LIW hat einen großen Teil ausgelassen: Debian ist eine Freiwilligenorganisation, daher kann niemand Freiwillige zwingen, etwas zu tun, das sie nicht tun wollen.
Nicht gezwungene Menschen bilden locker rotierende demokratische Strukturen, um Entscheidungen zu treffen, und die aus vorsichtigem Ressourceneinsatz entstehende Selbstversorgung scheint ein Kern der Organisation zu sein.
Für mich hat dieser Konflikt die Vorstellung davon, „was Debian ist“, dauerhaft verändert; ob das gut oder schlecht war, hängt davon ab, wen man fragt.
Auch in solchen Organisationen landet man selbstverständlich vor der Tür, wenn man nicht tut, was andere verlangen.
Manchmal stelle ich mir vor, so viel Geld zu haben, dass ich mir überhaupt keine Sorgen mehr darum machen müsste
Dann plane ich immer, welchen Open-Source-Projekten ich spenden würde, und Debian ist immer unter den ersten Kandidaten
Jetzt fehlt nur noch das Geld; natürlich spende ich Debian auch in der Zwischenzeit
Das macht viel mehr Spaß
Debian kann großartig sein, hat aber Probleme mit der Treiberunterstützung, und es scheint das nur zögerlich anzuerkennen
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
„Wir erkennen an, dass einige Nutzer Programme benötigen, die nicht den Debian Free Software Guidelines entsprechen. Für solche Software haben wir in unserem FTP-Archiv die Bereiche contrib und non-free eingerichtet.“
Vor ein oder zwei Jahren ließ ich Debian auf ein paar Maschinen laufen, aber nach einem WiFi-Update funktionierte es nicht mehr; nachdem ich mir Rollbacks usw. angesehen hatte, wechselte ich einfach zu Ubuntu, genauer gesagt Kubuntu, und damit lief alles problemlos
Debian 12 hat sogar ein eigenes non-free-firmware-Repository angelegt, damit Free-Software-Puristen bei unfreien Treibern zumindest so weit nachgeben können, dass ihre Hardware nutzbar ist
Bei bereits installierten Systemen sollte es reichen, das non-free-Repository zu aktivieren und linux-firmware oder ein spezifischeres, zur Hardware passendes firmware-*-Paket zu installieren
Zur Zeit des ersten Releases arbeitete ich in Purdue mit Ian Murdock zusammen
Er war Systemadministrator und Entwickler, ich war Webdesigner der Bibliothek
Er glaubte wirklich an den GNU/Linux-Ansatz und an „Freiheit wie in Redefreiheit“-Software
Der frühe Antrieb kam aus den Schwierigkeiten mit Packaging und Paketverwaltung, und das war vermutlich sein größter Beitrag
Er war auch begeistert von einer Idee namens Network-of-Workstations, kurz NOW, einer Art P2P-Infrastruktur, aber sie setzte sich nie richtig durch
Bruce Perens, an den er übergab, ist der autoritäre Leiter, von dem im Artikel die Rede ist
Ich mag ihn, und sein Führungsstil ist der alte Schlag wie bei Linus Torvalds; in großen, komplexen Projekten mit vielen Freiwilligen funktioniert so etwas
Die alten Linux- und Debian-Zeiten haben wirklich Spaß gemacht, und auch wenn ich nicht so tief drin war wie andere, vermisse ich diese Zeit
Heute sind zu viele Leute eingestiegen, die nach Geld riechen, aber so ist das eben
Ians Manifest erklärt alles: https://www.debian.org/doc/manuals/project-history/manifesto...
Ich habe noch nie davon gehört, und Google hilft auch nicht weiter
Sein Werdegang nach dem Rücktritt bis zu seinem Tod wirkt ziemlich instabil
Der ist älter als ich
Debian ist wie Toyota
Zuverlässig, aber langweilig, und obendrein von Freiwilligen gebaut
Wegen der Debian-Policy wird mitunter nicht die echte Version, sondern eine stark eingeschränkte RetroArch-Version ausgeliefert
RetroArch hat eine eigene Paketverwaltungsfunktion namens „Core Updater“, mit der Emulatoren als Bibliotheksdateien heruntergeladen und installiert werden; Debian verbietet das, weil es das gesamte Paketverwaltungssystem umgeht
Wenn man jedoch die Abhängigkeiten des Debian-Quellpakets installiert und dann den Upstream-Quellcode baut, kann man sich selbst ein RetroArch mit vollem Funktionsumfang bauen
Das habe ich auf die harte Tour gelernt, als ich Kodi und RetroArch betreiben wollte; abgesehen davon ist es aber ein großartiges Betriebssystem
Ich persönlich mag und nutze Debian wegen seiner Prinzipien und Stabilität.
Ich habe von Nutzern anderer Distributionen oder von einigen Upstream-Projekten gehört, die sich darüber beschweren, dass Debian Pakete „modifiziert“.
Ob das wirklich so ist – und falls ja, gibt es sicher gute Gründe dafür; ich würde gern eine Erklärung hören.
Erstens Patches, die dafür sorgen, dass Software so funktioniert, wie Debian es möchte: Konfigurationen werden unter /etc/ gespeichert, zur Laufzeit werden keine zusätzlichen Downloads durchgeführt, und statt gebündelter Bibliotheken werden Systembibliotheken verwendet.
Zweitens Security-Backports.
Debian friert bei einem Release die Funktionen ein und liefert nur Sicherheitsupdates aus, aber heutzutage bündeln viele Softwareprojekte auch Sicherheitsfixes zusammen mit neuen Funktionen in neuen Releases.
Wenn diese beiden Arten zusammenkommen, wird der Unterschied zwischen Debians 1.2 und der „echten“ 1.2 groß, und die Bearbeitung von Bugreports wird schwierig.
Zum Beispiel bekommt man einen Bugreport zu 1.2-Debian, während das Upstream-Projekt nur die „echte“ 1.4 zusammen mit einem aktualisierten Bibliothekspaket unterstützt.
Drittens gibt es eine Vorgehensweise, die heute weitgehend verschwunden ist: Debian patcht Software, weil es glaubt, sie verbessern zu können.
Dadurch sind auch Probleme entstanden, etwa dass die Zufälligkeit aus SSH-Schlüsseln entfernt wurde: https://github.com/g0tmi1k/debian-ssh
Die eine ist das inkrementelle Versionsmodell, wie bei Chrome, bei dem es praktisch keine separaten Bugfix-Releases gibt und Bugfixes in neuen Versionen enthalten sind.
Die andere ist ein Modell rund um Hauptversionen, ähnlich semantischer Versionierung: Es gibt Version 1 und 2, und auch nach Version 2 erscheint noch eine 1.1, die nur Bugfixes für Version 1 enthält.
Debian funktioniert grundsätzlich nur mit dem zweiten Modell gut.
Weil es API-Stabilität beibehält, passt es nicht zu Software, die nach dem ersten Modell entwickelt wird.
Um das zu umgehen, backportet Debian „Fixes“ aus Version 3 nach Version 1 und erstellt daraus ein eigenes 1.debian-2.
Das Problem ist, dass das Upstream-Projekt nun Bugs zu einem Verhalten bekommt, das es selbst nie veröffentlicht hat.
Debian hat die Freiheit, das zu tun, aber Upstream-Projekte haben ebenso die Freiheit, sich über die zusätzliche Arbeit zu beschweren, die Debian ihnen aufbürdet.
Wenn nötig, patcht es Upstream-Projekte, die diesen Erwartungen nicht entsprechen; und genau die Möglichkeit, das zu tun, ist ein Kern freier Software.
Siehe https://www.debian.org/security/2008/dsa-1571.