I’ve read that containers are preferred for development, but they aren’t persistent and it doesn’t seem like files such as /etc/fstab can be accessed through them when running distrobox (I enjoy editing such files using vim).
It’s also a bit annoying having to enter a specific container to run something like btop.
Are you supposed to layer them with rpm-ostree?
You’re indeed describing workflows that suit servers better. Be it “immutable”(/atomic) or not.
But, atomicity (i.e., updates either occur as a whole or simply don’t at all) have been used on our phones (source) for quite a while now. And we do all kinds of things on our phones.
Similarly, we might borrow other concepts for reliability: like e.g. making part of the root filesystem read-only at runtime. On Fedora Atomic (and its derivatives; OP’s Bluefin being one of them), this basically only applies to
/usr. This is the extent of its immutability. Most of the remaining root folder is symlinked to/var(source). Which, together with/etc, continues to be mutable. Thus, enabling it to become perfectly suitable for desktop workflows. Like, literally; there’s very little you actually can’t do on these. The main difference being how. Hence, it’s more of a paradigm shift if anything.Rant on the naming scheme
Unfortunately, the name “immutable distro” doesn’t do a great job at conveying the nuance described above. Heck, while atomic distro is definitely more descriptive, I don’t think it helps to group/categorize these distros under one name beyond contrasting it to the traditional model. Simply, because the guts of these distros tend to differ a lot compared to traditional distros. I’m afraid that this will inevitably lead to a shift in how these convos will go: Instead of peeps making all kinds of assumptions because “immutability”, they might make all kinds of assumptions based on their experiences with the popular kids; i.e. Fedora Atomic and NixOS.