Warum Snaps besser sind als ihr Ruf - und Flathub kein bisschen offener

Bild von Tung Lam auf Pixabay

Es gibt wenige Themen, bei denen die Linux-Community so zuverlässig ihren Verstand verliert wie bei Paketformaten. Du kannst auf jedem beliebigen Forum, Subreddit oder Mastodon-Thread innerhalb von Minuten einen Glaubenskrieg auslösen, indem du das Wort "Snap" fallen lässt. Das funktioniert sogar besser als das Erwähnen von systemd oder Wayland, und das will etwas heissen.

Ich finde diese Debatte zunehmend lächerlich. Nicht weil die technischen Punkte alle falsch wären, sondern weil sie selektiv und mit einer Wut vorgetragen werden, die in keinem Verhältnis zum tatsächlichen Schaden steht. Ich nutze Snap, ich nutze Flatpak, ich habe AppImages auf der Platte und je tiefer ich in die Architektur der drei Formate schaue, desto häufiger denke ich: Die meisten Snap-Vorwürfe sind seit Jahren überholt, und die grossen Flatpak-Verkaufsargumente halten einer technischen Prüfung kaum stand. Wo Flathub im Ernstfall wirklich herkommt. Wo die Sandbox technisch tiefer sitzt. Und warum Snap seit 24.10 Funktionen hat, die selbst überzeugte Flatpak-Nutzer nicht auf dem Schirm haben. Hier kommt die Aufdröselung.

Snap: das gehasste Format, das einfach funktioniert

Fangen wir bei der Lieblings-Klage an. "Snaps sind langsam." Stimmt, beim ersten Start. Bei einem Programm, das du täglich nutzt, wirst du das genau einmal nach der Installation merken. Wir reden hier nicht von Sekunden, in denen man Kaffee kochen könnte. Wir reden von dem Moment, in dem der LoopMount durchläuft und die Sandbox eingerichtet ist. Beim zweiten Start ist alles im Cache und die App startet so schnell, wie sie auch nativ starten würde.

Diese Beschwerde ist mittlerweile auch technisch veraltet. Canonical hat das Verhalten in den letzten Versionen mehrfach optimiert, und auf einer halbwegs aktuellen NVMe-SSD ist der Unterschied nicht mehr spürbar. Wer 2026 noch mit Snap-Startzeiten argumentiert, hat das letzte Mal 2019 ernsthaft hingeschaut.

Der zweite Standardvorwurf: "Canonical kontrolliert das Backend." Korrekt. Snapcraft.io ist proprietär. Wer ein eigenes Snap-Repository betreiben möchte, kann das offiziell nicht. Das ist eine legitime Kritik und ich nehme sie ernst.

Nur: Wen betrifft das wirklich? Mich nicht. Dich vermutlich auch nicht. Und auch nicht die 99 Prozent der Linux-Nutzer, die ein Programm installieren wollen, ohne sich darüber Gedanken zu machen, wer ihren Repository-Server betreibt. Es ist eine prinzipielle Kritik, und prinzipielle Kritik ist wichtig - aber es ist nicht das Argument, mit dem man die Snap-Bashing-Lawine erklären kann, die seit Jahren über das Format rollt.

Was Snap dafür im Alltag richtig gut macht:

• Automatische Updates, ohne dass ich daran denken muss. Mein Firefox-Snap aktualisiert sich im Hintergrund. Ich tue nichts.
• Delta-Updates. Snap lädt nicht die ganzen 200 MB jedes Mal neu, sondern nur die Differenz. Bei Flatpak funktioniert das mittlerweile auch, aber Snap hatte das früher und stabiler.
• Konsistenz über Ubuntu-Versionen hinweg. Mein Snap läuft auf 22.04 LTS genauso wie auf 24.04 oder 26.04. Das ist für mich als Entwickler praktisch, weil ich weiss, was beim Kunden auf dem Server ankommt.
• Server-Stack. LXD, MicroK8s, Nextcloud, etc im Server-Bereich macht Snap einen Job, den Flatpak gar nicht erst versucht.

