Last winter, a friend handed me his laptop with a broken bootloader and a question I hear a lot: "Can't I just undo this?" With a classic Linux install, the honest answer is "not easily." With Fedora Silverblue, the one he'd been running, it was two commands and about ninety seconds. That moment—when rollback stops being a rescue operation and starts being a reflex—is the whole point of immutable Linux distributions.
They're not new. The idea has been quietly maturing for a decade, and in 2026 it's on more desktops, servers, and handhelds than most people realize. But the marketing around them is loud and the actual mechanics are often glossed over. Below is what's really going on inside these systems, where they help, and where they'll waste your afternoon.
Key takeaways
- An "immutable" distro keeps the core operating system on a read-only image. You don't edit
/usr; you swap whole versions. - The benefit isn't absolute lockdown—it's predictable, atomic updates with a working rollback.
- Fedora Silverblue, NixOS, and openSUSE Aeon are the ones I'd actually recommend for most people.
- Gaming and proprietary NVIDIA drivers work, but they need the right layering approach.
- If you tweak system files weekly, an immutable distro will fight you. That's fine—it's not for everyone.
What an immutable Linux distribution actually is
Strip away the branding and the core idea is simple: the base system ships as a single signed image. When you update, the machine doesn't patch a hundred files in place. It downloads a new image and boots into it. The old one stays on disk until you decide otherwise.
That's it. Everything else—ostree, the Nix store, A/B partitions—is an implementation detail.
Read-only is not the same as frozen
People hear "immutable" and picture a museum piece. Wrong. You can still install software, change settings, and run whatever you want. What changes is where those things live. Your apps and configurations sit in /etc, /var, and your home directory, or in containers. The base image stays untouched.
The result: an update either fully succeeds or fully fails. No half-broken package state, no "it worked on my machine" surprise after a reboot.
Mutable vs immutable: the real difference
A traditional (mutable) distro lets you change anything, anywhere, at any time. That flexibility is why Linux became what it is. It's also why machines drift into weird states after two years of incremental tweaks.
Here's a comparison of what actually differs day to day:
| Aspect | Mutable distro | Immutable distro |
|---|---|---|
| System update | Packages patched in place | Whole image replaced, then reboot |
| Rollback | Manual, painful | Reboot into previous image |
| Installing a system package | One command | Layering or container required |
| Drift over time | Very common | Minimal by design |
| Best for | Power users, tinkerers | Fleets, stability, low-maintenance desktops |
The catch? That "one command" in the left column becomes two or three in the right. Most of the time you won't notice. When you do, you'll notice a lot.
Which Linux distributions are immutable?
More than most lists suggest, and the mechanics vary wildly. I've tested five of them on the same aging ThinkPad over a couple of months, mostly to see which ones respected my time.
- Fedora Silverblue (and its siblings Kinoite, Sericea): rpm-ostree, the most polished desktop experience I've tried.
- NixOS: the whole system described in a config file. Powerful, steep.
- openSUSE Aeon: transactional updates via btrfs snapshots; the calmest onboarding.
- Ubuntu Core: snap-based, mostly aimed at IoT.
- Flatcar Container Linux: for container hosts, no desktop pretensions.
- Talos Linux: Kubernetes only, nothing else. Deliberately minimal.
- SteamOS: immutable by design, and the reason gamers finally care.
I left a couple off on purpose. Some projects label themselves immutable but only freeze /usr, which is closer to a traditional distro than the marketing implies.
How each one implements it
The mechanisms matter because they determine how much friction you'll feel.
- ostree / rpm-ostree (Fedora family): image-based, with the ability to "layer" extra packages onto a new commit. Layering is convenient—and the #1 reason updates get slow if you overuse it.
- Nix store: every package isolated by hash; switching generations is instant and reversible. My config has been reproducible for two years; I still occasionally break it.
- btrfs snapshots (openSUSE): transparent to the user, quick to roll back, and it behaves exactly like a normal distro until you need it not to.
- A/B partitions: classic approach, used by Android and SteamOS. Simple, robust, and easy to reason about.
In my experience, ostree and btrfs feel the most natural for a desktop. NixOS is the most powerful and the most punishing if you don't enjoy reading documentation.
What is Linus Torvalds' favorite distro?
He's said publicly, more than once, that he uses Fedora on his main machines. That doesn't make Fedora an immutable distro—the flagship edition is still traditional. But it's worth noting, because the immutable Fedora variants (Silverblue, Kinoite) are built on the same base and maintained by the same project. If you trust his taste in a daily driver, the Silverblue branch is the closest immutable equivalent.
What is the most hated Linux distro?
There's no measurable answer, and anyone claiming otherwise is guessing. What you'll find in forums is grumbling—usually about Ubuntu's snap decisions, or systemd in general. But "most hated" is a popularity contest, not a technical fact. My honest take: the distro people complain about most is the one they used first and grew out of.
Where immutable distros earn their keep
Two things convinced me these systems are more than hype.
First, fleet maintenance. A colleague manages roughly 40 workstations for a small company. Before switching to an image-based setup, each major upgrade meant a weekend of remote troubleshooting. After, updates rolled out as image swaps, and a bad one could be reverted without touching a single machine by hand. Failures dropped to the occasional driver edge case.
Second, the "backup laptop" problem. My old X1 Carbon lives in a drawer for weeks at a time. On a mutable distro, coming back to it meant a long update session and the occasional broken dependency. On Silverblue, it's a download and a reboot. Boring, in the best sense.
Developers and containers
If you live in containers, immutability is close to a free win. Tools like Toolbx and Distrobox let you spin up a full mutable environment inside a container, run your toolchain there, and throw it away when it goes sideways. My dev setup is now three disposable containers and a config file. When something breaks, I delete it—no registry surgery, no "which package did I install in 2024?" archaeology.
For a developer machine, I'll say it plainly: this is my preferred setup, and I'd argue it beats a traditional install for anyone who values reproducibility. You may disagree, and that's fine—the friction is real when you step outside the container.
Where they fall short (and why that's okay)
Real talk: immutability isn't free, and the trade-offs are consistently undersold.
Layering too many packages via rpm-ostree slows updates noticeably. I once layered nine packages to match my old workflow, and reboots went from under a minute to well over three. The fix was moving most of them into a container, but I only figured that out after a week of irritation.
Proprietary NVIDIA drivers are better than they were two years ago but still a common stumbling block. Gaming mostly works on SteamOS and the Fedora variants, provided you use the project-blessed driver packages rather than fighting the system.
And if you're someone who edits /etc files for fun on a Sunday, this will feel like a straitjacket. That's not a flaw in the concept—it's the wrong tool for that job.
Is there an immutable Linux Mint?
No official one. Linux Mint remains a traditional, mutable distro—and there's no indication that's changing. If you want Mint's feel on an immutable base, the closest thing is running Mint tools inside a container on top of Silverblue. It works, but you're assembling it yourself.
Bottom line
- Choose immutable if you value predictable updates and easy rollback over tinkering.
- Fedora Silverblue or openSUSE Aeon for most desktops; NixOS if you love declarative configs.
- Keep your dev tools in containers. Layering is a shortcut, not a strategy.
- Skip it if you routinely edit system files—you'll fight the OS instead of using it.
The interesting thing about immutable distributions isn't the lockdown. It's the shift in mindset: you stop treating your operating system as a thing you nurse along and start treating it as a thing you replace. Once you've rolled back a broken update in under two minutes, going back to the old way feels a little like keeping a spare tire you never check. Fine—until it isn't.
