Thank you OP for that, but... why should we prefer this over uBlue's work on streamlining this process?

That's very valuable! Thank you for mentioning that! To make it even more relevant to OP, I would like to pose the following questions:

• Which CPU?
• Which GPU?
• How has the battery life been? Consider both light and heavy use*

Thank you in advance!

Hmm..., I think with the level of literacy (or just plain text skimping) we find on the internet, anything that helps in conveying the message is a clear win; especially if merely the use of just two characters enables one to achieve this.

Could you elaborate on what you dislike about it? I'm just genuinely curious*.

Why ublue over fedora’s images?

Personally, I've been enjoying uBlue over vanilla Fedora Atomic for what they offer in terms of system management.

To give you a better idea on what I mean; just a month ago an update to Podman caused breakage and people weren't able to use their containers created with Distrobox/Toolbx^[1]^. Sure; a rollback is accomplished relatively easy and I'm sure some would even be able to fix it themselves. Regardless, every Fedora Atomic user that relied on Podman would have been interrupted to some capacity.

Which, of course, begs the following questions... Isn't it very inefficient for everyone to fix this issue themselves? Wouldn't it be easier if somehow Fedora forced some fix upon all of us so that just one entity is burdened instead of all of us? Heck, wouldn't it be better if Fedora just withhold the update until it's fixed? Is this perhaps some pipe dream that will never see the light of day? etc...

The interesting part, though, would be how I (a 'uBlue-user') didn't even notice Podman was causing issues in the first place. "How?" you might ask, well... The uBlue devs noticed the issue, applied some magic so that I and many other uBlue users like me just went on with their day like they would otherwise; without being interrupted because Podman just had a bad update. (Did the supposed pipe dream actually already exist in some form or fashion?)

This is just the most recent example of this. But in the last year or so, out of the top of my head, there have been a few more times in which uBlue users didn't even notice a thing while the others either had to rollback or fix their issues themselves. If you enjoy this interruption and/or are willing to deal with it for the sake of whatever, then please feel to continue to do so. However, I prefer to have a system I can rely on at all times and uBlue offers me just that while remaining very close to vanilla Fedora Atomic.

You won’t have fedoras signatures anymore.

It depends if you have the luxury to rely on them in the first place.

If setting up your workflow (or whatever) requires you to get to the nitty gritty of things and change those parts of the system that strictly speaking isn't well supported by just rpm-ostree, then -for almost a year now- your best bet would have been to (instead) experiment with (what's been referred in Fedora's Wiki as) Ostree Native Containers.

And the truth is, unless you really know what you're doing, that uBlue offers the best platform to engage with this system. Heck, within a week after Kinoite's very own maintainer blogged about how to sign container images via Github actions, one of uBlue's maintainers tried to implement this for uBlue to improve their own platform and succeeded.

Finally, let's not forget that uBlue is even endorsed by Fedora (or at least by whoever maintains its documentation). Heck, even the inception of uBlue was due to an interaction between Jorge Castro (one of uBlue's maintainers) and Colin Walters (one of the masterminds behind the whole rpm-ostree-ecosystem).

P.S. If I hadn't made it clear, it's totally fine to continue to rely on Fedora Atomic directly without any interventions from third parties for system management or whatsoever. I just wanted to elaborate why I, personally, prefer to use images provided by uBlue.

1. Source to a thread in which this is discussed.

Unless you really want vim bindings

I kinda do for how ubiquitous Vim keybindings are.

try them out.

Regardless, I think I will try it out after I'm at least somewhat productive with Vim.

I much prefer the way Kakoune works over vim

I think preference is generally subjective. So you're completely in your right to prefer Kakoune over Vim (and vice versa). Though, if possible, would you mind elaborating what you prefer exactly and why?

while still being close enough so that you can pick it up quickly if you already know vim and the other way around.

Doesn't that disrupt muscle memory?

Btw, you make excellent points! Thank you for that. Much appreciated!

I’ve found that it is FOSS vs proprietary that causes beloved tech to die

There's definitely truth in that.

VSCode is, by a wide margin, now the most popular IDE. If MS abandons it, there’s a fleet of us ready to continue using VSCodium.

I can definitely see that happen.

Edit: The usual issue with plugins on VSCodium, out of the box, is that it defaults to a completely different plugin set, due to MS license rules about their plugin repository. It’s trivial to switch it back with a config file edit, which is, admittedly, a little buried, in the project FAQ. The VSCodium plugin repository is growing better over time, but there’s not good awareness of it yet by most plugin developers.

Wow! Thank you so much! At the time I just needed something that works, so the path of least resistance (read: go back to VS Code) was preferred. So, I probably didn't even bother finding a way to resolve the issue at the time. But this paragraph has provided a great amount of pointers that will surely help solving it.

Perhaps I should include VSCodium as another viable alternative 😜. So that it becomes -at the very least- the path of least resistance to Emacs and/or (Neo)Vim.

That's perhaps a bit too open of a question to ask 😅. But I'll give it a try:

I'll assume the following:

• You asked specifically for the 'immutable' distros that are intended to be used on desktop. Which, moving forward will be referred to as 'immutable' desktops.
• You asked me to look at them in a 'vacuum', thus not comparing it to other 'immutable' desktops. Or at least, it shouldn't be the primary focus.

So without further ado:

• Out of the earlier named 'versions', Aeon (GNOME version) is clearly the most polished and the only one I would actually recommend using. Regarding Kalpa (KDE version); just a few months ago its (then) most active maintainer had stated the following:

'I am stating, right now, for those of you that are clamoring for it to be so, or asking when it will be “release ready” that microOS Desktop Plasma, is not, and will not be “release ready” anytime soon.'

