Die Entwicklung von Flatpak hangelt sich entlang der von Containern, seine Zukunft hängt aber am Desktop.

Alternative Systeme zum Verteilen von Software sind im Kommen: 2018 waren Flatpak und Snap in aller Munde; dazu gesellt sich AppImage, das keinerlei grundlegende Installation benötigt – es bietet vollkommen autarke Pakete.

Bei dem federführend von Alexander Larsson bei Fedora entwickelten Flatpak [1] handelt es sich dabei um jene Methode, die sich für Desktop-Applikationen am ehesten eignet. Damit packen Sie Software so, dass dasselbe Paket mit allen Distributionen zusammenarbeitet. Als einzige Voraussetzung dafür benötigen Sie die entsprechende Laufzeitumgebung von Flatpak.

Alles begann mit Klik

Flatpak erreichte im Sommer 2018 Version 1.0 und gilt seitdem als geeignet für den produktiven Einsatz. Derzeit aktuell ist Version 1.1.3. Der Ursprung des Formats reicht bis ins Jahr 2007 zurück, als Red-Hat-Mitarbeiter Larsson mit Klik [2] experimentierte, dem Vorgänger von AppImage. Einige technische Details gefielen ihm jedoch nicht, und er veröffentlichte im gleichen Jahr Glick, das mangels der damals noch nicht existenten Container-APIs auf FUSE aufbaute [3].

Glick 2 setzte dann 2011 auf die neu eingeführten Kernel-Namespaces und weckte erneut Larssons Interesse am alternativen Paketieren. Er veröffentlichte in seinem Blog einen langen Artikel, in dem er aufzeigte, warum er die bestehenden Paketsysteme für nicht ideal hielt, und warum er das Bündeln von Software bevorzugte. Dieser frühe Artikel reißt bereits die Grundlagen von OSTree [4], Atomic Workstation [5] und Silverblue [6] an.

Um 2013 entwickelte sich die Kernel-Unterstützung für Container, und Docker kam auf den Markt. Larsson arbeitete damals daran, Red Hat Enterprise Linux (RHEL) fit für Docker zu machen. Auf einem Gnome-Hackfest im selben Jahr entstanden konkretere Ideen zu Runtime, Sandboxing und den als Portals bezeichneten Modulen für den geregelten Zugriff auf die Ressourcen des eigentlichen Systems.

An der Diskussion, die in einem Manifest mündete [7], nahmen neben Larsson unter anderem Lennart Poettering und Greg Kroah-Hartman teil. Damit war Flatpak geboren, dessen Name auf die bei Ikea verwendete Methode zurückgeht, Bausätze für Möbel flach zu verpacken.

Vorerst hieß das Projekt jedoch noch für eine Weile Xdg-apps, bevor der Name Flatpak aufkam. Schon dieser Vorläufer nutzte aber OSTree, um Anwendungen herunterzuladen, zu speichern und zu deduplizieren. Außerdem kamen Kernel-Namespaces zum Einsatz, um unprivilegierte Container auszuführen.

Container-Erbgut

Flatpak bedient sich derselben Bausteine und Mechanismen, die bei Containersystemen wie Docker oder LXC zum Einsatz kommen. Dazu zählt etwa die erwähnte Funktion der Kernel-Namespaces. Die Basis für Flatpaks bilden jedoch eine oder mehrere Laufzeitumgebungen, die Grundfunktionen für die Flatpaks über Bibliotheken und Interpreter bereitstellen. Im Unterschied zu den erwähnten Formaten für Container laufen die Sandboxen bei Flatpak unprivilegiert; sie benötigen keine Root-Rechte.

Um Flatpak-Anwendungen im Kontext von Anwendern zu betreiben, kommt Bubblewrap [8] zum Einsatz. Prinzipiell funktioniert die Software wie ein Change Root [9], verwendet aber unprivilegierte User-Namespaces [10]. Ein Prozess-Flag verhindert außerdem, dass die Software neue Privilegien erhält, die unter Umständen einen Ausbruch aus der Sandbox erlauben.

Darüber hinaus sichern die Entwickler die Sandbox mit Seccomp [11] ab. Auf diese Weise versuchen sie zu verhindern, dass potenziell riskante Systemaufrufe nach außen dringen. Dabei ist die Applikation in der Sandbox standardmäßig nur in der Lage, in einige Unterverzeichnisse des Home-Verzeichnisses zu schreiben.

Flathub

Flatpak ist mittlerweile bei vielen Distributionen vorinstalliert. Eine Ausnahme bildet Ubuntu, das mit Snap seine eigene Variante eines alternativen Paketsystems propagiert. Aus Anwendersicht sind Flatpaks gut integriert: Neben Tools für die Kommandozeile (Abbildung 1) gibt es inzwischen Verwaltungsanwendungen für die Desktop-Umgebungen. Dabei lässt sich Software auf diesem Weg im User- oder im System-Kontext installieren (Abbildung 2).

