Schlagwort: Debian GNU/Linux

Gerade erst wurde Debian 10 »Buster« veröffentlicht. Die Fertigstellung eines Debian-Release dauert in der Regel um die zwei Jahre. Die Entwickler lassen sich dabei nicht drängeln, denn das Motto der größten Distribution ohne ein Unternehmen im Hintergrund lautet seit jeher »Es wird veröffentlicht, wenn es fertig ist«. Ein Debian-Release ist eine wahre Herkulesaufgabe; Debian 10 »Buster« setzt sich laut Statistik aus 28.939 Quellpaketen mit insgesamt 11.610.055 Dateien zusammen.

Freeze leitet Endphase ein

Die neue Version wächst im Testing-Repository heran, während die aktuell stabile Version im Stable-Repository residiert. Nach rund 18 Monaten Entwicklungszeit geht es mit dem schrittweisen Einfrieren von Testing in die Endphase der Entwicklung zur neuen Version.

Das Einfrieren der Codebasis, der sogenannte Freeze ist ein Teil in Debians Entwicklungsablauf und verlangsamt sukzessive die Aktivität im Testing-Repository, in dem bereits seit der Veröffentlichung der Vorversion das neue Release heranwächst. Ohne diese Verlangsamung wäre eine Veröffentlichung sehr schwierig, da der Testing-Zweig nicht zur Ruhe käme.

Vorankündigung

Wenn der Release-Zeitpunkt absehbar ist, wird dieser als voraussichtliches Erscheinungsdatum veröffentlicht. Das gibt Entwicklern einen Zeitrahmen für letzte Anpassungen und Frühumsteigern auf die neue Version genügend Zeit für Vorbereitungen.

Geschlossene Veranstaltung

Einige Tage vor dem anvisierten Zeitpunkt erreicht der Freeze seinen Höhepunkt. Selbst releasekritische Fehler werden in dieser Phase nur noch in Ausnahmefällen korrigiert und meist auf das erste Punkt-Release einige Wochen später verschoben. Dringende Änderungen an der Dokumentation werden jedoch noch angenommen, da diese keine Regressionen verursachen. Der Debian-Installer erhält ein letztes Update vor dem Release.

Handarbeit beginnt

Am Tag vor dem Release werden die automatischen Scripte, die die Archive aktualisieren oder andere Wartungsaufgaben wahrnehmen, abgeschaltet. Ab diesem Punkt wird das Release von Hand gesteuert. An den Schalthebeln sitzen bis zur Veröffentlichung nun Mitglieder des Release- Teams und die FTP-Master. Eine Vielzahl an Testern wartet an ihren Rechnern auf erste Testbuilds. Zu diesem Zeitpunkt trudeln bereits die Übersetzungen der Release Notes in 76 Sprachen ein, die bereits vor Tagen an die Übersetzer verteilt wurden.

Dinstall

Am Morgen des Release wird der dinstall gegen acht Uhr morgens abgewartet. Dabei handelt es sich um einen Daemon, der das Verzeichnis incoming beobachtet und alle acht Stunden die neu dorthin hochgeladenen Pakete in die entsprechenden Repositories leitet. Dann beginnt der eigentliche Release-Prozess, der meist 12 – 18 Stunden dauert.

Neue Etiketten

Die Release-Manager geben das Signal, nachdem keinerlei Änderungen mehr vorgenommen werden. Die FTP-Master beginnen mit der Umbenennung der Repositories. So wurde das vor wenigen Tagen von »Buster« abgelöste »Stretch« von stable zu oldstable und Buster von testing auf stable umetikettiert. Ein neues Testing-Repository wird für Debian 11 »Bullseye« erstellt und bevölkert. Dort beginnt nach einer Erholungspause in dem in den nächsten Wochen die Entwicklung für das nächste Debian-Release.

Images werden gebaut

Im nächsten Schritt lösen die FTP-Master einen Push aller Änderungen an die Server aus, die die Images bauen. Dies und das anschließende Testen der Images unter verschiedenen Bedingungen nimmt die meiste Zeit in Anspruch. Das erklärt sich unter anderem dadurch, dass Debian für das jetzt erschienene »Buster« für zehn Architekturen ausgeliefert wird. Je exotischer die Architektur, desto weniger Hardware steht zum Testen zur Verfügung.

Zudem sind die Tester bemüht, möglichst viele der denkbaren Optionen zur Installation auszuprobieren. Vom Ausliefern der ersten Images an die Tester bis zur endgültigen Freigabe der Veröffentlichung und deren Verkündung an die Öffentlichkeit vergingen am vergangenen Wochenende rund 15 Stunden.

Ende gut – alles gut

