I'd like to produce a variant of Fedora that does use Btrfs-based transactional updates as an alternative to RPM-OSTree.

There are some advantages to a Btrfs-based model:

• All RPMs work
• Standard image build tools work
• Easy to mirror and sync
• More flexible and supports full FHS

I do not think that Silverblue or CoreOS' current model will be discontinued anytime soon, but there's definitely room for both types of immutable systems in Fedora.

If all additions/subtractions/modifications are "out of band" i.e. I'm currently booted sysroot A and all modifications happen on sysroot B which is a current snapshot of A, then it means I have to reboot in order to get the changes. That has been a pretty big pain point for Silverblue folks when layering rpms via rpm-ostree install. By doing as much as possible with flatpaks and toolbox, reboot is avoided.

If there's a way to identify what kinds of changes do and don't require a reboot, and implement a hybrid approach where some modifications are transactional (happen out of band, requiring a reboot) and others can just modify the current sysroot in-place (a snapshot can still be taken for possible rollback). The logic is more complicated, but also more flexible for the user.

I think a rough draft, maybe in flow chat form, of how it'd work without any code at all would help figure out crash safeness liabilities of mixing the two approaches. And then circle back to the layout (nested vs flat vs hybrid) and if flat then it needs a naming scheme. Once there's a draft of that, then visit #12 and see how backup/restore looks.

I sorta envision a future where there will be different consumers of Btrfs features. The backups strategy may not backup every single thing, and may not even need to use the same subvolume/snapshot naming scheme because they really are so cheap it can just make its own set of snapshots, and manage them however it wants, including garbage collection - rather than expecting everyone to play ball with one specification.

As described in this Arstechnica article, the latest version of Mac OS has begun performing all system updates out of band using APFS snapshots.

Also, OpenSUSE is experimenting with a Silverblue-like desktop distribution using btrfs snapshots. See https://events.opensuse.org/conferences/oSLO/program/proposals/3256

This model of update avoids a variety of boot time complexities, not least of which is a GRUB menu populated by even more boot options - an environment that has more a11y,i18n limitations than the initramfs.

The transactional update model is more complicated up front. But if there's less UI/UX required, I think it'll end up being overall less complicated to design, create, test, and maintain.

Regardless of traditional or transactional models, I think we need to establish some priorities in order to get to a design and rollout.

1. Get rid of hidden .snapshot directories; this implies a replacement (e.g. flat layout using top-level namespacing) and suggests selinux/apparmor folks to help with the security implications.
2. Naming and organizing schema for subvolumes/snapshots; an analog of the Discoverable Partitions Spec.
3. Locking vs post merge vs instant merge. Hybrid approaches to transactional vs traditional schemes. Requires familiarity with negatives of all the existing models, including rpm-ostree, to avoid repeating the top negatives.
4. Booting it. Includes Boot Loader Spec, Boot Loader Interface, boot vs startup, bootupd, decoupling rpm from /boot.

Well, at least for the transaction implementation logic, the txnupd plugin for libdnf (which is very much WIP right now) leverages snapper to create a snapshot before the transaction starts, redirects MicroDNF or PackageKit to do the transaction on the snapshot, and then reconfigures to boot from the new snapshot. I don't have it working yet, but it's something I'm slowly developing...