Auf meinen privaten Linux-Installationen gehe ich Flatpak- und Snap-Paketen meistens aus dem Weg. Aber damit mir keiner vorwirft, ich sei zu altmodisch, mache ich hin und wieder doch die Probe auf Exempel: Wie gut funktionieren die neuen Paketsysteme? Meine Testkandidaten waren diesmal Fedora 42 sowie zwei Ubuntu-Installationen (25.04 und 25.10 daily), jeweils auf x86_64-Rechnern.
Fedora + Flatpak
Red Hat setzt bekanntermaßen auf Flatpak als sekundäres Paketformat für Desktop-Pakete. Es gibt zwei Motiviationsgründe: Einerseits will Red Hat den Aufwand für die Wartung großer Pakete (LibreOffice, Gimp etc.) längerfristig reduzieren; andererseits soll die Software-Installation für Anwender einfacher werden, insbesondere für Programme, die nicht in den klassischen Paketquellen verfügbar sind.
In Fedora 42 sind Flatpaks optional. Per Default ist kein einziges Flatpak-Paket installiert. Die Flatpak-Infrastruktur ist aber vorkonfiguriert, inklusive zweier Paketquellen (flathub und fedora). Mit dem Gnome-Programm Software können Sie nach Desktop-Programmen suchen. Manche Programme stehen in mehreren Paketformaten zur Auswahl (z.B. Gimp wahlweise als RPM- oder Flatpak-Paket) — dann haben Sie die Wahl, welches Format Sie verwenden möchten. Außerhalb des Linux-Universums entwickelte Apps wie Google Chrome, IntelliJ, Postman, Spotify oder VSCode gibt es hingegen nur als Flatpaks.
Bei RHEL 10 ist die Ausgangssituation ähnlich wie bei Fedora: Die Infrastruktur ist da, aber es sind keine Flatpaks installiert. Falls Sie RHEL als Desktop-System verwenden möchten, ist der Druck hin zu Flatpak aber stärker. Beispielsweise bietet Red Hat LibreOffice nicht mehr als RPM-Paket, sondern nur als Flatpak an. (Für Fedora gilt dies noch nicht, d.h., Sie können LibreOffice weiterhin als RPM installieren. Schauen wir, wie lange das noch so bleibt …)
Mein »Referenztest« ist die Installation von Spotify in einem bisher leeren System (also ohne andere vorher installierte Flatpaks bzw. Snaps). Sie können die Installation in Software oder per Kommando durchführen. Ich ziehe zweiteres oft vor, damit ich sehe, was vor sich geht (Listing gekürzt):
sudo flatpak install flathub com.spotify.Client
Required runtime for com.spotify.Client/x86_64/stable found in remote
flathub. Do you want to install it? [Y/n]: y
...
org.freedesktop.Platform.GL.default 24.08 155 MB
org.freedesktop.Platform.GL.default 24.08extra 155 MB
org.freedesktop.Platform.Locale 24.08 382 MB (partial)
org.freedesktop.Platform.openh264 2.5.1 1 MB
org.freedesktop.Platform 24.08 261 MB
com.spotify.Client stable 208 MB
Für die Installation von Spotify ist ein Download von 1,6 GiB und Platz auf dem Datenträger im Umfang von 1,9 GiB erforderlich. Das ist einfach verrückt.
Einen Überblick über alle installierte Flatpaks samt Größenangaben erhalten Sie mit flatpak list -d. Das folgende Listing ist aus Platzgründen stark gekürzt. Irritierend ist, dass die Paketgrößen in keiner Weise mit den Angaben während der Installation übereinstimmen (siehe das vorige Listing).
flatpak list -d
com.spotify.Client 1.2.63.394 stable 14 MB
org.freedesktop.Platform 24.08.22 24.08 672 MB
org.freedesktop.Platform.GL.default 25.1.3 24.08 464 MB
org.freedesktop.Platform.GL.default 25.1.3 24.08extra 464 MB
org.freedesktop.Platform.openh264 2.5.1 2.5.1 1 MB
Flatpak-Installationen landen im Verzeichnis /var/lib/flatpak. Die unzähligen dort angelegten Verzeichnisse und Dateien verwenden UUIDs und hexadezimale Codes als Namen. Für die Installation von Spotify auf einem zuvor leeren Flatpak-System werden mehr als 46.000 Verzeichnisse, Dateien und Links mit einem Platzbedarf von 1,9 GiB eingerichtet. Es ist nicht lange her, da reichte das für eine ganze Linux-Distribution aus!
sudo du -h -d 0 /var/lib/flatpak/
1,9G /var/lib/flatpak/
sudo find /var/lib/flatpak | wc -l
46241
Immerhin teilen weitere Flatpaks die nun etablierte Infrastruktur von Bibliotheken und Basispakete, so dass der Platzbedarf bei der Installation weitere Flatpaks etwas langsamer steigt.
Beim Start beansprucht Spotify »nur« ca. 400 MiB im Arbeitsspeicher (gemessen mit free -m vor und nach dem Start des Audio-Players). Von den vielen installierten Bibliotheken wird also nur ein Bruchteil tatsächlich genutzt. Wenn Sie mit Ihren Ressourcen sparsamer umgehen wollen/müssen, führen Sie Spotify am einfachsten in einem Webbrowser aus :-)
Ubuntu und Snap
Canonical hat Snap-Pakete bereits tief in der Ubuntu-Infrastruktur verankert. Bei Ubuntu 25.10 (daily 2025-07-31) sind
mehrere wichtige Desktop-Programme als Snap-Pakete vorinstalliert: Firefox, das App-Zentrum, der Firmware-Aktualisierer sowie ein relativ neues Security Center zur Verwaltung von Snap-Zugriffsrechten. Dazu kommen die dafür erforderlichen Basispakete. Immerhin ist der Platzbedarf auf der SSD mit 1,1 GByte spürbar geringer als bei vergleichbaren Flatpaks. Ein wenig frech erscheint mir, dass apt install thunderbird mittlerweile ungefragt zur Installation des entsprechenden Snap-Pakets führt.
Im Unterschied zu Flatpaks, die rein für Desktop-Installationen gedacht sind, bietet Canonical auch eine Menge Snap-Pakete für den Server-Einsatz an: https://snapcraft.io/store?categories=server
Zur Installation von Desktop-Snaps verwenden Sie das App-Zentrum. Als einzige Paketquelle ist https://snapcraft.io/store vorgesehen. Weil schon einige Basispakete vorinstalliert sind, ist die Installation eines weiteren Pakets nicht mit so riesigen Downloads wie beim konkurrierenden Flatpak-System verbunden.
Im Terminal administrieren Sie Snap durch das gleichnamige Kommando. Mit snap install installieren Sie ein neues Paket. snap list zählt alle installierten Snap-Anwendungen auf. snap run startet eine Anwendung, snap refresh aktualisiert alle Snap-Pakete, snap remove name löscht ein Paket.
Mein Referenztest ist wieder die Spotify-Installation. Zusammen mit spotify werden auch die Pakete core20 und gnome-3-38 heruntergeladen. Der Platzbedarf für alle drei Pakete beträgt ca. 600 MiB. (Der Vergleich hinkt aber, weil ja schon diverse Snap-Basispakete installiert sind.) Nach dem Start von Spotify sind ca. 320 MiB zusätzlich im RAM belegt.
sudo snap install spotify
spotify 1.2.63.394.g126b0d89 from Spotify installed
Die interne Verwaltung von Snaps erfolgt ganz anders als bei Flatpak. Snap-Anwendungen werden in Form von komprimierten *.snap-Dateien in /var/lib/snapd/snaps gespeichert:
ls -lh /var/lib/snapd/snaps
... 4,0K ... bare_5.snap
... 64M ... core20_2599.snap
... 74M ... core22_2045.snap
... 13M ... desktop-security-center_83.snap
... 246M ... firefox_6565.snap
... 12M ... firmware-updater_167.snap
... 350M ... gnome-3-38-2004_143.snap
... 517M ... gnome-42-2204_202.snap
... 92M ... gtk-common-themes_1535.snap
... 4,0K ... partial
... 15M ... prompting-client_104.snap
... 51M ... snapd_25227.snap
... 51M ... snapd_25241.snap
... 576K ... snapd-desktop-integration_315.snap
... 11M ... snap-store_1270.snap
... 190M ... spotify_88.snap
Der im Hintergrund laufende Snap-Dämon snapd bindet diese Dateien als squashfs-Dateisysteme an der Stelle /snap/xxx in den Verzeichnisbaum ein und macht die Anwendungen so zugänglich (alle Größenangaben in MiB):
sudo du -mcs /snap/*
210 /snap/core20
248 /snap/core22
30 /snap/desktop-security-center
644 /snap/firefox
35 /snap/firmware-updater
903 /snap/gnome-3-38-2004
1294 /snap/gnome-42-2204
360 /snap/gtk-common-themes
417 /snap/spotify
...
Im Vergleich zu Flatpak sparen die komprimierten Flat-Images zwar Platz auf dem Datenträger. Allerdings speichert
Snap standardmäßig von jedem installierten Paket ein Backup mit der vorigen Version. Im Laufe der Zeit verdoppelt das den von Snap beanspruchten Speicherplatz! Um nicht mehr benötigte Pakete zu löschen, verfassen Sie das folgende Mini-Script. export LANG= stellt dabei die Spracheinstellungen zurück, damit die Ausgaben von snap in englischer Sprache erfolgen. Das Script entfernt alle Snap-Pakete, deren Status disabled ist.
#!/bin/bash
# Datei ~/bin/delete-snap-crap.sh
# Idee: https://superuser.com/questions/1310825
export LANG=
snap list --all | awk '/disabled/{print $1, $3}' |
while read snapname revision; do
snap remove "$snapname" --revision="$revision"
done
Dieses Script führen Sie mit root-Rechten aus:
sudo bash delete-snap-crap.sh
Auf einem Testsystem mit diversen Snap-Paketen (Firefox, Gimp, LibreOffice, Nextcloud Client, VSCode) sank mit der Ausführung dieses Scripts der Platzbedarf in /var/lib/snapd/snaps von 7,6 auf 4,0 GiB.
Spotify als DEB-Paket
Spotify bietet seinen Client auch als Paket für Debian/Ubuntu an: https://www.spotify.com/us/download/linux/
Also habe ich einen Vergleich gemacht.
Download: ca. 150 MB
Platzbedarf auf der SSD: ca. 340 MB
RAM-Bedarf: ca. 350 MB
Fazit: RAM-Bedarf ist bei allen drei Varianten ähnlich, aber die RPM-Variante braucht weniger Platz am Datenträger.
Fazit
Ich sehe die Probleme, die herkömmliche Paketformate verursachen.
Ich verstehe auch den Wunsch nach einem universellem Paketformat, das für alle Distributionen funktioniert, das aus Anwendersicht einfach zu nutzen und das für den Software-Anbieter mit überschaubarem Wartungsaufwand verbunden ist.
Aus meiner Sicht bieten allerdings weder Flatpak noch Snap eine optimale Lösung für diese Probleme/Wünsche. Diese Erkenntnis ist nicht neu, ich habe sie in diesem Blog schon mehrfach formuliert. Die Weiterentwicklung beider Formate in den letzten Jahren hat diesbezüglich leider keine spürbaren Verbesserungen mit sich gebracht.
Bei Flatpak sind die Paketgrößen einfach absurd. Bei Snap sind sie auch zu groß, aber es ist nicht ganz so schlimm — zumindest, wenn alle Doppelgänger regelmäßig entfernt werden. Allerdings ist der Snap Store (also die Paketquelle) Closed Source, was die ohnedies schon geringe Akzeptanz nicht verbessert. Das Software-Angebot im Snap Store ist zwar größer als das auf Flathub, aber ich sehe dennoch die Gefahr, dass das Snap-Format eine Insellösung bleibt und Canonical auch mit dieser Eigenentwicklung Schiffbruch erleidet (ich sage nur Upstart Init System, Unity Desktop, Mir Display Server). Während Flatpaks außerhalb der Red-Hat-Welt zumindest als Option genutzt werden, scheint keine Distribution außer Ubuntu etwas mit Snaps zu tun haben wollen.
Letztlich ist meine Meinung natürlich irrelevant. Ubuntu ist aus meiner Sicht nach wie vor eine attraktive Distribution, sowohl am Desktop als auch am Server. Wer Ubuntu verwenden will, muss eben in den Snap-Apfel beißen. Auf einem Rechner mit einer ausreichend großen SSD und genug RAM funktioniert das gut.
Es ist unklar, ob Red Hat sein Flatpak-Format genauso vehement durchsetzen wird. Bis jetzt sieht es nicht so aus, aber es würde mich nicht überraschen, wenn auch Red Hat irgendwann keine Lust mehr hat, eigene RPM-Pakete für Firefox, Thunderbird, Gimp, Libreoffice usw. zu pflegen und parallel für diverse Distributionen (aktuell: RHEL 8/9/10, Fedora 40/41/42/Rawhide etc.) zu warten.
Vielleicht wir man sich / werde ich mic an den verrückten Ressourcenbedarf neuer Paketsysteme gewöhnen. Auf einem Rechner mit 32 GB RAM und 1 TB SSD — keine ungewöhnlichen Eckdaten heutzutage — spielen 10 GB mehr oder weniger für ein paar Flatpaks oder Snap-Pakete ja keine große Rolle … Mir widerspricht es trotzdem: Wenn es möglich ist, ein Auto zu bauen, das mit 5 Liter Treibstoff pro 100 km auskommt, warum dann eines verwenden, das 8 Liter braucht?
Quellen/Links
Flatpaks
- https://flathub.org/
- https://docs.flatpak.org/en/latest/introduction.html
- https://github.com/flatpak/flatpak/wiki/Sandbox
- https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/removed-features
Snap
- https://snapcraft.io/store
- https://snapcraft.io/store?categories=server
- https://snapcraft.io/docs/the-snap-format
- https://snapcraft.io/docs/system-options
- https://documentation.ubuntu.com/core/explanation/security-and-sandboxing
Diskussion auf mastadon
Schnapsideen hat es immer schon gegeben. Flatpak und Snap gehören nicht unbedingt dazu. Doch bedenklich sind sie auf jeden Fall. Etwas mehr nachgedacht hat man bei openSUSE:
https://build.opensuse.org/
https://github.com/openSUSE/opi
Die erfreuliche Nachricht lautet: Ubuntu 25.04 and Fedora 42 build targets got added
Mit Flatpaks hatte ich keine guten Erfahrungen, und Snap macht es (gefühlt) einfacher, ist aber konzeptionell eigentlich nicht besser. Das ganze Thema mag Vorteile haben, wenn man viel unterschiedliche Software einsetzt mit vielen Abhängigkeiten, die gelegentlich nicht zusammenpassen. Ubuntu-LTS-Nutzer erfahren das, wenn sie viele PPAs einbinden, dann passen irgendwann Pakete und Abhängigkeiten nicht mehr zusammen.
Aus dieser Problematik heraus wirken diese Systeme wie Hilfen, und wem es egal ist, da klappt es auch. Aber die Pakete kommunizieren auch (ähnlich wie Docker) im Hintergrund anders miteinander. Jeder kennt das, wenn Firefox Snaps etc. nicht so richtig wollen, wo ein traditionell installiertes Paket diesen „Problem-Overhead“ nicht mitbringt.
Unpassend finde ich solche Systeme, wenn es darum ginge, ältere Computer fit zu machen. Als Alternative zu Windows 10 oder 11 kann ich sowas nicht anpreisen, wenn eine Software zum Musikhören irrsinnig viel Speicherplatz braucht.
Wenn es gar nicht anders geht, würde ich immer ein AppImage bevorzugen. Das entpackt im Hintergrund auch ein SquashFS-System, aber da kann alles an Abhängigkeiten mit eingepackt werden. Sicher sind diese Pakete auch etwas größer als reguläre Installationspakete der Distributionen, aber immer noch merklich kompakter. Erinnerungen an „PortableApps“ unter Windows werden hier wach…
AppImages gefallen mir aufgrund ihrer Einfachheit auch sehr gut. (Selbst Linux Torvalds hat sich wohlwollend geäußert …) Aber nachdem die »großen« Distributoren damit keine Freude haben, sehe ich für AppImages keine große Zukunft.
Ja, das Gefühl mit der nicht so rosigen Zukunft für AppImages habe ich auch. Man findet nicht viele, obwohl ich das schon sehr hilfreich finde, ist es immerhin auch ein Format, welches distributionsunabhängig ist.
Michael, ich schätze deine Bücher als auch deinen Blog hier sehr und finde gut, dass du auch Dinge beleuchtest, die du selber nicht nutzt bzw. selbst nicht magst und versuchst dennoch die Dinge objektiv darzustellen.
Dennoch vermisse ich bei dem Vergleich eine entscheidende Sache. Die neuen Paketformate Flatpak als auch Snap sind weit mehr als diese. Sie beinhalten eine andere Sicherheitsarchitektur, weil es im Grunde auch Containerformate sind, wo gezielt Berechtigungen verteilt werden könnte.
Was ich mal aufgeschnappt habe, ist, dass Flatpak sich dahingegehend auch weiterentwickeln soll und Drittanbietersoftware (bzw. in Form von Flatseal) nicht mehr notwendig sein soll, um Berechtigungen zu setzen. Was ein immenser Sprung nach vorne wäre.
Ebenso soll Snap sich dahingehend entwickeln, dass es ähnlich wie bei Android oder iOS fungieren soll, indem VOR der ersten Nutzung die Berechtigungen zu verteilen sind. Bisher ist es ja so, dass Berechtigungen verteilt sind und man sich diese vor dem Start der jeweiligen Anwendung anschauen/prüfen/korrigieren muss.
Bei den traditionellen Paketformaten RPM oder DEB muss man sich selber AppArmor oder SELinux Policies erstellen, um den gewünschten Effekt zu erhalten. Welche normale Anwender macht dies? Erst dann kann man diese Formate wirklich vergleichen.
Hier hätte ich mir gerne einen Nachtrag gewünscht, der dies mit aufnimmt oder wäre es vielleicht auch einen gesonderten Blog-Eintrag wert?
Interessanter Einwand, und ja, wahrscheinlich wäre das Thema einen eigenen Blog-Beitrag wert, Aber mir fehlen Zeit und Motivation, diesen zu schreiben :-) Ein paar Anmerkungen:
Du hast natürlich recht, Snap + Flatpak beinhalten auch eine Sicherheitsarchitektur. Die Links dazu sind im Artikel, ich gehe hier aber nicht darauf ein, auch weil ich mich im Detail zu wenig damit auskenne.
Persönlich installiere ich nur relativ wenige Programme, oft Entwicklungswerkzeuge, vielleicht Zeichenprogramme (Gimp, Draw.io). Da mache ich mir um die Sicherheit ehrlich gesagt wenig Sorgen — und wenn doch, dann auf einer anderen Ebene: VSCode wäre ein ideales Einfallstor für Sicherheitsprobleme, und zwar über die vielen Plugins, die oft leichtfertig installiert werden. Aber das wäre ein Thema für noch einen Blog-Beitrag …
Unklar ist mir zudem, wie weit die Sicherheitsarchitektur von Snap + Flatpak vom Fundament der Distribution abhängt. Beide Paketsysteme werden ja als distributionsunabhängige Formate beworben. Aber funktioniert die Absicherung von Flatpaks auch, wenn ich ein Flatpak unter Ubuntu installiere (kein SELinux, keine Firewall)? Umgekehrt, funktioniert die Absicherung von Snaps auch, wenn ich Snaps unter Fedora installiere (kein AppArmor)?
Es braucht nicht erst Flatpak oder Snap um ein Loch in den Schweizer Käse zu bohren, siehe „chwoot: Kritische Linux-Lücke macht Nutzer auf den meisten Systemen zu Root“ bei Heise.
https://en.wikipedia.org/wiki/Swiss_cheese_model
Viele Dinge sind abgesichert wird von Flatpak und Snap behauptet, doch die Bösewichte arbeiten sich ja nicht an den Sicherungen ab, sondern kommen durch die Schlupflöcher.
Nachschlag:
Conclusion
Flatpak’s sandbox model is robust in design, but imperfect in deployment. Sandboxes dissolved through misconfiguration, vulnerabilities like CVE‑2024‑32462, and symlink exploits illustrate the friction between ideal and actual protection. Developers, repository maintainers, and users alike must stay alert, applying patches promptly, reducing permission scope, and improving tooling, to safeguard Flatpak’s promise of application isolation in real-world use.
https://www.linuxjournal.com/content/when-flatpaks-sandbox-cracks-real-life-security-issues-beyond-ideal