Why I Still Don't Care About Immutable Linux Desktops

I know the pitch. I still do not care.

Let me get the correction in before anyone sends it: this is not a field report. I have not daily-driven Silverblue, Kinoite, Bluefin, Bazzite, or Aurora, and I am not going to write as if I had. I have read the docs, watched the model mature for years, and formed an opinion from the outside. So when I say I do not care about immutable Linux desktops, I am not reviewing them. I am telling you why a technology I genuinely respect has never made me want to switch.

And I want the framing right before I say a single word that sounds like a complaint, because “I don’t care” reads too easily as “it’s bad.” It is not bad. Most of it is good engineering pointed at real problems. The point of this post is narrower and, I think, more useful: interest is earned by deleting a problem you actually have. Atomic desktops solve a set of problems cleanly. They are not the problems that ever made my own desktop decisions hard.

That distinction is the whole post.

What the immutable desktop pitch gets right

Let me state the pitch fairly, because a strawman would be cheap.

The base operating system stops being a pile of files you mutate with a package manager and becomes a versioned image. You do not dnf install your way into a unique snowflake of a root filesystem that no two machines share; you boot an image, then the next image, and you can roll back to the last one if something breaks. Fedora’s Atomic Desktops — Silverblue on GNOME, Kinoite on KDE Plasma, plus Sway, Budgie, and COSMIC variants, all on release 44 now — build this on ostree, the technology that composes, deploys, and updates the image and gives you the rollback.

The newer wave pushes it further. bootc describes itself as transactional, in-place OS updates using OCI/Docker container images — the same image-and-layer model you already use for services, applied to the bootable host. A detail I appreciate: the base userspace is not actually running inside a container at runtime; systemd is still pid1 the normal way. The container is the transport, not a cage. Universal Blue wraps that into a manufacturing process for continuously delivered images — Bluefin, Bazzite, Aurora, uCore — and is careful to say it is not a distribution but a new way to consume existing ones, with signed images, archives for rollback, reduced configuration drift, and a clean separation of the base system from your apps and data.

One correction to the usual framing, since precise nouns matter: “immutable” oversells it. Nothing is frozen forever. You get new images constantly, and you can layer packages onto the base when you must. “Atomic” is the better operational word — updates land all-or-nothing, and you can step back to the previous known-good state. That is a real, valuable property, and I am not going to pretend otherwise.

That is not the problem I was trying to solve

Here is where the respect and the disinterest stop being in tension.

When I think back over the desktop decisions that were actually hard for me, not one of them was “my root filesystem has accumulated too much drift.” That is a genuine problem for some people. It has never been my problem.

Mine were these. Ubuntu spent four years quietly changing what apt install firefox actually delivered until I no longer trusted the distro to tell me what it was doing — a trust complaint, not a technical one. When I ran Fedora KDE, the open question every morning was whether the machine would wake from suspend, because Blackwell on kernel 7.0 could hang on resume, and a daily driver that needs a reboot ritual after lunch is not a daily driver. That specific friction is why my main desktop is Windows again, with WSL carrying the Linux side.

Look at that list. Trust in the package manager. Whether the GPU and the resume path work. Whether the workflow stays out of the way. An image-based base OS with rollback addresses none of those. It would not have stopped Ubuntu’s silent snap swap — that was a policy decision, not a filesystem-drift decision. It would not, on its own, fix an NVIDIA resume hang; that bug lives in the kernel module, and it ships inside your shiny new image too. Rollback lets you retreat from a bad update. It does not make the hardware behave.

So the technology is aimed squarely at a target I was never standing in front of.

Rollback is not a personality

I want to be careful here, because rollback is genuinely good and the heading should not read as a sneer.

Built-in rollback is the strongest single thing the atomic model offers. If your update breaks, you boot the previous image and you are working again in two minutes instead of two hours. For a fleet of managed workstations, a rack of kiosks, a family laptop you maintain from three time zones away, a Steam Deck-style gaming appliance — that is enormous. It turns “the update bricked it” from an incident into a non-event.

