Das Fedora Projekt gehört zu den wichtigsten Säulen der Linux Welt. Es liefert eine moderne, gemeinschaftlich entwickelte Distribution und dient als Grundlage für Red Hat Enterprise Linux. Jetzt beschäftigt sich das Projekt mit einer aktuellen Herausforderung: Wie lassen sich KI Werkzeuge verantwortungsvoll in offene Entwicklungsprozesse integrieren? Nach einem Jahr intensiver Diskussion hat der Fedora Rat […]
Das Fedora Council hat Richtlinien zu KI-gestützten Beiträgen vorgeschlagen. Die zweiwöchige Diskussionsphase vor der Abstimmung wird bereits ausgiebig genutzt.
Fedora stellt sich mit dem Softlaunch von Fedora Forge organisatorisch neu auf. Die neue Plattform zur Organisation der Fedora-Projekte basiert auf der Open-Source-Software Forgejo
Canonical und das Fedora Projekt haben ihre kommenden Linux-Versionen als Beta veröffentlicht. Ubuntu 25.10 trägt den Codenamen Questing Quokka, Fedora erscheint als Version 43. Beide Systeme setzen auf Linux 6.17 und bringen viele neue Funktionen mit. Ubuntu 25.10 setzt auf GNOME 49 als Desktopumgebung. Die Sitzung läuft nun ausschließlich mit Wayland. Neu ist auch die […]
Die Linux-Distribution Fedora steht vor Veränderungen im Bereich Qualitätssicherung. Hintergrund ist der Abgang zahlreicher Mitglieder aus dem internen QA-Team von Red Hat. Einige wechselten zu anderen Abteilungen, etwa in Projekte rund um Künstliche Intelligenz. Dadurch steht nun weniger Personal für klassische Qualitätstests bereit. Besonders betroffen ist die ARM-Version von Fedora. Noch im Juli kündigte das […]
Der X.Org-Fork XLibre ist jetzt im COPR-Repository von Fedora zu finden. Die Installation der Pakete ersetzt den herkömmlichen X.Org-Server mit dem Fork.
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.
Mit dem Gnome-Programm »Software« können Desktop-Programme als herkömmliche Pakete oder als Flatpaks installiert werden. Die Kritierien für die »Editor’s Choice« sind aber nur schwer nachzuvollziehen. Nach den populären Programmen müssen Sie selbst suchen.
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-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!
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.
Ubuntus »App-Zentrum« ist einzig zur Installation von Snap-Paketen gedacht.
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:
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):
Unzählige squashfs-Dateisysteme machen das findmnt-Ergebnis ziemlich unübersichtlich
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.
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?
Fedora hat sich vorgenommen, bis 2028 das unveränderliche Fedora Silverblue zur Workstation-Edition zu machen. Dabei gibt es viele Herausforderungen, vor allem bei Paketen von Flathub.
Für die kommende Version Fedora 43 haben die Entwickler mehrere Änderungen beschlossen. Ziel ist es, das System schneller, moderner und einfacher nutzbar zu machen. Die Veröffentlichung ist für den 11. November geplant. Fedora 43 wird neue Versionen von Programmiersprachen und Entwicklerwerkzeugen enthalten. Dazu gehören unter anderem der Go-Compiler in Version 1.25 sowie die aktuelle LLVM- […]
In der Fedora-Community wurden kürzlich zwei bedeutende Änderungsvorschläge abgelehnt. Einer betraf die Zukunft der 32-Bit-Unterstützung, der andere die mögliche Integration des umstrittenen Xlibre X11 Servers. Ein Vorschlag sah vor, die Systemunterstützung für 32-Bit-Anwendungen auf x86-Rechnern vollständig zu streichen. Obwohl Fedora seit Jahren nur noch auf 64-Bit-Systemen läuft, können Nutzer bislang weiterhin 32-Bit-Programme verwenden. Dies ist […]
Sicherheitsforscher von ERNW haben eine schwerwiegende Schwachstelle in Linux-Distributionen dokumentiert. Die Lücke erlaubt Angreifern mit physischem Zugriff die vollständige Kontrolle über ein System, selbst bei aktivierter Festplattenverschlüsselung. Betroffen sind aktuelle und durchaus auch beliebte Linux Distros wie z.B. Ubuntu 25.04 oder Fedora 42 Ausgenutzt wird eine Debug-Shell, die nach mehrmaliger falscher Passworteingabe im Entschlüsselungsdialog erscheint. […]
Der Vorschlag, XLibre, den Fork für die X.Org X-Server-Implementierung von X11 in Fedora 43 aufzunehmen, wurde wegen fehlender Zustimmung der Community zurückgezogen.
Fedora nimmt oft die Pole-Position bei der Einführung neuer und der Entfernung alter Technologien ein. Das führt derzeit wieder zu kontroversen Diskussionen.
Fedora Linux will sich schrittweise von der veralteten 32-Bit-Architektur trennen. Eine neue Änderung schlägt vor, mit Fedora 44 den Bau von i686-Paketen vollständig einzustellen. Auch die Unterstützung für 32-Bit-Bibliotheken auf 64-Bit-Systemen soll entfallen. Die Multilib-Funktion, die 32-Bit-Software auf modernen Systemen ermöglicht, würde damit wegfallen. Bereits in früheren Fedora-Versionen wurden i686-Kernel und Installationsmedien entfernt. Nun sollen […]
Ab Version 43 setzt die Linux-Distribution Fedora vollständig auf Wayland (bzw. auf das Wayland-Server-Protokoll) für die GNOME-Desktop-Umgebung. Die Veröffentlichung ist für Oktober oder November 2025 geplant. Die Entscheidung wurde vom Fedora Engineering Steering Committee (FESCo) getroffen. Eine klare Mehrheit der Mitglieder sprach sich für den Wechsel aus: Fünf stimmten dafür, zwei dagegen. Kritiker sehen darin […]
Anmelden
Das Fedora Projekt gehört zu den wichtigsten Säulen der Linux Welt. Es liefert eine moderne, gemeinschaftlich entwickelte Distribution und dient als Grundlage für Red Hat Enterprise Linux. Jetzt beschäftigt sich das Projekt mit einer aktuellen Herausforderung: Wie lassen sich KI Werkzeuge verantwortungsvoll in offene Entwicklungsprozesse integrieren? Nach einem Jahr intensiver Diskussion hat der Fedora Rat […]
