I’m sure many seasoned Linux users have heard of Fedora Silverblue. For the uninitiated, Fedora Silverblue is an immutable variant of Fedora Workstation. That means that the core operating system is the same as every other installation of Fedora Silverblue, and it is read-only. You cannot change it, no matter how hard you try.
The benefits are explained well by the Fedora Project in the Silverblue documentation: “Silverblue’s immutable design is intended to make it more stable, less prone to bugs, and easier to test and develop. Finally, Silverblue’s immutable design also makes it an excellent platform for containerized apps as well as container-based software development. In each case, apps and containers are kept separate from the host system, improving stability and reliability.” These are the many reasons why I believe Fedora Silverblue may be the future of Linux.
Fedora Silverblue Is Immutable
Immutable Operating Systems are more common than you’d think. Both of the “mainstream” *nix based OS, those being macOS and Chrome OS, are both immutable in some way. This is a great option for those users who always seem to find themselves in trouble with mutable OS breaking.
The immutable nature also promotes containerized applications. For example, Flatpaks are the primary way that applications are installed on Silverblue, and layering RPM packages over the base system is a last resort if you can’t find a Flatpak or other containerized application.
/, /usr, and everything below those are read-only (immutable), and /var is where the runtime state is stored
Atomic OS Upgrades
Atomic OS upgrades mean that unlike other Linux systems, you don’t upgrade single packages, one at a time. You upgrade the entire OS image. This is what has to happen in order for you to install non-containerized software.
You use the command rpm-ostree to install whatever RPM package you want, and that will create a new bootable root filesystem. That means that your previous bootable root file system is still intact, and you can reboot into that previous image if something is wrong.
This is a similar function to snapshotting a system using Btrfs, ZFS, or LVM, among other tools available, but with Fedora being a difficult system into which to integrate ZFS, the Grub options available with OSTree are a welcome quality-of-life improvement.
Updates are automatic in Silverblue
OSTree and rpm-ostree
OSTree is the technology that powers the composing, updating, and deployment of new bootable roots in Silverblue. You can think of it as “Git for OS binaries.” It’s a really fascinating system for managing OS binaries, and it allows for that separation of system space and user space that I’ve mentioned before.
rpm-ostree is a system that combines package management from RPM and image management from OSTree into a system that allows you to layer RPMs over the base Silverblue image. Most RPMs from Fedora are installable through rpm-ostree, and integrating RPM with OSTree helps the package manager and the image manager work with each other.
An example of the benefits of this are that the RPMs that you layer over the base image are updated and controlled separately from the base image, so you can upgrade to a different version of Firefox and reboot into the new bootable root. But if for whatever reason the image upgrade didn’t go very well, you can roll back to the previous image and still keep the newest version of Firefox. It’s a separate layer from the OS image, and rpm-ostree is one tool that manages both.
OSTree, Flatpak, and Toolbox Layering
I’ve mentioned “layers” in Silverblue throughout this article. By that, I mean that Silverblue is separated into multiple, distinct spaces that all work together to make the OS work together. The base, immutable OS image is one layer, and each RPM that you layer over that creates a new layer with the same bootable root but new RPM packages layered over top. Those are all OSTree layers.
Separate from all that, you have Flatpaks, which all layer on top of each other and are completely isolated from the OSTree layers. Finally, you have another separate layer called Toolboxes, which are essentially Fedora Workstation root filesystems layered on top of the OSTree layers wherein you can use DNF to test software and gain access to one-time use tools, such as trying out software from Copr repos, or testing software you’ve written without having to reboot into a new deployment of Silverblue. You can use different versions of Fedora Workstation, so you can take advantage of new or old features from Workstation in your testing. Toolboxes are too much to cover in this space. You can check out the following video to learn more.
Silverblue comes with spartan-few default applications…
…and most of them are Flatpaks
Why Is Silverblue the Future?
I know a lot of this seems to be aimed more at developers. However, using it as a laptop or desktop workstation OS is also a very viable option. With layering just the necessary packages, like libvirt and other KVM virtualization tools, and using Flatpaks and toolboxes to create a containerized workflow, you’re using Silverblue to much of its full potential. There’s a learning curve, but most of it will feel very familiar to users of Fedora Workstation who like Flatpaks.
Make sure to check out some of our other Fedora content, including how to upgrade to Fedora 32 and how to manage your Fedora system with Cockpit. Also, learn the difference between RHEL, CentOS, and Fedora.
Subscribe to our newsletter!
Our latest tutorials delivered straight to your inbox
Sign up for all newsletters.
By signing up, you agree to our Privacy Policy and European users agree to the data transfer policy. We will not share your data and you can unsubscribe at any time. Subscribe
John Perkins
John is a young technical professional with a passion for educating users on the best ways to use their technology. He holds technical certifications covering topics ranging from computer hardware to cybersecurity to Linux system administration.
Comments (4)