Windows ->

Fedora Kinoite: A relatively mature atomic/immutable distro combined with excellent security standards and that resembles Windows’ workflow. Unfortunately, it broke almost immediately. Though, to be fair, it was a known issue with the ISO back then. As a newb, however, I couldn’t be bothered with it. ->

Fedora Silverblue: Well…, I didn’t have much of a choice 😜. Or I had to forego Fedora Atomic altogether. However, I actually really enjoyed GNOME’s workflow. I used this as my main system for about year. Until I found a related project… ->

Arch: The memes got me 😅. In all honesty, though, it was mostly curiosity. Still, I didn’t intend to throw away my working Silverblue installation for the sake of quenching my thirst for experiencing Arch. So, as dual boot, I tried to install it. This was pre archinstall, so it took a couple of tries before I booted into GNOME. However, I guess I did mess up something as I don’t recall ever booting back into that system 😅. So, what if I want Arch, but don’t want to spend more time with the installation… ->

EndeavourOS: Yup. I actually enjoyed it. I also took the opportunity to install another DE; KDE. Tried out the hardened kernel. Was able to make Davinci Resolve work, which just caused a lot of trouble on Silverblue. Access to AUR. It was cool, really. And, for some time, I was actually pondering to dismiss Silverblue altogether in favor of EndeavourOS. But, I started to miss the ‘stability’ that I was used to from Silverblue. Though, I don’t exactly recall if it was the fault of being based on Arch, or rather linked/attributed to KDE instead. Regardless, I noticed that (over time) I spend more and more time on Silverblue. At some point, booting into EndeavourOS didn’t work any more. It had broken. I did engage in some troubleshooting efforts, but to no avail… ->

Zorin OS lite: On backup laptop; the poor thing couldn’t run Windows but (even today) it’s still kicking on Linux ->

Nobara: So, I guess I did miss some of the functionality provided by EndeavourOS; running Davinci Resolve being the primary one. But, I didn’t want to pass out of the opportunity to try something else. Back then, Nobara was released relatively recently and was received very positively by the community. And had even a special guide/tutorial to make Davinci Resolve work on AMD devices. Nobara was cool. But, it didn’t feel very special. I actually enjoyed EndeavourOS a lot more. It was mostly utilized for Davinci Resolve and for gaming if Silverblue wasn’t fit for the job (for whatever reason). Unfortunately, even this one broke at some point 😅. I could still boot into it. But, the system just didn’t do what it’s supposed to do. I tried troubleshooting. But, once again, to no avail. ->

uBlue; Silverblue image: Through all that was previously mentioned, I had stability in Fedora Silverblue. It was reliable. I could trust it. Well…, most of the time 😅. Decisions related to mesa or video acceleration in browsers definitely felt more like misses rather than hits. I can’t blame Fedora as they’re legally restricted. But, shouldn’t we be able to do better? Enter uBlue. It seemed like some black magic shenanigans. The earlier issues would have never occurred (nor did they occur) on uBlue. This ‘managed’ aspect of uBlue was clearly, at least for me, the reason to consider it over regular Silverblue. And so, I parted with regular Silverblue and started using the Silverblue image provided by uBlue. Not long after, I even had my own (hardened) custom image. But, eventually (to be more precise; about half a year after switching to uBlue), keeping up with hardening took up too much effort for me to bear. But, thankfully, I had already found the perfect solution… ->

secureblue (based on the Silverblue image): This was Silverblue hardened by someone that actually knows their shit. And, thankfully, I didn’t have to maintain this myself. I used this for a couple of months until the next best thing… ->

secureblue (based on the Bluefin image): Currently on this for I think half a year now. It has just been a lovely experience through and through. Everything I could have asked is provided.

I think we’re misunderstanding eachother. So perhaps consider to outline if you agree with the following:

• uBlue has some systems in place that enable it to detect some breakages.
• uBlue’s pipeline is such to not ship you the detected breakages.
• After a method has been found to fix a breakage (or other issues), uBlue’s maintainers implement these fixes and then, the very next update, the users will receive an image that contains both the updated package and the fixes required for it to not cause problems. Heck, the user didn’t know anything was up in the first place. They didn’t notice a thing*.
• uBlue’s issue/problem detect systems are not absolute; things might slip through.
• However, Nvidia drivers will not cause breakage that will make you shiver in fear.
• uBlue does not fix it on your device. They fix the image and that fixed image will deliver you the fix built-in; so manual intervention are a thing of the past (except for edge cases).
• Their pipeline does not require nor does it detect (through telemetry or whatsoever) the breakage on the device of the user. Heck, as implied earlier, most breakages are detected, prevented from shipping broken, fixed, ship the fixed one before any end user is disturbed by it.
• uBlue is not a Stable system (i.e. it does not freeze packages (apart from security updates) until the next major release). So yes, you receive updates all the time.
• Not being tied to legal restrictions is cool. However, a lot of derivatives do this. So this can’t be its unique selling point.
• uBlue is not entirely free. Its maintainers do pay money for providing some of their services (as has been mentioned by Jorge).
• Some of their images do have testing branch; even Bazzite has.

But there is no automatic repair voodoo anywhere, on any distro. That driver is proprietary, only NVIDIA can fix it.

