Updated: December 11, 2024
Here's something I've not done before - I haven't tested an immutable AKA atomic Linux distro just yet. The idea is, your system is sort of read-only, and it can only be updated in a robust, reliable, atomic manner. Sounds like a cool concept. Necessary? Good for the end user? Well. We need to find out.
Indeed, when I decided to give atomicity its due attention, I faced a dilemma. There are many different flavors of immutable distros out there. Why join efforts and work on one cool thing, when you can fork and fight and dilute the already thin resources even further? The story of the Linux desktop. Browsing around, I sort of honed in on Fedora (and I tested the KDE version of the 41st release just recently). I had a choice. Gnome, KDE. Well, the latter obviously. This thing is called Kinoite, and you can install it like any other distro. To wit.
Immutable, you keep using that word ...
As it happens, a lot of people do not understand what immutable systems are, what their advantages are, and how they work. In essence, it comes down to two things: system security and system consistency.
You can easily create your own "immutable" Linux. Fire up any live CD image, and essentially, you have it. The operating system will be marked read-only, and all of the changes will be done in memory. Reboot, and you're back to square one. Nothing new or novel.
Some distros actually employ this mode of work as their thing - for example, the flexible Puppy Linux, which I've sampled many a time on Dedoimedo. It's great. Small, fast, rather secure, and you can also create a small writable partition on the USB media, so you retain persistence over sessions. Immutable, all right. Then, if you're savvy, you could remount your own root as read-only, create separable writable partitions for those bits of the underlying filesystem that do need changes, like say /run, /tmp and /var, and again, you could have an immutable distro at your disposal.
Outside of the Linux world, I've played with a whole bunch of programs that can do the same thing. In Windows, long time ago, there was a program called Shadow Defender. It would boot your Windows in a so-called shadow mode, all of the (current) session changes would be saved on top of a transparent, virtual layer, and if you liked them, you could commit them, and if you didn't, reboot, gone. Chromebooks do the same thing. System imaging and virtual machine snapshots also give you an immutable-like consistency, should you need it. Lastly, your network routers, or anything that runs off firmware that isn't easily modifiable, can qualify in this category.
So, security and consistency ... Let's address the first one, first.
- Immutable systems can prevent persistent malicious changes to the filesystem, alright. This means that malware could potentially get "installed", but it won't survive a reboot. However, immutability won't help with any in-memory changes during a running session. If someone or something has found a way to exploit a running program, as long as that program is loaded, you might be exposed and vulnerable.
- Immutable systems cannot address human errors, things like phishing and social engineering. If someone can be convinced to input their credentials in a fake login window, or send someone a payment for whatever, or any sort of issue of this nature, no software is going to help.
- Immutable systems use writable home directories, so that users can actually save their own data. If there's an option to run/execute programs from the home directory, then you're still effectively vulnerable to malicious software. It doesn't have to be anything sophisticated. For that matter, you could accidentally encrypt or delete your own user data, with or without a read-only system underneath.
- Browser extensions can be malicious.
- Scripts downloaded from random online sources can be malicious.
All of the vectors above do not require a writable root to render damage. Persistence is interesting for servers and high-value targets (businesses, organizations, etc), but for ordinary humans at home, you have about 50/50 chance of destroying your own data as you have of someone actively hax0ring you.
Consistency is more interesting, then. Indeed, having a reliable system baseline you can always revert to can be a boon in various scenarios. Notably, this can be super-useful in education and public spaces, where one machine may be used by dozens or hundreds or different people in a short time. The ability to quickly reset to the zero state is highly useful, hence the proliferation and popularity of Chromebooks in these environments. This is easier and faster and probably cheaper than reimaging or reinstalling, or locking down the system with security software.
The other aspect of consistency relates to system updates. In the Linux world, system updates are both extremely robust and highly fragile, at the same time. In other words, you're not likely to easily mess up your box by installing stuff (due to library dependency errors and issues), but when you do, it will be really messy. If you've read my articles over the years, you will note I did encounter such problems, especially when I used third-party repos for extra packages in CentOS and openSUSE. But I was always able to resolve them. Ordinary people stand no chance, though. And in general, if you can avoid the use of third-party repos, that's always a good choice.
Here, if you have a consistent mechanism of updates, you're less likely to fail. Sounds like a nice idea. Then again, what about ZFS or BTRFS (and tools like Snapper), which let you create system snapshots and roll back with ease? Well, from my experience, these filesystems are amazing, only they have huge requirements, they can be buggy, and they aren't easy for use and deployment. A simple mechanism of 1-2-switch sounds like a better idea overall.
Indeed, the Linux world seems to have grasped this a while back. The focus is on decoupling system from user, and vice versa, and tightening the security permissions. Hence the solutions like snaps, Flatpaks, and, to some extent, Appimage containers. And then, there's a whole bunch of immutable distros, because in a true Linux fashion, we can't have one simple solution, can we? Nope, we need a dozen, all of them with their fancy array of tech lingo, buzzwords and alike. To wit.
Fedora Kinoite is the KDE flavor of Fedora's immutability repertoire, and on its menu of buzzwords, you have OSTree for the system layer, and Flatpak sandboxed applications for the application layer. Sounds relatively simple and interesting enough, and so I went a-testing.
Installation attempt no.1
No live session, it's the ugly and pointless, non-intuitive installer from the get go. Well, it doesn't matter. I set up the system using the approved set of partitions (see Kinoite requirements), and let it churn. After about fifteen minutes, the installer wizard failed. I rebooted, tried again, same thing. Well, my IdeaPad 3 laptop has no bootloader anymore, and it cannot be used. Great stuff.
I was forced to use a virtual machine
With no ability to run on real hardware, as I always like and prefer, I had to resort to using VirtualBox. Here, the installation completed successfully. It took about 30 minutes for the process to complete, which feels a bit long. But in the end, it worked, and I had in front of me eyes a pretty, elegant KDE desktop.
Here, even with Wayland, there was no auto-scaling, like in Fedora 41 proper.
Software management
After some basic customization - which all worked just fine, plus Plasma is the best desktop out there, I dove into the software part of it. After all, this is what makes or breaks this whole immutable distro story. Is the actual usability any good? Ideally, package management ought to be transparent.
I opened Discover, and indeed, it had a bunch of updates for me. You can immediately see the difference from an ordinary, classic distro. Fewer packages, app based, plus the system bundle. Kinoite uses Flatpaks from its own official Fedora repository. You can, however, add new repositories, like the popular if somewhat unofficial FlatHub. And by this, I mean, using FlatHub is no different than using RPM Fusion, almost. Some applications may indeed be official. But others may be packaged without the involvement of upstream developers or owners or whatever. This is also true for snaps, and this model differentiates this new generation of sandboxed applications from distro-packaged software (RPMs or Debs or alike).
No icons. Why aren't there any icons?
I decided to try to install some extra software. After all, how easy is this? The GUI way did not work for me. The system simply did nothing. I was forced to use the command-line, where I made some good, fast, solid progress.
I am surprised that the "publisher" for VLC is listed as VideoLAN et al. Is that the actual name of the entity behind VLC? After all, if we're doing this whole immutable security thing, I want the best there is.
Is fedora (lowercase) the official source? Or is Fedora Project the official one? Hmm.
Looking at the expanded details for the updates, it would seem that Fedora Project is where I want to get my Flatpaks, and not necessarily "fedora", but then again, if it's included by default in the distro, the source ought to be reputable, right? In fact, what's the difference between the two sources? Why Flatpaks come from one, and the ostree stuff from the other? Is it redundancy? Maintenance decisions? Something else?
I am purposefully being dense and a bit obtuse here, because ordinary people won't be able to test the difference. And if, at the end of the day, it's community packages, then effectively, if someone wants to "breach in", they don't need to worry with the hardened system, they can instead focus on the highly popular and effective supply chain attacks, which start by packaging the bad stuff at the source, if possible. And if you've read the news in the past couple of years, there have been a lot of rogue libraries and packages in all sorts of tool ecosystems. Therefore, for this effort to work, in the intended manner that is, everything needs to be super tight.
In the end, VLC from Discover simply didn't install, forever waiting:
In Konsole, I made good progress:
Here, you also get more information, including a detailed path for the VLC application package, the needed permissions, and what stuff you need to download (and install). This required a bit over 1 GB worth of data, which is quite a lot, especially if you're on a wonky connection.
Next, I installed LibreOffice, another GB. I grabbed Thunderbird, GIMP, Calibre, Audacity, KDEnlive. Not bad. Solid selection, hefty bandwidth utilization. But then, you don't have the likes of Chromium, Chrome, Steam, and for these, you will need to hope they exist as Flatpaks, either on their official websites, on in third-party repos you're willing to use (and trust). You will also need to hope that these Flatpaks in these trusted places were indeed packaged by their official upstream maintainers. Otherwise, you may not necessarily get the exact thing you want and expect, with all the possible implications, good or bad. But essentially, if you can't have everything you need from the official sources, the whole thing breaks.
Overall usability
Other than that, the experience was surprisingly smooth. No crashes, no bugs. Dolphin could benefit from nicer default looks (including pinned places in the sidebar), as I've noted in my Fedora 41 review. The performance was reasonable. Well, wait, there was one bug, so to speak. In Firefox, whenever I tried to download an image, the Save as dialog would always revert to /home. It would not remember my previous choices. This could be due to sandboxing, how portals work and whatnot.
Apart from software management, Kinoite was identical to any which Fedora KDE desktop you may have used before. This is a good thing, because it means the immutable desktop model is fairly mature and robust. But then, as always, the availability of software is the weakest link. And here, it's even weaker than ordinary distros (with RPM, dnf, whatever), because you're limited in how you can interact with the system. Which brings me to my next point ...
OSTree management
The last part of this review is the system stuff. If you're not keen on making any changes to your machine, just let it be. Occasionally, Discover will give you updates, you run them, you utilize your network a bit more than before, and Bob's your uncle. Now, you can still alter the system. The only difference is, you need to do in a rather specific fashion. Basically, you can layer any which RPM available for Fedora on top of your system. This means, whatever isn't available by default, and if there's no Flatpak for it (or you don't trust it), you can add your own package and paste it on top of your system.
rpm-ostree install "package name"
I've not done much testing with this (yet), because I think it defeats the purpose of immutability. If you need to tinker, go with a regular distro. If your atomic distro isn't rich enough to give you what you need, then use something else. As for the distros themselves, like Kinoite, if they want to succeed, then they must offer 99% of what ordinary people require, in a seamless fashion. That means no third-party community repos, no command line, no layers, nothing of that sort. It needs to be plug 'n' play. Hard to solve with proprietary software, but then, that's life. Otherwise, this won't make any difference.
Conclusion
My brief adventure with Fedora Kinoite, version 41 to be exact, was fairly good. Surprisingly so. I didn't swear or curse or feel like bludgeoning my computer, even when the installation on a real laptop failed, twice. Now, that's a massive problem on its own. But I managed. Next, software management is a bit clunky and confusing, and it's a data guzzler, but it was better than I expected. Plus, you have the beauty, elegance and customization of the fine Plasma desktop. Solid speed, too.
One day, this might be a really cushty project. But for it to succeed beyond the nerdy cycles, there really needs to be an official application store for all Linux-related software, free, libre, paid, and proprietary. Without those taken into account, people will look elsewhere. If they cannot trust the store(s), they will look elsewhere. The model needs to be ultra-robust. Can it rely on community packaging? Unlikely. Would I want to use unofficial software for my serious work? Also unlikely. Alas, as history has shown us, there's no such thing as unified, joint efforts in the Linux world. It's fork, fork, fork. This means there never will be one store, there will be nine or fifteen, all 60-80% complete and all not good enough. And I'm not sure that atomic systems will provide the necessary security (reliability yes, most likely, maybe). If they somehow manage to do that, then the user experience will probably suffer. Well, let's see. To sum it up, Kinoite is a cool endeavor, give it a go.
Cheers.