Paketmanager arbeiten zu langsam – diese These versucht die experimentelle Distribution Distri zu belegen.

Paketmanager unterscheiden sich nicht nur im jeweils verwendeten Paketformat voneinander, sondern auch in der Ausführungsgeschwindigkeit. Der Entwickler Michael Stapelberg beschäftigt sich seit einiger Zeit damit, wie sich Paketmanager wie etwa Apt bei Debian oder Dnf bei Fedora entschlacken und somit schneller machen lassen. Er verfasste dazu Blog-Einträge, hielt Vorträge und rief eine experimentelle Distribution namens Distri zum Erforschen des Problems ins Leben.

Dabei handelt es sich um eine minimale, über die Kommandozeile gesteuerte Distribution zum Überprüfen von Konzepten für das Paketmanagement in Linux. Es geht um eine reine Machbarkeitsstudie, die sich nicht für den produktiven Einsatz eignet. Distri will die einfachste Distribution sein, die sich noch sinnvoll nutzen lässt.

Kritik an Debian

Anhand dieser Information widmen wir uns nun den Fragen, die sich Stapelberg stellt. Der bei Google angestellte Entwickler war von 2012 bis 2019 bei Debian als Paket-Maintainer tätig. Er betreute unter anderem den Fenstermanager i3 und die Codesuchmaschine Debian Code Search.

Im März 2019 verkündete er frustriert seinen weitgehenden Rückzug aus der Debian-Entwicklung und verband das mit einer geharnischten Kritik am Debian-Projekt [1]. Er bezog sich dabei auf die Praktiken und Werkzeuge, die zur Entwicklung, Verwaltung und Betreuung der Software in der Distribution zum Einsatz kommen: Die seien oft mehr hinderlich als fördernd.

Es fehlen nach seiner Ansicht effiziente Werkzeuge, um umfassende Änderungen zeitnah umzusetzen. Auch die in den Debian-Richtlinien festgelegten und vom Qualitätssicherungswerkzeug Lintian [2] forcierten Vorgaben behindern laut Stapelberg das Umsetzen notwendiger technischer Änderungen über Gebühr.

Zu viel, zu langsam

Vehement kritisiert Stapelberg insbesondere das Paketmanagement – nicht nur unter Debian, sondern generell bei Linux. Vor allem missfällt ihm, dass die Paketmanager zu viel machen und das zu langsam. Er führte dazu zunächst Versuchsreihen mit kleinen und größeren Paketen bei den Paketmanagern Apt, Dnf, Pacman, Nix und Apk durch. Dabei stellte er sowohl die heruntergeladenen Metadaten gegenüber als auch die benötigte Zeit und die genutzte Bandbreite [3].

Dabei stellte er fest, dass die heruntergeladenen Metadaten oft in keinem Verhältnis zur Größe des Pakets stehen, und das umso mehr, je kleiner das Paket ausfällt. Das überprüft beispielsweise jeder Debian-Nutzer leicht, indem er am Ende eines apt update im Terminal nachsieht, wie viele MByte an Metadaten der Vorgang herunterlädt. Diese Menge überschreitet oft die Gesamtgröße der eigentlich zu aktualisierenden Pakete (Abbildung 1).

Abbildung 1: Bei der Installation und dem Update von Paketen lädt der Paketmanager immer auch Metadaten herunter – bei Fedora und Debian besonders viele, was die Paketinstallation verzögert.

Auch die Maintainer-Skripte, die der Paketmanager während der Installation abarbeitet, verlangsamen den Prozess. Sie verhindern zudem das parallele Installieren von Paketen. Nach Stapelbergs Ansicht können diese Skripte genauso gut beim ersten Start der Anwendung laufen. Maintainer-Skripte arbeitet Debian über Dateien wie preinst und postinst bei der Installation oder Aktualisierung von Paketen ab; sie enthalten distributionsspezifische Anpassungen [4].

Debian verfügt über 8620 solcher Skripte. Einige Flussdiagramme auf der Webseite der Debian-Richtlinien zeigen die hier zugrundeliegende Komplexität exemplarisch auf [5]. Bei Fedora erfüllen Scriptlets diese Aufgabe [6].

Nicht effizient

Stapelberg lernte bei seiner Tätigkeit bei Google viel über effektives Arbeiten im Zusammenhang mit dem Update großer Datenmengen. Updates bei Distributionen erwiesen sich bei seinen Nachforschungen als eher ineffektiv. Er machte einen Test, bei dem er mit gängigen Systemen je ein kleines und ein großes Paket installierte und dabei die Zeiten festhielt.

Obwohl der Netzanschluss des Testrechners rund 115 MByte/s zuließ, erreichte keine der Distributionen mehr als knapp 11 MByte/s Durchsatz, die meisten verharrten bei etwa 3 MByte/s. Am besten schnitt noch Alpine Linux ab, das mit 10,8 MByte/s bei beiden Tests am schnellsten war und zudem noch die wenigsten Metadaten zur Erfüllung der Aufgabe benötigte. Im Mittelfeld lagen Arch Linux und NixOS, am schlechtesten schnitten Debian und Fedora ab.

