Does Silverblue still support traditional package managers? An immutable OS seems nice and I like Bubblewrap's isolation, but I would never switch full-time to an all-Flatpak distro...
Silverblue prefers you would use flatpak and containers for apps on top, but it does support “layering” regular packages on top of the immutable core system.
I have been running Silverblue for a couple month now (after years on Debian derivatives) and I can confidently say that it is something you will either love or hate (not much room for middle ground).
If you are the kind of Linux user that treats your OS like a pet, with lots of TLC and endless tweaking to get things "just right", then Silverblue is a terrible choice. It is way more difficult and time-consuming to "hack" stuff together at the system level.
However, if you prefer to treat your core OS as livestock (something rigidly structured and reproducible automatically), then I highly recommend giving Silverblue a try!
As a software developer, I run a lot of random software/dependencies/etc and I have historically struggled with my Linux system stability degrading over time as I add/remove packages and config. My goal with Silverblue is to have a solid base OS that does not suffer from package-drift over time. On top of Silverblue, I use distrobox to run many of my apps/bins in a virtual container. That container is where I do all my "hacking" to get things to work and I consider the container to be expendable. If I start having issues with it working correctly, I can just blow away that container and rebuild it without effective my core system, other containers, or the flatpak apps.
A small correction: Fedora Silverblue & co is highly Flatpak based, and the VanillaOS 'package manager' is Distrobox under the hood, which is a project for running full linux distros inside podman containers intended for desktop users.
Silverblue is pretty incredible, but after a month of using it (Fedora 29) I did hit the occasional RPM I couldn't install because OSTree didn't support layering packages to that directory. It's also weird about third-party repos. I also wish more software was available as a Flatpak - unfortunately Ubuntu's mindshare means more developers are aware of the proprietary Snap format.
I'm super excited about it though and will keep using it every month, it finally solves the dependency problem most distributions run into.
Silverblue is pretty great. But it's really been taken to another level in the last few months since it started allowing you to _boot_ from a container image. That means, you can have some automated container build somewhere that you point rpm-ostree too which gets automatically pulled down to all your machines. It's like building your own distro, but without any of the work. Here's mine, for example:
And then, of course, I _also_ have an automated Arch build that I use with Distrobox on top of my custom Silverblue build. I get the stability of an immutable OS layer with the easy installs and package availability of Arch.
So far, I hate Silverblue the least; although I wish Kinoite were as good so I could have a KDE desktop instead[0]. The combination of immutable base with Flatpak and Toolbox allow me to do pretty much everything I want to do, even if the GUI management tools could still be miles better (where the exist at all).
[0] I mean without adding KDE on top of the GNOME-centric base image.
silverblue effectively gives you the ability to have the benefits of a rolling distro and the benefits of a distro that does releases (stability focused).
They are very different, but lead to some of the same benefits. Silverblue largely follows the same system layout as traditional distributions (FHS, with packages in a global namespace). But compared to traditional distributions, it replaces the package manager with snapshots in a git-like store (OSTree). The system is immutable and provides atomic updates/rollbacks, like NixOS. They offer an mechanism on top of OSTree (rpm-ostree) to layer traditional RPMs from Yum/DNF repositories. To keep the base system lean and immutable, they encourage installing desktop applications through Flatpak and doing development through traditional, mutable containers through podman/toolbox.
Silverblue is a bit strange in that it is in two worlds: on the one hand it touts the benefits of immutable systems, on the other hand it acknowledges that in their own setup, development is only really comfortable by also providing mutable systems through containers.
NixOS is far less compromising than Silverblue. It chooses one model, functional package management, and that's the way of the highway (no FHS, immutable store, all packages live in their own directories in /nix/store). There are some small escape hatches like buildFHSUserEnv, but no major compromise as Silverblue has. Nix shares some benefits like atomic updates/rollbacks and an immutable system. But provides many others that Silverblue's model cannot easily provide (or has as the answer 'spin up another container'), such as permitting several different versions of packages in parallel, virtual environments (but for any package), etc.
I think both approaches are very promising and not one is necessarily better than the other. Nix/NixOS' approach is more consistent and more powerful. However, Silverblue's pragmatic use and strong integration of containers, makes it much more familiar for most people. Also, much more software works out-of-the-box as a result.
- Pushes the use of containers for apps, /usr is read-only (mostly). in most cases Flatpak and Podman/Docker/Distrobox/Toolbox
- Makes reproducible builds, your /usr is the base fedora image + whatever you have explicitly configured to add, the latter part makes it very easy to customise the base OS and undo changes (which are tracked), or share changes with others.
- Updates are atomic, you pull the power cord during an update? no bueno will just boot the old deployment. Additionally, because the system is always in a known and immutable state, updates should always work without any kind of dependency/package issue, your swapping one /usr for another.
- Makes malware harder as /usr is read only and you can use composefs to make sure content isn't changed, not really that secure though given any malware can just infect the initramfs
I hadn’t considered this. It makes me glad I keep as much as possible within my shell and browser.
In its current state I would recommend Silverblue to two classes of users:
1. Highly technical with a strong background in immutable systems and containerization.
2. Non-technical users whose app needs are completely fulfilled by Flathub.
The latter may require some assistance with initial setup, but if I needed to help a friend or family member maintain their computer then Silverblue would be my first choice.
As an interesting alternative, Fedora Silverblue is another experiment with immutable OSes for the masses. Haven't played with it myself, but heard good things. The DevEx might not be a solved problem with it though - chaining multiple dev tools with Flatpaks might not provide quite the same experience as having an entire isolated LXD container, as in Chrome OS.
Also, it's too bad Nvidia remains a second-class citizen, even on Chrome OS.
I’ve been running debian distros exclusively for the past few years. A few weeks back I attempted a reinstall, but I was blocked by a combo of nonfree firmware (that was incompatible w/kernel in stable) and partitioning/bootloader issues in testing.
After a few failed attempts at pre-partitioning in stable, then installing from testing, I gave up and tried Silverblue. Gotta admit, the lack of driver issues out of the box was refreshing!
Like any immutable distro, Silverblue has it’s quirks, but hardware support hasn’t been one of them in my recent experience.
That's why using immutable distros is awesome. Worst case scenario, you can boot the previous version.
I've been using Fedora Silverblue for a while and never got a borked upgrade. It's not without its own flaws, but if you can live with mostly flatpak apps, it's a pretty compelling package.
I stopped distro-hopping a few years ago after landing on Silverblue a few years ago (back when it was still called Fedora Atomic Workstation). While it doesn't satisfy all use cases, I view it as a boring (in a good way) 80-percent solution that normally just works.
Not quite. Silverblue is based around flatpak's (containers) and composing your OS from a set of containers.
NixOs is based on Nix, which doesn't use containers but links binaries against specific versions of dynamic libraries to resolve dependency issues and allow for reliable installations.
reply