I’ve looked at a lot of other immutable distros and I might just end up using one of those, but I feel like taking on a bit of a challenge and there’s a few things I’m not very keen on with existing solutions (last paragraph is my idea if you want to skip the context).
Most immutable systems I’ve seen require a reboot in order to apply system changes. What is this, Windows? Yeah, reboots are quick but restoring my windows and getting back into my groove is not quick. Also, every immutable OS I’ve seen wants you to opt-in to a rollback. Rarely do I see the full effects of installing a package or altering a config immediately. By the time I notice an issue maybe it’s too late to rollback to before the change or maybe I’ve done a few other things since and I don’t want to rollback everything. I would much prefer to make “rolling forward” or persisting changes to be a very conscious process.
I started messing with BTRFS and I think I’ve come up with a process that will get me what I want, no matter the distro. Please poke holes in my idea. So I think I can use BTRFS to hold data for the rootfs in three different subvolumes (at minimum): root-A, root-B, root-Z. root-Z is my golden image and it represents what I want root to look like after reboot. root-A and root-B are the active and passive instances of rootfs, but which one is active will flip-flop after every reboot. So if I boot with A, B gets replaced with the contents of Z. In the meantime I can do whatever I want with A. Not sure how I’ll update Z (chroot or “promote” the active subvol to be Z) but without an update every reboot is an automatic rollback.
Thoughts?
My semi-immutable OS is based around a Debian installation where every application is installed in a separate Docker container.
When you launch the application, it volume mounts an appropriate directory that contains only the data related to that application.
Chrome for example launches with a single subdirectory inside ~/Downloads, so each instance can only see its own directory.
I can also test compilation of random repositories inside a container, without affecting the underlying OS.
The OS itself has only got a minimal Debian and Docker installed.
Been using it for several years. I can’t recall when I last rebooted it.
That sounds… strange? I think Flatpak is way more resource efficient, as separate docker containers will not share a single library.
But yes, I manage some Debian workstations and the first thing I did after manually updating them to Debian 12 was
So, basically Rancher?
now I have to look up rancher. sounded like qubeos to me.
From Suse. It looks like V1 and V2 are maintenance only these days.
https://github.com/rancher/os
Looking at the rancher GitHub it looks like they can’t decide which direction they want to go.