Wer sich zum ersten Mal eine Linux-Distribution aussucht, stolpert ziemlich schnell über drei Begriffe: Rolling Release, Immutable und klassische Updates mit festen Versionen. Auf den Webseiten der Distributionen klingt jedes dieser Modelle wie das beste Feature der Welt. Wer von Windows kommt, kennt diese Wahl gar nicht, denn dort nehmt ihr in der Regel das Update-Modell, das Microsoft vorgibt.
Unter Linux entscheidet ihr selbst. Diese Freiheit liebe ich an freier Software: Euer System kann jahrelang stillhalten, jeden Tag die neueste Software bekommen oder sich als komplettes Paket aktualisieren und bei Problemen einfach zum Vorgänger zurückspringen. In diesem Beitrag erkläre ich euch alle drei Modelle, zeige euch, welche Distributionen dahinterstehen, und sage euch am Ende klar, was ich wem empfehlen würde.
Zwei Fragen, drei Begriffe: der schnelle Überblick
Der wichtigste Punkt vorweg, weil er in vielen Vergleichen untergeht: Die drei Begriffe sind keine drei Schubladen, aus denen ihr eine wählen müsst. Sie beantworten zwei verschiedene Fragen.
- Wann kommt neue Software? Entweder gebündelt in festen Versionen (klassisch, auch Point Release oder Fixed Release genannt) oder laufend in kleinen Schritten (Rolling Release).
- Wie wird das System verändert? Entweder Paket für Paket auf einem jederzeit veränderbaren System (klassisch) oder als komplettes, schreibgeschütztes Systemabbild, das nur als Ganzes getauscht wird (Immutable).
Daraus ergeben sich Kombinationen, die auf den ersten Blick widersprüchlich wirken. openSUSE Aeon ist ein immutable System auf Basis des Rolling Release Tumbleweed. Fedora Silverblue ist ebenfalls immutable, folgt aber den festen Fedora-Versionen.
| Klassisches System (Pakete) | Immutable (Systemabbild) | |
| Feste Versionen (Point Release) | Debian, Ubuntu, Fedora Workstation, Linux Mint, openSUSE Leap | Fedora Silverblue, Fedora Kinoite, Ubuntu Core |
| Rolling Release | Arch Linux, openSUSE Tumbleweed, CachyOS, Manjaro | openSUSE MicroOS, openSUSE Aeon |
Im Rest des Beitrags gehe ich die Modelle einzeln durch.
Was sind klassische Updates?
Klassische Updates heißen im Fachjargon Point Release oder Fixed Release. Die Distribution erscheint in nummerierten Versionen, etwa Debian 13 oder Ubuntu 26.04. Innerhalb einer Version bekommt ihr vor allem Sicherheits- und Fehlerkorrekturen. Neue Funktionen kommen gebündelt mit der nächsten Version, und für diesen Sprung macht ihr ein Release-Upgrade, also ein Upgrade auf die nächste Hauptversion.
Das System selbst wird dabei ganz normal Paket für Paket verändert. Jeder Befehl des Paketmanagers (das Programm, das Software installiert und aktualisiert) greift direkt in das laufende System ein. Dieses Modell prägt Linux seit Jahrzehnten, und es funktioniert hervorragend.
Der große Vorteil ist Planbarkeit. Debian gibt jeder Version einen Lebenszyklus von fünf Jahren: drei Jahre vollen Support und zwei Jahre Long Term Support (LTS). Die Debian-FAQ sagt es sehr deutlich: Wem Sicherheit oder Stabilität wichtig sind, der soll Stable installieren. Punkt. Der Nachteil steht gleich daneben: Stable unterstützt nicht unbedingt die neueste Hardware.
So sieht ein Update und ein Versionssprung aus
Innerhalb einer Version aktualisiert ihr unter Debian und Ubuntu so:
sudo apt update
sudo apt upgrade
Für den Sprung auf die nächste Ubuntu-Version bietet die Aktualisierungsverwaltung ein Upgrade an. Im Terminal geht es laut Ubuntu-Doku mit:
sudo do-release-upgrade
Wichtig für LTS-Nutzer: Das Upgrade von LTS zu LTS wird erst mit dem ersten Point Release angeboten, also mit 26.04.1. Das ist am 27. August 2026 erschienen. Laut Ankündigung sollten Nutzer von 24.04 LTS das Upgrade einige Wochen danach automatisch angeboten bekommen.
Bei Debian ist der Sprung von 12 „Bookworm“ auf 13 „Trixie“ etwas mehr Handarbeit. Die offizielle Upgrade-Anleitung sieht vor, in den Paketquellen (/etc/apt/sources.list oder Dateien unter /etc/apt/sources.list.d/) bookworm durch trixie zu ersetzen und dann in zwei Stufen zu aktualisieren:
sudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade
sudo apt autoremove
Als Tipp: Vor jedem Release-Upgrade ein Backup machen und die Release Notes lesen. Das kostet zehn Minuten und kann euch einen Abend retten.
Welche Distributionen haben klassische Updates?
Die bekanntesten Point-Release-Distributionen unterscheiden sich vor allem darin, wie oft neue Versionen kommen und wie lange sie gepflegt werden (Stand: September 2026):
| Distribution | Rhythmus | Support pro Version | Aktuelle Version |
| Debian | regelmäßig, ohne festen Termin | 5 Jahre (3 Jahre voll, 2 Jahre LTS) | Debian 13 „Trixie“ seit 9. August 2025, Point Release 13.7 |
| Ubuntu LTS | alle 2 Jahre | 5 Jahre, mit Ubuntu Pro und Legacy-Add-on bis zu 15 Jahre | Ubuntu 26.04 LTS seit April 2026 |
| Ubuntu Interim | alle 6 Monate | 9 Monate | halbjährlich zwischen den LTS-Versionen |
| Fedora | etwa alle 6 Monate, Frühjahr und Herbst | rund 13 Monate | Fedora 44 seit 28. April 2026, Fedora 45 für 20. Oktober 2026 geplant |
| Linux Mint | folgt Ubuntu LTS | Mint 22.x bis April 2029 | Linux Mint 22.3 „Zena“, dazu LMDE 7 „Gigi“ auf Debian-Trixie-Basis |
| openSUSE Leap | kein fester Rhythmus genannt | 24 Monate (Leap 16.0) | Leap 16.0, Beta von 16.1 verfügbar |
Fedora ist für mich der spannende Mittelweg: feste Versionen, aber durch den kurzen Zyklus immer recht aktuelle Software. Debian und Ubuntu LTS spielen ihre Stärken dagegen dort aus, wo ein System jahrelang laufen soll, ohne dass ihr euch um große Umbauten kümmern müsst. openSUSE Leap baut auf den Quellen von SUSE Linux Enterprise auf und kombiniert sie mit Community-Paketen.
Was ist ein Rolling Release?
Bei einem Rolling Release gibt es keine Versionssprünge. Das System rollt: Neue Versionen von Kernel, Desktop und Programmen landen laufend in den Paketquellen und mit dem nächsten Update auch bei euch. Arch Linux hat das schon 2006 in einer offiziellen Ankündigung klar formuliert: Arch nutzt ein Rolling-Release-System und hat „keine bestimmte stabile Version, niemals“. Versionsnummern beziehen sich dort nur auf das Installationsmedium. openSUSE beschreibt Tumbleweed genauso: keine eigenständigen Versionen, wie man sie von anderen Distributionen kennt. Statt fester Upgrade-Zeitpunkte bekommt ihr laut openSUSE-Doku häufig Updates für mehrere Systemkomponenten.
Das Versprechen: einmal installieren und dann einfach weiter nutzen. Auf der Tumbleweed-Seite wirbt openSUSE damit, dass ihr euch nicht mehr alle sechs Monate vor großen Upgrades fürchten müsst. Ich mag dieses Gefühl sehr, immer die aktuelle Version von KDE Plasma oder Mesa zu haben. Gerade für Gaming und neue Hardware ist das Gold wert.
Der Preis dafür: Ihr seid näher an den Änderungen dran. Ändert sich etwas Grundlegendes, merkt ihr es sofort und nicht gebündelt nach monatelangen Tests. Rolling heißt deshalb nicht chaotisch. Es heißt aber: regelmäßig updaten und im Blick behalten, was sich tut.
So aktualisiert ihr ein Rolling Release
Unter Arch und Arch-basierten Distributionen wie CachyOS bringt ihr das komplette System so auf den neuesten Stand:
sudo pacman -Syu
Unter openSUSE Tumbleweed ist der richtige Befehl laut openSUSE-Wiki nicht zypper up, sondern:
sudo zypper dup
zypper dup übernimmt den Stand der Paketquellen komplett, inklusive umbenannter oder aufgeteilter Pakete. Die openSUSE-Doku gibt dazu zwei Tipps, die ich sofort unterschreibe: etwa alle zwei Wochen updaten und das System nie über GNOME Software oder KDE Discover aktualisieren, sondern im Terminal. Als Sicherheitsnetz nutzt Tumbleweed das Dateisystem Btrfs mit dem Werkzeug Snapper. Damit könnt ihr nach einem holprigen Update zu einem früheren Systemstand zurückkehren.
Welche Rolling-Release-Distributionen gibt es?
- Arch Linux: das Rolling-Release-Urgestein. Arch beschreibt sich als schlanke, flexible Distribution nach dem Prinzip „Keep It Simple“. Ihr baut euch euer System selbst zusammen und lernt dabei unglaublich viel.
- openSUSE Tumbleweed: Updates werden automatisiert mit openQA getestet, laut openSUSE nicht nur einzeln, sondern auch im Zusammenspiel. Dazu kommen Snapper-Rollbacks. Für mich das Rolling Release mit dem besten Sicherheitsnetz.
- CachyOS: Arch-basiert und auf Leistung getrimmt. Pakete werden für x86-64-v3, x86-64-v4 und Zen4 kompiliert, der eigene Kernel bringt optimierte Scheduler mit. Das Release-Modell bleibt dabei rollend wie bei Arch.
- Manjaro: nutzt laut eigenem Wiki ein Rolling-Release-Modell und setzt auf „cascading stability“. Ihr wählt also, wie frisch oder wie abgehangen eure Pakete sein sollen.
- Void Linux: unabhängig entwickelt, mit runit als Init-System und dem eigenen Paketmanager XBPS. Void setzt ausdrücklich auf Stabilität statt auf Bleeding Edge.
- Solus: ein kuratiertes Rolling Release. Updates kommen wöchentlich, nachdem sie getestet wurden.
Und Debian? Debian Testing und Unstable („Sid“) bekommen laufend neue Pakete, Debian selbst nennt sie aber nicht Rolling Release. Laut Debian-FAQ liefert das Security-Team für beide keine Sicherheitsupdates, und Unstable kann jederzeit kaputtgehen. Für den Alltag würde ich deshalb zu einer der Distributionen oben greifen.
Was ist Immutable Linux?
Immutable heißt unveränderlich. Gemeint ist: Der Kern des Betriebssystems ist schreibgeschützt und wird nicht Paket für Paket umgebaut, sondern als komplettes Systemabbild (Image) ausgetauscht. Bei Fedora Silverblue ist laut Doku das Wurzeldateisystem / schreibgeschützt eingehängt, ebenso /usr mit allem, was darunter liegt. Beschreibbar bleiben /etc für Konfigurationsdateien und /var für Laufzeitdaten.
Ein Update baut ein neues Systemabbild, das beim nächsten Neustart aktiv wird. Laut Silverblue-Doku ist es dann nur noch eine Frage des Neustarts. Der bisherige Stand bleibt erhalten: Macht das neue System Probleme, wählt ihr im Bootmenü einfach die vorherige Version.
Andere Projekte setzen dieselbe Idee mit anderer Technik um. openSUSE MicroOS nutzt ein schreibgeschütztes Root-Dateisystem und transaktionale Updates über Btrfs-Snapshots. Ein Health-Checker prüft nach dem Update, ob das System läuft, und rollt bei Problemen automatisch zurück. Vanilla OS 2 und SteamOS arbeiten mit A/B-Partitionen: Das Update landet auf dem gerade nicht aktiven System.
Für mich ist das die größte Stärke dieses Modells: Ein kaputtes Update ist kein Notfall mehr, sondern einfach ein Neustart.
Warum Fedora lieber „atomic“ sagt
Fedora hat seine Varianten im Februar 2024 unter dem Namen Fedora Atomic Desktops zusammengefasst. Die Begründung im Fedora-Wiki: Der Begriff „immutable“ verwirre Nutzer und bilde die Vorteile dieser Systeme nicht richtig ab. Laut Fedora Magazine sind sie auch nicht wirklich unveränderlich, es gibt Wege, sie zu ändern, nur eben umständliche.
„Atomic“ trifft den Kern besser: Ein Update wird nur übernommen, wenn es erfolgreich gebaut wurde, und ihr könnt jederzeit zurückrollen oder auf ein anderes Host-System wechseln. Ein Update passiert also ganz oder gar nicht. Ich finde „atomic“ technisch den besseren Begriff. Im Alltag begegnet euch trotzdem meist „immutable“, auch Ubuntu Core und openSUSE Aeon beschreiben sich so.
Wie installiere ich Programme auf einem Immutable-System?
- Flatpak ist der Hauptweg für Desktop-Programme. Aeon bringt Flatpak mit Flathub fertig eingerichtet mit, bei KDE Linux kommen Apps primär aus Flatpak.
- Container sind ideal für Entwicklerwerkzeuge und Kommandozeilen-Programme. Aeon startet über Distrobox fertige Tumbleweed-Container, Vanilla OS nutzt mit Apx einen Aufsatz für Distrobox, der Subsysteme von Alpine bis Ubuntu bereitstellt.
- Package Layering ist der letzte Ausweg: Bei Silverblue könnt ihr RPM-Pakete mit rpm-ostree ins Systemabbild einbauen. Dabei entsteht ein neues, kombiniertes Image, das erst nach einem Neustart aktiv ist.
So sieht das bei Fedora Silverblue im Terminal aus (laut Silverblue-Doku):
# Update als neues Systemabbild vorbereiten, aktiv nach dem Neustart
rpm-ostree upgrade
# Dauerhaft zum vorherigen Systemstand zurück
rpm-ostree rollback
# Paket ins Systemabbild einbauen (Layering), aktiv nach dem Neustart
rpm-ostree install htop
# Versionssprung, z. B. auf Silverblue 45, sobald Fedora 45 erschienen ist
rpm-ostree rebase fedora:fedora/45/x86_64/silverblue
Vor einem Rebase solltet ihr erst mit rpm-ostree upgrade aktualisieren. Eine Hauptversion zu überspringen ist laut Doku ungetestet und wird nicht unterstützt. Standardmäßig hält rpm-ostree genau eine Rollback-Version vor.
Der Kompromiss dabei: Wer viel am Basissystem schraubt, etwa mit eigenen Kernelmodulen oder systemweiten Werkzeugen, hat es auf einem klassischen System bequemer. Auf einem Immutable-System heißt jede solche Änderung: neues Abbild, Neustart.
Welche Immutable-Distributionen gibt es?
Die Auswahl ist in den letzten Jahren richtig groß geworden. Hier die wichtigsten Projekte:
| Distribution | Basis | Desktop oder Einsatz | Besonderheit |
| Fedora Silverblue | Fedora, rpm-ostree | GNOME | offizielle Fedora-Variante, aktuell Fedora 44 |
| Fedora Kinoite | Fedora, rpm-ostree | KDE Plasma | offizielle Fedora-Variante |
| Sway Atomic, Budgie Atomic, COSMIC Atomic | Fedora, rpm-ostree | Sway, Budgie, COSMIC | offizielle Fedora-Varianten |
| Bazzite | Fedora Atomic, Universal Blue | Gaming, auch auf Handhelds | Steam und Lutris vorinstalliert, frühere Images per Bootmenü wählbar |
| Bluefin | Fedora Atomic, Universal Blue | GNOME, Entwickler | auf Container-Workflows ausgelegt |
| Aurora | Fedora Atomic, Universal Blue | KDE Plasma 6 | automatische Updates, „Zero Maintenance“ |
| openSUSE Aeon | Tumbleweed, MicroOS-Technik | GNOME | laut Projektseite Release Candidate, tägliche automatische Updates |
| openSUSE Kalpa | MicroOS | KDE Plasma | laut openSUSE-Wiki noch Alpha |
| openSUSE MicroOS | Tumbleweed | Container-Hosts, Edge-Geräte | automatischer Rollback bei Problemen |
| Vanilla OS 2 | OCI-Images aus Debian-Sid-Paketen, ABRoot | GNOME | A/B-Updates, standardmäßig wöchentlich |
| KDE Linux | Arch-Pakete | KDE Plasma | laut KDE noch Alpha, Apps über Flatpak |
| SteamOS 3 | Arch Linux | Steam Deck | schreibgeschütztes Root-Dateisystem, A/B-Partitionen |
| Ubuntu Core | Ubuntu, Snaps | IoT und Embedded | bis zu 15 Jahre Support |
Bazzite, Bluefin und Aurora kommen alle aus dem Projekt Universal Blue. Es baut auf den Fedora Atomic Desktops auf und verteilt das System als OCI-Image, also im selben Format wie Container.
Sonderfall NixOS: Das Projekt nennt sich selbst nicht immutable, sondern deklarativ und reproduzierbar. Laut nixos.org kann das Installieren oder Aktualisieren eines Pakets keine anderen Pakete kaputtmachen, und ihr könnt auf frühere Versionen zurückrollen. Damit teilt NixOS die wichtigsten Vorteile der Immutable-Welt, geht technisch aber einen ganz eigenen Weg.
Was solltet ihr nehmen?
Jetzt zur eigentlichen Frage. Die folgenden Empfehlungen sind meine persönliche Einschätzung aus der Praxis, keine allgemeingültige Wahrheit.
Ihr kommt von Windows und wollt, dass es einfach läuft
Nehmt ein Immutable-System. Automatische Updates im Hintergrund und ein Rollback per Bootmenü sind für Einsteiger das beste Sicherheitsnetz, das ich kenne. Zum Zocken Bazzite, für den Arbeitsrechner Aurora (KDE Plasma) oder Bluefin (GNOME). Wer es ganz offiziell mag, greift zu Fedora Silverblue oder Kinoite. Lieber ein klassisches System mit vertrauter Bedienung? Dann ist Linux Mint eine sehr gute Wahl, die 22er-Reihe wird bis April 2029 gepflegt.
Homelab und Server
Debian Stable. Fünf Jahre Lebenszyklus, riesige Community und laut Debian-FAQ die klare Empfehlung für Server, die am Internet hängen. Ubuntu LTS ist eine gute Alternative, wenn eure Software dafür gebaut ist oder ihr die längeren Supportzeiträume mit Ubuntu Pro nutzen wollt. Einen ausführlichen Vergleich findet ihr in meinem Vergleich zwischen Ubuntu und Debian.
Neueste Hardware, Gaming und Basteln
Ein Rolling Release. openSUSE Tumbleweed, wenn ihr ein starkes Sicherheitsnetz wollt. CachyOS, wenn ihr maximale Performance und das Arch-Ökosystem sucht. Und Arch pur, wenn ihr euer System von Grund auf verstehen wollt. Plant dann aber feste Update-Termine ein.
Aktuelle Software und trotzdem ein Sicherheitsnetz
Dann schaut euch die Kombination an. Die Fedora Atomic Desktops bekommen alle sechs Monate eine neue Basis, openSUSE Aeon aktualisiert sich täglich automatisch auf Tumbleweed-Basis. Bedenkt bei Aeon aber, dass es laut Projektseite noch ein Release Candidate ist.
Fazit: Rolling Release, Immutable oder klassisch?
Die wichtigste Erkenntnis: Ihr müsst euch nicht zwischen drei Modellen entscheiden, sondern zwei Fragen beantworten. Wie aktuell soll eure Software sein, also Point Release oder Rolling Release? Und wie viel Sicherheitsnetz wollt ihr beim Update, also klassisches Paketsystem oder Immutable?
Meine klare Empfehlung: Für Umsteiger ist ein Immutable-System wie Bazzite, Aurora oder Fedora Silverblue heute der entspannteste Einstieg. Für Server bleibt Debian Stable meine erste Wahl. Und wer immer das Neueste will und Spaß am Pflegen hat, wird mit einem Rolling Release wie Tumbleweed oder CachyOS glücklich.
Das Schönste daran: Alle diese Systeme sind freie Software. Ihr könnt sie ausprobieren, wechseln und selbst entscheiden, wann ihr updatet. Probiert es aus und schreibt mir in die Kommentare, welches Modell bei euch läuft.
FAQ
Ist ein Rolling Release instabil?
Nicht automatisch. „Stabil“ hat zwei Bedeutungen: „läuft zuverlässig“ und „ändert sich nicht“. Ein Rolling Release ändert sich ständig, kann aber trotzdem zuverlässig laufen. openSUSE prüft Tumbleweed mit seinem vollautomatischen Testdienst openQA, Solus liefert Updates erst nach Tests wöchentlich aus, und Void setzt ausdrücklich auf Stabilität statt Bleeding Edge. Mehr Pflege als ein Debian Stable braucht ein Rolling Release trotzdem.
Kann ich ein Rolling Release auf einem Server einsetzen?
Möglich ist es, für die meisten Homelabs würde ich es aber nicht empfehlen. Die Debian-FAQ rät für Server am Internet klar zu Stable. Eine spannende Ausnahme ist openSUSE MicroOS: Es basiert auf Tumbleweed, ist für Container-Hosts und Edge-Geräte gedacht und rollt nach fehlgeschlagenen Updates automatisch zurück.
Ist Immutable Linux sicherer?
Fedora bewirbt seine Atomic Desktops mit einer zusätzlichen Schicht an Sicherheit und Zuverlässigkeit. openSUSE nennt als Ziel des schreibgeschützten Root-Dateisystems bei MicroOS, versehentliche Änderungen am System zu verhindern. Ein Freifahrtschein ist das nicht: Programme und Browser brauchen weiterhin Updates, eure Daten weiterhin Backups. Meine Einschätzung: Der größte Gewinn liegt im Schutz vor kaputten Updates und eigenen Fehlern.
Kann ich zwischen Fedora-Atomic-Varianten wechseln, ohne neu zu installieren?
Ja. Laut Fedora Magazine könnt ihr zwischen den Host-Systemen per Rebase wechseln. Das läuft wie ein Versionssprung über rpm-ostree rebase und wird nach einem Neustart aktiv. Bei Bazzite könnt ihr außerdem auf ein früheres, funktionierendes Release zurückgehen und es festpinnen.


Schreibe einen Kommentar