This, indeed, is quite worrisome 😅. Unfortunately, Greybeard (Sway version) is arguably even less production ready... So for starters, if you want to use any of openSUSE's 'immutable' desktops, then you should definitely use openSUSE Aeon.

• Regarding the inner-workings of openSUSE's immutable desktops: -though this is merely an oversimplification- one could understand it as openSUSE Tumbleweed's model with some 'extras'. With those extras being:
  • The base system components of the currently running system is snapshot and copied
  • Changes (be it installing/removing packages (natively) or upgrading base system components etc) are applied on the newly copied snapshot atomically; which means it either happens or doesn't. There's no in-between state, even with power outages and whatnot. Thus guaranteeing that a lot of the complexity with updating that would be found on traditional systems is removed. Btw, atomic updates is almost like a basic requirement with how prevalent it is on any distro that's considered 'immutable'.
  • After the changes have been applied successfully, the copy is made read-only.
  • Changes are then supposed to require a (soft-)reboot for them to take effect.

As this model is relatively 'simple' compared to other immutable distros and doesn't seem a radical departure from traditional systems, one might expect a lot of things to 'just continue working'. However, I'm not confident if that's actually the case. Though, I'd love others to chime in and tell us their experiences. This more simple model does come at a 'cost' though; as it stands, this model is not declarative, nor is it reproducible. Which are qualities found on some other 'immutable' distros.

• The implementation of its release cycle, however, is a major win for openSUSE's immutable desktops and probably the best reason for choosing it over the others. For years openSUSE has pioneered what a stable rolling release is supposed to look like with their Tumbleweed. And its immutable desktops continue to benefit of this. So while blendOS, Fedora (on Rawhide) and NixOS (on unstable) technically are other 'immutable' distros with rolling release cycles, one simply can't deny that they're inferior (in the rolling release aspect) compared to openSUSE's immutable desktops.
• On a final note, I've often heard that openSUSE's 'immutable' desktops have more 'sane' defaults compared to some of the others. Things like offering Firefox as a flatpak instead, shipping Distrobox by default or installing flatpaks not system-wide but per user etc. These might seem like little nitpicks, and arguably others might simply not agree with these choices. However, I agree that generally-speaking most users should prefer these defaults.

Please let me know in case you were expecting a different type of answer!

Aight, I actually don't know a lot about it, but I guess something that looks like an answer is better than none. So without further a due.

First of all, Nitrux is quite unique, so I won't be able to do it justice regardless. However, I'd say that it being an 'immutable' distro with OpenRC and focusing on AppImage (over Flatpak/Snap) is the primary one. It's important to note that Nitrux' model doesn't allow you to install .deb packages natively at all. So in that regard, it's one of the less flexible among its 'immutable' siblings. It does offer great support for Distrobox, so you can install your debs, rpms and from the AUR etc if you so desire within a container instead; you can even install other desktop environments with this. Waydroid works. AppArmor is configured. KDE Plasma looks fantastic on Nitrux, but they offer even more spice through their Maui Shell.

I’d say that they’re mainly made for CI/CD, cloud environments etc, and probably not something you want to put in a laptop and use as a daily driver.

Why do you think that? Would you be so kind to elaborate?

You can install Distrobox on Fedora (or any of the distros that support it), create a Debian distrobox on your Fedora install, and within the Debian distrobox you can use apt-get to install whichever Debian package you like. Or..., you could make an Arch distrobox and even install stuff from the AUR. Or really any package from any of your favorite distros as long as it's supported.

The one thing it does best is offering the capability to share the results so that people can refer/link to it while making an inquiry as such.

Thank you!

I’m just starting to spread my wings outside of Ubuntu right and see what’s out there.

As you must have been aware of by now; there are hundreds of distros out there. Which obviously makes it a daunting task to find your distro with that overwhelming amount of distros to potentially choose from. However, quite fortunately, the vast majority is actually not even worth considering as a daily driver. Arguably only the popular independent distros (Arch, Debian, Fedora, Gentoo, openSUSE, Slackware and Ubuntu^[1]^ etc^[2]^) are noteworthy, unless you've got very specific wants and/or needs that are only easily accessible through a derivative of theirs. Out of these, Gentoo is perhaps too much of a deep dive at this point in your Linux journey. Slackware ain't bad, but as you've already had some experience with modern Linux distros, I find it rather unlikely that you would enjoy using it; though, perhaps, you might one day (read: decades down the line). So..., only five distros remain... On that note, for whatever it's worth, openSUSE Tumbleweed definitely stands out positively among these IMO (though perhaps another one might be shining even brighter (obviously biased 😜)).

The UI looks real neat as well.

Interesting. Are you referring to the desktop environment? Which -actually- should be reproducible on most other distros*. Or perhaps you're actually referring to YaST? Which is openSUSE's excellent configuration tool; perhaps closest thing that Linux has to Windows' Control Panel. Some even regard it as openSUSE's killer-feature, especially because most other distros (aside from MX Linux) only come with relatively basic configuration tools by comparison. In retrospect, I probably should have mentioned it in my earlier comment 😅.

I’m not really looking for a gaming focused distro right now.

I'm actually glad you aren't; they generally tend to miss out on polish. If you do end up looking into one, then I'd argue it's better to run a dedicated distro as such -perhaps as a dual boot- for all your gaming needs instead of trying to game heavily on your daily driver, unless you find that too cumbersome and/or fear for issues related to storage. I'm aware that this is probably an unpopular take*.

Just something that I can daily drive and occasionally play games with.

Aight, got ya. Well, in that case, openSUSE Tumbleweed is definitely worth considering.

1. I am very aware that Ubuntu is technically not quite as independent as the others are.
2. I felt the likes of Alpine, Guix, NixOS, Puppy, Solus and Void are at least worth mentioning as independent distros.