Ab dem 7. Dezember bis einschließlich gestern konnten die rund 1.000 offiziellen Debian-Entwickler in einer Urabstimmung (General Resolution) über die Zukunft alternativer Init-Systeme im Projekt entscheiden. Jetzt liegt das Ergebnis des komplexen, aber sehr demokratischen Auswertungsverfahrens vor. Insgesamt nahmen 557 Abstimmungsberechtigte teil, davon waren nur 459 gültig. Trotzdem war die Wahlbeteiligung überdurchschnittlich.
Entgegen den im Vorfeld geäußerten Erwartungen gewann nicht der Vorschlag, sich nur noch auf Systemd zu konzentrieren (F), sondern mit 22 Stimmen Vorsprung Vorschlag B, der weiterhin Alternativen zu Systemd unterstützt und Zusammenarbeit mit abgeleiteten Distributionen unterstützt, die ohne Systemd arbeiten. Damit wurde quasi der Status quo weiter gefestigt, ungeachtet der Tatsache, dass der Status quo die Abstimmung erst nötig machte.
Der Kernpunkt von Vorschlag B, der vom derzeitigen Projektleiter Sam Hartman stammt, lautet:
Das Debian-Projekt erkennt an, dass Systemd Service-Einheiten die bevorzugte Konfiguration sind, um zu beschreiben, wie man einen Daemon/Dienst startet. Dennoch bleibt Debian eine Umgebung, in der Entwickler und Benutzer alternative Init-Systeme und Alternativen zu Systemd erforschen und entwickeln können. Diejenigen, die daran interessiert sind, solche Alternativen zu erforschen, müssen die notwendigen Entwicklungs- und Paketierungs-Ressourcen zur Verfügung stellen, um diese Arbeit zu erledigen.
Somit hat eine Position der Mitte gewonnen. Somit wird dieses kontroverse Thema bestimmt nicht zum letzten Mal auf der Tagesordnung bei Debian gestanden haben, wie bereits einige Male zuvor. Die Systemd-Trolle sind jedenfalls schon wieder aufgewacht, wie dieser Kommentar belegt: »The vote’s rigged, it didn’t have the best option: „reject systemd and anything else made by Linus Poettering«
Heute vor 16 Jahren begann die Geschichte der Distribution Kanotix, die bis heute eher im Verborgenen blüht. Dort begann auch meine aktive Linux-Laufbahn. Das erste Abbild von Kanotix erschien am 24. 12. 2003 und steht heute noch zum Download bereit.
Kanotix hat Geburtstag
Kanotix entstand aus einem Ärgernis bei Knoppix. Dieses war als Live-Distribution konzipiert und eignete sich nicht sonderlich gut zur Installation auf der Festplatte. Jörg Schirottke aka Kano stellte dann die erste Ausgabe von Kanotix zusammen. Kano pflegt seine Distribution noch heute aktiv und gibt täglich Hilfestellung im IRC-Kanal von Kanotix auf den Freenode-Server. Bravo dazu!
Aktiver Einstieg in Linux
Die Distribution basierte die ersten Jahre auf Debian Unstable und beinhaltete für verschiedene Aufgaben eine Menge an Scripten von Kano. Für mich stellte Kanotix den aktiven Einstieg in Linux dar, auch wenn ich bereits vorher eher halbherzig SUSE Linux benutzt hatte. Mit der ersten Installation von Kanotix verschwand Windows von meinen Rechnern und ich habe seither kein Linux mehr benutzt, das nicht auf Debian Unstable basiert.
Eine Reihe an Distributionen
Kanotix basierte in der Folge auf Debian Testing und verfolgt heute Debian Stable. Für mich hieß es mit der Umstellung auf Testing mit einigen Kollegen Abschied zu nehmen und Sidux zu gründen, das von der Zeitschrift Chip 2007 als vermutlich schnellstes Linux der Welt bezeichnet wurde. Daraus wurde später Aptosid und vor 8 Jahren dann siduction, was seitdem meine Linux-Heimat ist.
Kanotix gut für Einsteiger
Kanotix wird weiterhin gepflegt und aktualisiert und mit Plasma oder LXDE ausgeliefert. Die aktuellen Versionen können in 32- und 64-Bit vom Kanotix-Server bezogen werden. Wer sich eher in einer kleineren Community als der von Debian wohlfühlt, wo der Entwickler selbst Support leistet, sollte sich Kanotix anschauen. Kanotix eignet sich gut für Linux-Einsteiger, während Siduction sich eher an etwas fortgeschrittene Anwender richtet. Alles Gute zum Kanotix-Geburtstag, Kano!
Im Debian-Projekt tritt keine Ruhe ein, wenn es um Init-Systeme geht. 2014 entschied der Technische Ausschuss als letzte Instanz nach andauernden heftigen Debatten, dass fortan Systemd als Standard-Init-System bei Debian verwendet wird. Jetzt sind nach wiederum anhaltenden Diskussionen die Debian-Entwickler zu einer Urabstimmung aufgerufen, die die Frage klären soll, wie sich Debian künftig zu alternativen Init-Systemen stellt. Bei Debian heißt eine solche Urabstimmung General Resolution (GR).
Systemd und kein Ende
Dazu hat der derzeitige Debian-Projektleiter (DPL) Sam Hartman aus den Diskussionen drei Vorschläge erarbeitet, die von anderen Entwicklern mittlerweile auf sieben Vorschläge erweitert wurden. Die darin vorgeschlagenen Richtlinien reichen von »strikt nur noch Systemd« über »auch andere Init-Systeme, wenn sie nicht ausbremsen« bis zu »zwingend auch andere Init-Systeme«.
Urabstimmung über Init-Systeme
Hartman möchte die Entscheidung hinter sich bringen, da solche Diskussionen dazu tendieren, das Projekt zu lähmen. Er hielt lediglich die Mindestdiskussionszeit ein, die Abstimmung beginnt am 7.12 und endet am 27.12. Wegen der Komplexität der Vorschläge wurde die Wahlperiode von den üblichen zwei auf drei Wochen verlängert.
Verschiedene Positionen
Die Vorschläge, die auf dem Stimmzettel auftauchen sind von 1–7 durchnummeriert, wobei DPL Hartman seinen dritten Vorschlag zurückgezogen hat, da die Aussage in anderen Vorschlägen bereits aufgeführt war. Sie stellen die verschiedenen Positionen dar, die sich in der Diskussion auf der Mailingliste herauskristallisiert haben.
Die Vorschläge
Vorschlag 1 stammt von Martin Michlmayr, der die Fokussierung auf Systemd festschreiben möchte und es damit Paketen ermöglicht, ausschließlich Systemd-Funktionen zu nutzen. Alternative Systeme sind willkommen, sollten aber die Entwicklung nicht aufhalten.
Vorschlag 2 wurde von Hartman formuliert und ist mit »Systemd, aber wir unterstützen die Suche nach Alternativen« überschrieben. Debian würde damit anerkennen, dass Systemd-Service-Einheiten die bevorzugte Konfiguration sind, um zu beschreiben, wie man einen Daemon oder Dienst startet. Debian bleibt damit jedoch weiterhin eine Umgebung, in der Entwickler und Benutzer alternative Init-Systeme und Alternativen zu Systemfunktionen erforschen und entwickeln können. Zudem betont der Vorschlag das Bekenntnis Debians zur Zusammenarbeit mit Derivaten, die unterschiedliche Entscheidungen über Init-Systeme treffen.
Vorschlag 3 ist mit »Unterstützung mehrerer Init-Systeme ist wichtig« überschrieben und besagt, alle Pakete müssen auch ohne Systemd funktionieren, sofern der Entwickler sie nicht ausdrücklich auf Systemd beschränkt hat. Steht ein Paket nicht für mehrere Init-System bereit, wäre das ein Fehler, der mitimportantzu klassifizieren wäre.
Vorschlag 4 stammt von Debian-Urgestein Ian Jackson und mit »Unterstützung von nicht Systemd-gebundenen Systemen, ohne den Fortschritt zu blockieren«. Der sehr ausführliche Vorschlag sieht vor, dass Pakete auf nicht Systemd-gebundenen Installationen funktionieren, aber ein Fehlverhalten gilt nicht als veröffentlichungskritischer Fehler – es sei denn, es gibt die notwendige Unterstützung, wurde aber vom Paketbetreuer nicht aktiviert. Die Verwendung von Systemd-spezifischen Funktionen ist nur zulässig, wenn diese Funktionen dokumentiert sind und alternative Implementierungen realisierbar sind.
Vorschlag 5 von Dmitry Bogatov lässt bereits in der Überschrift erkennen, dass Bogatov unterschiedliche Init-Systeme als verbindlich festgeschrieben sehen möchte. Nach seiner Ansicht muss jedes Paket auch mit Init-Alternativen zu Systemd funktionieren.
Vorschlag 6 stammt von Guillem Jover und ist mit »Unterstützt Portabilität und mehrere Implementierungen« überschrieben. Dieser Vorschlag bleibt vage und sagt lediglich, dass Hard- und Software wichtig sind, aber keine spezifischen Hinweise darauf gibt, was das für die Projektpolitik bedeuten würde. Option 7 steht bisher noch nicht auf der Webseite, stammt wiederum von Ian Jackson, der darin die Vorschläge 4 und 6 zusammenfasst und weiter ausarbeitet.
Stimmberechtigt
Alle rund 1.000 offiziellen Debian-Entwickler sind stimmberechtigt und können sich für einen der Vorschläge entscheiden oder dafür stimmen, das Problem zurück an den Diskussionstisch zu schicken. Da mittlerweile viele Entwickler von der anstrengenden Diskussion genervt sind, wird es aber vermutlich zu einer Entscheidung kommen, die dann in die Richtlinien der Debian Policy einfließen.
Das Debian-Projekt hat am Wochenende rund zwei Monate nach dem Update auf 10.1 die derzeit stabile Veröffentlichung Debian 10 »Buster« einer weiteren planmäßigen Aktualisierung auf Debian 10.2 unterzogen, wie den aktuellen Debian-News zu entnehmen ist.
Sicherheit und Paketfehler im Fokus
Die Aktualisierung behebt, wie bei solchen Punkt-Releases üblich, hauptsächlich aufgelaufene Sicherheitsprobleme seit dem letzten Update, zusammen mit ein paar Anpassungen für schwerwiegende Probleme in Anwendungen. Diese Anpassungen werden in den Punkt-Releases nur dann vorgenommen, wenn keine Regressionen zu befürchten sind.
Debian 10.2 durchschnittlich groß
Das Update auf Debian 10.2 behebt insgesamt 49 Sicherheitsprobleme und korrigiert Fehler in 64 Paketen. Die Sicherheitsprobleme betrafen neben dem Kernel unter anderem Apache2, Chromium, Firefox ESR, Thunderbird, LibreOffice, OpenSSL, OpenSSH und PHP 7.3. Die Behebung von Fehlern betraf den Debian-Installer sowie unter anderem die Pakete Akonadi, Flatpak, GNOME-Shell, NetworkManager, Postfix, Python 2.7 sowie Systemd.
Bitte zeitnah aktualisieren
Anwender, die häufiger Updates einspielen, werden viele der Änderungen bereits eingespielt haben. Ansonsten spielen Bestandsanwender die Updates am sichersten überdie Kommandozeile mit dem Befehl apt update && apt dist-upgrade ein. Für Neuinstallationen werden in den nächsten Tagen sukzessive frische Images bereitgestellt.
Debian 10 »Buster«
Debian 10 »Buster« wurde nach mehr als zwei Jahren Entwicklung am 6. Juli 2019 freigegeben. 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. Standard-Desktop ist GNOME 3.30.
Das Thema Init-Systeme hat Debian schon mehrfach erschüttert. Zuletzt 2014, als sich Debian nach zähem Ringen durch eine Entscheidung des Technischen Komitees für Systemd als künftigen Standard beim Init entschied. Damals verlor Debian viele Anwender, das Projekt wurde sogar geforkt. Seither versucht Devuan, mit alternativen Init-Systemen auszukommen. Debian dagegen versprach, alternative Init-Systeme weiter zu unterstützen und SysVinit möglichst lange parallel ko-installierbar zu halten.
Seit einigen Wochen deutet sich an, dass SysVinit und andere Alternativen anscheinend an Unterstützung im Projekt verlieren. Debians derzeitiger Projektleiter (DPL) Sam Hartman machte das Thema zum Hauptpunkt seiner monatlichen Zusammenfassung »Bits from the DPL« für August.
Elogind blockiert
Anlass war die Blockade einer neuen Version des Pakets elogind seitens eines Mitglieds des Release-Teams. Elogind ist eine bei Gentoo entwickelte Alternative zu logind, die aber ohne Systemd auskommt. Durch die Blockade wurde das Paket daran gehindert, in das Testing-Repository zu gelangen. Eine Diskussion im IRC und die Diskussion der Paketbetreuer von elogind und systemd verliefen zunächst fruchtlos.
Nicht trivial
Die alternative Nutzung von elogind greift tief ins System ein und der DPL und einige weitere Entwickler sehen dies skeptisch. Elogind versucht eine Reihe von Diensten bereitzustellen, die von Desktops beim Login benötigt werden. Um das unter Umgehung von Systemd zu erreichen, implementiert es Bibliotheken, die sowohl im Konflikt mit libsystemd0 und systemd stehen als auch diese ersetzen. Zusätzliche Komplexität entsteht dadurch, dass dazu Funktionen von APT und DPKG eingesetzt werden. Daraus unter Umständen entstehende Probleme beschreibt ein weiterer Bugreport.
Fehlende Kommunikation
Hartman stellt fest, dass die Kommunikation zwischen den beteiligten Teams zur Lösung dieses zunächst rein technischen Problems nicht funktioniert. Da er als DPL und nicht das Technische Komitee zur Lösung des Konflikts herangezogen wurde, fragt er sich, welche anderen, nicht-technischen Gründe hier hineinspielen.
Er macht dann im weiteren Verlauf die Belastung der Entwickler allgemein mit verantwortlich, die bei einigen bis zur emotionalen Erschöpfung reicht. Wenn nicht alle Beteiligten sich an einer Lösung beteiligen können oder wollen, kann niemand sie dazu zwingen.
General Resolution möglich
Hartman sieht eine Situation heraufziehen, in der das Einholen der Standpunkte aller Entwickler des Projekts zur Frage der Unterstützung von Init-Systemen nötig sein wird. Das Werkzeug dazu heißt bei Debian »General Resolution« (GR) oder auch »Allgemeine Abstimmung« und bittet die Entwickler, ihre Meinung zu einer Reihe von vordefinierten Fragen zu einem Thema zu sagen.
Die Bekräftigung der Unterstützung für SysVinit und Elogind wäre eine der möglichen Ergebnisse einer solchen GR . Es könnte allerdings auch in der Erkenntnis enden, dass Debian nicht mehr willens und in der Lage ist, alternative Init-Systeme neben Systemd weiterhin zu pflegen. Ein Indiz dafür, dass die Unterstützung für SysVinit abnimmt, sind die 1033 Pakete, die neben der systemd.service.unit kein init.d-Script für SysVinit mehr haben.
Das Ende der Pflege von SysVinit würde nicht nur den Beschluss des letzten GR zu Systemd negieren, sondern könnte auch zum Problem werden, falls Debian einmal Systemd den Rücken kehren wollte.
Wie bereits seit Längerem angekündigt, hat das Debian-Projekt am Wochenende die derzeit stabile Veröffentlichung Debian 10 »Buster« einer Aktualisierung auf Debian 10.1 unterzogen. Zeitgleich wurde Debian 9 »Stretch«, der mit dem Status »Oldstable« versehene Vorgänger auf Debian 9.10 angehoben.
Spätes Update
Das erste Update für Debian 10 folgt genau zwei Monate auf die initiale stabile Veröffentlichung, während üblicherweise nur vier bis fünf Wochen vergehen, bis die erste Aktualisierung erscheint. In diesem Jahr ist die etwas später angesetzte Veröffentlichung laut den Entwicklern der gerade zu Ende gegangenen Entwicklerkonferenz DebConf und der Urlaubszeit geschuldet.
Beide Aktualisierungen fügen, wie bei solchen Punkt-Releases üblich, hauptsächlich Korrekturen für Sicherheitsprobleme hinzu, zusammen mit ein paar Anpassungen für schwerwiegende Probleme.
Debian 9.9 und 10.1
Debian 9.10 folgt auf Debian 9.9 vom Ende April dieses Jahres, beseitigt 65 Sicherheitsprobleme und behebt 77 schwerwiegende Fehler. Bei Debian 10.1, der ersten Aktualisierung der stabilen Version 10, wurden von den Entwicklern 34 Sicherheitsprobleme beseitigt und 102 Fehler ausgeräumt.
Unter den Paketen, die Sicherheitskorrekturen erhielten, sind diesmal unter anderem Firefox ESR, Thunderbird, LibreOffice sowie Linux die Pakete, bei denen jeweils mehrere Lücken geschlossen wurden.
Nachwehen von Debian 10 »Buster«
Die Zahl der beseitigten Fehler ist bei Debian 10.1 höher als gewöhnlich, weil Patches, die es aus Zeitgründen nicht mehr in die stabile Veröffentlichung geschafft haben, nun in das erste Punkt-Release einflossen. Die beiden Pakete pump und teewords wurden aus beiden Veröffentlichungen wegen Sicherheitsproblemen beziehungsweise fehlender Kompatibilität entfernt.
Frische Installationsmedien
Frische Installationsmedien für beide Veröffentlichungen werden kurzfristig verfügbar sein, aber auch derzeit aktuelle Installationsmedien sind weiterhin benutzbar, wenn nach der Installation ein Upgrade vollzogen wird. Bestandsanwender benötigen lediglich ein Upgrade.
Edit: Bereits Stunden nach der Veröffentlichung von Debian 9.10 wurde die Version von Debian 9.11 abgelöst. Grund war ein kritischer Fehler im Debian-Installer.
Dieser Frage geht der bei Google tätige Entwickler Michael Stapelberg derzeit in seinemBlog und in einem Vortrag nach. Im März hatte Stapelberg seinen Rückzug aus Debian bekannt gegeben, wo er über zehn Jahre tätig war. Grund für seine Kritik an Debian waren dessen Strukturen, die ihm ein effizientes Arbeiten unmöglich machten.
Testobjekt Paketmanager
In der Zwischenzeit hat sich Stapelberg der Paketmanager angenommen und die bekanntesten Exemplare unter Linux systematisch untersucht. Im Grunde gibt es nur zwei Formate, von denen fast alle anderen mehr oder weniger abgeleitet sind. Dabei handelt es sich um das Debian-Paket deb und den Red Hat Package Manager rpm, die beide im Grunde Archivformate sind.
Sie machen zu viel
Was passiert nun, wenn wir eine Paketinstallation anstoßen? Traditionell werden zunächst die Paketlisten gelesen und die Abhängigkeiten überprüft. Darauf folgt der Download, das Entpacken der Archive und das Konfigurieren auf der Basis der im Paket hinterlegten Anweisungen. Schließlich wird das Paket in /usr/bin installiert.
Hoffen und Bangen
Der Moment der eigentlichen Installation nach dem Download der Pakete ist bei den hier betrachteten Paketmanagern heikel. Wenn währenddessen der Akku leer ist oder der Kernel aussteigt oder die Software fehlerhaft, haben wir meist ein Problem. Um das möglichst abzufedern, bedienen sich die Paketmanager des Linux-System-Calls fsync, um den gepufferten Dateiinhalt nicht nur im RAM zu haben, sondern auch auf den Datenträger zu schreiben. Das ist aber nur ein Grund warum eine Paketinstallation teilweise so lange dauert.
Stapelberg hat getestet, wie lange eine Auswahl von Paketmanagern braucht, um ein kleines und ein größeres Paket zu installieren:
Dabei hat das Paket ack eine Größe von 70 Kb, während qemu im Download 70 MB in die Waagschale wirft. Fedora macht bei beiden Paketen die schlechteste Figur. Die herunterzuladenden Metadaten stehen in keinem Verhältnis zur Größe des Pakets und das umso mehr, je kleiner das Paket ist.
Maintainer-Scripte
Ein weiterer Grund, warum Paketmanager lange für eine Paketinstallation brauchen sind die Maintainer-Scripte, die während der Installation über Hooks und Trigger abgearbeitet werden. Dabei werden Anweisungen aus den mit im Paket befindlichen Dateien preinst und postinst ausgeführt, die nach Stapelbergs Ansicht meist auch beim ersten Programmstart aufgerufen werden könnten. Zudem verhindert dieses Abarbeiten der Scripte, dass Pakete parallel installiert werden können.
Aus diesen Beobachtungen zog er den Schluss, dass entweder das Potenzial besteht, den Paketmanager selbst zu optimieren oder was das System macht, ist einfach zu komplex. Das veranlasste ihn dazu, eine experimentelle Distribution namens distri zu erstellen, die einige Dinge anders angeht und über einen wieselflinken Paketmanager verfügt.
Nicht ganz neu
Dabei hat Stapelberg das Rad nicht völlig neu erfunden, sondern verwendet Ideen aus der Distribution NixOS und deren Paketmanager Nix. Betrachtet man obige Grafik, so schafft es Nix einerseits, die benötigten Daten klein zu halten, erreicht aber andererseits nur lausige Übertragungsraten, sodass von der möglichen Geschwindigkeit nichts übrig bleibt. Stapelberg vermutet hier Implementationsfehler. Alpine und Arch Linux sind deutlich schneller als der Rest. Sie machen weniger als der Rest und das effizienter.
Images anstatt Archive
Stapelberg verwendet anstelle von Archiven, die entpackt werden müssen, Images, die schnell gemounted werden können, ähnlich wie bei AppImage oder Snap. Als Format kommen nur lesbare Squash-Images zum Zug, gemounted wird per FUSE. Ein weiterer Vorteil dieser Herangehensweise ist, dass die Pakete nicht verändert werden können. Ähnlich wie bei NixOS werden alle Bestandteile eines Pakets in ein einziges Verzeichnis installiert.
Wer näheres dazu lesen möchte, findet Details im Blog. Die Distribution soll ihren experimentellen Charakter behalten, kann aber von GitHub in verschiedenen Formaten heruntergeladen und getestet werden.
Am 21. Juli beginnt in Curitiba im Südwesten Brasilien die 20. Ausgabe der alljährlichen Debian-Entwicklerkonferenz DebConf. Vor der eigentlichen Konferenz fand eine Woche lang das DebCamp statt, das die Konferenz vor Ort in der »Federal University of Technology« im Herzen der Stadt vorbereitet hat. DebCamp bietet zudem Teams Zeit, um abseits des Trubels der eigentlichen Konferenz Projekte voranzutreiben. Die DebConf geht noch bis zum 28. Juli.
DebConf19 beginnt
Gestern, am 20. Juli wurde der Debian-Day abgehalten, der sich an die Öffentlichkeit richtet, die an diesem Tag Debian und freie Software beschnuppern kann. Die Vorbereitungen für die Konferenz in Curitiba wurden seit Monaten unter anderem von der »Debian User Group Paraná« und der Vereinigung »Curitiba Livre« übernommen.
Von Sponsoren getragen
Nach ersten Berechnungen wird DebConf19 bei rund 300 Teilnehmern Kosten in Höhe von 100.000 US-Dollar verursachen. Die Webseite der Konferenz listet derzeit 38 Sponsoren auf, die zu den Kosten beitragen. Das Programm umfasst neben vielen Vorträgen auch Arbeitstreffen und kurze BoF (Birds of a Feather) genannte informelle Treffen. Viele der 20 oder 45 Minuten langen Vorträge live übertragen und anschliessend archiviert.
Vorträge täglich ab 14 Uhr
Da Curitiba zeitlich fünf Stunden hinter unserer Central European Time (CET) zurückliegt, beginnen die DebConf-Vorträge bei uns jeweils um 14:00 und enden um 23:00. Das Programm ist wie immer prall gefüllt mit Vorträgen, die in bis zu drei Räumen parallel abgehalten werden. Die Archivierung ist meist ein bis zwei Wochen nach der Konferenz abgeschlossen, sodass auch Vorträge, die man im Live-Stream verpasst hat, nachträglich verfolgt werden können.
Sozial wichtige Funktion
Auf der DebConf treffen sich jährlich einige hundert Debian-Entwickler und Mitglieder der Gemeinschaft, um Vorträge zu halten und zu hören, über die zukünftigen Entwicklungen des Betriebssystems zu diskutieren und die nächste Veröffentlichung voranzutreiben. Es ist zudem ein wichtiges soziales Event, auf dem sich Entwickler persönlich austauschen können, die ansonsten das Jahr über auf Mailinglisten und im IRC zusammenarbeiten.
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-Imagesverfügbar. Anwender, die bereits Debian 9 einsetzen, können ihr System wie üblich per APT aktualisieren.
