Flatpaks und Snaps – was wie neue Knusperriegel klingt, schickt sich an, die Installation von Software zu revolutionieren.

Formate zum Packen von Software sind so alt wie Software selbst. Die heute gebräuchlichsten Formate DEB aus der Debian-Welt und RPM aus dem Red-Hat-Lager teilen die Linux-Welt größtenteils unter sich auf.

Dabei verteilen sich die einzelnen Bestandteile des Pakets – Binaries, Bibliotheken, Konfiguration und Dokumentation – bei der Installation über die gesamte Verzeichnisstruktur. Wo genau, das regelt der Filesystem Hierarchy Standard FHS [1]. Dessen Struktur entstand nicht immer gewollt, sondern ist teils der Ressourcenknappheit in den frühen Jahren der Entwicklung von Unix [2] geschuldet.

Dass man Software auch anders einrichten kann, beweisen seit Langem Betriebssysteme wie Gobo Linux, NixOS oder NeXTStep. Sie verfolgen den Ansatz, eine Applikation mitsamt aller Abhängigkeiten zu packen und als Ganzes zu verwalten. Dieses Prinzips bedienen sich ebenfalls die neuen Formate, deren Vor- und Nachteile sich in der Praxis erschließen.

Ein entscheidender Nachteil der aktuellen Formatvielfalt liegt im hohen Aufwand für Entwickler und Paketbetreuer, wenn diese eine Software für verschiedene Distributionen und deren unterschiedlich aktuellen Zweige paketieren und pflegen.

Linus Torvalds erklärte in einer Fragestunde auf einer Debian-Konferenz 2014 [3], warum es eine von ihm programmierte Software für sein Hobby Tauchen zwar für Windows und Mac OS X gibt, aber nicht für Linux: Keine der großen Distributionen habe die Bestandteile jemals zufriedenstellend gepackt. Torvalds betrachtet die Paketierungsmisere denn auch als einen der wesentlichen Gründe für den ausbleibenden Erfolg von Linux auf dem Desktop.

In etwa zeitgleich zur Fragestunde mit Torvalds veröffentlichte Systemd-Mastermind Lennart Poettering seine Gedanken dazu, wie wir künftig Distributionen bauen und Software installieren sollten. Darin klingt bereits einiges an, was derzeit besonders in Flatpak oder Snappy einfließt [4].

Von XDG-App zu Flatpak

Die vom Gnome-Projekt und von Fedora initiierten XDG-Apps, mittlerweile in Flatpak umbenannt, begegnen dem Problem, das Torvalds sowie viele Entwickler und Unternehmen mit dem Paketieren von Software haben. Das neue Format fasst Anwendungen inklusive fast aller Abhängigkeiten, Bibliotheken und anderer Bestandteile zusammen (Abbildung 1).

Abbildung 1: Krita lässt sich problemlos als Snap in Ubuntu 16.04 installieren.

Um diese Art von Paketen zu installieren und zu nutzen, bedarf es lediglich einer entsprechenden Laufzeitumgebung (Abbildung 2). Auf welcher Distribution unter welchem Desktop diese läuft, spielt dann kaum eine Rolle. Ähnliches gilt für die Tatsache, dass eventuell das gleiche Paket in derselben oder einer anderen Version bereits auf dem System installiert ist.

Abbildung 2: Die Runtime für GNOME 3.20 wird benötigt.

Hier spielt der Neuling einen weiteren Vorteil aus: Alle Apps laufen gegeneinander und das System isoliert in einer Sandbox. Wer sich jetzt an Container erinnert fühlt, liegt nicht so falsch – das Prinzip ist das gleiche. Zudem kommt die Container-Software LXC zum Einsatz, sodass man Flatpaks mit einigem Recht als Desktop-Container bezeichnen kann. So erstaunt es nicht weiter, dass die Entwickler die Spezifikation kompatibel zum Standard der Open-Container-Initiative halten wollen.

