Mit Debian 13 „Trixie“ liefert das Debian-Projekt eine gewohnt solide Weiterentwicklung seiner populären Linux-Distribution. Wie von einem Stable-Release zu erwarten, stehen nicht spektakuläre Neuerungen im Vordergrund, sondern vielmehr ein zuverlässiges System, das durch Stabilität, saubere Integration und Aktualität innerhalb des Debian-Kosmos überzeugt. Für diesen Test kam die KDE-Variante mit KDE Plasma 6.3 zum Einsatz. Die Desktop-Umgebung läuft […]
Was vielleicht nicht so bekannt ist: Man kann das Interface des Gimp weitreichend an seine individuellen Bedürfnisse anpassen. Dieser Artikel erklärt, wie man dabei vorgeht.
CachyOS ist das Kunststück gelungen, die Spitze der distrowatch-Charts zu erklimmen. Über diesen Meilenstein haben zuletzt die meisten IT-Medien berichtet. Das Ranking spiegelt zwar nicht die Anzahl der Installationen wider (diese Zahlen kennt distrowatch nicht), wohl aber das Interesse, das durch Seitenzugriffe gemessen wird. Und das Interesse an CachyOS ist aktuell hoch.
Warum? CachyOS ist eine relativ neue Distribution auf der Basis von Arch Linux. CachyOS verfügt aber über ein verhältnismäßig komfortables grafisches Installationsprogramm, verwendet einen eigenen, auf Geschwindigkeit optimierten Kernel und eigene Paketquellen, deren Programme ebenfalls im Hinblick auf optimale Geschwindigkeit kompiliert sind (mit mehreren Varianten optimiert je nach CPU-Generationen). CachyOS implementiert interessante Features per Default: btrfs-Dateisystem mit komprimierten Subvolumes und Snapper, ufw-Firewall, systemd-boot, fish als Shell etc. Die CachyOS-spezifischen Details sind im Wiki gut dokumentiert.
In Summe ergibt das ein schnelles, modernes und sympathisches Linux, das ganz offensichtlich den Zeitgeist trifft. Höchste Zeit also, dass ich auch in meinem Blog etwas dazu schreibe :-)
CachyOS mit KDE-Desktop
Eckdaten
Rolling Release Modell auf Arch-Linux-Basis (aber mit eigenen Paketquellen)
x86-only, keine ARM-Variante
btrfs als Defaultdateisystem
Snapper als Snapshot-Tool (erfordert btrfs)
systemd-boot als Default-Boot-Loader
fish als Default-Shell
ufw als Firewall
Unzählige Desktops zur Auswahl (mit einer gewissen Präferenz zu KDE)
paru als AUR-Helper
CachyOS-spezifische Zusatzprogramme:CachyOS Hello, CachyOS Package Manager, CachyOS Kernel Manager etc.
Die meisten Details sind frei wählbar. Sie haben bei der Installation die Wahl zwischen diversen Boot-Loadern, können die Dateisysteme frei konfigurieren usw. Ich habe mich bemüht, möglichst nahe an den CachyOS-Vorgaben/Vorlieben zu bleiben, inklusive KDE als Desktop.
Installation
Die Installation von CachyOS erfolgt aus einem Live-System heraus mit dem Programm Calamares. (Dieses distributionsunabhängige Framework wird auch von diversen anderen Distributionen verwendet.) Nach einem ersten Test in einer virtuellen Maschine habe ich diese Installation auf einem Lenovo-P1-Notebook durchgeführt. Die 1-TB-SSD war anfänglich leer, ich wollte aber nur ca. 1/5 der SSD nutzen.
Sie müssen UEFI Secure Boot deaktivieren, falls dieses auf Ihrem Rechner aktiv ist. Es ist möglich, Secure Boot nachträglich zu aktivieren.
Die Installation beginnt — ein wenig absurd! — mit einem Auswahldialog zwischen fünf Boot-Loadern. Willkommen in Nerdistan :-) Hier wäre ein Link in das CachyOS-Wiki hilfreich, wo die Vor- und Nachteile der fünf Programme gut zusammengefasst sind. Die Kurzfassung: GRUB funktioniert immer. Das vorgeschlagene systemd-boot ist klein + schnell und mein persönlicher Favorit. Es unterstützt allerdings nicht die Auswahl eines Snapper-Snapshots während des Bootprozesses. Genau das können GRUB und Limine. GRUB kenne ich von ca. 1000 anderen Linux-Installationen, systemd-boot verwende ich unter Arch Linux, also habe ich mich aus Neugier für Limine entschieden. Bei Limine landen alle Boot-Dateien (sowohl EFI als auch Kernel, Initrd etc.) in einer Partition mit vfat-Dateisystem. Calamares hat das in Verwirrung gebracht (siehe unten).
Auswahl des Boot-Loaders
Erst danach startet das eigentliche Installationsprogramm mit Einstellung von Sprache, Region und Tastatur.
Einstellung der SpracheEinstellung der RegionEinstellung der Tastatur
Wie bei den meisten Distributionen gelingt die Installation am einfachsten und schnellsten, wenn Sie dem Installationsprogramm die Kontrolle über den gesamten Datenträger überlassen und dieses selbst entscheiden kann, welche Partitionen es haben will. Aber wie einleitend erwähnt, wollte ich nur ca. 1/5 der SSD für CachyOS reservieren und habe deswegen eine manuelle Partitionierung durchgeführt. Der Prozess ist in Calamares nur mäßig intuitiv, aber zu schaffen. Ich habe eine 2-GB-Partition für /boot mit FAT32 und eine 180-GB-Partition für / mit btrfs eingerichtet.
Ärgerlicherweise hat Calamares die /-Partitionen vor der /boot-Partition platziert (abweichend von der Darstellung im Partitionseditor und im Zusammenfassungsdialog), was spätere Anpassungen nahezu unmöglich macht :-( Ist das so schwierig?
Beim Verlassen des Partitionseditor beklagt sich Calamares, dass die EFI-Partition fehlt. So wie ich das CachyOS-Wiki und die Limine-Dokumentation verstanden habe, ist diese Partition nicht erforderlich. Ich habe dennoch versucht, in Calamares wie gewünscht eine weitere EFI-Partition einzurichten, bin aber gescheitert. Es gibt nirgendwo die Option, das ESP-Flag zu setzen. Zuletzt habe ich entschieden, mich auf die Dokumentation zu verlassen und die Calamares-Empfehlung zu ignorieren und habe die Installation ohne EFI-Partition fortgesetzt. (Spoiler: hat funktioniert …)
In den nächsten Schritten wählen Sie zuerst den Desktop und dann eventuell gewünschte Zusatzpakete aus. Ich habe mich für KDE entschieden und keine weiteren Paket-Änderungen durchgeführt.
Auswahl des DesktopsAuswahl von zusätzlichen Paketen
Im Dialog »Users« müssen Sie entweder einen eigenen root-User einrichten oder die Option »Nutze das gleiche Passwort auf für das Administratorkonto« verwenden. Ich will weder noch: sudo reicht mir, root braucht kein Passwort (wie unter Ubuntu und macOS). Aber es hilft nichts, diesen Fall sieht Calamares nicht vor.
Benutzer einrichten
Calamares zeigt nun eine Zusammenfassung an. Danach beginnt die Installation, die (zumindest bei meinem lahmen Internet) recht lange braucht. Alle erforderlichen Pakete werden frisch heruntergeladen.
Zusammenfassung der Installationseinstellungen
Alles in allem ist die Installation mit etwas Linux-Erfahrung zu schaffen. Wenn Arch Linux die Messlatte ist, gibt es nichts zu meckern. Fedora, openSUSE oder Ubuntu zeigen aber, dass es deutlich intuitiver geht.
Erste Schritte
Immerhin: Nach einem Neustart bootet CachyOS korrekt. Die Distribution ist auf Platz 1 in der EFI-Bootliste, Limine funktioniert wie es soll.
Nach dem Login erscheint das Programm »CachyOS Hello« und hilft bei den ersten Schritten, z.B. bei der Installation weiterer Pakete. Google Chrome ist in der Auswahl nicht enthalten, aber paru -S google-chrome führt zum Ziel.
»CachyOS Hello« hilft bei ersten Schritten und bei der Installation wichtiger Desktop-Programme
In der Folge habe ich ein paar Stunden damit verbracht, CachyOS arbeitstauglich zu machen: Desktop einrichten, Nextcloud installieren, meine wichtigsten git-Repos herunterladen, Emacs und VSCode installieren usw. Merkwürdigerweise lässt sich die Fenstergröße von Emacs nur ganz schwer mit der Maus ändern — wohl ein Problem im Zusammenspiel mit KDE?
Shell
CachyOS verwendet meine Lieblings-Shell fish per Default — großartig. (Zu fish will ich demnächst einen eigenen Blog-Artikel verfassen.) Auch ein paar praktische Tools wie duf und exa sind standardmäßig installiert. Das bringt Farbe und Komfort ins Terminal. Die bash ist ebenso installiert, z.B. um eigene Scripts damit auszuführen.
fish, exa und duf bringen Farbe und Komfort ins Terminal
btrfs und Snapper
CachyOS empfiehlt btrfs als Dateisystem. Wenn Sie sich dafür entscheiden, richtet CachyOS dort einige Subvolumes für /home, /var/cache, /var/tmp etc. ein. In allen Subvolumes ist die Komprimierfunktion aktiv.
compress=zstd bringt im Root-Dateisystem relativ viel. In den restlichen Subvolumes ist der Nutzen — zumindest bei meinen Daten — sehr überschaubar.
sudo compsize -x /
Processed 264495 files, 143727 regular extents (144574 refs), 152617 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 59% 6.5G 11G 11G
none 100% 4.3G 4.3G 4.3G
zstd 33% 2.2G 6.7G 6.7G
prealloc 100% 1.2M 1.2M 15M
sudo compsize -x /home
Processed 16181 files, 18299 regular extents (18888 refs), 6961 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 95% 10G 10G 10G
none 100% 9.9G 9.9G 9.8G
zstd 25% 180M 715M 711M
prealloc 100% 2.5M 2.5M 44M
sudo compsize -x /var/cache/
Processed 2489 files, 1855 regular extents (1855 refs), 1219 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 99% 3.7G 3.7G 3.7G
none 100% 3.7G 3.7G 3.7G
zstd 27% 2.0M 7.5M 7.1M
sudo compsize -x /var/log
Processed 11 files, 99 regular extents (129 refs), 0 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 83% 13M 16M 16M
none 100% 12M 12M 3.0M
zstd 25% 956K 3.7M 3.7M
In CachyOS ist das von SUSE entwickelte Programm Snapper installiert. Es erstellt vor und nach jeder Paketinstallation bzw. jedem Update Snapshots. Sollte etwas schiefgehen, kann das Root-Dateisystem beim Neustart in einen früheren Zustand zurückversetzt werden. (Den folgenden Limine-Screenshot habe ich in einer virtuellen Maschine erstellt.)
Auswahl eines Snapshots in Limine
Eine Liste aller Snapshots erstellen Sie mit sudo snapper list. Noch bequemer gelingt die Snapper-Administration mit dem vorinstallierten btrfs-assistant. Snapper ist so vorkonfiguriert, dass maximal 50 Snapshots gespeichert werden. Danach werden alte Snapshots automatisch gelöscht.
btrfs-assistant hilft bei der btrfs- und Snapper-Administration
Persönlich habe ich Snapper noch nie benötigt. (Ich kenne das Programm schon seit einigen Jahren von openSUSE.) Man kann argumentieren, dass es ein Hilfsmittel für den Notfall ist, mit nur minimalen störenden Nebenwirkungen. Der Speicherbedarf für die Snapshots ist relativ klein. Wenn Sie die mit Snapper einhergehende Komplexität stört, deinstallieren sie einfach das gleichnamige Paket.
Limine
Wie gesagt, Sie haben bei CachyOS die Wahl zwischen vielen Boot-Loadern. Mich hat Limine interessiert, weil ich das Programm bisher noch nie verwendet habe. Kurz die Eckdaten: x86 + ARM, BIOS + EFI, aber kein Secure Boot.
Unter CachyOS landen die Dateien für Limine und EFI normalerweise in einem FAT32-Dateisystem:
Die gesamte Konfiguration befindet sich in der Textdatei /boot/limine.conf. Im folgenden Listing habe ich die vielen dort befindlichen UUIDs durch xxx ersetzt, damit die Struktur der Datei besser erkenntlich ist.
Um die für Snapper erforderlichen Konfigurationsänderungen kümmert sich das Paket limine-snapper-sync. Das Paket stellt einige systemd-Units zur Verfügung. Die Konfiguration übernimmt /etc/limine-snapper-sync.conf.
Geschwindigkeit
CachyOS stellt eine Menge Kernel zur Auswahl und gibt Ihnen unkompliziert die Möglichkeit, den Scheduler zu beeinflussen. (Der Scheduler steuert, wie viel Rechenzeit welcher Prozess bekommt.) Die für CachyOS kompilierten Kernel sind besonders im Hinblick auf die Geschwindigkeit optimiert. Details können Sie hier, hier und hier nachlesen.
Linux-Freaks haben die Wahl zwischen verschiedenen Kerneln und Schedulern
Darüber hinaus betreibt CachyOS mehrere Repositories mit Paketen, die für unterschiedliche CPU-Generationen optimiert sind. Anstatt also ein Paket anzubieten, das auf jeder noch so alten CPU läuft, gibt es mehrere Pakete, die die Features Ihrer CPU optimal nutzt. Installationen auf Rechner mit einer modernen CPU verwenden automatisch die v3-Repos. Details finden Sie wieder im CachyOS-Wiki.
# Datei /etc/pacman.conf
...
[cachyos-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos-core-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos-extra-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos]
Include = /etc/pacman.d/cachyos-mirrorlist
Was bringen all diese Maßnahmen? Subjektiv nicht viel. Mein Notebook fühlt sich mit CachyOS nicht spürbar schneller an als mit anderen Distributionen. (Die meiste Zeit verwende ich mein Notebook unter Arch Linux, insofern ist das meine Referenz. Und die meiste Zeit erledige ich Dinge, die nicht CPU-intensiv sind — Texte verfassen, Code entwickeln etc.) Andererseits: Wenn Sie viele performance-intensive Programme ausführen (Compiler, lokale KI-Tools, Spiele), dann sind die Optimierungen von CachyOS absolut wertvoll.
Phoronix hat im Mai 2025 umfangreiche Benchmarktests durchgeführt, in denen CachyOS hinter Clear Linux (mittlerweile eingestellt) auf Platz 2 landete, knapp vor Debian 13 RC. Aber die Unterschiede zwischen den Testkandidaten waren überwiegend minimal, im einstelligen Prozentbereich. Schneller ist natürlich immer besser, aber Wunder kann auch CachyOS nicht vollbringen.
CachyOS verwendet standardmäßig ZRAM-Swap und benötigt normalerweise keine zusätzliche Swap-Partition oder Datei. ZRAM-Swap verwendet den Arbeitsspeicher als Auslagerungsort und komprimiert die dort gespeicherten Blöcke. Dieses auch bei Fedora übliche Feature funktioniert normalerweise sehr gut (außer Sie haben wirklich deutlich zu wenig RAM). Der Swap-Speicher wird von systemd eingerichtet (siehe auch zram-generator).
zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd 30,8G 1,2M 84,7K 840K [SWAP]
Auch das Verzeichnis /tmp ist via tmpfs im Arbeitsspeicher abgebildet (siehe /etc/fstab). All diese Maßnahmen führen dazu, dass das (hoffentlich ausreichend verfügbare) RAM unter CachyOS möglichst gut im Sinne einer optimalen Geschwindigkeit genutzt wird.
Hardware-Erkennung und Treiber-Installation
CachyOS hat mit chwd ein eigenes Tool zur Hardware-Erkennung. Es wird bei der Installation verwendet, um alle notwendigen Treiber zu installieren. Im späteren Betrieb liefert chwd --list einen Überblick über die installierten Treiber. chwd --autoconfigure wiederholt die Treiberkonfiguration, z.B. um Treiber für später eingebaute Komponenten zu installieren.
Unter CachyOS läuft per Default die von Ubuntu stammende Firewall ufw. Von außen kommende Verbindungen werden für alle Ports (auch 22/SSH) blockiert. Wenn Sie einen SSH- oder Webserver installieren und von außen sichtbar machen möchten, müssen Sie den entsprechenden Port öffnen, z.B. so:
sudo systemctl enable --now sshd
sudo ufw allow ssh
sudo ufw status
Status: active
To Action From
-- ------ ----
22 ALLOW Anywhere
22 (v6) ALLOW Anywhere (v6)
Fazit
CachyOS ist eine sympathische, in vielen Details originelle, gut funktionierende neue Linux-Distribution. Es macht Spaß damit zu arbeiten, und man merkt, wie viel Mühe in die Entwicklung geflossen ist.
Ich habe schon viele Distributionen kommen und gehen gesehen. Hinter CachyOS steht ein verhältnismäßig kleines Team ohne die finanzielle Unterstützung großer Sponsoren. Wird es CachyOS also nächstes oder übernächstes Jahr noch geben? Ich weiß es nicht. Das Risiko, plötzlich eine nicht mehr gewartete Distribution zu nutzen, ist aber überschaubar: Zur Not sollte durch einen Wechsel der Paketquellen der Umstieg auf das ursprüngliche Arch Linux gelingen.
Es gehört zu meinem Beruf, dass ich viele Linux-Distributionen ausprobiere. Einen Wechsel meiner »Hauptinstallation« auf meinem Arbeits-Notebook mache ich aber nur ganz selten, das ist einfach zu viel Mühe. Dort läuft seit ca. drei Jahren Arch Linux und ich bin damit zufrieden.
CachyOS macht vieles richtig. Wenn ich mein Notebook heute neu aufsetzen bzw. ein neues Notebook einrichten müsste, würde ich vermutlich CachyOS eine Chance geben. Dafür gibt es aktuell aber keine Notwendigkeit, und so werde ich bis auf weiteres Arch Linux treu bleiben. So groß sind die Unterschiede zu CachyOS dann auch wieder nicht.
Ubuntu 24.04.3 LTS aktualisiert die Distribution und erleichtert dadurch die Installation auf aktueller Hardware. Dazu tragen Linux 6.14 und Mesa 25.0.7 bei.
Ein neues Projekt aus der KDE Community sorgt für Aufsehen. Unter dem Namen KDE Linux entsteht derzeit ein völlig neues Linux-Betriebssystem. Zuvor war es unter dem internen Codenamen „Project Banana“ bekannt. Nun steht es erstmals öffentlich zum Test bereit. Noch befindet es sich in einem sehr frühen Entwicklungsstadium. Im Gegensatz zu KDE Neon, das vor […]
Canonical hat die dritte Aktualisierung für Ubuntu 24.04 LTS veröffentlicht. Das Update trägt die Versionsnummer 24.04.3 LTS und steht ab sofort zum Download bereit. Es richtet sich vor allem an Nutzer, die Ubuntu neu installieren möchten. Die neue Version basiert auf dem aktuellen Linux Kernel 6.14. Damit erhält das System Unterstützung für moderne Hardware. Auch […]
Die Release Candidate Version von openSUSE Leap 16.0 ist nun verfügbar. Damit beginnt die letzte Testphase vor dem geplanten Stable Release im Oktober. Dieser folgt auf SUSE Linux Enterprise 16, das im September erscheint. Leap 16.0 bringt viele tiefgreifende Änderungen mit sich. Die Installation verzichtet erstmals auf YaST-Pakete. Stattdessen kommt Myrlyn zum Einsatz, ein neues […]
Nach Proxmox VE 9.0 ist nun auch der Proxmox Backup Server 4.0 stabil in der Basis von Debian 13 »Trixie« angekommen. Er bringt unter anderem Unterstützung für S3-kompatiblen Objektspeicher.
Die KDE-Entwickler haben mit Plasma 6.4.4 eine weitere stabile Ausgabe ihrer Desktopumgebung veröffentlicht. Es handelt sich um das vierte Wartungsupdate der aktuellen 6.4 Reihe. Rund drei Wochen nach Version 6.4.3 bringt dieses Update vor allem kleinere Korrekturen und Verbesserungen im Alltag. Der Fokus liegt klar auf Stabilität und Feinschliff. So bleiben Benachrichtigungen, die im Modus […]
Mit der neuen Version MX Linux 25 endet die bisherige Doppelstrategie beim Init-System. Nutzer müssen sich künftig beim ISO-Download für systemd oder sysVinit entscheiden. Eine Auswahl zur Bootzeit entfällt ab sofort vollständig. Die Standardausgaben mit Xfce, KDE und Fluxbox setzen künftig auf systemd. Wer sysVinit bevorzugt, findet es weiterhin in gesonderten Varianten für Xfce und […]
Die Veröffentlichung von Debian 13 mit dem Codenamen „Trixie“ rückt näher. In nur wenigen Tagen, am 9. August, soll die neue stabile Version offiziell erscheinen. In Vorbereitung darauf wurde jetzt der dritte und vermutlich letzte Veröffentlichungskandidat des Debian Installers vorgestellt. Dieser letzte RC bringt keine neuen Funktionen mehr. Debian 13 befindet sich inzwischen im sogenannten […]
Nur wenige Tage nach einem früheren Vorfall ist es einem Übeltäter gelungen, erneut Malware mit einem Remote Access Trojaner in Arch Linux AUR-Pakete einzuschleusen, berichtet Linuxiac.
Die kommende Version von KDE Plasma 6.5 erhält ein oft gewünschtes Feature. Der Desktop kann jetzt automatisch zwischen hellen und dunklen Designs wechseln. Diese Umschaltung erfolgt je nach Tageszeit und spart manuelles Eingreifen. Zudem lässt sich das globale Design nun direkt in den Schnelleinstellungen ändern. Anwender finden diese Funktion übersichtlich in den Systemeinstellungen. Damit wird […]
Der Linux Coffee Talk ist ein besonderes Format bei fosstopia, in dem wir die relevanten Themen des vergangenen Monats Revue passieren lassen. Schnapp Dir einen Kaffee, Tee oder Dein Lieblingsgetränk, lehn Dich zurück und genieße die lockere Stimmung. In dieser Ausgabe werfen wir einen Blick auf die wichtigsten Entwicklungen im Juli 2025. Viel Spaß beim […]
Der Linux Coffee Talk ist ein besonderes Format bei fosstopia, in dem wir die spannendsten Themen des vergangenen Monats Revue passieren lassen. Schnapp Dir einen Kaffee, Tee oder Dein Lieblingsgetränk, lehn Dich zurück und genieße die lockere Stimmung. In dieser Ausgabe werfen wir einen Blick auf die wichtigsten Entwicklungen im Juli 2025.
Das AUR von Arch Linux steht derzeit offenbar im Fokus als Malware-Schleuder. Zum zweiten Mal innerhalb von zehn Tagen wurden Remote-Access-Trojaner hochgeladen.
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?
Unveränderliche Distributionen liegen im Trend, sind aber gleichzeitig nicht unumstritten. Fedora Silverblue und andere Angebote sind mittlerweile etabliert, Neuankömmling HeliumOS wird sich erst beweisen müssen.
Der Schweizer Anbieter Proton bringt eine neue App für Sicherheit. Proton Authenticator erzeugt sechsstellige Codes zur Anmeldung bei Onlinekonten. Diese Codes erneuern sich automatisch alle 30 Sekunden. Damit ergänzt das Tool die bisherige Produktpalette rund um Datenschutz. Im Unterschied zu anderen bekannten Apps ist Proton Authenticator komplett offen zugänglich. Der Quellcode ist öffentlich einsehbar und […]
GitHub spricht sich in einem neuen Bericht für einen europaweiten Technologie-Fonds aus. Ziel ist es, kritische Open Source Software langfristig zu finanzieren und zu sichern. Denn viele zentrale digitale Werkzeuge entstehen in ehrenamtlicher Arbeit und bleiben unterfinanziert. Laut GitHub enthalten rund 96 Prozent aller Softwareprojekte offenen Quellcode. Der wirtschaftliche Wert dieser Software wird weltweit auf […]
Die ARM-Plattform bietet mit den aktuellen SoCs eine interessante Alternative zu Laptops mit X86. Was unter Windows boomt, wird unter Linux noch stiefmütterlich behandelt. TUXEDO Computers möchte das ändern.