Consider to revisit this, cuz this is basically (at least for me) most of uBlue’s schtick:

“No more building drivers on your laptop, dealing with signing, akmods, third party repo conflicts, or any of that. We’ve fully automated it so that if there’s an issue, we fix it in GitHub, for everyone.”

And the way it’s setup, is so that you don’t get the broken update ever on your device in the first place.

So, contrary to what you might expect, this black magic (or just excellent engineering) somehow does exist.

But they rely on rpmfusion, an external repo packaging the proprietary NVIDIA stuff for Fedora. The repo is not supported by Fedora, and the drivers cannot be fixed by anyone.

Not sure what you’re trying to say here. Would you mind elaborating? FWIW, Bazzite’s model (by default) allows automatic fixes to be applied to a broken driver without requiring any manual intervention from its user.

In your case it’s still an excellent choice.

Though, other opinionated images by uBlue (like e.g. Aurora and Bluefin) do deserve a mention. I’m on Bluefin (through secureblue to be more precise) as I desired more hardening than what Fedora offers by default.

The excellent part is also that it’s possible to rebase to another branch without reinstalling. So, let’s say you’re actually interested in experiencing these different images without going through the installation process over and over again. Then, you simple enter the following command:

rpm-ostree rebase ...

With ... being replaced by whatever is required for the image and/or branch you’re interested in. Then, simply reboot, (pro-tip: make a new user account and through the new user account) experience the other image. Rinse and repeat to your heart’s content.

Why are you even considering Manjaro?

If gaming is the priority, then I honestly don’t think anything out there can beat Bazzite in terms of ease of use, ‘hands-off’-ness, robustness and stability.

Honorable mentions include: Nobara and Pop!_OS.

Update 2: After trying out EOS, Arch, Manjaro, OpenSUSE Tumbleweed and Universal Blue, among many other options, I’ve come to the decision that I’m okay with sticking to Mint for now on my main desktop and setting up UBlue Aurora on my work laptop, but might consider switching to Kubuntu or Fedora if I want something similar at work and at home (one of my main draws away from Mint was that it didn’t offer a KDE option), or to OpenSUSE Tumbleweed if I must have a rolling distro for some reason. Thank you all for your guidance, and happy distro hopping!

Thank you for the update!

Could you elaborate upon your decision-making?

If it is the default on the distro they intend to use, then, by all means, they should definitely go with it. Btrfs has been really stable for a pretty long time anyways. Just don’t use it for RAID 5/6 and you’d be absolutely fine.

Fedora and opensuse are copying from the commercial distros

How are they copying if Fedora and openSUSE Tumbleweed are upstream to RHEL and SLE respectively?

Btw, I don’t understand what your comment was set out to do. Could you elaborate?

But have been wondering why I haven’t heard of any immutable distros from arch based distros yet.

If your question is “Why doesn’t Arch have its own atomic/immutable spin/flavor like Fedora and openSUSE have in their Silverblue/Kinoite and Aeon/Kalpa respectively?”, then the answer simply lies in the fact that Fedora and openSUSE have a lot more incentive for venturing the unexplored waters of atomicity/immutability as their enterprise counterparts exist and will benefit majorly from it. And I haven’t even mentioned how most of the new stuff first appear on Fedora (systemd, PipeWire, Wayland etc) before they’re adopted on other distros.

The enterprise counterparts also allow funding that is essential for erecting this from the ground. But, even then, the shift towards atomic/immutable is a difficult one with a lot of hardships and complexity. From the ones that have developed their atomic/immutable projects retroactively (so GuixSD and NixOS don’t count as they’ve been atomic/immutable (and declarative) from inception), only Fedora’s (I’d argue) have matured sufficiently. But Fedora has been at it since at least 2017, so they’ve had a head start compared to the others.

In contrast to Debian (through Canonical), Fedora (through Red Hat) and openSUSE (through SuSE), Arch has literally no (in)direct ties to enterprise. Hence, it will only adopt an atomic/immutable variant if the incentive is high from the community or if it’s very easy and only comes with major benefits. But, as even openSUSE is currently struggling with their atomic/immutable variants, it has a long road ahead before it becomes something that can be easily adopted by Arch. Hence, don’t expect Arch’s atomic/immutable variant any time soon.

However, if any derivative suffices, then at least the likes of blendOS, ChimeraOS and even SteamOS are worth mentioning here.

I’ve had Manjaro, and OpenSUSE recommended to me by a friend who likes both of them but he doesn’t game much and doesn’t need various software development tools.

If your friend is familiar around Linux, then I’d advice you to just stick to the distro they’re using themselves. That’s probably the best course of action.

I advice against using https://distrochooser.de as it’s horrendously outdated and doesn’t offer accurate information. The results will also bombard you with a bunch of distros that have lost all of their relevance.

Consider making another post after everything has been done in which you note down your expectations, experiences etc.

Excellent choice! I’m sure you’ll manage 😉 (right after you’ve found yourself a USB drive).

So…, what will it be 😜?

Yup, as time went on, I simply felt less need to have proprietary software on my system. Steam remains as an exception; simply by virtue of having no F(L)OSS alternative (AFAIK).