Snap ist ein erwachsenes Format mit einem klaren Verständnis davon, was es sein will. Und es macht das, was es will, richtig gut.

Flatpak: dezentral in der Theorie, monopolistisch in der Praxis

Jetzt zum interessanten Teil. Flatpak wird gerne als die offene, dezentrale Alternative zu Snap dargestellt. Jeder kann ein eigenes Repository betreiben, niemand kontrolliert die Infrastruktur, das Format gehört der Community. Klingt grossartig.

Nur: Wo installiert ihr eure Flatpaks her?

Genau. Flathub. Alle. Immer. Praktisch ohne Ausnahme.

Flathub ist de facto das einzige Repository, das ernsthaft genutzt wird. Es gibt KDE-eigene Repos, einzelne Projekt-Repos, Fedora hat ein eigenes Flatpak-Remote - aber im realen Nutzungsverhalten kommen 99 Prozent aller Installationen von Flathub. Damit hat man genau die Zentralisierung, die man Canonical permanent vorwirft, einfach nur mit einer anderen Adresse in der URL.

Der Unterschied ist Governance, nicht Architektur. Flathub wird von einer Stiftung getragen, Snapcraft.io von einer Firma. Das ist ein realer Unterschied, aber er löst nicht das Problem, das die Snap-Kritiker als zentral darstellen. Wenn morgen die Flathub-Server abrauchen, geht für 99 Prozent der Flatpak-Nutzer das gleiche Licht aus, das angeblich nur bei Snap ausgehen kann.

Dazu kommen die handfesten Probleme von Flatpak im Alltag:

• Runtimes sind fett. Wer ein paar GNOME-Apps, ein paar KDE-Apps und ein paar Electron-Apps installiert, hat schnell mehrere GB an Runtimes auf der Platte, teilweise in mehreren Versionen parallel.
• Theming ist ein Dauerbrenner. Ausserhalb von GNOME wirkt das Ganze immer ein bisschen wie geliehene Kleidung. Wer KDE benutzt, kennt das Problem.
• Berechtigungen sind im Alltag zu fummelig. Flatseal ist ein gutes Werkzeug, aber wenn ich für jede zweite App nachjustieren muss, ob sie mein ~/Documents sehen darf, ist das keine Sandbox, sondern eine Hausaufgabe.
• Portal-Inkonsistenzen. Datei-Dialoge fühlen sich je nach Distribution und DE unterschiedlich an, manche Apps integrieren sich gut, andere nicht.

Verstehe mich nicht falsch: Flatpak ist ein gutes Format, und ich nutze es sehr häufig. Aber es ist nicht der heilige Gegenentwurf zu Snap, als der es gerne dargestellt wird. Es ist ein Schwesterformat mit ähnlicher Architektur, ähnlicher Zentralisierung im Alltag und einem freundlicheren PR-Apparat.

Sandboxing ist nicht gleich Sandboxing

Apropos Architektur. Schaut man unter die Haube der beiden Formate, sind sich Snap und Flatpak weniger ähnlich, als die oberflächliche "ist halt beides eine Sandbox"-Beschreibung suggeriert. Hier wird es kurz fachlich, aber bleib dran, ich erkläre die Begriffe: Hier liegt nämlich der eigentliche technische Unterschied, der in den meisten Vergleichen einfach untergeht.

Wenn eine App in einer Sandbox läuft, muss irgendetwas dafür sorgen, dass sie diese Sandbox nicht verlässt. Snap und Flatpak lösen das auf unterschiedlichen Ebenen, und die Ebene macht den Unterschied.