Der Name für das Format stammt aus der schwedischen Heimat des Entwicklers Alexander Larsson. Er lehnt sich an die Art an, wie das Unternehmen Ikea seine Produkte in flachen Paketen verpackt. Larsson arbeitet sowohl beim Gnome-Projekt für den Desktop als auch bei Red Hat an Container-Technologien. Er setzt für das Paketformat auf Technologien aus dem Kernel, wie etwa Cgroups, Namespaces, Bind Mounts. Hinzu kommen Seccomp und OSTree [5] aus Red Hats Atomic-Projekt sowie das OCI-Format der Open Container Initiative. Der Einsatz der Linux-spezifischen Techniken bindet das Format, aber auch Snaps an diese Plattform.

Neu entwickelte Techniken wie Bubblewrap [6] finden ihren Weg von Flatpak in das Project Atomic. Bubblewrap erlaubt im Zusammenspiel mit Flatpaks dem normalen Anwender, isolierte Anwendungen zu installieren und zu verwenden, ohne dass diese Zugriff auf das System oder das Home-Verzeichnis erlangen oder Privilegien eskalieren könnten.

Nicht statisch gelinkt

Einen entscheidenden Unterschied gibt es jedoch zu Containern aus der Server-Welt: Systeme wie Docker linken statisch und binden in jedem Container die Laufzeitumgebung mit ein. Flatpaks hingegen bringen eine Abhängigkeit zur Laufzeitumgebung mit, die wiederum den Zugriff auf die grundlegenden Bibliotheken des Systems gewährt.

Der Vorteil liegt darin, dass ein Flatpak theoretisch unbegrenzt lange lauffähig bleibt, selbst wenn sich das Basissystem oder die Anforderungen an die Hardware ändern. Eine Applikation darf allerdings jeweils nur von einer Laufzeitumgebung abhängen. Um hier etwas mehr Flexibilität zu erlauben, arbeitet einer der Entwickler daran, die Laufzeitumgebung in Module aufzuteilen.

Ein genereller Vorteil von diesem und ähnlichen Formaten für Software liegt im verkürzten Weg vom Entwickler zum Anwender: Der Benutzer muss nicht seine gesamte Distribution aktualisieren, um die passenden Abhängigkeiten für eine aktuelle Software zu erhalten. So kann er etwa bei einer Ubuntu-LTS-Version bleiben, aber trotzdem die neueste Software ausprobieren.

Ein Nachteil, der aber in der heutigen Zeit dank niedriger Preise für Festplatten nicht mehr so ins Gewicht fällt, liegt im Bedarf an Plattenplatz, da jedes Flatpak oder Snap einen Teil seiner Bibliotheken und weitere Abhängigkeiten mitbringt. Beim Einsatz von vielen Paketen in diesen Formaten bläht sich das System entsprechend auf.

Flatpak steckt noch mitten in der Entwicklung und ist daher noch kaum bekannt, geschweige denn verbreitet. In Fedora 24 können aber der Paketmanager Gnome Software sowie die IDE Gnome Builder bereits mit dem neuen Format umgehen.

Schnapp’s dir

Die Wurzeln von Canonicals Flatpak-Gegenentwurf Snappy liegen im Format Klik für das Ubuntu Phone. Das erste Mal setzten die Entwickler dieses Prinzip Ende 2014 mit Snappy Ubuntu Core für das Internet der Dinge und für eingebettete Systeme um. Daraus entstand in der Folge die Idee eines “Snappy Personal”, um das Konzept für den Desktop umzusetzen.

Mit der Veröffentlichung von Ubuntu 16.04 “Xenial Xerus” gelangte der Entwurf vor Kurzem erstmals offiziell auf den Desktop. Die Pakete heißen einfach Snaps und eignen sich für die parallele Installation zum DEB-Format. Sie enthalten ebenfalls die gesamte Software als Bündel, das auf gleiche Weise gegen den Rest des Systems isoliert ist wie bei Flatpaks. Snaps bieten die Möglichkeit zu atomaren Aktualisierungen – Canonical nennt es “transactional updates” – mittels Delta-Dateien [7].

Canonical-Gründer Mark Shuttleworth wies schon im Vorfeld von Ubuntu 16.04 mehrfach auf den Sicherheitsgewinn durch das Sandbox-System hin. Kurz nach der Veröffentlichung sprach jedoch der bekannte Entwickler Matthew Garrett dem System eben dieses Mehr an Sicherheit in seinem Blog wieder ab, solange Ubuntu noch auf X11 setzt und Mir weiter auf sich warten lässt [8]. Hier handelt es sich allerdings eher um ein Problem von X11 als eines von Snappy. Tatsache bleibt jedoch, dass sich das Mehr an Sicherheit hier frühestens in einem Jahr einstellt, wenn Ubuntu auf den eigenen Display-Server umschwenkt.

