base VS layering-examples

Like you mentioned, rpm-ostree is meant to be a fallback after non-working options like, in order, flatpak then distrobox/toolbox. But that doesn't mean it can't be used. Keep in mind this is simply a rule of thumb to increase security, stability and rpm-ostree performace, but it's still just a rule of thumb. Silverblue is very flexiible, and I have roughly 600 overlays and while rpm-ostree is slow, the only thing I really do with it is upgrade those packages installed with it, now that my system has the packages I need. Since this can be done automatically (See "man rpm-ostreed.conf") and the system is immutable, the only intervention required is rebooting when necessary (Such as if there's a fixed vulnerability or a new feature update you want). The other nice thing about auto-updates and immutability is that Silverblue is more resistant to breaking while running do to an update of an important system library or the like, since the library isn't even "visible" until the next boot, when those things it depends on are all already setup to use the new version. I also recommend checking out Jorge's flatpak automatic update systemd .timer and .service filese over at https://github.com/ublue-os/base/tree/main/usr/lib/systemd/system and downloading them and using sudo (From a Silverblue terminal) to put them into /etc//systemd/system, doing a "sudo systemctl daemon-reload" and "sudo sytemctl enable flatpak-system-update.timer" . This will update your flatpaks for you. In my opinion, between rpm-ostree auto-updates flatpak updates, you'll have a much smoother experience.

You'll see that the base image installs flatpaks as a post-install step. I really tried to work around this limitation, but haven't been able to via the OCI approach.

I think Flatcar is alive and well. I haven't used it personally so I can't really comment much on it.

As for building VM images, I don't actually do that in my setup. I just use the base FCOS image, boot it with a barebones Butane to configure disks and then use the CoreOS Layering features to setup my workload.

If you want to use ZFS on your setup, check out https://github.com/coreos/layering-examples/blob/main/build-... which has an example of building the ZFS on Linux module so you can setup your ZFS pools.

I am thinking, at the moment at the least, I will have to make a custom layer like in these example.

The good news is they fully plan on supporting ansible ... check this out: https://github.com/coreos/layering-examples/tree/main/ansible-firewalld