[COGlory]

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.

[prmoustache]

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.

[jasomill]

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,

  ln -s /var/lib/flatpak/exports/bin/tld.organizationname.appname ~/.local/bin/appname

fixes your annoyance.

[prmoustache]

Thanks for the tip, I wasn't aware of those wrapper scripts.

[larme]

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.

[spookie]

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.

[zozbot234]

> 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.