Compared to other distros, Vanilla OS 2 'Orchid' is rewriting how Linux works

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.

No loss here. I'd consider it a benefit in fact.

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.

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 state this because btrfs/stratis vs zfs "a rampant layer violation" (for those who remember) was the perfect example of a devs reactionary cohort who try, fails and even fails to recognize their failure, trying to state that anything new is bad, their old beloved way is the best.

Honestly package managers, boot process and installers are RELIC from another era and most fails to understand that. Declarative systems on top of modern storage like zfs (witch is modern since the others are stuck in the '80s even if born after zfs) or hammer (DragonFly BSD log-based fs like the old Linux nilfs2, but with much less of it's garbage collection issues and much more useful than "modern" ffs used on Android and alike) are "the future" since more than a decades but most try to ignore that sticking with relics and some try to denied they are the future creating monsters from stratis to docker, passing through snap/appimage/flatpacks etc all do denied a substantial change who simplify ENORMOUSLY anything just because such revolution will empower users and operations instead of the service industries and devs under Silicon Valley mode dummy-Toyoda-alike managers slavery command.

If you do not understand try to visualize how simple is to build a custom ISO with NixOS/Guix System, describe an easy to replicate system, orchestrate your hosts and handling their storage with zfs send-able snapshots. If you succeed you'll understand that AT HOME, on much smaller iron, you can do more than a k8s deploy, with much more resilience and much less effort. Now try to imaging it on scale: how many companies will remain on someone else computer (aka the cloud) with such systems common and spread?