Zur Installation von Software stehen unter Linux seit jeher verschiedene Möglichkeiten zur Verfügung. So gibt es beispielsiwese immer die Möglichkeit der manuellen Übersetzung mithilfe des altbekannten Dreisatzes (configure, make, make install) - inklusive allen Vor- und Nachteilen. Am komfortabelsten ist es jedoch, den jeweiligen Paket-Manager der Distribution zu verweden. So sparen sich User das lästige Übersetzen von Quellcode - doch auch hier gibt es zahlreiche Vertreter. Neben den üblichen Red Hat- (yum, dnf) und Debian-artigen (apt, apt-get) Paket-Managern gibt es noch zahlreiche weitere Tools - und genau hier liegt das Problem.

Mit AppImage, Flatpak und Snap gibt es drei weitere Entwicklungen, die es sich zur Aufgabe gemacht haben, Software-Verwaltung unter Linux zu revolutionieren - doch wie gut gelingt das?

Prinzipiell hat Diversität Linux in weitem Maße bereichert - jedoch nicht in jedem Bereich. Ein Bereich, in welchem zu viel Auswahl schnell zum Nachteil wird, ist Software-Verwaltung. Anfänger:innen sehen sich mit einer Auswahl verschiedener Paket-Manager konfrontiert, was den Einstieg erschwert - weitaus kritischer dürfte jedoch der Mehraufwand für Entwickler:innen sein.

Linux-Distributoren, wie Red Hat oder Ubuntu, dienen als eine Art Zwischenhändler. Software-Projekte, wie beispielsweise Firefox oder GIMP, stellen ihren Quellcode bereit, welcher von den Distributoren übersetzt, getestet und schlussendlich paketiert ausgeliefert wird. Dieser Mehraufwand geht meist zulasten der Aktualität - das bedeutet, dass Anwender:innen bei den meisten Linux-Distributionen nicht die neueste Versionen ihrer Lieblingsprogramme vorfinden. Besonders auffällig ist dieser Effekt beim Einsatz einer sehr restriktiven Distribution, wie Debian oder Red Hat Enterprise Linux. Einige Projekte arbeiten eng mit den Distributoren zusammen, um die Paket-Bereitstellung zu verbessern. Nichtsdestotrotz bedarf es oft einiger Patches, um Pakete in eine schon länger verfügbare Distribution zu integrieren.

Dieser Zustand ist für Anwender- und Entwickler:innen gleichermaßen unzufriedenstellend. Einerseits möchte man möglichst aktuelle Software entwickeln und benutzen, aber stabil darf sie trotzdem sein - beides gegensätzliche Paradigmen, die sich mit dem Status Quo nicht unbedingt abbilden lassen.

Die drei erwähnten Frameworks beabsichtigen die Situation zu verbessern, indem Anwendungen unabhängig vom Betriebssystem aktualisiert und gepflegt werden. Die Distribution als Zwischenhändler entfällt - Entwickler:innen haben erstmalig die vollständige Hoheit über die Pflege ihrer Applikation. Das klingt verlockend, bringt aber auch seine Tücken mit sich, die nachfolgend beschrieben werden. In gewisser Hinsicht weisen jedoch alle drei erwähnten Frameworks ähnliche Merkmale auf:

• einfache Verwendung
• Installation bzw. Benutzung ohne Root-Rechte möglich
• unter mehreren Linux-Distributionen verwendbar

Werfen wir einen Blick auf den tabellarischen Vergleich:

Die erste Entwicklung leitete AppImage 2004 ein. Hier werden Applikationen inklusive aller Abhängigkeiten als Image via FUSE eingehängt. AppImages sind simpel gestrickt und benötigen keine Runtime oder Hintergrunddienste und müssen auch nicht installiert werden - dadurch eignen sie sich auch hervorragend für portable Anwendungen auf USB-Sticks. Fertige Abbilder finden sich auf den jeweiligen Projekt-Webseiten oder auf AppImageHub - eine Art AppImage App-Store. Updates erfolgen in der Regel in Form von neuen Images, jedoch sind auch Binärdelta-Updates möglich. Einziger Wermutstropfen - eine Rechtverwaltung sucht man derzeit vergebens. Somit verfügen ausgeführte Anwendungen prinzipiell über alle Berechtigungen des ausführenden Users - SELinux kann hier möglicherweise Schlimmeres verhindern. Andere Frameworks setzen hier Konzepte um, die bereits aus von Smartphone-Apps bekannt sein dürfen - so können Anwendungen der Zugriff auf das Netzwerk, Dateien oder spezifische Hardware verwehrt werden.

Nur drei Jahre später folgte mit Flatpak ein weiterer, etwas komplexerer, Ansatz. Hier werden ebenfalls Programme inklusive Abhängigkeiten bereitgestellt - jedoch reduzieren sich hier Dateigrößen, da die benötigte Runtime auch gleich Basis-Bibliotheken mitliefert. Anwendungen können - falls notwendig - neuere Bibliotheken mitliefern. Anwendungen werden in einer Sandbox-Umgebung ausgeführt, was die Sicherheit erhöht. Auch gibt es eine Rechteverwaltung (hier hat sich der XDG Desktop Portals-Standard etabliert), die installierte Flatpaks in ihren Befugnissen beschneidet. Allerdings muss dieser Schritt im Anschluss erfolgen - beispielsweise über das Programm Flatseal, elementary OS liefert sogar ein eigenes Tool mit. Es wäre schön, die benötigten Berechtigungen schon im Vorfeld sehen und anpassen zu können - analog zu den üblichen App-Stores mobiler Endgeräte. Anstelle von SquashFS-Abbildern verwendet Flatpak OSTree - das ermöglicht Deduplizierung und eine mit Git vergleichbare Versionierung. Alternativ können auch OCI-Images als Installationsmedium fungieren. Mit Flathub steht ein eigener Store zur Verfügung, jedoch können auch eigene Stores definiert werden, damit ist Flatpak per Definition dezentral.

