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.

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.

Thank you for the write-up! I liked it overall. Perhaps consider to have like a day in-between proofread sessions. This might have alleviated some passages for which I currently hold some minor nitpicks. It’s clear that you’ve written it with care, but -at least in my case- I notice that my proofreading skills (somehow) are a lot sharper the next day (or something).

VSCodium wouldn’t see that I’ve installed the languages I did, nor find my font (Geist Mono Nerd Font).

Assuming you had VSCodium installed as a Flatpak, perhaps the pointers found in this excellent blogpost could help out with that. FWIW, I succeeded with a similar endeavor without installing the IDE in the Toolbx/Distrobox.

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.

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.

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)?

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.

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.

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.

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.