I've recently moved my laptop over to openSUSE MicroOS (specifically Kalpa, the KDE variant). It shares a bit of philosophy with Vanilla OS. However, in many ways it's almost unrecognizable as a Linux/Unix system.
The way it works (in my incomplete understanding) is that the root filesystem (running on Btfrs), specifically /usr and /var, are actually a read-only image. You can write changes to it, but each time you do, you have to rewrite the image. Each time you boot, you boot that immutable image.
This allows for easy automatic updates. And if it fails to boot after an update, it merely rolls back to the previous working image (crowdstrike take note). This seems to work well provided you don't have to modify the image too much. I installed fprintd, kdeconnect, and wine, and it's still doing OK.
The user applications are almost all Flatpaks. This works well most of the time, but not always. I was a heavy flatpak user before, and I will say that a number of Flatpsk bugs I've run into on other systems, I've not had on Kalpa, so perhaps its Flatpak implementation is better. The biggest issues I have are Flatpaks not being able to communicate with each other as easily as native binaries can.
If you don't have a Flatpak, you can always try to run it in DistroBox. This works..... OK....provided it's a userspace app. But if it's a userspace app, why not run the binary directly? Where distrobox really shines is for running .debs or .rpms on a non-native system. But those are gradually going away thanks to Flatpak anyways. Distrobox does have a fake root mode. I consistently run into boubdary issues with it on Kalpa. I was able to run software in distrobox that required root, and it technically ran, but it couldn't use any audio devices.
Overall, I find Kalpa (and MicroOS) very interesting. There are still edge cases where they break, but I was easily able to work around everything.
I have also a laptop on silverblue, which is the immutable version of fedora. Most of the time usage is identical but once in a while you encounter an edge case that is easily solved on regular fedora workstation where you have to find extra weird workarounds to simple stuff.
Also while flatpak applications are usually sandboxed, they very often need access to your files to be useful. You are either limited to a small subset of flatpaks on fedora flatpak repo, or the whole uncurated flathub shithole where quality and security is totally random.
Also running a flatpak from the command line using `flatpak run tld.organizationname.appname` is a bit annoying. Toolbox, distrobox and containers solve some of the stuff but are also clunky way to do stuff that you would just do normally on a regular linux system.
All in all I will keep it on one of my laptops as I am curious about how it will evolve in the future and it is a decent OS for non tech / family use where your typical usage is to open a browser and a handful of gui apps so I can easily lend it to my kids and partner without worry.
Fedora Kinoite (like Silverblue, but with KDE in place of Gnome) user here. I agree with most of your points, though I've actually grown to appreciate the Distrobox/Flatpak workflow once I grew accustomed to them, to the point where I have no interest in returning to a traditional distro.
I've even started using Fedora CoreOS VMs as the basis for containerized service installs on my home network (Pihole, etc.).
To be fair, I do have quite a few packages layered on top of the base distro, as well. From memory: many admin tools that require "real" root, KVM virtualization support, RPM Fusion packages to enable hardware video decode, Mullvad's VPN client, tmux, vim-default-editor, a few font packages, Emacs, and a few basic development tools like cmake and make for the benefit of Emacs package installs.
The only problem I've ever had with layering is that once in a while I have to wait a bit and retry an update because newer package versions from the base image haven't yet made it out to the main RPM mirrors.
Oh, and Flatpak automatically symlinks "flatpak run" wrapper scripts to /var/lib/flatpak/exports/bin, so, assuming ~/.local/bin is in your PATH,
I use a docker image as my whole development environment and the experience is similar. I can do whatever I want inside the container, and all will gone after I restart it. For the changes I like it, I edit the dockerfile and build a new image. When I get a new machine, I just install docker and pull the image and start coding.
Also found MicroOS interesting. At first I felt limited but more and more I started to like the flow of doing things and being more pragmatic about my system.
In the end though, some of the cons of such a system started being too much and I went back to Leap. It was close to winning over me however.
> The way it works (in my incomplete understanding) is that the root filesystem (running on Btfrs), specifically /usr and /var, are actually a read-only image. You can write changes to it, but each time you do, you have to rewrite the image. Each time you boot, you boot that immutable image.
Sounds like a glorified LiveCD distro. (In fact, it's almost exactly a LiveCD with 'persistence' once you account for other parts of the filesystem that are not 'immutable', such as /home/ .) Not sure what's supposed to be so innovative about this.
For firefox I've found it extremely annoying. When the snap updated in the background:
1. Pinning the desktop icon to the toolbar is annoying ... the desktop file is in a snap folder that keeps changing, so would disappear.
2. It showed the "you need to restart firefox in X days" notification frequently; I wasn't able to find a way to stop it reshowing the notification after dismissing it.
3. Updates caused firefox to crash if the underlying snap folder gets removed.
4. Keeping profile information across the snaps is not easy; I've had updates reset the profiles to the base.
For IntelliJ IDE I've not had issues thus far. I'm not sure if this is because it hasn't been updated enough to encounter the above issues.
IMHO for personal workstations immutable distros are a solution in search of a problem.
In 3 years using Fedora (which hasn't a reputation for being a stable distro) I once had a bad kernel that prevented my Framework laptop from booting (solved by blacklisting said kernel). All my other Fedora machines were fine.
Why would I need an immutable distro if even Fedora is stable enough? Heck i could use Debian or a RHEL clone and never have to worry about stability.
Nothing is new under the sun. Reminds me of the good ol' CoreOS (the original, not the fedora-flavored, although it also applies), Container-Optimized OS from GCP and the likes of the new wave with Talos and Bottlerocket.
My only wish is that immutable filesystem, read-only rootfs and most of the system with just a FEW exceptions, atomic upgrades/rollbacks would be more and more widely encouraged, discussed and adopted.
Just eliminating the worry of root partition running out of space is a life changer. From the ground up any "traditional" linux distro will force you sit and design how to partition the disk sooner or later. The guys above address this issue (and a huge bunch of others) for you.
I’ve made a /data partition for many years now taking the majority of the disk. Root then has not needed more than thirty GB or so. (With kernels in the efi system partition, and home in data even less. I used to make it 32gb.)
Interesting. Anyone familiar with it? I'm curious if it's container per application, or container per distro supported. Having never run a system like this, how do you manage files? If I have samba from Debian and nginx from Arch, how does one edit their respective configs and such?
Not vanillaos, but bluefin/silverblue. You can manage many user level programs via toolbox or distrobox in a similiar way as a regular distro, but the packages are installed in your $HOME. You can still use regular containers as well too. Although you can still add extra system level stuff if you desire via layering (or soon via systemd sysext)
Ive read the source code of apx (the package manager) and its basically just a distrobox wrapper. From what I understand, It creates a container for each distribution and packages are installed in that container.
Filesystem is automatically mounted to the container. I believe this one use LXC through distrobox, Fedora silverblue does the same with toolbox which used podman.
If you want to give it a try you can install distrobox or toolbox right now on any distro, this is not unique to immutable readonly distros. This allows you to separate system / userland package management and have access to say, pacman on a fedora for example.
Not much familiar with it, but familiar with the concept: it's a fail.
If you want a comfy modern system goes for NixOS/Guix System on top of zfs. Safety came from design, not from isolation. Comfort came from autonomous power not quickly import third parties blob and so on. Such distros are like btrfs vs zfs. A tentative to denied the fact a model needed by some actors is total crap.
For me it's exactly the opposite: I like numbered versions and I hate this Ubuntu/Debian/appleOS idiocy with naming versions like barking bore or lucrative lynx or Samara or any other crap like this where you need to constantly google the whole naming series to get the idea which one is newer.
The immutable root seems like it'd be troublesome. How do you end up with workable little dev environments on this sort of immutable root setup? NixOS has a similar benefit without immutable roots, and even allows for development shells per project which is... absolutely fantastic.
Readit News
The way it works (in my incomplete understanding) is that the root filesystem (running on Btfrs), specifically /usr and /var, are actually a read-only image. You can write changes to it, but each time you do, you have to rewrite the image. Each time you boot, you boot that immutable image.
This allows for easy automatic updates. And if it fails to boot after an update, it merely rolls back to the previous working image (crowdstrike take note). This seems to work well provided you don't have to modify the image too much. I installed fprintd, kdeconnect, and wine, and it's still doing OK.
The user applications are almost all Flatpaks. This works well most of the time, but not always. I was a heavy flatpak user before, and I will say that a number of Flatpsk bugs I've run into on other systems, I've not had on Kalpa, so perhaps its Flatpak implementation is better. The biggest issues I have are Flatpaks not being able to communicate with each other as easily as native binaries can.
If you don't have a Flatpak, you can always try to run it in DistroBox. This works..... OK....provided it's a userspace app. But if it's a userspace app, why not run the binary directly? Where distrobox really shines is for running .debs or .rpms on a non-native system. But those are gradually going away thanks to Flatpak anyways. Distrobox does have a fake root mode. I consistently run into boubdary issues with it on Kalpa. I was able to run software in distrobox that required root, and it technically ran, but it couldn't use any audio devices.
Overall, I find Kalpa (and MicroOS) very interesting. There are still edge cases where they break, but I was easily able to work around everything.
Also while flatpak applications are usually sandboxed, they very often need access to your files to be useful. You are either limited to a small subset of flatpaks on fedora flatpak repo, or the whole uncurated flathub shithole where quality and security is totally random.
Also running a flatpak from the command line using `flatpak run tld.organizationname.appname` is a bit annoying. Toolbox, distrobox and containers solve some of the stuff but are also clunky way to do stuff that you would just do normally on a regular linux system.
All in all I will keep it on one of my laptops as I am curious about how it will evolve in the future and it is a decent OS for non tech / family use where your typical usage is to open a browser and a handful of gui apps so I can easily lend it to my kids and partner without worry.
I've even started using Fedora CoreOS VMs as the basis for containerized service installs on my home network (Pihole, etc.).
To be fair, I do have quite a few packages layered on top of the base distro, as well. From memory: many admin tools that require "real" root, KVM virtualization support, RPM Fusion packages to enable hardware video decode, Mullvad's VPN client, tmux, vim-default-editor, a few font packages, Emacs, and a few basic development tools like cmake and make for the benefit of Emacs package installs.
The only problem I've ever had with layering is that once in a while I have to wait a bit and retry an update because newer package versions from the base image haven't yet made it out to the main RPM mirrors.
Oh, and Flatpak automatically symlinks "flatpak run" wrapper scripts to /var/lib/flatpak/exports/bin, so, assuming ~/.local/bin is in your PATH,
fixes your annoyance.In the end though, some of the cons of such a system started being too much and I went back to Leap. It was close to winning over me however.
Sounds like a glorified LiveCD distro. (In fact, it's almost exactly a LiveCD with 'persistence' once you account for other parts of the filesystem that are not 'immutable', such as /home/ .) Not sure what's supposed to be so innovative about this.
No loss here. I'd consider it a benefit in fact.
For firefox I've found it extremely annoying. When the snap updated in the background:
1. Pinning the desktop icon to the toolbar is annoying ... the desktop file is in a snap folder that keeps changing, so would disappear.
2. It showed the "you need to restart firefox in X days" notification frequently; I wasn't able to find a way to stop it reshowing the notification after dismissing it.
3. Updates caused firefox to crash if the underlying snap folder gets removed.
4. Keeping profile information across the snaps is not easy; I've had updates reset the profiles to the base.
For IntelliJ IDE I've not had issues thus far. I'm not sure if this is because it hasn't been updated enough to encounter the above issues.
In 3 years using Fedora (which hasn't a reputation for being a stable distro) I once had a bad kernel that prevented my Framework laptop from booting (solved by blacklisting said kernel). All my other Fedora machines were fine.
Why would I need an immutable distro if even Fedora is stable enough? Heck i could use Debian or a RHEL clone and never have to worry about stability.
"50% power reliability is enough for anyone, I sometimes don't have to gather firewood"
Its hard to imagine never gathering firewood to heat your home in that reality.
All of this to say that you can make more assumptions and enable things that were not possible before with better reproducibility.
I eschew complexity wherever practical. There's so much complexity in modern life, especially for tech people.
Right now mutable Linux is absolutely fine for me, but I'd like to thank all the people that are alpha testing some of the tech I'll adopt later ;)
My only wish is that immutable filesystem, read-only rootfs and most of the system with just a FEW exceptions, atomic upgrades/rollbacks would be more and more widely encouraged, discussed and adopted.
Just eliminating the worry of root partition running out of space is a life changer. From the ground up any "traditional" linux distro will force you sit and design how to partition the disk sooner or later. The guys above address this issue (and a huge bunch of others) for you.
I’ve made a /data partition for many years now taking the majority of the disk. Root then has not needed more than thirty GB or so. (With kernels in the efi system partition, and home in data even less. I used to make it 32gb.)
If you want to give it a try you can install distrobox or toolbox right now on any distro, this is not unique to immutable readonly distros. This allows you to separate system / userland package management and have access to say, pacman on a fedora for example.
If you want a comfy modern system goes for NixOS/Guix System on top of zfs. Safety came from design, not from isolation. Comfort came from autonomous power not quickly import third parties blob and so on. Such distros are like btrfs vs zfs. A tentative to denied the fact a model needed by some actors is total crap.
User filesystem is totally transparent.