With more time, testing, and thought on the subject of immutable distros, my personal take is that I don’t see them becoming broadly popular. Especially on the desktop. The benefits make sense for some servers, on kiosks, and in tightly controlled environments, but for everyday Linux users and admins, the trade-offs are too significant.
Immutable distros significantly change the basic model that Linux users are used to. Traditional distros let us install a package with a command, tweak config files in place, and rebuild or fix things on the fly. Immutable systems explicitly discourage that.
Normal package managers (apt, dnf, etc.) aren’t used because the root is read-only, and installing software often means relying on Flatpak or container-based tooling. That, to me, introduces more complexity than it actually adds stability.
I suspect immutable distros will continue to grow in specific niches only. For general use,it seems like an unnecessary complication for an already stable and secure OS that is Linux.
I never really took time to explore these type of Distros, but you just explained my deep down gut feeling. The lock down of the core system gave me pause, because I do like updates. Software is growing and updating on Linux, not at a lightning pace per say, but not slow either. And being able to benefit from those updates is an attraction for me.
@hydn I agree with you, and moreover, I tried a couple of them. The Manjaro implementation didn’t work at all. I cannot recall what else I tried; I may have been able to get one working, but it didn’t impress me at all. There was nothing SUPERIOR about it and plenty lacking, including performance and flexibility.
It’s interesting for me to see your views on this. You (and other long term users) have intimately known how linux has been and the change seems to go against some of your fundamental understandings of how you like linux to work. I believe you when you say these features add more complexity. What I find interesting though, is that I am a user who is gaining their fundamental understanding of linux through these technologies. For me, it makes sense for things to work this way. I want to learn to make my system do whatever I need it to and in learning and exploring linux I’ve found a ton of different tools, all built for different systems with different languages and dependencies etc. I used to be frustrated when I found a cool repo on github and had to figure out how to build from source if the devs hadn’t specifically built it for my system. And eventually, my system would become very muddy. Now, on an immutable system I use toolbox and distrobox to open up a container, safely away from my core system. I can create containers based on specific distro architecture (fedora 41 or 42, arch, ubuntu latest etc.) Within my containers I can use the basic package managers like dnf or pacman. If I do it wrong, I delete that container and try again, no harm done, no uninstalling packages. It keeps my host os clean and I don’t get as confused when I think about everything I have done to my system over time. In my mental model of my system, I think of things in this containerized way, which for me has helped me learn and do more than when I was I was trying to envision it all as one big idea. For certain tools I can even “export” them to the host system and alias the command so the containers automatically launch and run as if they were actually installed on the host system. While it seems like more steps, for me it feels like necessary steps. Linux is complex and this organizes it in a way that makes it feel accessible for me. To sum it all up, I’m not offering this as an opposing opinion but rather as an interesting observation. Linux has always grown and evolved. While immutability may not reach broad popularity, new users growing up in this technology might learn to use it well, much how you and others have learned to use non-immutability well. As much as system recovery and maintenence is important to know, I have generations of programmers who have figured out a lot of that and built tools that allow me to not focus on that and just use linux. I love that idea, and I’m grateful for it. Thanks for the article and comments, its great to put this technology in perspective and helps me feel sure of my decision to use it.
@powder I appreciate your dialog about this. I’m definitely one who has established many methods and techniques that work for me but others may question or personally oppose. What I do think is the most interesting factor about a variety of techniques and technologies is that they offer us more choices. Immutable systems certainly have a use case: those who want their system to work productively and provide access to applications, rather than scratch and itch to update, upgrade, maintain, or grab the latest and greatest widget. Not having to constantly maintain or upgrade a system is certainly a major feature. Some of the best immutable solutions provide the current environment and a prior environment; some even handle the upgrade and replacement, and they may even - in situations where there are many processors or possibly a cluster of resources - offer a mechanism where the updated environment is built on separate processors or clusters, when complete that new cluster is rebooted; if it’s stable, it becomes the current environment and the previous environment can then be booted to the new current, and the process can repeat whenever there are scheduled changes. This is one of many possible ways to manage a stable environment, including a production environment.
While I’m not a fan of this for personal use, I can appreciate why the idea was developed and why it’s useful for people who are looking for a way to minimize maintenance and support, versus complete control over every aspect of their system.
This is certainly an interesting use case scenario. And I can totally agree that it fits you well. Your reasons for choosing immutable systems and your workflow is solid and logical.
I also appreciate you sharing this workflow, it helps others to know what is for them and what is not.
This perfectly elaborates on the heart of what I wanted to express. The workflow and choices I outlined, I picked specifically for my use case. I want something I can easily rebuild from scratch, I want stability and redundancy, I want to easily share pieces of what I am working on with other users and I want to emulate best practices of development and deployment, with scalability, efficiency and security all as priorities. It is absolutely a very specific setup built with very specific uses in mind. But that’s the best point here, that’s linux! You can build it however your system needs it to be. And even further, while these use cases are designed to help the system itself work how it should, it’s also designed for how I like to work with the system. I work and parent and don’t have much time leftover to work with my computer, so I explicitly wanted something that helped me focus on getting where I intend to go, in the most effective timeline possible. I love tinkering. I love freedom and customization. I had to choose what was going to be right for me with what I have to work with. I think it says a lot about linux that it can be built in many different ways to serve both the needs of the systems it runs and the users who build, maintain and use those systems. It doesn’t have to grow in one way, it can be fractal and that’s what makes it such a great operating system and community.
Fascinating read. I’m still on a “standard” Linux system for my daily driver and I regularly look at other distros out of curiosity and interest in seeing what others have done.
While I don’t think an immutable system is my style – though I have definitely considered it – the distros out there using an A/B update model is a kind of middle-of-the-road option and I can see value in that as well.
I can answer yes to only one of the questions so this wouldn’t be my style. I’m perfectly fine with Debian Testing (Forky). If I wanted stability I’d use Debian Trixie I know that’s a solid OS with no problems.
Just my two cents.
The real problems come when a vendor like those that created bazaite, ask you if you’re using an AMD based system and they know it is an AMD GPU, but they conveniently exclude ROCm from the system and because that’s kind of a core piece, it can install fine, but sandboxed apps are broken.
I’m trying to find a laptop and Linux distribution that does everything I want. However, no ROCm means no LM Studio, no PyTorch AI, no HIP-RT in Blender, and other things.
Now if I go with Ubuntu or something like that, I can install the AMD drivers, HIP / ROCm, LM Studio, PyTorch, and even Steam. So immutable is nice, but it’s creating problems that weren’t there with regular distributions, while solving others.
Oh and that’s not a cutting edge feature, it’s a flaw in the design of their image and it is a pain to work around.
Yes I have tried bazzite. It’s not necessarily a bazzite exclusive issue as it is partially created by the fact that AMD, unlike Intel, aren’t building in great support for iGPUs and partially due to the fact that ROCm is a bit of an awkward solution.
Intel iGPUs have integrated support in PyTorch and their API is fully integrated into Blender as well as having solid kernel drivers now. So this wouldn’t require distrobox or anything like that to get it to work out of the box.
Nvidia is the same as Intel here and that’s disappointing, that AMD is the only option that is failing. This is compounded by the fact that their iGPU solutions are the majority of handheld gaming devices as well (I’m using a laptop, but the issue is present on those devices as well).
Exactly! Containers are mandatory to make that work with an AMD iGPU and that’s the biggest issue. I literally have to create a separate set of libraries that I need to update, to make it functional.
I’m honestly just debating returning the laptop for the Intel 258v based version, so I can just use these immutable, distributions right out of the box.
I noticed “Take the Test” and examined the questions. A few might be “okay”, but the test mainly indicates that I can use a Chromebook for the cases where I don’t want to concern myself which much (similar to how the average person just buys a computer when "something’s not quite right). In the majority of the cases, that’s NOT me. Sure, I DO want something that works. That’s why I have USB copies of my systems (backups), more than one machine, etc. so there’s no single point of failure (other than networking, I’m stuck with what I have, unless I drive to some place that offers a network I can connect to). Anyway, the test indicates that immutable systems are NOT ideal for me (and that’s precisely what I had previously determined). Good check list, maybe I forgot about it, but I checked it again and it is “right on” when considering this technology.
I’ve always been interested in making use of specific processors ever since I experimented with proxmox. I think I just felt drawn to it because it sounded cool to assign the use of ‘sockets’ and virtual cpus. The assumption being that I could learn to optimize the hardware I had. Thanks for your comment, it is something I continue to think about. I wonder how many cores I would need to actually execute the ‘live update’ process you mentioned. The documentation in my distro also mentioned another similar feature, a way to make the system available with either the tiling window manager or a more standard env. Similar to the “snapshots” you would choose which env to boot into, both would be the same system with all of your files accessible. I don’t know that I would need to switch between window managers but its a nice option.
Great article! While I answered yes to most of the questions, I’ve never gelled with vendors like fedora and suse, I’m not keen on flatpacks (don’t understand them, and they seem like work), and I like apt-get (and related, they’re pretty straight forward). You wrote
In the last few years, I’ve set up a Debian-based system that provides me with access to bleeding-edge packages but also top-notch stability.
Which is why I’ve been planning to use Debian for my transition from Win 11 back to Linux. I always keep a notebook to make rebuilds manageable (and seldom needed to rebuild). @unixdude (who had a name for the scheme) used what I’ll call build scripts. That sounds approachable as long as I’m the author (so I understand the pieces). Isn’t there something one could add to Debian to get most of the good parts and avoid using a “black box”?
