Longtime Debian and Arch veteran here. I moved most of my workstations to Silverblue earlier this year (maybe 8 months ago now), and I’ve been very happy overall.

There is a bit of a learning curve if you aren’t familiar with Flatpak or container-based workflows, assuming you wish to embrace those elements, but the curve is nowhere near as steep or unconventional as NixOS.

I love the automated updates. The flexibility to rebase or rollback the core OS on the fly, without any extra work, is great too. For example, it’s very easy to test out beta releases, remixes, and preconfigured software bundles like uBlue.

I still use Arch for 99% of my command line tasks, inside a container managed by distrobox.

I strongly believe that Flatpak is the future of Linux software deployment, and although the format still has its kinks, it is already quite mature and will only get better as more and more upstream developers adopts its use.

Am I going off the deep end by considering Fedora Silverblue or Kinoite?

I started my Linux journey on Kinoite, which unfortunately had some issues at the time of installing; after which I rebased to Silverblue, I have since ‘mained’ Silverblue while experimenting with a couple of other distros through dual-boot or on spare devices. The first two weeks were really hard as I literally knew nothing about Linux. The fact that documentation is -generally speaking- lacking doesn’t help either. But if I was able to surpass that initial barrier, then I’m sure you can too.

But, motivation is important! Why do you even consider an ‘immutable’ distro?

I don’t really understand what new I would need to learn

You’d have to replace sudo dnf install *package-name* with flatpak install *package-name*. If, however, the package is not available as a flatpak, then -following Fedora’s initial guidelines- one should install it within a container through Toolbx(/Distrobox). After a container has been created (toolbox create *pick name for container*) and entered (toolbox enter *chosen name for container*), one simply behaves within the container as though how they would in a traditional distro. As a last resort -in case installing within a container is not possible, well supported or doesn’t work as intended- one can layer it (rpm-ostree install *package-name*).

Furthermore, /usr can’t be touched (at least not easily), except for /usr/local. And some features, like UKI, aren’t supported yet.

or really what benefits it would have.

• Updates are atomic; it either happens or doesn’t, there’s no in-between state. Even a power outage or a random crash doesn’t change that. This ensures your system isn’t broken if something unfortunate befalls it.

• Additionally, the system (for the most part) is reproducible; I can rebuild my system from scratch (barring configs; unless your dotfiles management is sublime) and it is exactly the same as the one that has been running since the inception of Silverblue. Cruft, state, bitrot etc can finally be left behind…, but we’re not their yet. There’s still some amount of these present in Silverblue’s current model. But we’re embracing OCIs and Silverblue’s primary contributors know what’s up over at NixOS and (hopefully) are working to make Silverblue ever so slightly more stateless. Even if a lot of work is still required, it’s infinitely better than the traditional model as it has gone from an uncountable amount of possible states to a countable amount. And the mathematicians under us know that such an improvement is infinitely times better. Another benefit of where we are currently with reproducibility would be that it allows us to combat bugs effectively.

• Security benefits due to more parts of the system being read-only. This is however (somewhat) offset due to lack of the aforementioned UKI support. Hopefully, the well-defined nature of an image-based distro will eventually make more robust system-integrity checks possible.

• Not necessarily exclusively granted through/by ‘immutability’, but system maintenance has been a joy. Most of the time, it just works anyways. But, if somehow something breaks, then I can easily rollback; either through the terminal if I was able to get inside. Or through the GRUB-menu if the ‘broken’ deployment doesn’t allow me to get inside. Furthermore, you can even pin a confirmed working deployment through sudo ostree admin pin *number* to select the deployment to keep around for longer. I recommend everyone to keep around their first deployment after installing Silverblue, if used wisely it’s one of the closest things to a factory reset we’ve got within the Linux space.

Arguably there’s a lot more to talk about, but these are probably the primary benefits.

Immutability is useful from a sysadmin standpoint because it solves a couple problems. It’s a little easier to secure a system if you can know that, in fact, files outside the home directory have not been modified, and also, it’s a little easier to keep systems running because programs can’t just shit on each other’s files etc.

Unless these two are problems for you, you’re signing up to re-learn how to use Linux, and tbh not very elegantly, for basically no real gains at this time. Immutability has potential as a concept, but Red Hat’s approach is super weird and not very efficient. They have a tool that allows you to manage filesystem trees, and then they extended this tool with RPM to allow you to compose custom filesystem trees at install/upgrade time. This approach, in my experience, is shockingly inefficient if you need to add any custom packages to your base tree and you install updates with any frequency.

If you’re a sysadmin rolling out updates to workstations maybe once a month, these aren’t really issues, but for daily use, it didn’t seem worth it to me just yet, especially since we don’t really have any neat separation of code and config like you get with Docker. You can’t just zip up your home directory and move it to a new Silverblue installation and have your user back yet (there’s work in this direction with systemd-homed, likely once it’s good enough this will become standard, but also, that’s not an “immutability” feature). I believe /etc is mounted rw, which is a step in this direction, but until lots of stateful stuff gets moved out of /etc that isn’t going to be portable in the same way a Docker config is.

EDIT For a comparison of a different approach to immutability that includes a different bundle of tradeoffs, you can also look at OpenSUSE’s MicroOS. The TL;DR is that it’s easier to customize the base system, but it locks you into btrfs and it’s not as robust overall – https://www.ypsidanger.com/comparing-opensuse-microos-to-fedora-silverblue-37/ https://discussion.fedoraproject.org/t/understanding-differences-between-rpm-ostree-and-opensuses-transactional-update/84289/3

If it’s fun, it’s not overkill!

You also have experience you can use in the workplace (even if it’s mostly experience of what happens if you f**k things up).

Have you checked out OpenSUSE MicroOS at all? It’s similar to Silverblue. Runs great on my Framework 13 with Intel 13th Gen.

I wouldn’t be too concerned with “officially” supported Linux on the Framework. It is a very Linux friendly machine. The folks they have supporting Linux are active in the Framework forums and very helpful.

I eventually went back to my tried and true Debain. I loved the immutable OS thing for all the reasons people have listed here. My one issue was direct access to external devices can be a pain. IE: I just could not get USB passthrough working with virt-viewer after all my fiddiling.

If Fedora runs fine, I see no reason why openSUSE wouldn’t. Friends of mine use regular Manjaro with the same Framework. Just keep using openSUSE if that’s what you feel most comfortable with.

I used Silverblue for a bit but got very annoyed by its rpm-ostree command. I think it’s too complicated for a simple single user setup.

Yes.

If you wanna switch to Silverblue, i would highly recommend the universal blue images, they have a whole bunch of different DE version, specialized versions for example: bazzite for gaming, and they also have framework specific images for most of them.

with ublue i dont have to layer a single package over my basic image (silverblue-nvidia).

All the apps are installed as Flatpak, except the ones that dont have one run on Distroboxes (distrobox is included in ublue images and highly recommended over the default toolbox in silverblue)

https://universal-blue.org/

I like Kinoite, have been happy for a year or so (how time flies). Pretty bulletproof, automatic updates and rollbacks, lotsa good stuff. One minor but relevant gotcha is it doesn’t like docker particularly much, I found the path of least resistance was to move to podman (which is more secure, can be easily turned into (–user) system.d units and has a cool auto update feature), podman-compose is your friend…

Tried it before, but went back to normal version. I recall it being slightly limited in package availability and some apps requiring extra fiddling.

Maybe it’ll be fine for your use case, though.