Fedora Silverblue #1: What is Silverblue?

I recently realized that it’s been almost exactly 2 years since I started using Fedora SIlverblue, which I’ve written a bit about. So I thought I’d make a short series on Silverblue to mark this 2-year anniversary and go through the various aspects of this system, which is a bit different from the usual distributions.

In the first part of the series, I’ll mainly go over the basic concepts and explain how Silverblue is so different from both classic Fedora and most other Linux distributions you’ve worked with so far. In future episodes, I’ll cover a particular feature each time, like the toolbox or various Kionite spins.
Silverblue: a virtually indestructible OS

Silverblue, as you can read in a number of articles, is something called a “next-gen OS”. What does that mean? That it changes the established conventions of conventional operating systems and takes the whole industry forward again. In the case of Silverblue, the goal was quite simple: to create a system that would be secure both from the point of view of external threats (viruses, “bad” applications) and from the point of view of the user – simply put, it would be really hard to break the system.

Silverblue achieved this by building the entire system on something called OSTree. OSTree is an upgrade system for Linux that treats the system much like a git repository. Single updates are equivalent to commits, and new versions of the system correspond to new branches. As in git, we can move around different commits or switch to a different branch. The main advantage then is that if the system breaks after an update, reverting to the previous state is actually very simple.

The breakage is even more complicated because most of the system is “read-only” – the user cannot change any files. The only exception is the /var directory. Even the /home directory is just a symlink to /var/home. So the system is really robust and breaking it is quite hard (but not impossible – tried it for you :)).

However, the problem arises if we would like to install an application using the classic dnf packaging system. The first problem is that you won’t find any dnf in Silverblue and instead there is a CLI utility rpm-ostree. However, installing the rpm package means that you need to create a new commit of your system and reboot the whole system to boot into this new commit. Not to mention that conflicts can occur when updating from “upstream”.

So how to install applications?

Flatpak: a new way to distribute applications

The first (and preferred) option is to use a new package system – flatpak. Since this will be the subject of an entire one-part series, I will only describe its basic features here.

Flatpak is named after the flat boxes used by IKEA. The idea behind these boxes is that the customer can assemble furniture using only what is in the box. And flatpaks are very similar to that. Traditional flatpak systems work on the basis that they are linked by a network of dependencies. This can lead to all sorts of problems, like when you need to have two packages in different versions in the system. Flatpak solves this elegantly.

All dependencies are notionally divided into two groups. In the first group are commonly used packages that need a large number of applications while not being present on the host system. From this group, a runtime environment is created, and the dependencies from this environment will be available to all flatpaks. The second group contains dependencies that are specific to each application – older (or newer) versions of libraries or packages that are used by a limited number of applications. Such packages are then packaged into a single package with the application – thus creating the flatpak itself.

Flatpak architecture

Thanks to this architecture, flatpak can then run anywhere the runtime itself can be installed, regardless of the operating system.

Another feature that makes flatpak so special is permission management. This simply means that, by default, the application cannot do anything; it cannot display on the screen, play sound, or connect to the Internet. All of these permissions are explicitly granted to it, and it performs activities through so-called portals. This means that the user can know exactly what each app needs to function, and it also makes it harder for people who might want to get a rogue app on your system.

Toolbox: when flatpaks aren’t enough…

Well, but what to do if my application is not in flatpak, or it’s an unusable solution for my purpose – for example, when I need to change the system, develop a specific application, etc.? In such a case toolbox comes into the picture – a great CLI utility built on top of the podman containerization tool.

Two commands take you to a container that is indistinguishable at first (and several other) glance from a normal Fedora Workastation – albeit in text mode only. Inside the toolbox you have your favourite dnf, you can install rpm packages and even break the whole toolbox container if you want. However, your host system will remain intact (at worst you will lose data from /home, since this directory is attached to the container).

The ideal use case for a toolbox is if you are a programmer developing an application – even if the container itself doesn’t have a GUI, graphical applications will (mostly) run.


So what have we learned? That there is Fedora Silverblue, a nearly unbreakable operating system that behaves much like a git repository. We can install applications using flatpak, which takes away the worry of dependencies and lets us know what an application can and can’t do thanks to the permissions overview. And if we need Fedora Workstation (for example, in development), we have a powerful toolbox that gives us a container virtually indistinguishable from Fedora Workstation in the CLI. And that’s it for today’s episode.

At the very end, I add a complete list of useful links:

Translated with www.DeepL.com/Translator (free version)

Leave a Reply

Your email address will not be published. Required fields are marked *