Does anyone happen to know if bubblewrap is more powerful than bubblejail (or vice versa). Or how they differ in the first place (beyond CLI vs GUI)?

Distrobox FTW!

While distrobox works well, I am worried that mismatches in packages could cause issues.

That should not be a thing in the first place. Though, if you prefer to designate a different home folder for the distrobox container, then it's worth noting that Distrobox does offer support for that.

Pushing aside that the last paragraph isn't as carefully written as the first, I feel very conflicted with the main recommendation. On one hand, the Linux enthusiast in me absolutely agrees with it. While on the other hand, I remember how 'second-day-on-Linux'-me (while not using any of the recommended distros for beginners) struggled hard to fight against the temptation of returning back to Windows.

IMO, if anything, we need better platforms that function as guided tours for newcomers.

Until now, I had been under the impression that KDE was just arch Linux itself.

Like others have already noted, KDE Plasma^[1]^ is widely available and thus not only limited to Arch Linux. Heck, the same applies to 99% of the available software on Linux; universal package managers^[2]^ have been vital to this.

Would you happen to know a good way for me to learn more about Linux, and how to put it to good use from a beginner’s perspective?

As you already own a Steam Deck, I assume you want to look into how you may improve your mileage out of it. Others have already noted how you may do so for more traditional systems. But the way Linux is utilized on the Steam Deck is rather unique. It utilizes immutability^[3]^ (i.e. the inability to make certain (permanent) changes) which makes it rather harsh to change certain parts of the system; SteamOS' implementation might even require you to redo some of these changes every so often... which is probably not what you were expecting. To circumvent this, perhaps it's worth exploring other SteamOS-like distributions that are more friendly towards tinkerers. There are many to choose from; perhaps this breakdown may help you with making an informed decision (even if it's found on a page dedicated to the Legion Go).

1. That is, the desktop environment (i.e. the piece of software responsible for how you visually interact with your system) that team KDE works on. They're also responsible for many other projects; like Kate, Kdenlive and Krita etc (these are often easily recognized by their names that start with a "K").
2. We may refer to package managers as the original App/Play Stores; a piece of software used to find, install and upgrade software. For a long time, every major distribution (like Arch, Debian and Fedora) had its own repository (i.e. set of installable software through the package manager). This meant that, it was very conceivable that software may be packaged (i.e. distributed and maintained through the repository) on some distros (abbreviation for distributions) but not on others. In the last couple of years, so-called universal package managers (like AppImage, Distrobox (technically this doesn't belong here, but it does allow access to packages found on (other) distros), Flatpak, Guix, Nix and Snap) have become alternative package managers that are distro-agnostic. And have slowly, but surely, ridden Linux distros from concerns related to package availability.
3. There's a lot to say about immutability. But for now, it's most important to note that not all systems that are (sometimes falsely) referred to as immutable are created equally. For example, the respective implementations for Bazzite, Jovian NixOS and SteamOS differ immensely from one another. Arguably, referring to Bazzite and Jovian NixOS as immutable with 'unchanging' being what's implied, would be a major disservice to both projects.

A quick search revealed that others have experienced issues that may be related. In order to disclose that this is different from the issue reported by others, please consider the following:

After updating to the latest kernel, shut off instead of reboot. After which you turn your device back on. If strict adherence to 'rebooting' like this prevents the issue from coming up, then it's likely the aforementioned known issue with the latest generation of AMD GPUs and recent kernel updates.

Please consider to report back on your findings.

I agree with the general sentiment. Thank you for mentioning that!

Though, the use of sudo nano might still pose a risk if any software found on the system is either vulnerable/exploitable, not trusted, or simply exploitative. In that case, like what's achieved through sandboxing i.e. not allow the software to go beyond their intended scope, it makes sense to put a limit on the capabilities of the software. And to that effect, the use of sudoedit still offers merit over sudo nano.

Though, if the user doesn't (already) rely on bubblejail, firejail, Flatpak etc for what they offer in sandboxing. And/or if said user simply doesn't care for the principle of least privilege, then the use of sudo nano is perfectly valid.

So I would like to ask a couple of questions:

Qubes OS (Tried it twice, not ready yet)

Is Qubes OS not ready yet for your intended workflow/usage? Or are you not ready to make the complete switch (yet)?

For me, it has been incredibly difficult to find a properly privacy oriented Linux distro that also has ease of use.

Unfortunately, in almost all cases, increased security/privacy is achieved through the loss of convenience. Therefore, you should ask yourself what the minimum level of security/privacy is that you absolutely require/need. How's your threat model defined (if at all)?

My issue with Fedora is the lack of proper sandboxing, and it seems as though Qubes is the only one that really takes care in sandboxing apps.

I agree that there's still a long road ahead until we have on Linux whatever is found on GrapheneOS or Qubes OS. I'm aware that you can technically utilize VMs on any distro, but the experience will not be as streamlined (nor as secure) as you may find on Qubes OS. But, Flatpak does offer some sandboxing. And while it may not be as powerful as you may want, and some apps may not utilize portals as they should. Still, it's definitely worthwhile and perhaps the best we've got currently. Furthermore, bubblejail allows you to (relatively easily) utilize (some of) the technology that's used to sandbox Flatpak apps for all your non-Flatpak apps. It can be found on Copr if you choose to stick to Fedora.

On that note, the maintainers of the aforementioned Copr package have built an interesting project for those that seek security-focused (or simply hardened) images of Fedora Atomic; (aptly named) secureblue. It's still a relatively young project, but their innovations have definitely been noteworthy and it seems to have a bright future ahead.

While we're in the vicinity of 'hardened-for-you'-distros, we should mention Kicksecure. By contrast, this is a well-established distro by the people that also develop Whonix.

Without hearing your answers to my questions, I think these two are the primary candidates. Though sticking to Fedora ain't a bad choice either.

so I run sudo nano /etc/default/grub

For improved security during file edits that require root access, it's highly advised to use sudoedit (or sudo -e). This method is considered the standard practice to avoid the security pitfalls associated with directly invoking editors with sudo. To ensure the use of nano with sudoedit, simply set the VISUAL environment variable with export VISUAL=nano before running sudoedit . Alternatively, for a one-off command: VISUAL=nano sudoedit /path/to/file.

Please note that while sudoedit is a safer starting point, it's not the only method available. Alternatives such as doas, doasedit, or leveraging polkit with pkexec can offer even more controlled and secure ways to manage file editing with elevated privileges. However, it's perfectly acceptable to stick with sudoedit, as it's a commonly trusted tool.

Be aware that direct usage of sudo nano or other editors is strongly discouraged. It bypasses important security mechanisms and can lead to inadvertent system-wide risks.

EDIT: changed VISUAL=nano sudoedit to VISUAL=nano sudoedit /path/to/file.

podman does not autostart containers after boot. You have to manually start them, or write a start script. Or create a systemd unit for each of them.

FWIW, I'm on Bluefin-dx (one of uBlue^[1]^'s images) and I've noticed that my containers autostart at boot since I've rebased from Silverblue to Bluefin-dx. Mind you; I'm not necessarily advocating for you to make the switch to Bluefin-dx, but it's at least worth finding out how they've been able to achieve that and perhaps implement their ways for your own benefit.

1. Which are mostly Fedora Atomic images with some QoL and thus SELinux, Podman (etc.) are just baked in as you would expect.

Thank you OP for sharing your evaluations on these distros! Everyone has their own biases, but they can still become valuable whenever more than one item/article is evaluated. Which is exactly what you've done. So kudos to you!

people are asking around about what’s the best distro for a newbie gamer

"newbie gamer" sounds cute. Did you mean newbie to Linux instead? Or perhaps newbie to Linux gaming?

Furthermore, are you also interested into a distro for yourself? Or to recommend to others? Or were you just interested in some of the distros you've been seeing and wanted to try a couple of them out?

I am highly considering using it as a daily driver.

Which would imply that you're at least (somewhat) interested in exploring a different daily driver. Are there any reasons you want to let go of your current daily driver?

Which one(s)

Unsure if distrohopping the dualboot counts, but if it does, then the following was my path (note that after Fedora Silverblue was installed, it remained on the system; the two distros in between the two Silverblues were dualboots):

Fedora Kinoite -> Fedora Silverblue -> EndeavourOS -> Nobara -> Fedora Silverblue

why?

I started with Fedora Kinoite after spending 1-2 weeks on gathering information on distros. During the research-phase, I learned what distros are, their components, how to analyze the differences between distros, which components are ultimately more beneficial for me and thus slowly but surely the distro that would suit me best started to take shape.

My switch to Linux was on the basis of privacy concerns and Windows 10's mishaps on my laptop were what pulled the trigger, which in retrospect were probably caused by hardware faults. Regardless, as privacy was my main concern, security became paramount; as there's no privacy as long as access to your data is not secured off. Therefore Qubes OS, while not necessarily a Linux distro, would have been my first choice. But, unfortunately, my system wasn't capable of running it.

Therefore, I had to settle with something else. As my endgame is Qubes OS, I wasn't very interested in getting into the nitty gritty of Linux for the virtue of hardening it. Instead, I opted to rely on a distro that would do the heavy lifting for me. Such a distro wouldn't only have to be known for taking security very seriously, they also required an excellent track record. As such, I landed on Fedora, Kicksecure and openSUSE. Other projects that are known to take security seriously like Whonix and Tails aren't suited for general use. Furthermore, they're ideally used in conjunction with another system; Whonix as a VM and Tails accessed on a USB-stick whenever you require an amnesic operating system.

Choosing between Fedora, Kicksecure and openSUSE was hard based on these criteria only. The third and final criteria to seal the deal was atomicity. Like I mentioned earlier, my laptop had issues; it could randomly turn off. So I needed a robust system that could handle such disturbances and not die in the process. This is where the aforementioned atomicity comes into play, this ensures that the system either updates or not; no in-between messed up state due to a power outage or whatsoever. At the time, only Fedora had a somewhat mature system capable of atomic upgrades; namely Kinoite and Silverblue. The differences between these two were about their respective desktop environments. I hadn't experienced either of the two previously, but went initially for Kinoite for how KDE Plasma reminded me more of what I was already used to (i.e. Windows).

Fedora Kinoite came with its sets of troubles. It was still a relatively young project; it was the first release in which it was officially supported. As I knew how easy Fedora's Atomic distros made switching from one base to another, I just rebased to Fedora Silverblue with the rpm-ostree rebase fedora:fedora/35/x86_64/silverblue command and went on with my life 😜.

After this came the honeymoon-phase and I was really positively surprised by how well everything was going. From all the things I had done for the sake of privacy, switching to Linux was (and still is) my favorite. But as I was ever expanding my Linux workflow to include everything I did on Windows, I happened to reach a (seemingly) insurmountable obstacle; Davinci Resolve. No matter what I did on Fedora Silverblue, it was always functioning less performant compared to Windows; which in retrospect seems to be related to the fact that Davinci Resolve requires a dedicated GPU on Linux (though some workarounds do exist). In hopes of resolving this issue, I tried to install Arch as a dualboot. As this was pre archinstall, this was a miserable experience. And after a few tries, I still wasn't content with what I got and instead opted to install EndeavourOS.

EndeavourOS was pretty cool. I already liked what I saw from Arch within Distrobox and EndeavourOS was able to deliver an excellent experience (at least initially). Davinci Resolve worked better here than it did in Fedora Silverblue. And it was overall a pretty snappy experience, so I returned to it occasionally for other things (like gaming) as well. Until..., one day..., it just stopped working 🤣. Perhaps I could have done a better job by installing Snapper/Timeshift, but I didn't and didn't care enough for it to reinstall...

Of course, the departure of EndeavourOS did leave behind a void, so eventually I tried Nobara as I believed it might be capable to provide a similar experience. And I did like it, though not to the degree of EndeavourOS. Eventually this one also passed out 🤣.

Currently, I've just dismissed the idea to run Davinci Resolve on Linux and I'm more happy ever since 😜. For better performance during gaming, I've since been resorting to bazzite-arch and Conty. While performance shouldn't be as good as native CachyOS or other highly optimized gaming distributions, it's more than fine as is and the sub 5% performance/fps I'm missing out on is not worth for how much more convenient my current setup is.

FWIW, I do see myself utilizing Gentoo and NixOS in their designated qubes whenever the switch to Qubes OS occurs. But until then, I'm making the best out of Fedora Silverblue.

First of all, I applaud your efforts. Making an all-encompassing guide/flowchart that is able to answer all kinds of needs that new users might have is hard and not done in just a few sittings. And it seems you're willing to iterate a couple more times until you and the community are satisfied with the end result. That's just awesome and highly commendable.

As for my personal critique, perhaps it's noteworthy that I'm not entirely satisfied with the current setup. I think the following would align better with my personal convictions on how I would assist friends and/or family with these matters:

Having said all of that, whatever is mentioned above is a lot more involved than what you have currently. Therefore, I wouldn't be surprised if you would deem most of it out of scope.

Moving on to the actual critique:

• While I (somewhat) understand why you've tried to tie one's preferences in earlier used OSes to a potential desktop environment they might like, I do think that this might set new users up for false expectations. Therefore, I would propose to not even go there. If you want them to make a conscious choice on the desktop environment, then perhaps implore them to boot a live USB environment in which they can explore it themselves. The only important thing to note would be that in all cases customization is allowed and thus they shouldn't necessarily abandon a DE for a minor issue as it's most likely easily solvable.
• If this gets good (and it certainly has the potential), then only the flowchart itself will be shared while the accompanied text might be disregarded. In hopes of ensuring that others also read the accompanied text, consider to either (somehow) include the text in the image of the flowchart or include a link to the text and ensure it's easily found and one is somehow able to easily access the text through the link. This might even require a shortened custom url that redirects to the text. The exact specifics are obviously up to you though.
• I can't agree with the inclusion of both Pop!_OS and Vanilla OS. Don't get me wrong, the potential is absolutely there. But both are currently in a major overhaul and need at least one or two proper releases to mature. Expecting new users to either start with the 'abandoned' old release which they might have to abandon themselves when they move over to the (eventually) matured new release or start with (at best) beta software that may come with a lot more trouble than worthwhile is IMO irresponsible.
• I got a ton of smaller (personal) nitpicks, but most of those are related to scope and/or preconceived notions and therefore not worth mentioning here.