It seems like a lot of people in the thread here are using immutable distros as a way to not have to deal with cleanup after uninstalling programs, but other than that it seems that the article is questionable at best? I’m new to this immutable distro thing so i’m curious how many people actually use immutable distros for other reasons than above. To me it seems to be unnecessarily locking down your machine.
Apparently it’s supposed to be harder to bork than regular distros.
But, really, how frequently a normal user borks their system?
I’ve been using Linux for since 2024 and I can’t remember the last time (if any) that I irrecoverably borked the system.
I use arch, mint and Fedora. Repositories in those three are solid.
Yes, immutable systems have their uses. Mostly entreprise uses but for home? Only out of curiosity.
I feel the same way. Like yes, everyone has screwed around and found out but to the point that we need to be like “I will NOT touch anything in the filesystem other than home”? Seems a little bit overkill to me. Would like to hear from someone who uses one to see what their reasons are, because if its just “i dont like cleaning up installation files” i’m not on board.
i’ve moved to immutable systems for my home server (OpenSUSE MicroOS) and for my wife (Kalpa.)
i tried it on my personal machine, but i still need more flexibility to get things just the way i like them, so i stick with EndeavourOS (arch-based.)
This is the single most important aspect of immutable distributions. Because the core of the system is mounted in read-only mode, it cannot be changed. With the core system locked down as read-only, it’s not possible to change settings in directories like /etc, /boot, /dev, /proc, or other critical locations. That means if you wound up with malware on your system, it wouldn’t be able to alter the contents of those directories.
Because of this, immutable distributions are more reliable than non-immutable. Even better, if you accidentally break something, it will most likely be fixed during the next reboot.
Atomic updates are quite different from standard updates. Instead of the OS treating an update on a package-by-package basis, it’s an all-or-none situation. In other words, if an update to a single package would break something, the update will not happen and the system rolls back to the previous working state.
You get the same by setting up btrfs snapshots with any regular distro…
With an immutable system, you are always guaranteed to have a bootable system.
Wonder if that issue applies to systems using bootc. rpm-ostree is still involved AFAIK but not for booting.
Bazzite has been my main driver for months and other than a rocky start involving video encoding it’s been a dream. Bluefin has been fine, but some of the “batteries included” stuff would’ve been better left out entirely.
Trying to do more things inside of a container has been a challenge but it’s a challenge I’m willing to accept. I personally think the headaches of integrating container processes with host processes are preferable to the headaches of tweaking files under
/etcor leaving artifacts of configuration and old programs all across my filesystem.I got a new PC a couple months ago, mostly for gaming, and I knew I wanted an immutable distro after hearing about the immutable gaming distros. I went with Kinoite since I have plenty of daily driver stuff I still need to do.
So far, the only big issue I’ve had was figuring out a way to access apps and a desktop for work that I could only get access with the Windows RDP client and a smart card. Eventually, after a lot of digging through docs I was able to work it out by setting up a Windows VM jump box in Virtual Machine Manager with a few additional command line arguments.
Otherwise, no issues at all. The most tweaking I’ve had to do to launch a game so far was picking a different version of Proton.
What’s a “jump box?”
I recently got a new desktop and decided to try something immutable for the first time. At the suggestion of a coworker, I went for Bazzite.
The install process was pretty simple; there were a few differences, but I expected that. For example, my desktop is a client of my NFS server and I’m accustomed to accessing the share through a directory immediately under root. Can’t have that here. Presumably I could find a way to do that if it were necessary, but I just mounted it elsewhere.
Also, I like Cinnamon and was disappointed to find it wasn’t simply available. However, it’s been at least 12 years since I used any form of KDE and it’s certainly improved a lot since then. I can get over that for now.
Those things settled, I setup all of my various accounts, ran a system update and rebooted just to bring everything in sync, as I would with any new install.
On coming back up, I could not launch steam; clicking the taskbar icon, clicking the start menu icon and manually attempting to launch from both the terminal and run prompt all returned the same error: steam not found.
I did some research and found a script entitled “fix-steam-reset” or something like that. I ran it and it did indeed appear to fix steam, even opening the main window when the script finished. However, when I closed that window and tried to launch steam manually through any of the other methods I mentioned, I got “you are not authorized to run this command.”
I’m sure I messed up something - maybe I’m not supposed to run system updates manually or something? - and that it could have been recovered from where I left it, but it wasn’t a great first UX for a distro that touts its own simplicity.
In the end I switched back to my old workhorse, Fedora, and have been very pleased with my machine.
I get it. I recently switched to NixOS from Arch and I absolutely love it. I would routinely go buck wild with Arch and eventually my system would just be populated with garbage or half assed things that I never bothered to fix. With Nix I don’t have that choice. If I fuck around with the config well then it’s not rebuilding and I need to actually fix it. It prevents me from breaking my system. If I do somehow many to break something then I can instantly roll back from the grub OR just retrieve a backup copy of my config which I keep on my server backup and my private git instance. Just have to git clone it.
So I was once one of those anti-immutable people but now I get it and i love it.
Thanks for understanding! We work with an immutable system at my office and it’s fine, I just don’t see the need for it on my desktop (yet). Next time I replace any of my server hardware (or otherwise reformat) I expect I’ll go immutable.
Thanks!
no prob. I think for certain situations immutable is good. Like in your cause where you use it at work, it makes sense to have a workplace on an immutable distro, just makes things easier. In my case since I’m a developer it also makes sense as the likely hood of me absolutely breaking something is high. plus with nix and the nix flakes and nix shell environments it makes developing a breeze.
For someone at home who is NEW to Linux, yeah it also makes sense. For everyone else? meh I don’t really see a need for it if you know what you’re doing. Don’t get me wrong I love Arch and all its various forks, especially CachyOS, so I mean if it works for you then why go immutable? there’s no right and wrong distro for a user, it’s whatever they prefer. Hell a buddy of mine uses Slackware and will never move from it.
This is a very canny take, and I appreciate the frankness of it. I find myself agreeing with basically everything you say (except about OS’ I don’t use because I don’t have enough of an opinion).
Thanks for being a positive representative of the Linux community!
This is a very misinformed “article” 😂
In what way? Any claims of it being unbreakable or rock solid are obviously hype because nobody can guarantee that about any computer. Otherwise I don’t think it’s misinformed.
Seriously? Number 1-4 are just outright stupid claims, or misguided explanations at best. I especially laughed at the “system being in read-only mode” stupidity. WTF do you think EVERY SINGLE Unix-like system has configured, world writable everything?
Just what a stupid thing to claim:
- some sort of recognizable difference for an immutable distro (it’s not).
- just completely wrong with the facts
- shows the author has no concept of the core differences between why immutable is different.
The atomic updates but is also pretty stupid, since that’s literally just a process difference, and unless you’re running a stock base image (which almost nobody generally is), then you’re not getting full atomic updates globally on your system, and certainly claiming they have no problems is dumb as hell. They then try and point out that NOT being able to update a single application is some sort of benefit, which, hey…maybe that’s subjective, but it’s outright just a dumb claim.
Lastly, there’s a claim in there seems to sound something like it’s normally a battlefield amongst running applications on a non-immutable system, and that somehow there is problematic interaction between programs which is, again, false and ignorant. I don’t even need to deep dive on how misinformed this is, but THEN they take it a step deeper and do one of these idiotic things these uninformed “tech writers” like to do and give this old chestnut: “THANKS TO CONTAINERIZATION”…
HOLEEE SHIT. I DID NOT KNOW THAT CONTAINERZ WERE OTHERWISE NOT CAPABLE OF RUNNING ON OTHER SYSTEMS ZOMAGEE. It’s almost an equally stupid claim as the security bit, and has absolutely nothing to do with immutable distros. Writing “because you’re forced to use containers” doesn’t ring like a feature, so of course they’re going to phrase it the other way. The point is that it’s not some feature of immutable distro, just a thing that exists everywhere. Has absolutely nothing to do with the feature set of what they’re trying to write about.
Just dumb.
Seriously? Number 1-4 are just outright stupid claims, or misguided explanations at best. I especially laughed at the “system being in read-only mode” stupidity. WTF do you think EVERY SINGLE Unix-like system has configured, world writable everything?
The important parts of the filesystem are mounted read-only so you’d have to explicitly reboot and mount as read-write. That’s a lot different than marking individual files or folders as read-only which is what you’re referring to.
The atomic updates but is also pretty stupid, since that’s literally just a process difference,
Yes and no. To get the same behavior without an immutable OS you’d need to take a snapshot before every update and update every package on the system every time and install no additional packages.
and unless you’re running a stock base image (which almost nobody generally is), then you’re not getting full atomic updates globally on your system, and certainly claiming they have no problems is dumb as hell. They then try and point out that NOT being able to update a single application is some sort of benefit, which, hey…maybe that’s subjective, but it’s outright just a dumb claim.
I’m guessing you mean “stock” as in never installing anything additional. If using the base packaging system is your jam then absolutely you shouldn’t use an immutable OS. There are plenty of alternatives to doing a
apt installand that’s what you’re encouraged to do because those options don’t usually involve writing to important system dirs.Lastly, there’s a claim in there seems to sound something like it’s normally a battlefield amongst running applications on a non-immutable system, and that somehow there is problematic interaction between programs which is, again, false and ignorant.
I can’t say I’ve ever run into two packages that, in effect, conflicted with each other, but I’ve absolutely seen packages conflict during installation where I was forced to look for an alternative package without a conflict or complie from source.
Writing “because you’re forced to use containers” doesn’t ring like a feature, so of course they’re going to phrase it the other way.
Saying, “Look at what you can’t do!” is usually not a good idea but depending on your priorities and skill level it’s really about taking riskier options off the table. Yes, some things are more challenging using containers but the likelihood of a container making your machine unbootable is practically zero. I’ve run and administered Linux machines (personally) for over 20 years and not working about base packages has frankly been a load off my mind. And because I’m doing more things in containers I’m coming up with solutions I can easily port to any machine.
I would never say immutables are better than standard distros but I don’t think it’s fair to say they don’t provide any advantages or that you can get the same benefits simply by changing your habits.
Immutable systems rely heavily on Flatpak because the universal installer sandboxes an installed application
They are also all Fedora based so far. Can you install from tar.gz into home directory?
Installing development libraries, whether bleeding edge nightlies, or just slightly obscure, often requires write access to some of the key folders. Does that get difficult?
Non-Fedora-based immutable distros:
- NixOS → Not based on any distro. Immutable-like because the entire system is declaratively managed through the Nix package manager. Rollbacks are built-in.
- openSUSE MicroOS / Aeon → Based on openSUSE Tumbleweed (not Fedora). Uses transactional updates and Btrfs snapshots for immutability.
- Vanilla OS (2.x, Orchid) → Originally Ubuntu-based, but now moving to a Debian Sid base with its own package manager (apx) and immutability features.
- Endless OS → Independent distro, based on Debian but shipped as a read-only OSTree system with Flatpak apps.
- Ubuntu Core → Based on Ubuntu, but entirely snap-based and immutable. Mostly aimed at IoT.
- blendOS → Independent, immutable, designed around atomic updates and containerized package managers (supports apt, dnf, pacman, etc. via containers).
Installing development libraries, whether bleeding edge nightlies, or just slightly obscure, often requires write access to some of the key folders. Does that get difficult?
Nope if you do it in containers. In case of Bazzite, you have podman/distrobox/toolbox, and this particular thing you’d usually want to do in distrobox, which is going to be easier/faster than going full general docker/podman container route. It usually goes like this:
distrobox create -n ubuntubox -i ubuntu:20.04 distrobox enter ubuntubox sudo apt-get install mydevlibraries ...I think you are saying that distrobox on Fedora based system can create a ubuntu/mint/whatever “subsystem” and inside that distrobox it is as though you were in ubuntu/apt environment?
Yes, and the difference compared to docker/podman, is that a lot of things like networking, gpu, audio, shared memory, etc, are passed through automatically by default. So you for example can build/run games inside those containers and expect native performance.
You’d do most of that stuff inside a container (Distrobox probably). You’d basically have a “clean OS” to start with (doesn’t have to be the same OS as the host even) and install your libraries like normal. Distrobox does a good job of integrating with the host so you mostly won’t know you’re in a container. It’s not perfect though, and if you have little experience with containers you’ll definitely have a hard time doing what you need to.