Derweil werden im Hintergrund diverse Anpassungen der Infrastruktur vorgenommen. So wird etwa die Debian-Webseite auf den Neuankömmling vorbereitet und mittlerweile eingetroffene Übersetzungen der Release Notes eingebunden. Nach dem Ende der Testphase schieben die FTP-Master in einem letzten Schritt die Früchte der Arbeit eines langen Tages auf die offiziellen Debian-Server und deren weltweit verteilte Spiegelserver. Nachts gegen drei Uhr unserer Zeit war es dann soweit und ein neues Debian-Release konnte verkündet werden.

Rund zwei Jahre sind vergangen, seit Debian 9 »Stretch« herausgegeben wurde. Jetzt erscheint, wie vor einigen Wochen bereits angekündigt, der Nachfolger Debian 10 »Buster«. Wie üblich stammt der Codename wieder aus dem Hollywood-Streifen Toy Story. Buster ist dort der Dackel des Protagonisten Andy.

Viel Neues unter der Haube

Neben aktualisierten Paketen und Desktop-Umgebungen hat Debian 10 auch einige wichtige Änderungen und Weiterentwicklungen unter der Haube aufzuweisen. Dazu zählen unter anderem UsrMerge, Gnome mit Wayland als Standard und die Einführung von Secure Boot.

Debian 10 Buster mit GNOME 3.30

Doch zunächst zu den für den Anwender sichtbaren Änderungen. Als Basis kommen Kernel 4.19 mit Langzeitunterstützung, Systemd 241 und Mesa 18.3 zum Einsatz. GNOME 3.30 stellt auch dieses Mal wieder den Standard-Desktop. Im Gegensatz zum letzten Release wird dieser jedoch mit Wayland als Standard ausgeliefert. Wer lieber noch beim althergebrachten X-Server bleiben möchte, muss hier händisch eingreifen. Als alternative Desktops stehen KDE Plasma 5.14, LXDE 10,LXQt 0.14, MATE 1.20 und Xfce 4.12 zur Verfügung.

Endlich UsrMerge

Debian 10 setzt den UsrMerge um, der bereits für Debian 9 vorgesehen war. Alle großen Distributionen außer openSUSE haben diesen Schritt bereits vollzogen. Hinter dem Stichwort UsrMerge versteckt sich die Aufhebung der Trennung von /bin und /usr/bin, /sbin und /usr/sbin, /lib und /usr/lib sowie /lib64 und /usr/lib64. Alle Dateien aus den Verzeichnissen in / werden mit ihren jeweiligen Gegenstücken in /usr zusammengeführt, stattdessen werden aus Kompatibilitätsgründen Symlinks für die alten Verzeichnisse erstellt.

Damit wird eine historisch bedingte Verkomplizierung des Filesystem Hierarchy Standard (FHS) aufgehoben. Mit dem UsrMerge eröffnet sich die Möglichkeit, die unveränderlichen Teile des installierten Betriebssystems schreibgeschützt einzuhängen, es atomar zu aktualisieren, als zustandsloses System auszulegen oder auch auf mehrere Hosts oder Container zu verteilen.

Secure Boot unterstützt

Eine weitere Neuerung, mit der Debian lange gewartet hat ist die Unterstützung von Secure Boot. Secure Boot ist ein von UEFI implementierter Verifizierungsmechanismus, um sicherzustellen, dass der von der UEFI-Firmware eines Computers gestartete Code vertrauenswürdig ist. Es wurde entwickelt, um ein System davor zu schützen, dass bösartiger Code früh im Bootvorgang geladen und ausgeführt wird, bevor das Betriebssystem fertig geladen ist.

Calamares als Alternative

Die Live-Medien von Debian 10 werden mit einem Installer auf der Basis des Calamares Installer-Frameworks anstelle des üblichen Debian-Installers (DI) ausgeliefert. Das ermöglicht neuen Anwendern die Installation von Debian ohne die Komplexität des DI, allerdings auch ohne dessen vielfältige Möglichkeiten.

Weitere Änderungen betreffen die längst überfällige Aktualisierung von OpenJDK 8 auf Version 11. Gleiches gilt für den Umstieg von Nodejs 4.8 auf 10.15.2. AppArmor ist nun standardmäßig aktiviert und bei den Firewall-Scripten ersetzt NFtables jetzt iptables.

Breite Unterstützung

Das Release von Debian 10 wird für zehn Architekturen veröffentlicht. Diese sind amd64, AArch64, armel, armhf, i386, MIPS (Big und Little Endian), Mips64 (Little Endian), Power und IBMSystem Z.

