There’s a lot of choice in desktop Linux these days. So many distros and so many workflows to choose from. Some light, some heavy. Some traditional, some far-out. However, for the most part they all follow a very similar path. There’s the base Linux system, systemd (though not always), Xorg/Wayland, and your package manager and accompanying packages. It’s a solid system that’s worked for a very long time.

What if I told you that there was a different way? A way that can, in fact, simplify your Linux experience through complexity. A future of immutable hosts and containerized applications.

I present to you Fedora Silverblue.

What is Silverblue?

Fedora Silverblue is a distro that accomplishes simpler management, increased security, and improved development all in one. It does this through a few avenues. First is the immutable (unchangeable) base system. Second is the promotion of Flatpak as a first-class citizen. Third is the use of pet containers to round out the edges. Using all of these methods can sound complex, but this strange complexity provides an overall simpler distro for the user.

Immutable Base

The base system of Silverblue is immutable. This means that the base system is unchangeable by any process or user on the system. This is very different from the standard Linux distro that seeks to provide access to everything for at least the root user.

Not every directory is immutable, though. /,/usr, and everything below those are read-only. There are some exceptions, though. /etc is writable so that configs can be modified. /var hosts a number of mounted and linked directories such as /var/opt, /var/usr/local, /var/home and others that need to be writable.

The immutable base brings many advantages to the table, though.

The obvious advantage: security. There is no need to be concerned about your system being modified by a rogue process, or even a careless user, if it cannot be changed by them.

The second advantage is ease of upgrade and management. These immutable base systems are provisioned as images. So, when installing the operating system and updating the new image is pulled in and committed to the system. This allows for upgrades to be done without the user even noticing. When an update is available, a notification is sent that indicates the user should restart to apply the update. Behind the scenes, a tool called rpm-ostree is pulling down a new image with the newest packages in the system. Then, when a user chooses to update and restart from the software center, they are applying the new image to the system and then reboot into the new version. This is similar to the way Chrome OS delivers updates.

When an upgrade is available to a new version of the operating system, like going from Fedora 29 to Fedora 30, the process is similar, but takes third party repositories into consideration. So it is advised to rebase on the new version with other repositories disabled (as is recommended for all upgrades regardless of distro).

Installing Packages

Well, if the system is immutable, how are you supposed to install anything on it? Well, there are a couple way to accomplish that: Flatpak and Layered Packages.

Flatpak is a packaging scheme that provides self-contained packages of applications that can be sandboxed for increased security. The technicals of Flatpak are a bit beyond this post, but they provide an entire package that contains the binaries to run as well as the libraries for the version of that software to run with. They are supported by a series of other Flatpaks that are designated as runtimes. These runtimes provide common libraries that other Flatpaks can pull from.

Installing Flatpak applications is fairly simple on Silverblue. First, you add the repo from something like Flathub (directions on the site), then you simply search for the software in the GNOME Software center. It’s simply a button click away! Because these applications are self-contained, you don’t have to worry about pieces being left behind scattered throughout your system when you remove them! They came together, they go together.

There are certain instances where a Flatpak isn’t available or isn’t appropriate for the situation. A good example of this would be the NVIDIA driver or KVM virtualization tools. For this, we have layered packages.

Using rpm-ostree we can install packages on top of our immutable base system from the repos, and third-party repos. When rpm-ostree layers a package, it recommits the base image with the packages on top of it. These packages are then updated along with the base image when updates are available.

This is not the intended way to install packages generally. It’s really designed for the times where you have to integrate the package with the system or it absolutely has to be installed into a specific directory (like Google Chrome). Flatpak is the intended avenue for installing software for Silverblue in the end and provides a cleaner and easier to manage system overall.

There is, however, one other way to get software…

Fedora Toolbox

Fedora Toolbox is a wonderful tool that was created for Silverblue to provide a pet containerized version of a standard Fedora install. These containers are created and orchestrated by a few different tools such as buildah and podmanbut the way that most people will interact with them is through the toolbox command.

Using toolbox you can create a new container of different supported versions of Fedora (and possibly CentOS). This container only has a VERY minimal system with dnf on top. It is intended that you install any development or application packages within this container yourself.

Being containers, this allows developers and users to maintain separate versions of packages and build environments from their host system. The upshot of this is you can have development versions of applications alongside your standard, stable versions. Being containers allows you to create and destroy these environments at will without worries of destroying your base system in the process.

These containers have certain resources from the host system passed through, though. Your user’s home directory, graphics stack, 3D driver stack, networking, and ALSA are all available to the container. This allows the user to test and use applications, even graphical ones, inside these containers. Having your home folder connected allows you to work with your configuration and development files that exist outside the container without having to copy them or create them as part of the build process.

So What’s the Big Deal?

This design for a distro has some complexity on the surface, certainly. For those who have never dealt with containerized worflows can be confused by the way things are put together. However, I think the complexity gives way to simplicity.

For an everyday user, this system is stable, secure, and provides a way to simply install and manage their software. Traditional Linux power users will find the lack of control over the system to be frustrating at first. However the ability to simply install your applications from Software and just launch them and use them without worrying about any of the mess that some of these apps can leave behind is not to be underestimated.

This is a system I would feel comfortable giving my parents or other family. It provides a simple and solid update mechanism, an easy-to-use software installation method, and a wide selection of tools to accomplish just about any task they might need. All of this with the peace of mind that they system isn’t completely hosed because they tried to install packages from some random source by copy-pasting some dnf code.

It’s quite possibly the most exciting distro I’ve used in a long time. The future is bright, even if the light is Silverblue.