atomicStan

My apologies for inserting this "akshually ☝️", but I'm almost 100% sure that the distro that just didn't make the cut -the one represented in green, right under Manjaro- is openSUSE. It's possible to deduce this from an earlier report of Boiling Steam and its respective graph.

But, perhaps unsurprisingly, I don't ever recall seeing Slackware in any of these.

FWIW, similarly, we can deduce the grey one right below openSUSE to be Gentoo from this report and its respective graph. And, finally, the blue one below Gentoo to be Garuda from the respective graph of this report.

The last distro I was able to identify is Solus. Unfortunately, it's only relevant in the very beginning. It used to be the best performing grey one. See this report and its respective graph.

Asahi Linux is basically top notch engineering for free. Unless it gets (really) big, I don't see any reason for Apple to even consider putting it down.

Yeah, NixOS is excellent. But, for nix (or close enough) to be the future, an upgrade path should exist for other distros. But, for some reason, I don't really see any such efforts. Like, where are the nix-variants of other distros?

FWIW, Bootcrew has created bootc-variants of many other distros. And, even before, both Endless OS and GNOME OS offered examples of non-Fedora distros with ostree.

EDIT: TIL

Perhaps I should have been more clear. My apologies. I wanted to draw attention to the fact that -in the case of Fedora Atomic- layering remains a necessity (for most users). This thread goes over it in more detail.

flatpak

Technically speaking, the flatpak format isn't even as limited as some make it out to be. For example, software like Bottles have offered CLI/TUI functionality through it. But Flathub, its most popular storefront, does put a limitation on submissions. Which means that it's effectively not even competing with other package managers that (conventionally) try to offer a broader set of software.

Furthermore, even if the flatpak package exists, not all functionality is retained. For example, the situation around native messaging is still a mess. This prevents e.g. your flatpak browser from communicating with your locally installed password manager. While a(n ugly) workaround exists, it’s quite maddening that it hasn’t been resolved in all these years 😅.

distrobox/toolbx

This is actually a mess. See this comment elsewhere under this post for a bit more elaboration.

Overall, I wholeheartedly agree with your assessment.

The suggestion to just use ~~toolkits~~ toolbox is not for mortals.

I am also not convinced that it was ever meant as the endgame. Like, toolbox still doesn't offer a mechanic to upgrade a(ll) container(s) without entering one. The last time I used it, it also shat itself whenever the old pet container became EOL and desired a 'system update' to become functional. IIRC, distrobox doesn't fare any better at this. Thus, coming with what looks like planned obsolescence; with the recreation of the pet containers every couple of months as a result. I suppose the solution is picking an image that's supposed to be rolling-release. Which is why I think this workflow suits Aeon better.

I could see it becoming the future. But only under a couple of scenarios.

Scenario A: It becomes (strictly) better and/or easier than the alternative. Kinda like how systemd effectively replaced SysVinit within a couple of years, simply because it was a more sane alternative. But this is reliant on the read-only aspect being put in place without affecting existing workflows on traditional distros. So, as Fedora Atomic is the atomic distro I'm most familiar with, I'll provide explicit examples from it:

• Installing packages shouldn't take a reboot to take effect. I can see sysexts being leveraged for this eventually.
• Any commands that involve dnf should (somehow) continue to function. It could even be an alias (or something) that invokes something else entirely. I don't even think most users will care for what exactly happens in the background, as long as the functional expectation is being met.
• The previous two points shouldn't come at a (significant) speed loss.

Scenario B: It's enforced on us by (some of) our Linux overlords and/or expected by (parts of) the Desktop Linux stack. Kinda like how the GNOME desktop environment currently has dependencies that are systemd-components. Thus, requiring some hacking to make it work in its absence. Currently, I can only see some RHEL(-adjacent) projects committing to this.

But I think both of the above scenarios are at least 5 years away. While atomic/immutable distros enjoy a healthy (perhaps even generous) amount of development, AFAIK none of them are actually 100% feature-complete^[To be clear, it's probably at like 95% or so.] compared to their traditional counterparts. So, fixing (most of) the remaining edge cases to make migration possible for every enthusiast that even considers switching, should probably be their priority.

I didn't really mean it in the sense that the communities of different atomic/immutable engage regarding the trade-offs associated by their respective methods of achieving atomicity/immutability. And, honestly, I'd actually love to see more of that. Even if NixOS users would dunk on the rest, at least until the learning curves are brought up.

Instead, what we often find are unproductive threads like this one 😅. In which, naysayers and proponents act like they're engaging, but I simply fail to understand what's happening.

There's also a lot of zealous discourse on the subject of atomic/immutable distros.

Not the person you asked. But the only thing I can think of, would be how the flatpak's sandbox might cause friction. Most of the time, you won't even notice it. But, once every while, it shows its ugly face.

For example, the situation around native messaging is still a mess. This prevents e.g. your flatpak browser from communicating with your locally installed password manager. While a(n ugly) workaround exists, it's quite maddening that it hasn't been resolved in all these years 😅.

IIRC, historically, it was (one of) the first to do so. It took a significant time for (most^[Slackware, famously, continues to not have a dependency resolver. Though, they got their reasons.]) others to catch up.

still

Maybe. I honestly don't know either.

Many different solutions exist, even native ones. But I'd have to mention Sandboxie as probably the most popular option.

• Step 1. Upgrade to proactive security. Projects like HotCakeX' offer a streamlined method of attaining it.
• Step 2. Commit to best practices. There's a long list of this, but the short of it would be:
  • Uphold a strong backbone of secure software that has proven to be committed to safe practices.
  • Ensure that your system and/or software is always up-to-date.
  • Don't visit unsafe/untrusted websites. Don't click on shady/untrusted links.
  • Don't execute untrusted/unsafe files. Especially not with administrator's rights.
  • Sandbox all activities. So that even if you're compromised, that the adversary can only access very little beyond the binary/program/software itself.