But a feature being valuable is not the same as it being valuable to me, for the price it asks. And the price is not zero. To get the rollback I reorganize how I think about the machine: base image plus layered packages, rebases instead of upgrades, container escape hatches for the mutable developer userland. That is a new mental model, new mental models are a real expense, and I do not pay that expense for tools that relocate a problem instead of deleting one.

My current pain around bad updates is already tolerable, and mostly solved elsewhere with snapshots and backups and other unglamorous habits. Rollback as a headline feature does not move me, because the thing it fixes is not currently on fire for me. A good answer to a question I am not asking is still not an answer I need.

The Toolbx and Distrobox escape hatch tells on the model

Here is the part that, more than any feature list, explains my disinterest. And I have to be careful, because I genuinely like the tools involved.

On an atomic desktop, the official answer to “I need mutable developer tooling” is usually “put it in a container.” Toolbx is preinstalled on Silverblue and Kinoite for exactly this. Distrobox does the broader version of the same job, and I run it on Podman on plain Fedora Workstation — by choice, not because an immutable host ever forced me into containers. So this is not me attacking containers as a dev environment. I picked that pattern deliberately.

The thing I notice is structural. The model keeps the base clean by asking the developer to split the machine in two: an immutable host you are not supposed to touch, and one or more toolboxes where the actual work lives. For a lot of people that split is the appeal — the host stays pristine, the mess is sandboxed, you nuke a toolbox and rebuild it from a script.

For me, that split is not automatically simpler than a normal workstation with a few deliberate containers on top. It is the same containers I already run, plus a host I now have to treat as off-limits. I would keep the escape hatch and give up the ability to just dnf install something on instinct when that is genuinely the right call. On Workstation I get the containers and the instinct. The atomic model asks me to trade the instinct away to protect a base layer whose drift was never my problem in the first place.

That the escape hatch has to exist at all tells you the model knows the host is too rigid for real development on its own. That is a fair design choice. It is just not a trade that pays for me.

Who should care

I would be writing a worse, less honest post if I pretended nobody should run these. Plenty of people should, and for them the math runs the opposite way from mine.

• Fleet and workstation managers. If you maintain dozens or thousands of identical machines, an image you build once, sign, and roll out — with guaranteed rollback — is a genuinely better operational story than configuring drift-prone individual installs. This is arguably what the model was for.
• Appliance gaming. Bazzite and the Steam Deck lineage treat the OS as an appliance, and an appliance should be exactly this: image-based, self-healing, rollback-ready. Nobody wants to debug ostree from the couch, and the whole point is that they will not have to.
• Family and non-technical machines. A laptop you support for a relative wants ChromeOS-like reliability with Linux flexibility. Atomic gets close to that.
• Container-first developers. If your workflow already lives in containers by choice, a host that assumes the same is a clean fit rather than an imposition.
• Teams building custom workstation images. Universal Blue’s whole pitch — compose your organization’s image, deliver it continuously — is real leverage when that is your problem.
• People who break desktops by experimenting. If you tinker your root filesystem into a corner every few months, an OS that reverts your tinkering for free is a gift.

None of those is a slight. Every one of them is a case where the model deletes a real, recurring pain. If you are in one of them, you should look seriously, and the fact that I am not in one of them is irrelevant to your decision.

Why I still do not

So back to the filter I run every tool change through: what operational pain does this delete for me?

The honest answer is mostly aesthetic, philosophical, or future-looking. A cleaner base I did not need cleaned. A rollback for breakage I already handle. A model I find genuinely elegant and can admire without wanting to live inside. None of those is nothing — but none of them is a 3 a.m. page I am trying to stop, and that is the bar a migration has to clear before I pay for it.

There is one line I will keep, and I want it precise. When I left Ubuntu for Fedora I wrote that I liked having a clear path to atomic if I ever wanted it. I stand by that. A clear path to atomic is not the same as wanting to walk it. An open door is a comfort; it is not an invitation I have to accept. Keeping the option is free. Reorganizing my workstation around it is not.

I am not anti-new-tools, and I am not anti-atomic. I am anti-adopting anything that does not subtract a real cost from my actual day. The day this model deletes a pain I am genuinely carrying, I will walk through the door I deliberately left open. Until then, I do not need my desktop to be a container image. I need it to wake up, open the terminal, run my WSL and Linux tooling, and stay out of the way — and it already does.