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

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.

>Leaving its Ubuntu base behind also means that Orchid drops Snap support, though.

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

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.

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?

So why would I use this instead of Fedora Silverblue? (I am using Bazzite for a Steam box and Bluefin as a workstation, love them both).

Vanilla OS 2 just feels like unfortunate naming. :/

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.

Ehm... The old OpenSolaris (even before IllumOS) have had "boot environments" based on zfs clones, on GNU/Linux NixOS/Guix System offer "generations" with a network of symlinks to obtain the same result. This distro honestly sound like btrfs: an answer of those fanatically convinced their model is right and others really different are wrong.

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?