Alle weiteren Änderungen können den Release Notes entnommen werden. Debian 10 ist in Form zahlreicher verschiedener Installationsmedien inklusive offizieller OpenStack-Images verfügbar. Anwender, die bereits Debian 9 einsetzen, können ihr System wie üblich per APT aktualisieren.

Debian hat am Wochenende erstmals ein Debian-Project-Leader-Team (DPL) aus vier Entwicklern als Leitungsgremium bestimmt. Bisher wurde bei Debian immer nur eine Person zum DPL gewählt. Dieser konnte zwar Aufgaben delegieren, war aber dem Projekt gegenüber verantwortlich.

Erst kein Kandidat…

Während der ursprünglichen Nominierungsphase zu den alljährlich im Frühjahr abgehaltenen Wahlen zum DPL fand sich erstmals in der Projekthistorie nicht ein einziger Kandidat. Die Richtlinien sehen in einem solchen Fall vor, dass jeweils um eine Woche verlängert wird, bis zumindest ein Kandidat auf der Liste steht.

…dann gleich fünf

Zum Erstaunen vieler im Projekt meldeten sich in der Verlängerungswoche gleich fünf Entwickler, die das Amt für ein Jahr übernehmen wollten. Die Kandidaten sind Joerg Jaspert, Sam Hartman, Martin Michlmayr, Jonathan Carter und Simon Richter. Davon können zumindest die ersten drei als Schwergewichte in Debian gelten. Sie sind schon sehr lange im Projekt und haben ihm in mannigfaltigen Rollen gedient.

Wahlkampf

Nachdem die Kandidaten ihre Wahlplattformen bereits veröffentlicht hatten, zog sich Simon Richter aus persönlichen Gründen zurück. Die vier verbleibenden Anwärter verteidigten zunächst ihre Plattformen auf der Mailingliste und beantworteten die Fragen der Kollegen zu ihrer Kandidatur.

Gute Ergänzung

Nachdem dann die Kandidaten auch die teils umfangreichen Plattformen der Mitanwärter gelesen hatten, ergab sich die Erkenntnis, dass die vier recht unterschiedlichen Plattformen einander ideal ergänzen. Sind Michlmayr und Jaspert eher technisch und programmatisch ausgerichtet, so geht es Sam Hartman zum Beispiel mehr darum, den Spaß bei der Projektarbeit zu erhalten und die Diskussionskultur und den generellen Umgang miteinander zu verbessern. Er sieht sich dabei in der Rolle des Mediator.

DPL-Team

So kam es am Freitag zu der Entscheidung, dass man sich an einen kürzlich gemachten Vorschlag des ehemaligen DPL Lucas Nussbaum erinnerte und sich entschloss, gemeinsam als Team bei der am 31.März abgehaltenen Wahl anzutreten. Die Kürze der Bekanntgabe der Entscheidung ließ keine lange Diskussion zu, was aber nichts daran änderte, dass bei der Wahl von den 458 teilnehmenden Entwicklern 334 für den Vorschlag stimmten.

Zwei Jahre im Amt

Anders als bisher nimmt das gewählte Team den Posten für zwei Jahre ein, um die Effizienz eines solchen Teams besser beurteilen zu können. Gleich nach der Wahl stellte das DPL-Team auch bereits einen ersten brisanten Ansatz zur Lösung einiger der Probleme im Projekt vor.

Bezahlte Entwickler?

Aufgrund einer Spende von 300.000 US-Dollar, die das Projekt kürzlich von der Handshake Foundation erhielt, möchte das DPL-Team einen Teil dieser Summe dazu verwenden, um interne oder externe Entwickler zu bezahlen, um einige der Probleme der überalterten Infrastruktur Debians zu beheben.

Dunc-Tank anyone?

Die Brisanz dieses Vorschlags liegt darin, dass das Projekt vor 13 Jahren bereits einmal einen solchen Vorstoß unternahm, punktuell Entwickler für bestimmte Aufgaben zu bezahlen. Das heute noch unter dem Namen Dunc-Tank. Damals ging es darum, das Release-Team zu bezahlen um die Veröffentlichung von Debian GNU/Linux 4 »Etch« zu beschleunigen.

Projekt gespalten

Dunc-Tank wurde von vielen Entwicklern als Experiment befürwortet, von einer Minderheit aber vehement bekämpft, die der Meinung waren, Debian 4 solle veröffentlicht werden wenn es fertig sei. Eine Meinung, die sich später durchsetzen sollte und zum Mantra von Debian wurde. Der Protest reichte bis hin zu einer Parodie namens Dunc-Bank. Im Rahmen der Diskussion, die das Projekt bis zum Zerreißen anspannte, wurde unter anderem die Entfernung des damaligen DPL Anthony Towns, der Dunc-Tank erdacht hatte, aus dem Amt gefordert.