Snap setzt auf AppArmor. AppArmor ist ein Sicherheitsmodul, das direkt im Linux-Kernel sitzt - also in dem tiefsten, mächtigsten Teil des Betriebssystems, dem Stück Software, das alle anderen Programme verwaltet. Für jede Snap-App gibt es ein Profil, in dem haarklein definiert ist, was die App darf: welche Dateien sie öffnen kann, welche Geräte sie ansprechen darf, mit welchen anderen Programmen sie reden darf. Versucht die App etwas, das nicht im Profil steht, blockiert der Kernel sie unmittelbar. Das ist keine Bitte, keine Einstellung, die die App selbst beachten muss, sondern eine Mauer. Die der Kernel um die App herum baut, an der die App schlicht nicht vorbeikommt.

Flatpak nutzt Bubblewrap und Linux-Namespaces. Das ist ebenfalls Sandbox-Technik, sitzt aber im sogenannten User-Space. Slso auf der Ebene normaler Programme, oberhalb des Kernels. Vereinfacht gesagt: Flatpak baut der App ein eigenes Mini-Universum aus Sicht des Dateisystems und der Prozesse, in dem sie nur sieht, was Flatpak ihr zeigt. Das funktioniert gut und wird auf vielen seriösen Distributionen eingesetzt. Es ist aber konzeptionell eine Stufe höher angesiedelt als das, was AppArmor macht.

Stell es dir so vor: AppArmor ist eine Mauer mit Wächter, der vom Hausmeister selbst eingestellt wurde und Leute körperlich aufhält. Bubblewrap ist eine Tür, die man hinter der App abschliesst, nachdem man sie in den Raum gelassen hat. Beides funktioniert. Aber wenn jemand wirklich rauswill, ist die Mauer schwerer zu überwinden als die Tür.

Snap hat zusätzlich über hundert sogenannte Interfaces. Ein Interface ist eine vordefinierte Berechtigungsgruppe für einen bestimmten Zweck: home für Zugriff aufs Heimverzeichnis, removable-media für USB-Sticks, camera, audio-record, bluetooth-control, network-control und so weiter. Jedes dieser Interfaces hat ein eigenes AppArmor-Profil hinterlegt und wird vom Snap Store geprüft, bevor eine App es überhaupt anfordern darf. Heisst konkret: schon vor der Installation ist klar, dass eine App, die camera anfordert, vom Store dafür freigegeben wurde.

Und hier kommt der Punkt, den Flatpak-Fans entweder nicht wissen oder geflissentlich übersehen: Snap-Berechtigungen lassen sich auch nach der Installation nutzerfreundlich verwalten - direkt im Betriebssystem. Diese Funktion gab es ursprünglich im Ubuntu Software Center, ist mittlerweile aber sauber in die GNOME-Einstellungen unter "Anwendungen" eingewandert. Du wählst eine installierte App aus, siehst alle Interfaces, die sie angefordert hat, und schaltest sie per Toggle ein oder aus. Bei Firefox sieht das zum Beispiel so aus: mount-control, system-files, network, network-bind, opengl, Zugriff auf Wechseldatenträger, alles einzeln aufgelistet, alles einzeln steuerbar. Genau das, was Flatseal für Flatpak macht. Nur dass du dafür kein Drittwerkzeug installieren musst, weil es Teil des Systems ist.

Mit Ubuntu 24.10 hat Canonical zusätzlich das Permission Prompting eingeführt. Das ist ein System, bei dem dich eine Snap-App im Moment des Zugriffs fragt, ob sie etwas tun darf, das ausserhalb ihres Standardprofils liegt. Du kannst eine Berechtigung einmalig, zeitlich begrenzt, nur für bestimmte Ordner oder nur lesend vergeben. Konzeptionell einen Schritt weiter als Flatseal: Flatseal stellt alle Berechtigungen statisch im Voraus ein, der Prompting-Client fragt im Moment des tatsächlichen Zugriffs.

Die Behauptung, Flatpak habe bei Berechtigungen den klaren Endnutzer-Vorteil, ist damit überholt. Sie war historisch mal richtig, vor ungefähr fünf Jahren. Heute hat Snap eine vergleichbare GUI direkt in den System-Einstellungen, eine kernel-level Durchsetzung via AppArmor, eine Vor-Prüfung im Store und einen Prompting-Client, der im Moment des Zugriffs fragt.