Abbildung 1: Neben einem über das Dateisystem installierten Firefox lässt sich ein Nightly Build des Browsers installieren, der ein eigenes Profil nutzt. Hier ist er im User-Kontext installiert.

Abbildung 2: Im User-Kontext installierte Apps bindet das System über den im Home-Verzeichnis versteckten Ordner .var/app/ ein.

Das gilt zumindest für Gnome (Abbildung 3) und KDE (Abbildung 4). Dort binden Applikationen für das Paketmanagement wie Gnome Software oder Plasma Discover die Flatpaks ein und zeigen vorhandene Aktualisierungen automatisch an. Hier bleibt aber noch Raum für Verbesserungen.

Abbildung 3: Fedora bietet in Gnome Software verschiedene Apps im nativen Format und als Flatpak an – hier beispielsweise Polari, wobei die Software den Flatpak als 3rd party kennzeichnet.

Abbildung 4: Neben Flatpak-Apps bietet Plasma Discover die grundlegenden Bestandteile von Flatpak zur Installation an.

Mit Flathub [12] steht ein zentrales Repository mit derzeit über 400 entsprechenden Paketen bereit. Entwickler stellen hier ihre Apps ein, Anwender installieren sie bei Bedarf mit einem Klick (Abbildung 5).

Abbildung 5: Flathub als zentrales Repository bietet mittlerweile über 400 Applikationen als entsprechendes Dateiformat an.

Da bei Flatpak das Prinzip der Repositories bereits im Quellcode verankert ist, verursacht es nur wenig Aufwand, eigene Archive in diesem Format zu erstellen und anzubieten [13].

Entwicklerkritik

Der Wunsch nach einem einheitlichen System für die Paketauslieferung unter Linux ist nicht neu: Seit Langem gibt es Kritik an den herkömmlichen Ansätzen der Distributionen, hauptsächlich aus Entwicklerkreisen. Ein Paketformat für alle Distributionen würde aktuelle Entwicklungen schneller zu den Anwendern bringen und somit die Arbeit an vielen Programmen allgemein beschleunigen.

Das Heer der Kritiker reicht bis hin zu Linus Torvalds, der auf einer Debian-Konferenz zum Thema Stellung bezog [14]. Doch so schlüssig der Gedanke eines einheitlichen Paketmanagements scheint – es gibt von mehreren Seiten Kritik an Flatpak, die generell auch die anderen Mitbewerber betrifft.

Deduplizierung

Von Anfang an galt als Mangel, dass Flatpak und ähnliche Ansätze auf den Festplatten durch das Duplizieren von Laufzeitumgebungen und Bibliotheken zu viel Platz verschwenden. Das lässt sich nicht so einfach von der Hand weisen, denn oft erfordert das Einrichten eines Pakets als Flatpak, Snap oder AppImage einen Download in der Größe von mehreren Hundert MByte, wohingegen die Version des Distributions-Maintainers vielleicht nur wenige KByte oder MByte beansprucht (Abbildung 6).

Abbildung 6: Die Installation des Spotify-Client als Flatpak lädt inklusive einer Runtime über 300 MByte herunter. Das Paket im DEB-Format hat eine Größe von rund 40 MByte.

Das ist der universellen Verwendbarkeit geschuldet: Flatpak bündelt alle nötigen zusätzlichen Programme und installiert diese mit der eigentlichen Software. Das wirkt sich insbesondere dann aus, wenn in einer Bibliothek, die in vielen Programmen zum Einsatz kommt, ein Bug auftaucht: Tauscht nicht jeder Flatpak-Maintainer diese Version aus, verbleibt eine fehlerhafte Version im System. Das Problem ergibt sich beim klassischen Ansatz nicht, da dort die Distribution die Bibliothek austauscht.

Mittlerweile hat sich die Situation etwas verbessert, denn die Bibliothek Libostree ermöglicht nun, doppelt vorhandene Teile zu deduplizieren. Hinsichtlich des Festplattenplatzes bleibt zu sagen, dass dieser heute so günstig zu haben ist wie nie zuvor. Wer einen minimalistischen Ansatz verfolgt, für den ist Flatpak ohnehin kaum das Richtige.

Paketbetreuer gefährdet

Ein weiterer Kritikpunkt: Der Entwickler einer Anwendung sollte nicht allein entscheiden, was mit seinem Paket ausgeliefert wird. Diese Aufgabe übernimmt bislang der Paketbetreuer der jeweiligen Distribution, der die Anwendung an die Bedürfnisse und Richtlinien des jeweiligen Systems anpasst. Zudem dient er als Ansprechpartner und Mittler sowohl für Entwickler wie für Anwender.

