“Immutable” is a bad name for these systems. You can still change everything you actually care about — your files, your configuration in /etc, your applications. What changes is how the operating system underneath is updated: not by editing your machine in place, but by building a complete new version of it and switching to that.
What it means technically
/usris mounted read-only. The programs and libraries that make up the system cannot be modified, by you or by anything that compromises you./etcand/varstay writable and are carried across updates. Your configuration and data are not part of the image.- Updates are transactional. A new version is downloaded as a complete, checksummed image and staged alongside the current one. It applies entirely or not at all — there is no half-upgraded state, and a power cut mid-update leaves the running system untouched.
- The previous version stays bootable. An update that breaks something is undone by picking the older entry in the boot menu.
That last point is the whole pitch. On a conventional distribution, a bad upgrade leaves you repairing a machine. Here it leaves you rebooting one.
The families
| System | Base | Status |
|---|---|---|
| Fedora Silverblue (GNOME) | Fedora, ostree | Mature; the reference implementation |
| Fedora Kinoite (KDE Plasma) | Fedora, ostree | Mature |
| Sway / Budgie / COSMIC Atomic | Fedora, ostree | Same base, different desktops |
| openSUSE MicroOS | Tumbleweed, btrfs snapshots | Stable; aimed at container hosts |
| openSUSE Aeon (GNOME) | MicroOS | Release candidate, still |
| openSUSE Kalpa (KDE) | MicroOS | Alpha |
| Ubuntu Core | Ubuntu, snaps | Stable; embedded and IoT, not desktops |
| NixOS / Guix | Neither — see below | Stable, and a different idea entirely |
Two of those statuses are worth taking at face value. openSUSE’s own site still describes Aeon as a release candidate and Kalpa as alpha — they are usable and people run them daily, but the projects have not called them finished, and it is not polite to pretend otherwise on their behalf. Fedora’s Atomic Desktops carry no such caveat.
Fedora and openSUSE also get to the same place by different routes: Fedora composes system images with ostree, while MicroOS uses btrfs snapshots — update inside a snapshot, reboot into it, roll back by booting the previous one.
How you install software
This is the part that requires actual relearning. There are three routes, and you should reach for them in this order.
- Flatpak, for graphical applications. Sandboxed, versioned separately from the system, installed and updated without touching the base image. This covers most of a desktop.
- Toolbx or Distrobox, for command-line and development work. Both give you a container that feels like a normal machine — your home directory, your terminal,
dnforaptinside it — while the host stays clean.distrobox-exporteven puts a containerised application in your host menu. If you spend your day in a terminal, this is where you will live. - Layering, as a last resort.
rpm-ostree installadds a package to the base image itself, producing a new deployment you must reboot into. Reserve it for things that genuinely must be on the host: drivers, VPN clients, kernel modules, shell replacements.
flatpak install flathub org.mozilla.firefox
toolbox create && toolbox enter # a Fedora container to work in
distrobox create -i ubuntu:24.04 -n ubu # or someone else's distribution
rpm-ostree install tailscale # layered; takes effect after reboot
rpm-ostree status # deployments, and which is booted
rpm-ostree rollback # go back to the previous onerpm-ostree and bootc: where things stand
You will read that Fedora is moving from rpm-ostree to bootc — bootable containers, where your operating system is defined by a Containerfile and built with the same tooling as any other container image. That is genuinely the direction, and it is a good one: building a custom OS image becomes a build pipeline anyone already knows.
But it is not finished, and the Atomic Desktops still run on rpm-ostree today. rpm-ostree is not deprecated; upstream describes it as widely used and supported, while saying new bootable-container work belongs in bootc. Graphical update tools do not support bootc yet, and a sustainable story for locally layered packages is still an open item on Fedora’s own roadmap — on a bootc system, layering packages locally stops bootc from updating you at all.
The practical reading: install one today and use rpm-ostree. Follow bootc if you want to build your own image; do not wait for a migration before trying the idea.
NixOS and Guix are a different thing
They are usually filed under the same heading and they do not belong there. Silverblue gives you the same image everyone else has; NixOS gives you the same result from the same declaration.
Every package is built in isolation with no undeclared dependencies, so a build is reproducible; the entire machine — packages, services, users, configuration — is described in a file you keep in version control; and every previous generation remains bootable. Installing something cannot break something else, because nothing shares a mutable directory in the first place.
The cost is that you must learn a language and a way of thinking that resembles nothing else in Linux. People who make it through are evangelical; a lot of people do not make it through. If your interest is “my machine should be describable and rebuildable”, this is the family to look at. If it is “an upgrade should never leave me stranded”, Silverblue asks far less of you.
The costs, plainly
Anything that must live on the host costs you a reboot. Not a slow install — a reboot. That is fine for a VPN client you add once, and genuinely irritating the first time you discover it applies to a driver you needed five minutes ago. If the software you depend on is unusual, install one of these in a virtual machine and try your actual workflow before committing a laptop to it.
- Instructions from the internet often do not apply. Every “just run
dnf install” guide needs translating into Flatpak, a container, or layering. This is the friction people actually leave over. - Proprietary and vendor software assumes a normal system. Anything with an installer script that writes to
/usrwill fail. - Tooling lags. Graphical package managers do not yet handle bootc, and ecosystem churn still bites — Fedora 44 removed the old FUSE 2 libraries, which broke legacy AppImages.
- Disk use is higher. Keeping a second full deployment, plus Flatpak runtimes, plus containers, adds up. Not a problem on a modern SSD; a real one on a 128 GB machine.
- Layering erodes the benefit. A system with twenty layered packages is a bespoke image nobody else is testing. If you find yourself doing that, the honest answer is a conventional distribution.
Who should run one
- People who want a desktop that does not slowly accumulate cruft, and who mostly use Flatpak applications and a browser.
- Developers already comfortable working inside containers — Toolbx makes the transition close to free.
- Fleets of identical machines: kiosks, lab workstations, anything where every machine should be provably the same and recoverable by reboot.
- Anyone who has been burned by an upgrade that left a machine unbootable and does not want a second one.
Who should not
- Anyone new to Linux. The mental model is unusual and almost no beginner documentation assumes it. Start with Linux Mint or Fedora Workstation, and come back later.
- Anyone whose work depends on host-level tinkering — kernel modules, out-of-tree drivers, hardware you compile things for. You will spend your life layering and rebooting.
- Servers, mostly. Fedora CoreOS and MicroOS exist for container hosts and are excellent at it, but a general-purpose server is better served by Debian or Rocky. The reboot-to-change model fits a fleet, not a pet.
- Anyone hoping for less maintenance. There is not less. It is differently shaped, and considerably harder to get catastrophically wrong.
Related
- Fedora — the conventional version of the same distribution
- openSUSE — whose snapshot-and-rollback story predates all of this
- Containers — the technology bootc, Toolbx and Distrobox are all built on
- How Packages Work — the problem immutability is an answer to