Or, How I’m Rethinking My Linux Installs
Splitting the atom was, quite possibly, one of the most daredevil things that mankind has ever attempted. After all, we had our doubts if we’d ignite a chain reaction in the atmosphere and destroy the world. None the less, we went for it anyways.
In (not quite so) similar fashion, Linux has gone atomic. Or, rather, you have some atomic distributions (sometimes called immutable) of Linux available to you.
But what the hell does that even mean? Well, that’s a wonderful question!
Hayden James describes it pretty well on linuxblog.io. And, if you’re more for the visual side, rather than reading about it, then this Gary Explains video covers is pretty decently:
And if you really want the TL;DR, it boils down to this: an atomic distribution is typically immutable in that you can’t change the running system while it’s running, it is updated all at once, or not at all, and you typically have a way of going back to a previous known good state, in case something isn’t working for some reason.
Now that we’ve established what an atomic distribution is, what does that have to do with me?
Distro Hopping Is A Bug, Not A Feature
Has anyone ever heard the phrase “you’ve been bitten by the <X> bug”? No? Maybe it’s a midwestern colloquialism.
Distro hopping is the concept of moving from one Linux distribution, to the next, with little regard to longevity or long term usage. Basically, you’re on Arch one week, Gentoo the next, and then maybe you’re over here in Ubuntu world after that.
While I haven’t always been a distro hopper, I have been known to run several different distributions on different machines, all for various reasons. No one particular distribution has my heart.
That said, for the last few years, I’ve been running nearly exclusively an Arch-based system (called EndeavourOS). But, I kinda got “bored” with it, as one often does. It just did what it was supposed to do. And the itch of the bug bite got to me.
Let Me Back Up A Second
My ADHD brain is often chaotic, and as such, my writing tends to be as well, so bear with me while I get to the point of this story.
You see, this (at least the last few weeks of “this”) all started with the end of 10 (that is to say, the ultimate death of Windows 10). I have a ThinkPad X1 Carbon (2nd generation) that was running Windows 10, and it was ineligible for Windows 11.
What’s a guy to do? Well, if you follow the advice out of Redmond, you’d throw it away and buy a new computer.
But me being a tech geek, that wasn’t an option.
It was time to throw some Linux at it.
I started off with Fedora Kinoite, which was my first experience with an atomic distribution. And I found it interesting, but hadn’t done a whole lot with it.
I then started messing around with openSUSE Kalpa in a virtual machine. Kalpa is based on openSUSE MicroOS, which is openSUSE’s slimmed down and atomic version of openSUSE Tumbleweed, a rolling release distribution. It comes with the KDE Plasma desktop (noticing a pattern?) and, for the most part, operates like any other install of Tumbleweed.
Fast forward a little bit, and I discover Aurora. It is a product of Universal Blue, which is based off of Fedora. It’s similar to Kinoite (in fact, it even refers to itself as Kinoite in a few places within the stack), but it comes with some really cool features out of the box, with others a simple toggle switch away.
Needless to say, I went ahead and installed Aurora over the top of Kinoite (technically I didn’t even have to do that, I could have simply run a rebase operation that replaced Kinoite with Aurora). But, why do it the easy way?
Speaking of easy way, since Aurora is based on Fedora, it’s at least a semi-fixed release. Fedora has “versions” rather than a rolling release, however it is actually a semi-rolling release. But I digress. My point is, upgrading between point releases can sometimes be problematic, or can sometimes take some manual intervention (i.e. updating your repos to point to the latest version, etc). But, with Aurora, it was as simple as rebooting my computer.
Yes, really. That’s it. The new update had downloaded itself overnight, and was just waiting for a reboot to apply the image. And on reboot, the Fedora 42 base ran just as smoothly as the Fedora 41 base did.
This Got Me Thinking
One of the biggest changes when moving from a regular Linux distribution to an atomic one is how you install software.
The base operating system is in read only mode, so using your standard package tools to install additional software isn’t an option (technically you can do this through a method called “layering” where you layer in additional software on top of the base image, but it’s not advisable for most situations).
To get software, you either install Flatpaks, or use HomeBrew, or, my personal favorite that I’ve only just started using, through Distrobox containers.
Distrobox works with either Podman (my preference) or Docker to create a containerized version of another system on your system. From within that system, you can install whatever software you want, and either run it through the container, or, export it from the container to your base system (which really only provides a shortcut to the containerized app, it’s not moving the app itself on to the base system).
And, given that I’ve been using Arch and have gotten used to basically everything being available in the AUR, I have created an Arch Distrobox on each of my systems. This has given me an easy and familiar way to bring in just about any software I can think of, essentially removing any limitations on installing additional software.
And these methods have got me thinking about, or rethinking, how I manage additional software installs on my existing, non-atomic systems. It gives you an opportunity to keep things separate and distinct, so as not to litter the pristine base install with additional cruft.
It also has me looking at things like MicroOS and containerized workloads to rebuild my server. But if I do that, it would be a much longer-term project that would require a lot of thought and planning.
Bringing It All Together
All in all, my experiences so far with atomic/immutable Linux have been good. As much of a nerd and tinkerer as I am, I found the almost boring automatic updating of Aurora to be refreshing and exciting (yes, I’m aware calling it boring yet exciting is an oxymoron).
I plan to continue testing and evaluating these systems, and may even consider moving my main workloads to such setups. As much as it sounds like hyperbole or hype, I am really starting to believe that atomic distributions may well be the future of Linux. When you look at where Linux has been most successful (mobile devices such as Android and ChromeOS, cloud/containerization workloads) many of these features are prevalent. Could this be what Linux on the desktop needed all along? Time will tell.