Auf Ubuntu fixiert

Die noch recht neuen Snaps für den Desktop befinden sich noch mitten in der Entwicklung. Ein klarer Nachteil liegt darin, dass sich das System auf Ubuntu als Plattform beschränkt. Das macht es anders als bei den Flatpaks schwer, es auf andere Distributionen zu portieren.

Ein weiterer, prinzipbedingter Nachteil zeigt sich beim Aktualisieren: Taucht ein Fehler in einer Bibliothek auf, so ersetzen Sie auf einem herkömmlichen System diese durch eine neuere Version. Bei Snaps gilt es, diese Bibliothek in allen Paketen zu ersetzen, in denen sie steckt.

Der Vorteil von Snaps liegt dagegen in der Tatsache, dass es relativ leicht fällt, die Pakete aus einem DEB-Paket [9] oder aus den Quellen zu bauen [10]. Dabei dient ebenfalls eine Laufzeitumgebung als Grundlage, in diesem Fall Snapcraft [11].

Snaps spielen eine große Rolle bei Canonicals primärem Entwicklungsziel der letzten Jahre, der Konvergenz. In diesem Szenario baut Software auf allen Plattformen auf dem gleichen Code auf, vom kleinsten Gadget im IoT bis zum IBM-Mainframe. Ein Smartphone, ergänzt um Display, Tastatur und Maus, verwandelt sich so in ein Desktop-System. Erste Ansätze dazu befinden sich derzeit mit dem Ubuntu-Tablet Bq M10 und dem Smartphone Meizu Pro 5 in der freien Wildbahn. Snaps spielen außerhalb von Ubuntu und seinen Derivaten jedoch kaum eine Rolle.

In Ubuntu 16.04 rufen Sie mit snap find eine Liste der verfügbaren Snaps auf (Abbildung 3). Mit sudo snap install Paket installieren Sie dann die Software. Hier fällt auf, dass Sie anders als bei Flatpak dazu Root-Rechte benötigen.

Abbildung 3: Ubuntu 16.04 ermöglicht es, eine ganze Reihe von Programmen als Snaps zu installieren.

In medias Flatpak

Im Test kam ein tagesaktuelles Fedora 24 Beta als Basis für den Flatpak-Test zum Einsatz (die finale Version finden Sie auf dem Datenträger der Media-Edition). Zusätzlich gehörte ein Siduction mit Plasma 5.6.4 zum Testfeld. Im Prinzip eignet sich aber jede Distribution, die Flatpak unterstützt. Die für den Test gewählte Anwendung LibreOffice 5.2 Beta als Flatpak setzt lediglich die Laufzeitumgebung von Gnome 3.20 voraus (Abbildung 4).

Abbildung 4: Runtime und LibreOffice als Flatpak installiert.

Damit die Distributionen mit Flatpak arbeiten, installieren Sie zunächst die entsprechende Software [12]. Sie liegt ab Fedora 23 sowie Mageia 5 bereits in den entsprechenden Archiven bereit. Ubuntu nutzt ein PPA, während Sie bei Debian das Paket per APT beziehen, nachdem Sie die Liste der Quellen um einen passenden Eintrag ergänzt haben. Aus dem Experimental-Repository von Debian beziehen Sie Flatpak derzeit direkt (Abbildung 5). Bei Erscheinen dieses Artikels sollte es bereits in Debian “Unstable” liegen. Unter Debian 8 “Jessie” installieren Sie es mit den Befehlen aus Listing 1.

Abbildung 5: Flatpak ist auch in Debian schnell installiert.

$ wget -O - https://sdk.gnome.org/apt/debian/conf/alexl.gpg.key | apt-key add -
$ echo "deb [arch=amd64] https://sdk.gnome.org/apt/debian/ jessie main" > /etc/apt/sources.list.d/flatpak.list
$ sudo apt update && apt install flatpak

