Ever since I started working on Kairos, I’ve wanted to test out Fedora Silverblue on the desktop. Not sure why I postponed this so much, but I finally pulled the trigger. Installation was fairly simple, though it got stuck every single time when trying to enable the third-party repositories. When this happened I was a bit scared that the whole experience was going to be the same. Fortunately, this hasn’t been the case—quite the opposite.
I’ve never used Fedora before, but I’ve used openSUSE, and to be honest, most major distros are so similar that for the majority of my needs all I have to do is understand which package manager they use and the underlying init system. In the case of Fedora Silverblue those are rpm-ostree and systemd. For the latter, there are no surprises; it’s the same one I’ve used for many years now in openSUSE and Ubuntu, the two major distros I use. For the former, it’s a bit less obvious because here we’re comparing apples to pears: while openSUSE has zypper and Ubuntu has apt, Fedora has dnf, but we can’t make use of it since the system is immutable. rpm-ostree is more of a hybrid between a package manager and an image manager. So yes, it knows about packages but it doesn’t install them on your running system. Maybe first we need to quickly introduce what an immutable system is, and then we can dig into how you maintain such systems.
Disclaimer: I’m not an expert in Fedora Silverblue. If there’s anything in this article that is wrong or misleading, please send me an email (bottom of the article) so I can correct it and learn from my mistake.
Immutable OS#
An immutable OS is not completely immutable, otherwise you wouldn’t be able to run anything. What most operating systems out there mean when they say they are immutable is that there is a layer mounted read-only and therefore it cannot be modified. This is meant as a positive thing because it gives you a predictable system while reducing the attack surface, or at least making it harder to get hacked. There’s a lot more under this term, but let’s use this definition for this post. This means that by design you cannot install, remove, or upgrade packages in these systems.
System Modifications#
Obviously if you couldn’t install, remove, or upgrade anything on your Linux desktop, it would be pretty useless. Hence we need mechanisms for modifying the system. There are two major approaches to achieve this. The first is to make changes in the areas of the system that aren’t mounted read-only. That’s partially true—there are more nuances—but for the sake of keeping things simple we’re going to say that’s the case. For example, within my home directory I can do whatever I want. This gives me lots of freedom without exposing the more sensitive areas of the system. We can achieve this via Flatpaks and toolboxes; you can think of them as two ways to containerize applications. There are obviously more ways to extend the system and I’ll dig into them a bit later, but I’m mentioning these first because Fedora Silverblue seems to promote them.
The other way to modify the system is not to change the running system at all, but to create a new version of the immutable image based on the current image plus our desired changes. Fedora’s solution for this is rpm-ostree. I haven’t dug enough into Fedora’s ecosystem to tell if there are more ways to generate images, so I’ll focus on this one for now.
Flatpaks#
Flatpaks are very user-friendly. You can install them through the system’s Store—which is not really a store because you don’t pay for anything, but it’s named like that for users coming from the Apple, Microsoft, or Android ecosystems. Installing applications is very simple: just look for what you want and click install.
Linux being Linux, you can also search, install, update, and remove Flatpaks via the command line. You can read more about it in their documentation but a quick example would be:
flatpak install gimp
This is how I’ve installed Slack and Visual Studio Code.
Not everything is perfect though. For example, Visual Studio Code throws a messages after installation about missing permissions, and giving me only a hint about how to solve the problem is IMO bad UX. Instead of just offering a close button, it should let me jump straight into the settings where I can make the needed changes.
Toolboxes#
From what I understand, a toolbox is like a sandbox. Imagine spinning up a container that already mounts local directories and the network, making it perfect to install everything you need for specific development projects. Normally I’d use tools like goenv or rbenv to have multiple versions of programming languages. With toolboxes I can do that for everything, not just the language runtime. Plus, it’s better isolated! Not only are they cool, they’re well integrated with the terminal—for example, if you’re already inside a toolbox, opening a new tab drops you in the same toolbox.
These toolboxes run on top of Podman, Red Hat’s container runtime. I’m more of a Docker user myself and while the experience of using Podman was ok for the most part, they aren’t one-to-one compatible. I had to jump through some hoops to get some of the commands on the Kairos documentation running properly on Podman.
This is how I’ve installed Vim and npm.
So far the experience with toolboxes has been great. The only complaint I have is that my muscle memory keeps trying to open Vim on the host system when I know it’s only installed in the toolbox. I’d like to make the toolbox the default for the terminal and switch to the host system—or a different toolbox—only when I need to. I still have to check if there’s a way to configure that.
RPM-OStree#
Okay, so far we’ve covered how to install software on the running system, but at some point you’ll notice that there are packages you cannot easily install via Flatpaks or within a toolbox. In that case, you want to create a new image with those packages. In Fedora Silverblue land this process is called layering.
The tool used to layer your system is rpm-ostree. Think of it as a package manager that can peek across images. Within its database it keeps the currently installed packages and tracks the packages you want to add to your system. I say “tracks” because it doesn’t apply the changes to the running system. To see the changes you must restart, and then you get a new image—most likely the original base with your layers on top, though I still need to read more about the exact architecture.
In the example below, you can see that my system’s previous image included the cursor package, which has been removed in my current one, denoted by the ● symbol, and there’s a new version of the base image with 43 upgraded packages.
mauro@workstation:~$ rpm-ostree status
State: idle
Deployments:
fedora:fedora/42/x86_64/silverblue
Version: 42.20251027.0 (2025-10-27T00:31:19Z)
BaseCommit: 220e7462ba4ef4389f88a7d1de72c266676ef317225f8d003e82a9c3b37dd45a
GPGSignature: Valid signature by B0F4950458F69E1150C6C5EDC8AC4916105EF944
Diff: 43 upgraded
LayeredPackages: cockpit cockpit-machines libvirt-daemon-config-network libvirt-daemon-kvm qemu-kvm tailscale virt-install virt-viewer
● fedora:fedora/42/x86_64/silverblue
Version: 42.20251023.0 (2025-10-23T00:38:32Z)
BaseCommit: 71f6dfcd9d4b76bb831f9e8a82cf244fc698d74e763de63c44cb20b0ca4d205a
GPGSignature: Valid signature by B0F4950458F69E1150C6C5EDC8AC4916105EF944
LayeredPackages: cockpit cockpit-machines libvirt-daemon-config-network libvirt-daemon-kvm qemu-kvm tailscale virt-install virt-viewer
fedora:fedora/42/x86_64/silverblue
Version: 42.20251023.0 (2025-10-23T00:38:32Z)
BaseCommit: 71f6dfcd9d4b76bb831f9e8a82cf244fc698d74e763de63c44cb20b0ca4d205a
GPGSignature: Valid signature by B0F4950458F69E1150C6C5EDC8AC4916105EF944
LayeredPackages: cockpit cockpit-machines libvirt-daemon-config-network libvirt-daemon-kvm qemu-kvm tailscale virt-install virt-viewer
LocalPackages: cursor-1.7.33-1759462983.el8.x86_64
I see this as a very interesting transition from traditional mutable systems, where you interact with the package manager to install, remove, and upgrade packages in your current system. rpm-ostree gives you a similar feeling, with the major difference that the system you’re interacting with is the upcoming one. The other project that comes to mind is ABRoots, but I don’t know enough about it to compare them.
I can also diff the database to see how those 43 packages upgrade (I’m only showing three here for the sake of readability):
mauro@workstation:~/Personal$ rpm-ostree db diff
ostree diff commit from: booted deployment (df21230f0d8c842212b5530a492eaec12d9735aa259a9da3f81abccc6d67d29a)
ostree diff commit to: pending deployment (ad6195067ab96b2b8f9d776b9b5b5346fa2575818efab36cbf6c4b314440303a)
Upgraded:
...
intel-gpu-firmware 20251011-1.fc42 -> 20251021-1.fc42
...
python3 3.13.7-1.fc42 -> 3.13.9-1.fc42
...
This is how I’ve installed libvirt and Tailscale:
For libvirt it was as simple as running:
sudo rpm-ostree install libvirt
For Tailscale, you need to add its sources:
# add tailscale package to the root filesystem
$ sudo ostree remote add tailscale https://pkgs.tailscale.com/stable/fedora/tailscale.repo
$ sudo rpm-ostree install tailscale
# reboot
$ sudo reboot
# now register the device into the tailnet
$ sudo systemctl enable --now tailscaled
$ sudo tailscale up
# there will be a URL displayed, use it to add the device to the tailnet.
# after you've registered it, it will automatically connect every time
# you reboot.
Taken from Andreas Happe’s blog
So far I haven’t encountered any issues layering my images, but I did notice on some videos and forums that people tend to avoid layering at all costs. I don’t know if this is Fedora Silverblue’s official suggestion or just a community thing, but I don’t think it’s good advice. Having built so many immutable systems now with Kairos, I don’t see the problem with diverging from the upstream system as long as it’s a deliberate design decision. In my example, the packages are meant to run in kernel space, so I don’t even know if there would be a way to add them without layering, so there should be no shame in doing that.
Other ways to extend the system#
As I mentioned before, there are more ways to extend the system outside these possibilities; you can lean on systemd’s system extensions, ship custom binaries, and what not. So far, I’ve used an AppImage and a binary to install Cursor’s IDE and CLI respectively. The problem with this approach is that you’re on your own, so it’s up to you or the app developer to make sure you’re getting updates with the necessary security patches. In the case of Cursor it does self-update, but that won’t be the case for all apps.
Talking about Cursor, on their website they recommend installing their rpm/deb package instead of the AppImage, so first I tried installing it within the toolbox. That resulted in Cursor complaining about the keyring and what not, so I ended up installing it with rpm-ostree, which worked well but required me to repeat the process whenever I wanted to upgrade, and that’s a bit too much for my personal taste. So I decided to test the AppImage, and it hasn’t given me any trouble during the time I’ve been using it.
Conclusion#
I’ve tried to stay objective in the previous sections. My goal with this post is not to praise or trash Fedora Silverblue, but simply to share the thoughts that come to mind. These thoughts are obviously biased by my experience and personal preference.
Traditional and immutable systems are completely different approaches to managing operating systems, and both are valid. We just happen to be more familiar with traditional systems when we talk about desktop environments. If we look at smartphones, we’d realize we’ve been using “immutable” systems for a long time already.
Immutable systems are a different beast, and some aspects of their architecture might get you scratching your head and thinking, “why do they make things so difficult? I just want to install a package.” I think that’s the wrong way to look at them, but I’m not going to lie: for mass adoption, technologies need to be as user-friendly as possible. Fedora Silverblue is doing a great job in that space and I hope they succeed. Having said that, I don’t think I have a particular need for it right now—I just happen to want to use it for learning purposes.
Let me elaborate on that a bit because I don’t want to sound unfair. My main goal in running Linux on my workstation is development. There’s nothing, IMO, that Fedora Silverblue offers me today that is crucial to get my work done; instead, I end up learning its quirks and being part of a niche community. So why am I using it? Because I want to learn more about how other immutable systems operate—for example, I’d also like to test NixOS at some point.
Is there someone I think this is a good option for? Yes. If you’re someone who does most things in the browser or within apps you can find in the Store, this is actually a great system because you don’t have to worry about the OS at all—just like you don’t care about the OS on your phone.
Also, in case you’re wondering why I try Fedora Silverblue instead of just running Kairos, there’s a good reason for that. Kairos official images are aimed at “server” use cases, like when you download the server version of Ubuntu or Fedora, not the desktop one. And sure, I could build a desktop myself, like Jacques Landru does in his Polimorphic OS abcd, which I might do at some point, but precisely because I haven’t managed such a system, I’m interested in learning how other immutable systems do it to see what I’d have to deal with.
So will I keep using Fedora Silverblue as my daily driver? Yes, but I’m not sure for how long; unless something blocks my work at Kairos—or another distro tempts me—I’ll stick with it. If you’re already using Silverblue, send any tips my way. Would you try an immutable desktop like Silverblue yourself? What’s still blocking you from putting immutable systems on your servers?
Reply by Email