So I took the plunge and installed Fedora Silverblue because of all that immutable buzz. And it’s the most frustrating change I have made in almost 20 years of my distrohopping.
After installing Silverblue I configured it as usual. I installed necessary flatpaks, played with toolbox and distrobox, installed codecs, configured my bluetooth keyboard and other stuff in /etc and /var. Applied some useful tweaks I found on the web and… well… everything works. Nothing to do anymore. No issues. Nothing breaks, no dependency hell, everything runs smooth. I have nothing to tweak, tinker or configure anymore. So frustrating.
Every update is just… meh. Smooth, new, fresh system not affected by my stupid tweaking and breaking. Booooring.
I don’t have to distrohop anymore. If I want other distros I can just install them in distrobox. Other versions of apps? Something from AUR perhaps…? No problem. What’s the point of distrohopping now? Other DEs? I just rebase my system to other images with almost any DE or WM I want without losing data or messing everything up (damn you, UBlue!).
I don’t even have to reinstall the damn thing cause every time I update the system or rebase it to another image it’s like reinstalling it.
Silverblue killed distrohopping for me. Really frustrating.
What is silver blue, and how does it differ from vanilla Fedora?
It’s an immutable/atomic version of Fedora: https://fedoraproject.org/atomic-desktops/silverblue/
My understanding is that the core system is immutable (read-only) and major upgrades essentially just swap out that whole layer. Updates are atomic, meaning the entire thing either succeeds or fails and you can never end up with a broken half-updated system. UI apps all run using Flatpak.
I’ve never tried it though!
Ew Flatpak. Feels like an OS inside an OS. And it also feels bloated. Like almost one GB just to install an emulator.
The quoted storage figures for Flatpaks are misleading. They don’t use that much. I have 50+ Flatpaks installed and they use barely more than 2.4GB.
And Flatpaks are great. There’s nothing to ew at.
Are you sure they are using 2.4 GiB? because that’s nowhere near what I’ve gotten: https://imgur.com/MjExYMB (notice flatpak-dedup-checker is being used)
EDIT:
https://github.com/flatpak/flatpak/issues/994
https://github.com/flatpak/flatpak/issues/1651
https://github.com/flatpak/flatpak/issues/46
https://github.com/flatpak/flatpak.github.io/issues/191
Their numbers sound questionable, but if you weren’t pulling in KDE yours would be significantly lower too.
The whole plasma DE meta package on arch is 1.1 GiB. It will be lower indeed but I don’t think it is that significant? (Unless flatpak has a surprise here lol)
edit: iirc the app that really blew the overall size in that screenshot was libreoffice btw.
you want your application to work everywhere, that’s why flatpak is needed, no one complains about nix, when they have the same principle, flatpak is just more distro-agnostic and with a more powerful sandbox
It’s actually more than it, you can get to the point of having something like several different OS inside the OS because it might start having several different versions of big dependencies like mesa.
It’s an “immutable” Fedora, that is, the system comes as a read only image, kind of like how android works. Anything you do is “layered” on top of that image. This means you have to actually try to break it, because you can undo anything you did to break it by simply not booting with the extra layer(s).
You’re encouraged to install in userspace flatpaks instead of system-wide rpms where possible, as system-wide rpms means adding a layer on top if the image as it is.
Oh I thought Fedora itself was immutable
the default fedora installation isn’t, but fedora atomic is
It’s immutable (aka. atomic), which means the system files cannot be changed, even by root. System updates come as complete system snapshots of the core filesystem, and everything else exists in containers or filesystem overlays (user directory is still writeable). Containers and the user’s home directory are unaffected by the updates, so the update process is typically much safer overall.
If an update does break something, you can easily do
rpm-ostree rollback
, and everything will be working again. On top of that, you can swap between versions with a simplerebase
command (e.g. swap between Silverblue and Kinoite, Kinoite and Bazzite).This is a definite “well um actually” moment, but technically immutability can be switched off at any time with
chattr
, and “true” immutability will not be achieved until full image signing is commonplace. You can see the ideas laid out here: https://github.com/ostreedev/ostree/issues/2867It does let you do cool things though, like install nix: https://github.com/dnkmmr69420/nix-installer-scripts/blob/main/installer-scripts/silverblue-nix-installer.sh
don’t use that use this https://github.com/DeterminateSystems/nix-installer
up-to-date, full support silverblue, don’t need to unlock the filesystem, full support for selinux too, they create the /etc/nix forlder and mount it on /nix
Yeah, I was just linking the other one because its usage of temporarily disabling immutability is more apparent. That one also disables immutability temporarily to install nix.