Für den Test kam vorrangig Fedora zum Einsatz, da es Flatpaks bislang am besten integriert. Zuerst brachten wir die Distribution mit sudo dnf upgrade auf den neuesten Stand. Nachdem die eigentliche Software dann mittels sudo dnf install flatpakinstalliert war, fügten wir das Repository der Flatpak-Laufzeitumgebung hinzu (Listing 2).

$ wget https://sdk.gnome.org/keys/gnome-sdk.gpg
$ flatpak remote-add --user --gpg-import=gnome-sdk.gpg gnome https://sdk.gnome.org/repo/
$ flatpak install --user gnome org.gnome.Platform 3.20
$ flatpak install --user gnome org.gnome.Platform.Locale 3.20
$ flatpak install --user --bundle LibreOffice.flatpak
$ flatpak run org.libreoffice.LibreOffice

Die Laufzeitumgebung samt Lokalisation schlägt mit rund 200 MByte zu Buche. Nach deren Installation laden Sie das LibreOffice-Paket (156 MByte belegt) herunter [13] und richten die Software als normaler User aus dem Download-Ordner ein (Listing 2, Zeile 5). Dabei spielt es keine Rolle, ob und in welcher Version LibreOffice auf dem System bereits installiert ist: Die Anwendungen kommen sich nicht ins Gehege.

Nach rund 20 Sekunden starten Sie die Bürosuite über das Kommando aus der letzten Zeile von Listing 2 oder via Gnome Shell. Im Home-Verzeichnis finden sich unter ./local/share/flatpak/ die installierten Laufzeitumgebungen und Anwendungen (Abbildung 6). Eine Befehlsübersicht über Flatpak bieten die Manpage sowie der Befehl flatpak -h.

Abbildung 6: Auch bei Debian liegen alle Daten im Home des Anwenders.

Auch das Software-Center Gnome Software integriert das LibreOffice-Flatpak bereits. Haben Sie zusätzlich LibreOffice auf herkömmlichem Weg installiert, so erscheinen hier allerdings beide Versionen, ohne dass man sie anhand der Icons optisch unterscheiden könnte.

Aus dem frühen Entwicklungsstand resultieren zudem einige Einschränkungen: Da Flatpak-Anwendungen in Sandboxen gegeneinander isoliert laufen, funktionieren im LibreOffice-Paket derzeit noch keine Hyperlinks aus Dokumenten heraus. Auch die Online-Hilfe per [F1] lädt nicht. Zudem fehlt zum jetzigen Zeitpunkt ein Flatpak des Java Runtime Environments (JRE), sodass darauf aufbauende Funktionen nicht laufen.

Fazit

Flatpaks und Snaps bilden eine vielversprechende Alternative zu herkömmlichen Paketformaten. Zu deren Vorteilen zählen die (teilweise) Unabhängigkeit von Distributionen, die Installation ohne Root-Rechte sowie die Isolierung gegen andere Pakete und gegen das Host-System. Mögliche Nachteile liegen im höheren Platzbedarf und – aufgrund des frühen Entwicklungsstands – in der Möglichkeit bisher nicht bekannter Probleme in Bezug auf die Sicherheit.

Flatpaks bieten einen universelleren Ansatz; ein Test unter Debian mit der Software aus dem “Experimental”-Repository [14] funktionierte ebenso gut wie bei Fedora 24. Snaps dagegen gehören eher in das “konvergente” Ubuntu-Universum aus IoT-Gadgets, Ubuntu-Phones, Desktop, Server und Cloud. Es bestehen Zweifel, dass Snaps sich über Ubuntu hinaus verbreiten.

Die neuen Formate heilen einige der Wehwehchen, die Entwickler, Betreuer von Paketen sowie Anwender mit den herkömmlichen Pakten haben. Ob sich die neuen Ansätze aber in der Praxis durchsetzen, muss sich erst noch zeigen. Auf absehbare Zeit existieren sie vermutlich alternativ neben DEB und RPM. Interesse vonseiten der Entwickler besteht aber durchaus, wie der getestete LibreOffice-Flatpak demonstriert.

Derzeit treten beide Formate lediglich den Beweis an, dass sie funktionieren. Ein wirklicher Gewinn an Sicherheit aufgrund der Isolation stellt sich jedoch erst mit dem Einsatz von Wayland und Mir ein. Dann steht einer weiteren Verbreitung von Snaps und Flatpaks nichts mehr im Weg.