[finaard]

No, updates are done by creating a snapshot of the read only mounted root, and applying the packages via the usual package manager in there. The snapshot only becomes active at reboot, and if starting fails it'll revert automatically back to the last known working snapshot for the next boot.

Things like /etc are writeable, so you don't need to reboot for simple configuration changes.

You can run it just like always with all packages installed - it's just not recommended as the additional complexity on updates increases the risk that manual intervention is needed, and tooling is good enough that for a lot of stuff you don't really need it there. Like, toolbox or distrobox as podman based containers running in the host namespace (either as user or root), allowing persistent installation of debug tools, without having to reboot.

[tommica]

Really well explained - I use fedora kinoite, and have had hard time grasping how the immutability exactly works when compared to traditional setup.

I would add to this that homebrew is a nice tool for being able to install software that are not in flatpaks and if you do not want to add too many layers to the "os-tree".

The fact that home is shared between all the distro- and toolboxes is a bit annoying, because I would like to have stronger isolation from the host in some projects.

Also doing basic polyglot stuff is a bit messy, if you have toolboxes like "node" and "php". But if you have project based boxes, then you end up with billion copies of node.

But what a pleasure it is to just update the base image and have things work, or rollback if something fails. Hell, you can even rebase the base image to some other setup, and most likely have your system work.

[finaard]

> The fact that home is shared between all the distro- and toolboxes is a bit annoying, because I would like to have stronger isolation from the host in some projects.

You can limit the access of distrobox, but it's a bit annoying, as they didn't think about isolation when designing it. Personally I'm not doing much with distrobox - I've been using LXC for ages to run some applications (like browsers) somewhat isolated, with only specific directories shared between home and the container.

Few years ago I started switching some of them to podman as that makes it easier to pre-build and share containers between systems, with a custom wrapper script to mount in resources as needed (directories, wayland socket, pulse/pipewiresocket, ...) - with my approach the opposite of distrobox: allow nothing per default, and specify resources that should be available.

So when I switched to immutable systems I had everything ready already to not have to rely on either system packages or flatpack and distrobox too much.

Overall I'm very please with the progress there - suse microos is pretty much everything we were hoping to achieve with our phone OS back at Jolla 15 years ago, but for most of the things were just not ready. We did use btrfs with snapshots to allow roll back for updates, though we didn't do a full read only root - and ran into issues with btrfs just not being stable enough at that point.

[dizhn]

Distrobox takes a home parameter if you don't want to share it.

[dizhn]

This is what I don't get. You're supposed to use flatpaks and distrobox and docker none of which are easier or better than just using the package manager. And if you do use the package manager you have to reboot for the most trivial thing. And this is the future. Maybe for an appliance but for a desktop?

[anthk]

Install Fedora Silverblue, or any subedition if you don't like Gnome. The one for Cosmic it's being polished and looks good. You basically use 'toolbox enter' for developing with Docker, Python with pip with venvs and the like and Flatpak (and Flatpak SDK's) to install the desktop software.

If you don't like Fedora's Flatpak repos you can disable these and reinstall all the software installed from FLathub, there are instructions to do so online and again once you do that you pretty much finished your desktop needs.

RPM's are just used as overlays in an emergency (maybe you need virtualization support, but you just install the libvirt services/tools once and you'll never touch rpm-ostree again). Ormaybe to try Waydroid. Again, use rpm-ostree once and forget.

Your maintenance? Upgrade the system with 'rpm-ostree upgrade' and 'flatk upate'.

This is the future, and well, Guix wants to do the same but with Guix and Guile for everything, and IMHO it's a good step over Unix. AIX with SMIT was not-so-Unix, ditto with Solaris with SMF and the like. If Unix itself diverged a lot from v7 with BSD sockets and ioctls, who cares about classical Unix.

The true Unix philosophy lies from late 90's in Plan9/9front, the C creators stated that Unix was already dead and 'rotten'. 9front does Unix better than UnixTM itself. No VT's, true 'everything it's a file everywhere' - hello 9p-, namespaces, rio being much unix-like than the X11 nightmare. No BSD crazyness to create a socket, no ioctls.

If something better gets created with FedoraOS, GNU Guix with Shepherd (plus Hurd too; non-root filesystem mounting and the like looks very liberating for the user), that good for us, the thinkerers. You get really easy rollbacks (9front too, per file, with GeFS), less tirany from package managers (flatpak can set updated desktop software with a stable kernel and with Guix everything it's pinnable, reproducible and whatnot; and from 9front, everything it's statically compiled, so you build something once, backup that file, restore it, done), and so on.