• 1 Post
  • 8 Comments
Joined 7 months ago
cake
Cake day: February 20th, 2024

help-circle


  • 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 ;).


  • 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)…




  • 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.