So musste Fedora für das 75 KByte kleine Paket ack satte 114 MByte herunterladen und brauchte für die Installation 33 Sekunden. Alpine begnügte sich dagegen mit 10 MByte, die in einer Sekunde installiert waren. Bei der Installation der Virtualisierungs-Software Qemu kam Alpine mit 26 MByte aus, während Fedora mit 226 MByte fast die zehnfache Datenmenge benötigte.

Angesichts solcher Zahlen verwundert es wenig, dass Fedora bei Updates und Installationen eher behäbig zu Werk geht. Bei beiden Szenarien stand Debian als zweiter Verlierer da, weil auch hier das Herunterladen der vielen Metadaten den Prozess verzögerte. Neben Alpine bringt auch Arch Linux einen der schnelleren Paketmanager im Test mit.

Hooks und Trigger

Fedora arbeitet auch deswegen so langsam, weil allein seine Paketliste im entpackten Zustand 60 MByte umfasst, die von Alpine dagegen schlanke 734 KByte. Fedora bietet zwar mit über 20 000 Paketen drei Mal mehr Pakete an als das mit 5 MByte sehr kleine Alpine, trotzdem fällt der Unterschied frappierend aus.

Aber selbst die besten Ergebnisse des Tests hält Stapelberg für zu langsam. Einen weiteren Grund dafür sieht er in den häufig eingesetzten Hooks und Triggern, die der Paketmanager während der Installation ausführt. Sie stoßen beispielsweise die erwähnten Maintainer-Skripte an, erstellen Daemon-User-Accounts (etwa einen FTP- oder WWW-Account) oder legen Cache-Dateien an.

Zu den am häufigsten benutzten Triggern gehört der des Pakets man, der dafür sorgt, dass bei jeder Paketinstallation eine Manpage dafür mit aufs System kommt. In seinem Blog erläutert Stapelberg, warum all das nicht während der Installation passieren sollte, und wie es die Parallelinstallation von Paketen verhindert [7].

Diese Unterbrechungen der eigentlichen Installation sollten nach Stapelbergs Meinung besser beim ersten Start der App stattfinden. Startet eine Anwendung zwischen Installation und dem ersten oder gar weiteren Updates nicht, würden die Anpassungen etwa nur ein Mal statt mehrmals ausgeführt.

Image statt Archiv

Nach Stapelbergs Vorstellung soll ein Paketmanager nur das absolut Nötige tun, um ein Paket so im System zu verankern, damit es einsatzbereit ist – also das Programm startet oder ein Kernel-Modul lädt. Das Auspacken während der Installation fällt weg, wenn Pakete als Dateisystem-Images vorliegen, die die Distribution beim Start einhängt, wie das etwa bei AppImage oder Snap der Fall ist.

Dieses Szenario nutzt laut Stapelberg derzeit noch kein Paketmanager einer Linux-Distribution, obwohl sich damit die Geschwindigkeit noch über das Niveau von Alpines Apk erhöhen ließe, dem bei seinen Testreihen schnellsten Paketmanager. Images verwendet derzeit lediglich das Betriebssystemprojekt Haiku.

Mit der experimentellen Distribution Distri, die Stapelberg zusammenstellte, will er experimentell die Komplexität des Paketmanagements verringern. Er kommt dabei zu dem Ergebnis, dass auch Distributionen wie Fedora oder Debian mit weniger Komplexität schneller agieren könnten. Das bedeutet zwar nicht, dass es sich technisch einfach umsetzen lässt, aber machbar wäre es.

Distri verwendet als Paketformat beispielsweise schreibgeschützte SquashFS-Images anstelle der üblichen TAR-Archive (Abbildung 2). Das hat neben einer höheren Geschwindigkeit den Vorteil, dass sich Anwendungen nicht verändern lassen, was sie vor versehentlichen oder böswilligen Modifikationen schützt.

Abbildung 2: Dieser Ausschnitt des Distri-Repositories zeigt SquashFS als Format der Pakete. Diese stehen sowohl als Images bereit als auch gepackt.

Alle von einem Paket bereitgestellten Dateien organisiert Distri unter dem Einhängepunkt /ro/ in einem jeweils eigenen Verzeichnis. Der übliche Austausch von Daten zwischen Software-Paketen, der bei konventionellen Distributionen über die festgelegten Verzeichnisse des Filesystem Hierarchy Standard (FHS) stattfindet, regelt das System über sogenannte Exchange-Verzeichnisse, die es über FUSE bereitstellt.

Das Exchange-Verzeichnis /ro/share/ stellt beispielsweise die Vereinigung des share/-Unterverzeichnisses aller Pakete im Paketspeicher bereit. Die globalen Exchange-Verzeichnisse bilden den FHS ausreichend genau ab, sodass auch Software aus dritter Hand funktioniert, wie etwa Google Chrome oder Spotify. Das Verwenden von /ro/ verhindert zudem Konflikte bei der Installation mehrerer Versionen eines Pakets.

