Ultimately, it’s for you to decide whichever suits you best. But I understand why that initial impression may have made you cautious.

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

Links to bug reports are found below:

• https://bugzilla.redhat.com/show_bug.cgi?id=2263934
• https://bugzilla.redhat.com/show_bug.cgi?id=2262577

In both cases, the kernel has been assigned as component.

Alright. Thank you for reporting back!

Uhmm…, so, the good thing is that it’s reproducible, a bug report has already been issued for it and should (therefore) eventually get a fix in upstream. The bad news, however, is that you may experience the same issue on every other relatively bleeding edge distro until then… But, there are two ways around it:

1. Just reboot by shutting off 🤣.
2. Or…, switch to Nobara. Some users reported the bug to its maintainer and they’ve fixed the issue on Nobara since. It’s conceivable that the fix may already be found on other distros as well, but it’s definitely fixed on Nobara. Thankfully, Nobara is based on Fedora. So you shouldn’t feel too far away from home ;).

Thank you for the reply!

I’ve tried rebooting it like that.

And…, what’s the result? Does the problem persist? Or is it resolved? (Under strict adherence to rebooting as described*)

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 am aware that Homebrew has become the go-to solution for installing CLI applications on Bluefin. Which is exactly why I feel compelled to ask the question in my previous comment.

Btw, I don’t really understand why you felt the need to share Jorge Castro’s blog post on Homebrew? AFAIK it doesn’t go over any security implications. Sharing the article would only make sense if Jorge Castro is regarded as some authority that’s known to be non-conforming when security is concerned. While I haven’t seen any security related major mishaps from him or the projects he works on, the search for the CLI-counterpart to Flatpak seemed to be primarily motivated by facilitating (what I’d refer to as) ‘old habits’; which is exactly what Homebrew allows. It’s worth noting that, during the aforementioned search process, they’ve made the deliberate choice to rely on Wolfi (which is known for upholding some excellent security standards) rather than Alpine (which -in all fairness- has also been utilized by Jorge for boxkit). IIRC, people working on uBlue and related projects have even contributed to upstream (read Distrobox) for patches related to Wolfi. So, there’s reason to believe that the uBlue team takes security seriously enough to work, contribute and deliver on more secure alternatives as long as it doesn’t come with a price to be paid by convenience. Which, in all fairness, is IMO exactly why Homebrew is used for in the first place (besides their recent utilization of technologies that have similarities to the ‘uBlue-way’ of doing things)…

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 😊!

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.