Neuer Versuch?

Die Bezahlung zweier Release-Manager führte allerdings nicht dazu, dass Debian 4 zum projektierten Termin fertig wurde. Das dauerte dann noch fast ein halbes Jahr länger. Nun soll das Experiment, die Entwicklung Freier Software mit Geld zu beschleunigen, nach 13 Jahren wiederholt werden, wenn es nach dem Willen des neuen DPL-Teams geht. Ob das diesmal gutgeht?

Die letzten Wochen haben an einigen Stellen gezeigt, dass sich das Debian-Projekt einer Reihe von schwierigen Herausforderungen gegenüber sieht. Dabei wird das Meistern dieser Probleme nicht einfacher dadurch, dass Debian eine demokratische Ausrichtung hat, beziehungsweise den Prinzipien einer Do-ocracy folgt, ohne dass jemand an der Spitze die Marschrichtung vorgibt.

Veraltete Werkzeuge

Zunächst kritisierte der Entwickler Michael Stapelberg, der mehr als zehn Jahre lang eine Reihe von Paketen innerhalb von Debian betreut hatte, das Projekt. In einem Blogeintrag, in dem er seinen Rückzug erklärte, mahnte er, Debians Werkzeuge seinen veraltet und nicht effektiv genug.

Auch die Tatsache, dass sich in den ersten beiden Wochen der Wahlperiode kein Bewerber gemeldet hatte ist ein Novum. Dass sich dann in der Verlängerungswoche gleich fünf Kandidaten bereit erklärten, das stressige Ehrenamt zu übernehmen, lässt dagegen Hoffnung zu.

Nachlassende Relevanz

In seiner Plattform zur Wahl zum Debian Projekt Leader (DPL) kritisiert Langzeit-Debianer Martin Michlmayr das Projekt in ähnlicher Weise. Vor 10 – 15 Jahren sei Debian in einer existentiellen Krise gewesen, was seine Relevanz im Reigen der Linux-Distributionen angeht. Das sei zum einen durch die Einführung von Ubuntu, andererseits durch eine Abwanderung zu macOS bedingt gewesen.

Wie vor 20 Jahren

Michlmayr bestätigt Stapelbergs Analyse, sieht die Probleme aber als noch größer an. Die Open-Source-welt habe sich in den letzten 5 – 10 Jahren in vielerlei Hinsicht verändert. Trotzdem agiere Debian in weiten Teilen wie vor 20 Jahren.

Kaum Innovation

In dieser Zeit sei Debian ständiger Innovator gewesen und habe für die damalige Zeit aufregende Dinge wie Paketmanager und automatische Upgrades eingeführt und Pakete für mehr als 10 Architekturen bereit gestellt. Als einzige bedeutende Innovation der letzten Jahre bei Debian nennt Michlmayr reproduzierbare Builds. Diese lösten ein wichtiges Problem und die Idee habe sich über Debian hinaus auf die gesamte FOSS-Welt ausgebreitet.

Nicht entscheidungsfreudig

Das schreibt Michlmayr, der bereits in 2003 und 2004 das Amt des DPL innehatte, der Unfähigkeit des Projekts zu, in der schnelllebigen Zeit Entscheidungen zeitig zu treffen und umzusetzen. Projektmitglieder hätten Angst, weitreichende Änderungen auch nur vorzuschlagen, weil die oft toxische Diskussionskultur und die resultierenden Flamewars die Umsetzung von gefundenen Lösungen zu sehr erschweren. Michlmayr ist der Meinung, dass Debian im Laufe der Jahre eine Reihe von Anti-Verhaltensmustern entwickelt hat, von denen das Projekt weggehen muss.

Probleme lösbar

Dabei sei Debian in der Welt der Server, bei Containern und in der Cloud so relevant wie nie. Deshalb glaubt er, die Probleme seien lösbar und sieht die Rolle des DPL dabei als Vermittler, der Leute zusammenbringt. Joerg Jaspert, Mitbewerber und ebenfalls Debian-Urgestein, sieht das ähnlich, wenn er schreibt: »Die Aufgabe des DPL ist es nicht, technische Lösungen für die Probleme des Projekts zu finden, sondern anderen zu ermöglichen, Herausforderungen zu meistern.

Die Wahlplattformen aller Kandiaten sind auf der Webseite zur Wahl des DPL einsehbar. Es bleibt zu hoffen, dass nach vielen Anregungen der letzten Zeit das Amt des DPL nicht länger als One-Man-Show begriffen wird, sondern ein Team die Aufgaben unter sich aufteilt und effektiv angeht.