Der Plasma-Desktop unter Debian Testing oder Unstable lässt des Öfteren Aktualität vermissen. Das liegt daran, dass das Qt-KDE-Team notorisch unterbesetzt ist. Jetzt gibt es trotzdem ein aktuelles Plasma 18.3 zum Testen.
Plasma 5.18.3 LTS
Bis vor wenigen Wochen hingen die Anwender von Plasma auf den Entwicklungszweigen Testing und Unstable bei Plasma 5.13 fest, dann wurde auf 5.17 aktualisiert, während 5.18 LTS bereits offiziell verfügbar war. Jetzt stellt Debian-Entwickler Norbert Preining, der bereits aktuelle Pakete von Okular und Calibre pflegt, ein aktuelles, jedoch inoffizielles Set von Paketen für Plasma 5.18.4 bereit.
Quellenliste anpassen
Um die Pakete installieren zu können, muss die Quellenliste unter /etc/apt/sources.list.d/debian.list für Debian Testing um die Zeile
deb http://download.opensuse.org/repositories/home:/npreining:/debian-plasma/Debian_Testing ./
und für Debian Unstable um die Zeile
deb http://download.opensuse.org/repositories/home:/npreining:/debian-plasma/Debian_Unstable ./ ergänzt werden.
Danach gilt es zunächst den Repository-Schlüssel von Norbert herunterzuladen und in die zu erstellende Datei /etc/apt/trusted.gpg.d/obs-npreining.asc zu kopieren. Ein darauffolgendes sudo apt update && sudo apt dist-upgrade aktualisiert die Plasma-Pakete auf den Stand des aktuellen Plasma 5.18.4.
Nur für Testing und Unstable
Um es nochmals zu betonen: diese Pakete eignen sich nur für Anwender von Debian Testing und Unstable. Sie eignen sich nicht für Debian 10.3 »Buster«. Bei mir verlief das Upgrade ohne Vorfälle und auf den ersten Blick funktioniert alles. Dank geht an Norbert Preining, der sich nicht wenig Arbeit machte, um diese aktuelle Version zur Verfügung zu stellen.
LTS-Version mit 2 Jahren Support
Plasma 5.18.3 bringt weitere Verbesserungen am Benachrichtigungssystem. Frisch heruntergeladene Dateien lassen sich nun direkt aus dem Benachrichtigungsbereich mittels Drag & Drop in andere Verzeichnisse ziehen. Die Anbindung von GTK-Anwendungen an Plasma wurde weiter verbessert, sodass diese jetzt automatisch die Einstellungen für Schriften, Icons, Zeiger und anderes von Plasma übernehmen.
Wie jedes Jahr im März treten die Kandidaten für die Wahl zum Debian-Projektleiter mit ihren Wahlplattformen gegeneinander an. In diesem Jahr haben sich drei Entwickler zur Verfügung gestellt, den Posten für mindestens ein Jahr zu übernehmen. Der derzeitige Amtsinhaber Sam Hartman steht zu diesem Zeitpunkt nicht für eine zweite Amtszeit zur Verfügung.
Eher Präsident denn Kanzler
Das Amt des Debian-Projektleiters (DPL) gleicht eher dem des Bundespräsidenten als dem des Bundeskanzlers. Die Aufgaben umfassen unter anderem die Mediation in Teams oder zwischen Teams oder Mitgliedern des Projekts, die Vertretung des Projekts in der Öffentlichkeit bei Vorträgen und Präsentationen, die Übersicht über Finanzen und legale Angelegenheiten und ganz viel tägliches Klein-Klein.
Noch bis zum 4. April werden die Plattformen der Kandidaten, in denen sie ihre Ideen und Ziele für die angestrebte Amtszeit erläutern, auf der Mailingliste diskutiert. Vom 5. bis 18. April können alle offiziellen Debian-Entwickler ihre Stimme abgeben. Die Kandidaten in diesem Jahr sind Jonathan Carter, Sruthi Chandran and Brian Gupta.
Jonathan Carter
Jonathan Carter, der bereits letztes Jahr angetreten war, nutzt Linux seit 1999, ist seit drei Jahren offizieller Debian-Entwickler. Er ist 38 Jahre alt und betreut in seiner Heimat Süd-Afrika seit 15 Jahren einen Debian-Ableger für ein Bildungs-Institut. Die Schwerpunkte in seiner DPL-Plattform sind, Debian attraktiver für Neueinsteiger zu machen, die Zusammenarbeit untereinander zu stärken, Engpässe zu beseitigen und mehr Transparenz in die Verwaltung und Finanzierung zu schaffen.
In seiner Bewerbungs-E-Mail schrieb er: »Ich kandidiere für den Job als DPL, weil ich denke, dass Debian es wert ist, sich dafür einzusetzen und es zu einer angenehmen und produktiven Umgebung zu machen. Ich denke, dass wir in gewisser Weise in einem Überlebensmodus gelandet sind, und wir müssen uns darüber hinaus entwickeln und dem Projekt erlauben, wieder zu florieren«.
Sruthi Chandran
Sruthi Chandran ist 32, betreut seit 2016 Debian-Pakete und ist seit Mai 2019 Debian-Entwickler. Ihr Hauptaugenmerk für die Kandidatur ist ihre Besorgnis über das verzerrte Geschlechterverhältnis innerhalb freier Software-Projekte. Sie schreibt in ihrer Plattform: »Diese DPL-Kandidatur ist auch tatsächlich ein kleiner Schritt in diese Richtung. Wie oft hatten wir schon einen nicht-männlichen Kandidaten für den DPL? Mein primäres Ziel bei meiner Bewerbung ist es, die Fragen der Geschlechtervielfalt in den Mainstream zu bringen.«
Brian Gupta
Der dritte Bewerber um den DPL-Posten ist Brian Gupta, der seit 15 Jahren insgesamt und seit 7 Jahren offiziell an Debian mitarbeitet. Seine Bewerbung hat nur ein Ziel, wie aus seiner Wahlplattform hervorgeht. Er möchte eine Debian-Stiftung einrichten, die unter anderem die bisherigen externen Mechanismen zur Spendensammlung ersetzt. Die Stiftung soll zweigeteilt für die USA und für Europa gegründet werden.
Eigene Stiftung
Gupta kritisiert das bisher für die Geldangelegenheiten zuständige Projekt Software in the Public Interest (SPI), das 1997 von Debian mitbegründet wurde. Die Qualität der Dienstleistung sei über die Jahrfe sehr schwankend gewesen, so Gupta. Zudem konzentriere sich SPI nicht mehr auf Debian, sondern erbringt seine Dienste für viele Projekte.
Das drücke sich etwa dadurch aus, dass der DPL nicht mehr automatisch Ehrenmitgleid von SPI sei und dadurch auch nicht mehr zu den Sitzungen eingeladen werde. Aus diesen Gründen könne sich Debian die 5 Prozent, die SPI einbehält und die sich bereits auf rund 16.000 US-Dollar belaufen, auch sparen. Der europäische Ableger FFIS hat seinen Dienst fast komplett eingestellt und Spenden über diesen Verein werden nicht mehr empfohlen.
Nach meinem Empfinden hat Jonathan Carter die besten Chancen, die Wahl zu gewinnen, da er als einziger Kandidat eine umfassende Plattform bietet, die sich nicht auf Nischenthemen beschränkt. Näheres wissen wir am 19. April.
Im Team des Debian-Projekts wird Debian 11 »Bullseye« vorbereitet. Das geht aus einem aktuellen Eintrag auf der Mailingliste des Release Teams hervor. Darin werden die vorläufigen Daten für den Freeze zu »Bullseye« genannt. Der Freeze findet vor jeder Hauptveröffentlichung der Distribution statt und zieht sich über einige Monate hin. Dabei werden sukzessive die Freiheiten in Bezug auf das Hochladen von Paketen für das Testing-Repository bis hin zum fast kompletten Stillstand eingefroren.
Vier Phasen
Ohne diese Maßnahme wäre der Umstieg von einem Rolling-Release-Repository (Testing) auf ein stabiles Repository (Stable) unzumutbar erschwert. Der Freeze zu Debian 11 ist in vier Phasen aufgeteilt, welche die Aktionen im Testing-Repo zunehmend lahmlegen.
12.01.2021: Freeze für größere Transitions und Build-Essentials
12.02.2021 Soft Freeze
12.03.2021 Hard Freeze für wichtige Pakete
noch offen Full Freeze
Angepasste Richtlinien
Diese Daten sind nicht in Stein gemeißelt, sollen aber möglichst eingehalten werden. Die Mail klärt zudem über Änderungen der Richtlinien für den Freeze zu Debian 11 auf. So wurde zwischen Soft Freeze und Full Freeze ein weiterer Meilenstein namens Hard Freeze eingeschoben.
Eingeschränkte Migration
In dieser Phase wird die automatische Migration von wichtigen Basispaketen von Unstable nach Testing verhindert. Paketbetreuer benötigen damit früher als bisher eine Ausnahmegenehmigung für solche Pakete. Andere Pakete migrieren in dieser Phase automatisch nach 20 Tagen in das Testing-Repo, das am Tag der Veröffentlichung durch Umbenennung zu Stable wird.
Eiszeit
Während des Full Freeze benötigen alle hochzuladenden Pakete eine manuelle Freigabe. Es ist beabsichtigt, den Full Freeze erst kurz vor der Veröffentlichung von Debian 11 in Kraft zu setzen. Er wird mindestens 14 Tage vorher angekündigt. Die Richtlinien betonen zudem klarer als bisher, dass während des gesamten Freeze nur Pakete nach Unstable geladen werden sollten, die für Debian 11 gedacht sind. Alles andere kann im Experimental-Zweig bis nach dem Release geparkt werden.
Das derzeit stabile Debian 10 »Buster« wurde am 6. Juli 2019 veröffentlicht. Somit strebt Debian auch für «Bullseye« einen Turnus von rund zwei Jahren an. Ich rechne derzeit mit einer Veröffentlichung von Debian 11 im Spätsommer 2021.
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.