Mit Snappy, oder kurz Snap, bietet Canonical eine weitere Lösung, die jedoch nicht nur Desktop-Applikationen sondern auch Server-Dienste im Sinn hat. Auch hier ist eine Runtime nötig - diesmal in Form eines Hintergrunddienstes. Dieser verwaltet Anwendungen, die als SquashFS-Image eingehängt und in Sandboxen ausgeführt werden. Auch hier gibt es eine Rechteverwaltung sowie eine Integration in das ebenfalls von Ubuntu unterstützte AppArmor. Ein weiterer Mehrwert sind transaktionale Updates inklusive Rollbacks, die die Aktualisierung von Snaps deutlich verschlanken und vereinfachen. Vor- und gleichzeitig auch Nachteil ist die Komprimierung eingehängter Images. Da die Dekomprimierung zur Laufzeit erfolgt verlangsamt es den Start der Applikationen spürbar. Problematisch ist, dass Canonical für gewohnt hier wieder einen eigenen Weg geht und die Quellen seines Snapcraft-Stores nicht offenlegt. Hier werden Inhalte angeboten und automatisiert nach Malware untersucht - neben quelloffener Software findet sich hier auch proprietäre Software, wie Spotify oder Steam. Hersteller können ihre Inhalte mit öffentlichen und verifizierten Accounts von der Masse abheben.

SELinux-Support sucht man bei Snap derzeit vergebens - eine Umsetzung ist geplant, dürfte aber aufgrund tieferer Abhängigkeiten noch länger auf sich warten lassen. Ein weiterer Kritikpunkt ist, dass Snap immer automatisch nach Updates sucht und diese auch in Eigenregie installiert. Auch wenn diese Entscheidung vermutlich im Sinne der Anwendungssicherheit getroffen wurde stellt der Update-Zwang unfreiwillig Parallelen zu anderen Betriebssystemen her - nicht zuletzt, weil Snapcraft Anwendungen in verschiedenen Kanälen anbietet. So können Anwender:innen beispielsweise eine spezifische Hauptversion abonnieren und vermeiden die automatische Aktualisierung auf neuere Hauptversionen. Zur Paketierung von Anwendungen legt Snapcraft die Verwendung von Multipass nahe - einem weiteren exklusiven Tool zur einfacheren Bereistellung von Ubuntu-VMs.

Geschwindigkeit

Der folgende Test soll verdeutlichen, inwiefern sich native Programmpakete von den drei Alternativ-Formaten in puncto Geschwindigkeit unterscheiden. Als Beispielanwendung wurde Firefox 94.x in einer Ubuntu 21.10-VM mit 2 CPUs und 2 GB RAM gestartet und mittels BrowserBench.org getestet. Auf Host-Seite kamen VirtualBox 6.1 und eine Intel i7-8850H CPU zum Einsatz.

Alle Tests wurden 3x ausgeführt um einen Mittelwert zu berechnen. Ich bin mir nicht sicher, wie repräsentativ und aussagekräftig die Browser-Benchmarks sind, aber die Startzeiten und RAM-Auslastungen verdeutlichen, dass native Pakete immer noch die beste Performance und geringste Resourcen-Belegung bieten. Insbesondere bei häufig genutzter Software, wie einem Web-Browser, sind Verzögerungen ärgerlich.

Fazit

Zugegebenermaßen sind native Pakete der Distribution nach wie vor meine erste Wahl. Hier hat man meiner Meinung nach die beste Software-Qualität und beste Integration ins Betriebssystem. Bei allen Ansätzen hatte ich häufig mit abweichenden UI-Themes und HiDPI-Problemen zu kämpfen.

Ich verstehe allerdings die Problematik rund um die gegensätzliche Aktualität und Stabilität. Bei einigen Anwendungen möchte man eben neuere Versionen einsetzen als der Distributor ermöglicht - aber bitte nicht den Web-Browser, der ohnehin inzwischen als Client für sämtliche Belange herhalten und daher besonders häufig genutzt werden muss. Unter den vorgestellten Tools erachte ich Flatpak und AppImage als die brauchbarsten Lösungen. Flatpaks integrieren sich in den meisten Linux-Distributionen inzwischen nahtlos in die Paketverwaltung und ermöglichen ein einfaches Verwenden und Aktualisieren der jeweiligen Programmpakete. AppImages setze ich für einige wenige Anwendungen ein und weiß die Schlankheit sehr zu schätzen. Es werden keine Runtimes benötigt, ein einfaches Ausführen des Images genügt - architekturbedingt lässt hier jedoch die Sicherheit zu wünschen übrig. Wenn man jedoch die Anwendungen kennt und überprüft und SELinux einsetzt, halte ich den Einsatz für durchaus vertretbar.

Nicht vertretbar halte ich die Einstellung Canonicals den Snapcraft-Store proprietär zu betreiben. Das Ermöglichen eines dezentralen Modells würde die Akzeptanz in der Community erhöhen. Über eine Option, Komprimierung deaktivieren zu können, um Anwendungsstarts zu beschleunigen würde ich mich freuen. Hier ergeben sich im Alltag derzeit leider unnötige Verzögerungen - mir ist schleierhaft, warum standardmäßig die Snap-Variante des Firefox-Browsers in Ubuntu 21.10 installiert wird. Umso kritischer finde ich es, dass nach dem Erscheinen von Ubuntu 22.04 Canonical plant ausschließlich Snap-Pakete für Firefox anzubieten.