I am not sure I fully understand the usability trade-offs when it comes to these "atomic" distros. One the one hand, security seems to improve markedly, since the root filesystem is largely immutable. On the other hand, it does seem that a lot of straightforward things become harder. I generally dislike flatpaks and favor a low-level, bare-metal approach to things and atomic distros seem to go against that. Maybe I should just run some experiments in a VM.
The idea is that the immutability of the operating system leads to greater stability. The partition should (in theory) be exactly as the distribution expects on every computer it’s installed to, which limits the potential for user changes breaking anything. The benefit to the user is that it’s a lot harder to shoot yourself in the foot by running the wrong script.
For me, the point is not security, but maintenance. Whenever system upgrades have gone wrong, it's almost always been a partial update, and that just no longer happens.
I've found doing work in containers made things straightforward enough, as a developer. Though I still somewhat think that that's just moving the problem - I'm not quite keeping those containers up-to-date. `distrobox assemble` helps a bit though.
> dislike flatpaks and favor a low-level, bare-metal approach
Flatpaks are sandboxed with bubblewrap[1]. I would still call that bare-metal. And flatpaks aren't particularly bloated either, there's no need for a flatpak to be any bigger than a regular binary if it only depends on the kde/gnome/freedesktop runtime.
I used to prefer installing apps via my distro directly, but I now prefer using flatpaks because of the way it sandboxes the applications. When I delete a flatpak I know for sure any configuration or cache files for that app are also gone (unless you opt to keep them).
If you want to play with atomic distro's, there's a bunch of different approaches out there. For instance GnomeOS is not package based at all. OpenSUSE works via btrfs snapshots, Fedora Atomic uses rpm-ostree currently.
If you manage enough diverse servers, then patching will break something critical fairly frequently. Back when I was a sysadmin, Windows updates would break some server every 2 months, and Redhat every 6 months.
Being able to just reboot the server back into a working state, and then fix it at a later time would have been nice.
It's also a big deal for desktops, especially when they're operated by people who ain't experts at troubleshooting software issues. Aeon's my go-to when setting up computers for non-technical folks specifically because I can have it auto-update fearlessly, knowing that the absolute worst case scenario is having to talk someone through booting into a known-good snapshot.
