XY problem confirmed. Thank you OP!

There have been complaints in posts about people asking for advice on which disto to use, that there are too many such posts.

This is a legit concern.Thank you for trying to tackle this!

Provide users the tools to possibly answer the question themselves before creating a post.

Noble. And in its essence, it makes a lot of sense.

DistroChooser is a self-help tool for that purpose.

As a self-help tool it's very bad. Sorry*. I actually hoped that you would mention how it might be used as a basic requirement for anyone that asks which distro to use. The enforcement could be done with a bot which simply scans if any link to distrochooser is present in a post that remotely resembles one that asks for advice on which distro to use. I would actually even argue against this, but I think we might be able to reach an agreement on which questions are actually worth keeping around for further use...

• keep answering posts --> more complaints, possibly silent quitting of community

Honestly, this is better than to limit newbies to strictly stick to Distrochooser for asking which distro they should use 🤣.

• write bot --> I ain’t got the time, maybe somebody has, dunno what the bot would do

I haven't got any experience with building a bot, but I suppose it works by scanning for words in posts. In that case, simply 'flagging' everything that contains the words "which" or "what" in combination with "distro(s)" or "distribution(s)" and ask them to refer their questions to a dedicated Lemmy community in which they can ask would already solve a lot.

• find alternative website --> I ain’t got the time

You don't have to find an alternative website. Nor write one yourself. As it stands, as far as I'm aware, there's simply nothing that satisfies the basic needs for this.

So what do I propose? Relegating these questions to their own dedicated Lemmy community is probably a great and easy solution. If something like a test/algorithm/flowchart/quiz/whatever has to be created, then that one might need substantial effort to get off the ground. However, perhaps comments like these might be helpful as a blueprint.

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.

Hmm, one I guess is that it is not “permanent” and deactivates after one command (in Kakoune, you have to explicitly do ‘;’ to collapse the selection to its end (which you can flip with the start using ‘alt+;’) or move around without extending the selection). That’s really the only thing I can think of at the moment and I feel like often it really doesn’t matter tbh, so maybe I was just talking out of my ass there a bit lmao.

Regardless; thank you for mentioning this!

Apparently you can quickly reselect it in vim with ‘gv’ though, which I never checked until now. That’s useful to know.

Hehe, thanks for sharing that; might become useful soon 😅.

One thing I’m really missing from vim though is that it can list directories, has a hex editor, and can read a bunch of other file formats. I think it can even edit remote files over sftp, but maybe I’m confusing that with Emacs. Kakoune just does local text files (though you can of course do stuff like ‘%|xxd’ to pipe the file through xxd to get a hex view, edit and then ‘%|xxd -r’ and save but that feels very very sketchy).

Until yesterday I knew almost nothing about Kakoune. But I've since tried to do some reading; while there's still a lot to uncover and/or explore, I feel as if it tries to offer a more focused experience (for better or worse).

I'm not surprised to hear that you preferred Fedora Silverblue over openSUSE MicroOS. Don't get me wrong, I think that openSUSE Aeon/Kalpa (current names for openSUSE MicroOS Desktop) have a lot of potential. However, as it stands, Fedora's Atomic Desktops are just more mature.

Seriously, if you want an IDE for Python and C#, VS Code with the Microsoft plugins is and will be miles ahead of the VIM experience.

Someone else already pointed how VS Code has become the most popular IDE (at least according to statistics found on stackoverflow). While categorically I'd like to dismiss VS Code for not adhering to F(L)OSS, VSCodium -however- actually does fit the bill. And while formerly I've had bad experiences on it related to how the plugin ecosystem is configured by default compared to VS Code, I've since learned how it works on VSCodium. So I shall set it up in case Emacs and/or (Neo)Vim somehow seem to be less fit for the job and/or I can't be bothered at that moment to configure Emacs/(Neo)Vim to do my bidding.

Learn vi

Will do.

The time trying to force VIM/EMACS into a descent IDE will never come back and the theory sounds better than it will be in reality.

I understand the concerns. And I agree that I should be realistic in how I approach this. Nonetheless, I'm faithful for it to be a very productive endeavor. Thank you for chiming in!

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!

That's good to know! And I'm sure it's beneficial information for those that were unaware of that. However, (unless I'm wrong) the method you described requires you to be deliberate and precise in the placement of your own bang; i.e. bag of d holding or bag of holding d wouldn't work. As I often just start typing whatever I want to search/look for and only notice midway/afterwards that I hadn't specified where I would like to search, the built-in 'bangs' in Firefox/Chrome just wouldn't cut it unless I would try to rewire my behavior.

You should be fine regardless. However, I have at least read from one developer that works on one of the SteamOS clones that there is still some merit in running it on Arch due to how Valve targets that specifically for its SteamOS. One might even get better performances on Arch as the user is able to tweak it beyond what SteamOS offers. But this requires proper know-how, so this route is not recommended for those that are still very novel to Linux.

Perhaps consider watching this excellent video guide on dualbooting and multibooting by DorianDotSlash. It was what I used as a reference the first few times I engaged in dualbooting and/or multibooting.

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?

That's unfortunate indeed. Currently I gravitate towards installing something like Endless OS for either elderly people or children. Automatic atomic updates from the get go on an immutable distro based on Debian Stable; just good stuff. FWIW, it allows updates between major versions as well 😉.