AppImage: der charmante Rückfall in die 90er

AppImage hat etwas Sympathisches. Eine Datei, ausführbar machen, doppelklicken, läuft. Keine Installation, kein Store, keine Infrastruktur. Es ist die direkteste Antwort auf die Frage "Wie führe ich auf Linux ein Programm aus, das nicht im Repository ist."

Aber es ist konzeptionell ein Rückfall. AppImage funktioniert wie ein portable EXE aus den späten 90er und frühen 2000er Jahren unter Windows. Du lädst eine Datei runter, du startest sie, fertig. Sandboxing? Nein, nur mit Drittwerkzeugen. Updates? Nein, ausser du nutzt AppImageUpdate. Desktop-Integration? Nein, ausser du installierst AppImageLauncher. Signierung und Vertrauenskette? Theoretisch ja, praktisch fast nie genutzt.

Ich mag moderne Konzepte. Sandboxing per Default. Automatische Updates. Saubere Trennung zwischen System und Anwendung. Portale, die mir vorschreiben, was eine App darf und was nicht. AppImage ist davon das Gegenteil. Es ist die Lösung für Leute, die ihre Software so installieren wollen wie 1998. Romantisch, aber nicht das, was ich von einem modernen System im Jahr 2026 erwarte.

Das heisst nicht, dass AppImage keinen Platz hat. Für Spezialsoftware, alte Versionen, Studio-Tools, Embedded-Anwendungen ist es perfekt. Aber als Hauptweg, Programme zu installieren? Nein.

Worauf das Ganze hinausläuft

Wenn ich ehrlich bin, ist die Snap-vs-Flatpak-Debatte zu grossen Teilen ein Stellvertreterkrieg. Es geht nicht um Sandboxing, nicht um Startzeiten, nicht um Repository-Architektur. Es geht darum, wer in der Linux-Welt das Sagen hat. Canonical oder Red Hat.

Das wird gerne vergessen oder bewusst verschwiegen, aber Flatpak ist genauso ein Konzern-Projekt wie Snap. Alexander Larsson, der Erfinder von Flatpak, ist seit Jahren bei Red Hat angestellt. Ein Grossteil des Kernteams sitzt ebenfalls dort. Flathub wird zwar formal von der GNOME Foundation getragen, aber der finanzielle, infrastrukturelle und personelle Einfluss von Red Hat ist erheblich. Wenn morgen Red Hat den Geldhahn zudreht, hätte Flathub Probleme, die sich nicht in einem Wochenende lösen lassen.

Das macht Flatpak nicht schlecht. Aber es macht den moralischen Überlegenheitsanspruch der Flatpak-Community gegenüber Snap zur Farce. Beide Formate werden von einem grossen Linux-Konzern getragen, beide haben ein dominierendes Default-Repository, beide leben von der finanziellen Unterstützung ihrer jeweiligen Mutterfirma. Der einzige relevante Unterschied: Red Hat hat in der Linux-Welt ein besseres Image als Canonical. Das ist Marketing, nicht Architektur.

Ich nehme den pragmatischen Weg. Snap funktioniert auf meinem Ubuntu-System tadellos, es macht keine Probleme, es macht mein Leben einfacher. Flatpak nutze ich für die paar Apps, die nicht als Snap verfügbar sind, mit dem stillen Wissen, dass auch dort Flathub das Default-Schicksal aller Pakete ist und ein Konzern in North Carolina im Hintergrund die Strippen mitzieht.

Und wenn jemand auf Reddit zum vierhundertsten Mal erklärt, warum Snaps das Schlimmste sind, was Linux je passiert ist, zucke ich nur mit den Schultern und scrolle weiter.

Snap verdient eine zweite Chance. Oder zumindest die erste, ehrliche.