I was on Fedora workstation before switching to Silverblue and they’re both quite solid, to be fair. The big feature that differentiates Silverblue is immutability–you can’t easily make changes to the base system.
Now, to some people I think that’s going to sound awful, but it has its pros and cons. The biggest benefit being that your base system is solid (and not just solid as in unlikely to break, but literally unchanging over time). Updating your system is effectively replacing it with a different system entirely (delta compressed, so it’s not too inefficient, if I understand correctly), and you can rollback/revert/swap between systems on the fly, in the unlikely event that an update makes something worse, though I haven’t needed to. You can even rebase your Silverblue (Gnome) system into a Kinoite (KDE Plasma) system, pin both “commits” and swap between them. I haven’t tried that though, since I’m pretty happy with the Gnome workflow. Long story short, immutable distros like Silverblue are basically as solid as solid can be.
There are two drawbacks that I can think of, and then a couple of minor nitpicks. The biggest being that you need to restart your system after making changes or installing packages. You don’t need to restart between each package install or anything, but any system-level changes that you make won’t take effect until you restart. The second drawback is that layering packages is not always ideal and working inside docker/podman containers (often via toolbx/distrobox) is the best way to do some tasks. For example, if you’re a programmer and need to install a lot of dependencies to build some program, I find it’s best to create a “pet container” to work in. That doesn’t both me much though, in fact I kind of like that workflow.
So basically, it’s probably not for everyone, especially people who really love to tinker and customizes everything. But if you want a basically unbreakable Linux machine, it’s worth looking into.
Thanks much for the detailed reply. It’s obviously not for me since I do a lot of tinkering and I’m used to the traditional system. But it definitely should be suitable for some scenarios. Scools and kiosks come to mind.
The base os is immutable, but you can still change configuration files, compile and install local software (but not in the immutable directories), install desktop environment extensions, add custom repositories, etc. You can also layer packages, but most graphical software is best installed as flatpaks (but not mandatory). So it depends on what tinkering means for you. If it means messing around with binaries in the default locations, like /usr/bin, then it’s not for you, but for many other things there is a way, it’s just a matter of getting used to the separation between the immutable base layer and the things that you build around and on top of it.
I was on Fedora workstation before switching to Silverblue and they’re both quite solid, to be fair. The big feature that differentiates Silverblue is immutability–you can’t easily make changes to the base system.
Now, to some people I think that’s going to sound awful, but it has its pros and cons. The biggest benefit being that your base system is solid (and not just solid as in unlikely to break, but literally unchanging over time). Updating your system is effectively replacing it with a different system entirely (delta compressed, so it’s not too inefficient, if I understand correctly), and you can rollback/revert/swap between systems on the fly, in the unlikely event that an update makes something worse, though I haven’t needed to. You can even rebase your Silverblue (Gnome) system into a Kinoite (KDE Plasma) system, pin both “commits” and swap between them. I haven’t tried that though, since I’m pretty happy with the Gnome workflow. Long story short, immutable distros like Silverblue are basically as solid as solid can be.
There are two drawbacks that I can think of, and then a couple of minor nitpicks. The biggest being that you need to restart your system after making changes or installing packages. You don’t need to restart between each package install or anything, but any system-level changes that you make won’t take effect until you restart. The second drawback is that layering packages is not always ideal and working inside docker/podman containers (often via toolbx/distrobox) is the best way to do some tasks. For example, if you’re a programmer and need to install a lot of dependencies to build some program, I find it’s best to create a “pet container” to work in. That doesn’t both me much though, in fact I kind of like that workflow.
So basically, it’s probably not for everyone, especially people who really love to tinker and customizes everything. But if you want a basically unbreakable Linux machine, it’s worth looking into.
Thanks much for the detailed reply. It’s obviously not for me since I do a lot of tinkering and I’m used to the traditional system. But it definitely should be suitable for some scenarios. Scools and kiosks come to mind.
The base os is immutable, but you can still change configuration files, compile and install local software (but not in the immutable directories), install desktop environment extensions, add custom repositories, etc. You can also layer packages, but most graphical software is best installed as flatpaks (but not mandatory). So it depends on what tinkering means for you. If it means messing around with binaries in the default locations, like /usr/bin, then it’s not for you, but for many other things there is a way, it’s just a matter of getting used to the separation between the immutable base layer and the things that you build around and on top of it.