Auch den Paketbau entschlackt Distri. Anders als bei den Buildern herkömmlicher Distributionen installiert der Distri-Package-Builder keine Pakete in die Build-Umgebung. Stattdessen stellt das System eine gefilterte Ansicht des Paketspeichers unter /ro/ in der Build-Umgebung bereit. Das bedeutet, dass selbst bei großen Abhängigkeitsbäumen das Einrichten einer Build-Umgebung im Bruchteil einer Sekunde geschieht.

Die Webseite von Distri informiert über die verschiedenen Möglichkeiten, die Distribution zu verwenden [8]. Einen Installer gibt es noch nicht, der Maintainer plant ihn aber. Distri lässt sich von einem USB-Stick oder in einem Docker- oder LXD-Container starten, ebenso in einer virtuellen Maschine mit Virtualbox oder Qemu. Da es im Format IMG vorliegt [9] und nicht als ISO, müssen Sie es für Virtualbox zunächst in ein VDI-Image umwandeln (Abbildung 3).

Abbildung 3: Wenn Virtualbox zum Einsatz kommen soll, müssen Sie das heruntergeladene Image zunächst in ein Virtual Disk Image (VDI) umwandeln.

Zunächst gilt es, das Abbild zu entpacken. Da es die Entwickler mit dem relativ neuen Kompressionsalgorithmus Zstandard (Zstd) verpacken, müssen Sie vermutlich vorab zstd installieren. Unter Debian gelingt das mit apt install zstd, bei Fedora führt dnf install zstd zum Ziel. Anschließend extrahieren Sie die Datei mit dem Aufruf aus Listing 1.

$ unzstd ~/Downloads/distri-disk.img.zst

Dabei verliert sie den Anhang .zst und wächst auf 8 GByte an. Der Versuch, Distri auf einem USB-Stick mit 8 GByte zu starten, schlug erwartungsgemäß fehl, Sie benötigen entsprechend ein Exemplar mit mindestens 16 GByte Kapazität. Nach dem Start von Distri öffnet sich ein Login-Prompt, an dem Sie für root das Passwort peace eingeben (Abbildung 4).

Abbildung 4: Beim Login mountet Distri die grundsätzlich benötigten Anwendungen. Zur Laufzeit hängt es, je nach Nutzung, weitere Apps ein.

Es begrüßt Sie ein sehr einfacher Z-Shell-Prompt, der es erlaubt, das System zu erkunden. Zunächst dachten wir, der Befehl cd würde nicht funktionieren, da der Prompt nach dem Wechsel den neuen Standort nicht anzeigt – hier hilft nur ein pwd weiter. Ein cd /ro/ führt ins Verzeichnis mit allen installierten Paketen, ein weiterer Wechsel nach /ro/share/ in das Exchange-Verzeichnis (Abbildung 5).

Abbildung 5: Ein Blick ins Wurzelverzeichnis zeigt Vertrautes und Neues. Neben den üblichen Verdächtigen wie /etc oder /usr finden sich auch Distri-spezifische Verzeichnisse wie /ro und /roimg.

Einige äquivalente Befehle im Vergleich mit Debian listet die Dokumentation auf [10]. Dort erfahren Sie zudem mehr über das Paketformat von Distri und lernen, wie Sie Pakete dafür selbst erstellen. Der Befehl distri update (Abbildung 6) ersetzt apt update && apt full-upgrade und aktualisiert die gesamte Distribution in einem beeindruckenden Tempo. Mit einer 1-Gbit/s-Verbindung lädt das System dabei rund 275 MByte Daten in weniger als 4 Sekunden herunter und installiert sie.

Abbildung 6: Der Befehl distri update aktualisiert das System. In unserem Beispiel dauerte das knapp 3,3 Sekunden.

Auch Paketinstallationen sind in einem Augenzwinkern erledigt (Abbildung 7). Im Fall des Editors Nano (distri install nano-amd64-4.9.5-2) dauerte es knapp über eine Millisekunde. Die Version müssen Sie bei Paketen mit angeben, weil mehrere Versionen parallel installiert sein dürfen. Verfügbare Pakete finden Sie im Repository [11].

Abbildung 7: Die Installation einzelner Pakete geht rasend schnell. Das Paket Cmake mit rund 75 MByte war mit einer schnellen Internet-Verbindung in etwa 1,5 Sekunden installiert.

Fazit

Distri stellt ein Experiment in Sachen Paketmanagement dar, weswegen es nur einen begrenzten Anwenderkreis interessieren dürfte. Falls Sie tiefer einsteigen möchten, empfiehlt es sich, alle Blog-Einträge von Stapelberg zum Thema zu lesen [12] und den Vortrag auf der Arch-Entwicklerkonferenz 2020 anzuschauen [13]. Offiziell gibt es keinen Support für Distri, doch auf der Mailing-Liste [14] und im IRC auf dem Server legacy.irc-robustirc im Raum #distri beantwortet Stapelberg Fragen. Hierbei müssen Sie allerdings etwas Geduld aufbringen. (tle)