Gäbe es nur noch alternative Paketsysteme wie Flatpak, würde die Rolle der Maintainer entfallen. Kyle Keen, der als Maintainer bei Arch Linux tätig ist, hat dieses Dilemma 2016 im viel beachteten Artikel “Maintainers Matter” [15] aus seiner Sicht beschrieben. Grundsätzlich lässt sich dem nur entgegenhalten, dass Distributionen ständig klamm an Personal sind; hier würde ein Entwickler, der das Paketieren übernimmt, Ressourcen einsparen.

Plakativer Angriff

Kurzzeitig erregte letztes Jahr die Webseite Flatkill.org [16] Aufsehen, die im Stil zur Genüge bekannter Systemd-Kritik glaubhaft machen wollte, Flatpak sei ein Albtraum in Bezug auf die Sicherheit des Sandboxing-Prinzips. Mit viel roter Schrift hatten die Macher die Art kritisiert, wie Flatpak Berechtigungen handhabt. Die Schelte traf aber zum Zeitpunkt der Veröffentlichung bis auf wenige Ausnahmen nicht mehr zu.

Sie richtet sich gegen Apps auf Basis von Gtk 2. Anwendungen, die auf Gtk 3 und Qt 5 beruhen, bedienen sich der bereits erwähnten Portals [17], um aus der Sandbox heraus per D-Bus Zugriff auf das Dateisystem und andere Ressourcen wie Drucker zu erlangen (Abbildung 7).

Abbildung 7: Portals bilden die Schnittstelle zwischen der App in der Sandbox und dem System darunter. Sie sorgen für zweigleisige Kommunikation per D-Bus und regeln den Zugriff auf Ressourcen.

Nun steht Flatpak 1.2 vor der Tür und bringt voraussichtlich weitere Portals, etwa für Webcams. Zudem sind eine bessere Kontrolle über den Lebenszyklus einzelner Versionen sowie eine verbesserte Plattform für Regressionstests geplant.

Hauptversionen sollen künftig quartalsweise erscheinen, ergänzt durch Snapshots in den Zeiträumen dazwischen. Wer ein tieferes Verständnis der technischen Hintergründe von Flatpak sucht, der findet dieses etwa durch einen Vortrag von Larsson, den dieser auf der Konferenz “All Systems Go” im September 2018 in Berlin gehalten hat [18].

Die Mitte macht’s

Flatpak und andere alternative Systeme haben ihren Weg in die Linux-Infrastruktur gefunden und verschwinden so schnell nicht wieder. Jeder der Ansätze erntete sowohl Lob als auch Kritik. Manche Kritiker sehen den Untergang von Linux kommen; manche Befürworter wünschen sich, Distributionen würden überwiegend aus Flatpaks oder Snaps bestehen. Fedora realisiert das derzeit etwa im Projekt Silverblue. Wie so oft liegt das vernünftige Maß in der Mitte.

Für Anwender bieten die Flatpaks Vorteile – und je nach Sicht eben wieder zusätzlich Nachteile. Die Vorteile spielen besonders bei stabilen Distributionen und LTS-Versionen eine Rolle. Während dort aus Gründen der Stabilität Software oft in älteren Versionen vorliegt, bietet Flatpak die Möglichkeit, aktuelle Software auf eine Weise zu installieren, die sich nicht mit der durch das eigentliche Paketmanagement bereitgestellten Version beißt.

Betreiben Sie verschiedene Distributionen parallel, brauchen Sie darüber hinaus Flatpaks nur einmal herunterzuladen, um die Software überall einzusetzen. Sie sind also völlig unabhängig vom jeweiligen Update-Zyklus der Distributionen.

Fazit und Ausblick

Flatpak ist auf dem Desktop angekommen und erfreut sich unterschiedlicher Resonanz. Entwickler nutzen die neuen Möglichkeiten, alle Distributionen mit einem Paket zu erreichen. Fedora verfolgt den enthusiastischen Ansatz, die Distribution möglichst komplett auf das neue Format umzustellen, und sieht darin die Zukunft.

Umfragen im Bekanntenkreis des Autors haben ergeben, dass Flatpaks bei Befürwortern eher in Maßen zum Einsatz kommen, wobei die Zahl der Applikationen selten das Dutzend überschreitet.

Was die Zukunft angeht, so lebt Flatpak nur so lange wie der Desktop. Nimmt der Einfluss von Web-Apps immer mehr zu, liegt vielleicht irgendwann die Funktion des Desktops hauptsächlich darin, den Browser zu starten. Das wäre dann vermutlich wieder das Ende von Flatpak.