Ian

The only reason Red Hat needed to invent this very complex mechanism was because RH does not officially have a COW-snapshot capable filesystem in its enterprise distro.

A filesystem with snapshots makes software installation transactional. You take a snapshot, install some software, and if it doesn't work right, you can revert to the snapshot. (With very slightly more flexible snapshots, you can limit the snapshot to just some part of the directory tree, but this is not essential; it merely permits more flexibility.)

In other words, you are a long way toward what in database language is called ACID (atomicity, consistency, isolation, durability). It makes your software inastallation transactional: an update either happens completely (A), you can check it is valid (C) and works (I), or it can be totally reverted, and the system restored to the earlier state (D).

That's a good thing. It means you can safely automate software deployment knowing that if it goes wrong you have an Undo mechanism. Databases got this 50+ years ago; in the 21st century it's making its way to FOSS OSes.

Do this in the filesystem and it's easy. SUSE's implementation is so simple, it's basically a bunch of shell scripts, and it can be turned on and off. You can run an immutable OS, reboot for updates, and if you need, disable it, go in and fix the system, and then turn it back on again.

You don't need a COW filesystem for this. But if you have a snapshotting FS underneath, transactional software maintenance becomes an order or two of magnitude easier to achieve.

The underlying philosophies of Unix are "keep it in files" and "keep it simple". That's why it didn't even have a file-hiding mechanism -- the dot-file thing was an accidental, emergent property.

Keep it simple, keep it visible, keep it human-readable and human-fixable.

Because the more complex you make it, the more likely it is to go wrong, and some poor sap is going to have to fix it. Do not get in their way. Instead, think about them, allow for that, and help keep their life easy.

This is because SUSE leans very heavily on Btrfs and that is the critical weakness -- Btrfs is only half finished and is not robust.

But RH removed Btrfs from RHEL and Btrfs was the only GPL COW filesystem, so core infrastructure in the distro means no COW on RH. Oracle Linux has Btrfs -- the FS was developed at Oracle, after all -- and so does Alma.

(Yes I know, Fedora put it back, but the key thing is, it only uses Btrfs only for compression so that Flatpak looks less horrendously inefficient. Fedora doesn't use snapshots.)

With no COW FS, RH had to invent a way to do transactional updates without filesystem support. Result, OStree. Git, but for binaries.

(And yes, everyone developing FOSS uses Git, but almost nobody understands Git.

You know that if there's an Xkcd about it, it must be true.

Embedding something you don't understand in your OS design is a VERY BAD PLAN.)

With OStree your FS is a virtual one, it's not real, it's synthesized on the fly from a local repository. The real FS is hidden and can't be hand-edited or anything. It generates the OS filesystem tree on the fly, you see. OS-tree.

Use it just for GUI apps, that's Flatpak.

Use it for the whole OS, that's OStree. It is so mind-shreddingly complicated that you can't do package management any more, you can't touch the underlying FS. So you need a whole new set of layers on top: virtual directories on top of the main virtual directory, and some bits with extra pseudo-filesystems layered on top of that to make some bits read-write.

It's like the scene in the Wasp Factory where under the skull plate it's just writhing maggots. I recoll in horror and revulsion when I see it.

So it's deeply bizarre to read blog posts praising all the cool stuff you can do with it.