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.

But then again some people use things like Homebrew and pacstall unironically so …

Thank you for mentioning this! Unfortunately a quick search on the internet didn't yield any pointers. Would you mind elaborating upon the security problems of Homebrew(/Linuxbrew)? Thanks in advance 😊!

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.

Thank you for your elaborate answers!

Qubes OS has a very steep learning curve due to its difficult usability, so the answer would be “both”. I am willing to tackle and overcome, but I’m not ready to put in that work yet, if at all.

Qubes OS is definitely more involved than the average distro, so I can understand why you feel that way.

I have a really funny story regarding threat models. When I first got into privacy 2-3 years ago, I had the goal of getting as deep as I could (the “strictest threat model possible”) and work backwards to find out what I was willing to allow.

Hahaha 🤣, very relatable; I almost wanted to learn SELinux for hardening purposes. Thankfully, Qubes OS exists as my endgame, which deterred (most of) the motivation (and need) to comprehend SELinux in the first place.

I have a “subconscious” threat model. I have, over the past week, started working on answering the classic questions. I am trying to protect against “evil” corporations, and such, I must also protect myself against some low level government threats. My threat model “philosophy” is: I will not use a piece of software if it actively goes against me in terms of privacy. Windows, for example, is a pain to try to use while maintaining privacy.

We can work with that, though I kindly implore you to further work out your threat model. It will(/should) give you some peace of mind (or at least a security/privacy roadmap on which you can (slowly but steadily) work towards). If I would have to distill your philosophy, it would be something like "be protected from attacks targeted towards low(er) hanging fruit". Would that be fair?

You are the third person to recommend SecureBlue (I’ve been keeping track), and since it is a “Fedora Atomic spin” (Fedora Atomic as well as Atomic distros in general were also recommended three times each), I believe I will switch to it to see how it is.

Great choice! FWIW, I've also been on it for a couple of weeks now and I've really been enjoying it. Before, I had my own custom image that was built using the (legacy-)template from uBlue. I tried to harden it myself 😅, and I would argue I did and achieved some cool stuff with it. But, it's very clear that my technical knowledge doesn't even come close to that of secureblue's maintainers. I just wish I had rebased earlier 😅.

By the way, I love the mention of GrapheneOS, since that will eventually (finances be blessed) be my main mobile OS

I definitely agree with that sentiment. Btw, FWIW, I know for a fact that at least one individual that's associated with GrapheneOS has 'contributed' to secureblue.

I wish there was a true “Linux alternative to GrapheneOS”.

Hehe, without going into what that actually means and would entail, I agree 😜.

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.

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.