As a Debian user for more than two decades it's hard for me to admit, but I've actually switched to Fedora Silverblue in the last few months for my laptops.
The appeal of Silverblue is that it's an immutable operating system. Similar to how programming in a functional style with immutable data structures can avoid bugs, an immutable OS can avoid configuration mistakes and breaking your system in irreversible ways.
Before Silverblue, other distros like NixOS have already experimented with declarative and functional OS configuration. With NixOS, you essentially write a functional program that describes the state of your Linux distro (the installed packages, the configuration of daemons, and so on), and it evaluates to a working install. Updating the configuration and rebuilding creates a new revision, and you can revert to previous versions if there's a problem.
However, this still requires a non-trivial amount of both initial and on-going configuration work to keep the OS working. It's expected, for example, that you may need to update the configuration to add more packages or revise how some system services work.
In contrast, Silverblue goes further and makes the core OS immutable. The first
time you boot it after install, it has all the packages that you need for a working
desktop and all the packages that the core OS will ever have (until a new
version of Silverblue comes out). In fact, the
/usr directory is mounted as
Of course, you probably can't get away without installing any new software. For that purpose, Silverblue provides two options:
- You can install any software that is packaged as a flatpak. This means it's installed in userspace and is sandboxed to some degree as well. Flatpaks that you install can't break the OS itself.
- You can install any software using containerization. Silverblue comes with
toolboxby default that provides a simple UI for containers.
To some degree, the use of containers does resurface the issue that you might break your OS. Instead of breaking Silverblue itself, you can break the container. In that situation, however, you can just delete the container and try again while the desktop running it will be unharmed.