jrgd

I did accidentally type the relevant command incorrectly, forgetting that sudo swaps the user before subcommands like whoami will resolve. So that command attempted to add the kvm group to 'root' rather to your user. I have fixed the command in the relevant comment for anyone else reading this thread. You can try sudo adduser "<username>" kvm, manually substituting for your username. As normal, restart after adding the group to your user. Additionally, I have added a warning to the solution in the original comment of why you may not want to keep this solution enabled forever as well as a way to disable it later if desired.

Rockbox unfortunately is built with "dinosaurs" in mind. As a side effect, the project does not intend to properly handle modern ID3, Vorbis tags.

I could use an older Android phone, but would have to find a suitable device to de-Google and load a custom music player app onto (such as Vinyl). Neither my Pixel XL nor Pixel 5a that I own currently are suitable targets (neither have microSD support, my Pixel XL has a damaged headphone jack and needs to be repaired). If you have any recommendations for something used that has a headphone jack, microSD slot, and can bootloader unlock via adb, let me know.

Based on using a local installation without elevated permissions (outside of /usr/(local)), I can only guess of two things happening:

The first is GNOME Boxes asks for elevated permissions when running or otherwise uses Polkit to gain those permissions. Your user by default likely isn't granted access to /dev/kvm and running userland software without additional permissions will inherently not allow KVM access.

To allow this sanely, you can add your user to the KVM group to allow userland KVM access. It can be done via sudo adduser "<username>" kvm and then restarting your computer. To note, this is something that can allow any application to access virtualization without special permissions. If you don't want this change to remain forever, the command sudo usermod -r -G kvm "<username>" followed by a restart can revert this change.

Alternatively, installing Android Studio via the Flathub Flatpak may handle permissions without needing to modify user groups in this case.

The second (unlikely, but possible) problem is the AppArmor profile blocking KVM access for userland. I don't have particularly any experience with creating modified profiles for AppArmor, if this is the cause. I could only offer terrible advice for AppArmor (disabling AppArmor or switching to warn-only, both things I do not recommend doing). Again, it might be worth trying to install Android Studio via flatpak to see if things work better if this is the cause.

I am testing this currently to ensure correctness, but if you're using Android Studio via Flatpak, you may need to enable kvm permissions for the application to have hardware-accelerated VMs. This can be done using Flatseal. The relevant permission (device=kvm) is under the Device section labeled as Virtualization.

Additionally, if problems are occurring outside of Flatpak, you might need to enable certain hardware virtualization technologies from your computer's BIOS (AMD-V, VT-x, VT-d, Intel VT, Virtualization, or some other similar term depending on CPU and motherboard).

EDIT: Doing testing, it seems the default permissions provided for Android Studio's Flathub Flatpak includes device=all. No permissions edits are necessary by default. If there are problems with the /dev/kvm device not being reachable, it is almost certainly due to the necessary extensions not being enabled in the BIOS, or your CPU doesn't support virtualization. Pop! OS 22.04 has the necessary components in software for KVM to function pre-installed, so nothing should be wrong on the OS side.

Superior over what exactly? Most workstation/desktop distros have a graphical software manager and handle drivers in a similar manner.

From my experience with a modern Thinkpad (A485); nothing if not outright inferior. The trackpoints on them are pretty terrible compared to classic IBM-era thinkpads (10-20hz polling rate, abysmal velocity curve). The physical durability of the machine might be above-average for business laptops, but the chance of the hardware failing in some major way within warranty seems to be quite high (among other replacement parts, I had 4-5 mainboard replacements done under warranty). The cooling solution on the Thinkpad I used to use was also a fair bit inadequate, and would lead to severe thermal throttling of the mid-range APU. Honestly between the reliability and torturous process to even buy a new Thinkpad from Lenovo, I just wouldn't bother.

On my mobile Lemmy client (Eternity), I already keep a multicommunity group for finding tech support posts in case I have something to offer in response. As it stands with !linux@lemmy.ml, there aren't too many posts that are pure conjecture or information and thus doesn't really clog my feed. If this community grows to have more of these kinds of posts showing up, it may be worth having a split. As it stands currently though, I feel it would mostly serve to significantly lessen what gets posted to this community.

What board/connector is affected? At worst, a replacement connector and a soldering iron should be able to replace the damaged connector and get your printer in a functional state.

UPDATE: if you are referring to certain mainboard connectors, it may be best to replace the mainboard if you don't have the tools for replacement. I see surface-mount connectors for some things on the mainboard that can be difficult to replace correctly without more unique tools.

Systemd is both in a lot more large distros than just Fedora, RHEL and has limited viable alternatives (OpenRC as a partial replacement, no others I can think of that come close). While it has its issues particularly with the extra bundled services of mixed quality, SystemD is generally a flexible and suitable option for service management on Linux.

Not to mention how inflammatory the parent comment is.

NMap through a terminal emulator like Termux?

GrapheneOS only publishes updates for devices with active security updates. Your device is EOL and therefore won't receive any further mainline updates. It still will receive extended support from the Android 14 legacy branch with whatever security patches arrive in upstream AOSP, but unlikely to see device-specific patches nor firmware patches. Your device isn't getting the same care and attention that active devices are receiving nor will it receive any future versions of Android through GrapheneOS.

The last update to the game destroyed the usability of its positional audio among other things. The developers have remained silent on all channels beside their Discord about future game updates or content. The game hasn't been updated for about a year now.

Additionally, ome people have complained about getting banned from the in-game chat for allegedly "no reason". No idea if even half of these people are being truthful or were actually banned for things like saying racial slurs.