Most of the chips in a smartphone are made by Qualcomm, both processors and peripheral chips like 5G modem, LTE modem, WiFi, and Bluetooth. Qualcomm chips require proprietary binary blobs to function, and usually only have a support lifetime of about 2 years. They also only supply those blobs to the manufacturer of the device.
To be clear, these are game problems, not NVDIA GPU problems. Some games only work on Windows and need to use a translation wrapper, which has overhead.
Oh yeah definitely. It’s a slow EInk Android tablet on a very old version of Android. If you need more than just an EReader it’s the only reputable brand.
I don’t think you’ve used anything but a Boox in a long time, and have forgotten what the standard is. Boox has 1/10 the battery life, takes forever to wake up, and doesn’t support deep sleep properly (so it either drains battery when sitting idle, or shuts off entirely taking 5+ minutes to power back on). It’s decent hardware with very badly designed software. Neither Kobo or Kindle devices have these problems, they have battery that actually lasts, deep sleep when idle for any length of time, and power back up, even from deep sleep in 10 seconds or less.
Except so far the only time they’ve actually gotten any fines paid by anyone significant, the initial multi-billion euro fine on Meta was settles for only a few hundred million euro after half a decade of litigation and ended up including all subsequent fines in what was forgiven despite them continuing the activity. In theory it should dissuade them, but the companies being fined that really deserve it have annual profits greater than most countries’ GDPs. They can litigate indefinitely against the entire EuroBlock and keep making a profit from the activities while doing it.
Bluetooth protocol support for audio is a bit of a mess, and many Bluetooth devices (especially knock off or no-name budget brand headphones/headsets) skimp on applying the standard properly.
Absent the absolute latest Bluetooth standard support (5.3 or better), you’re usually limited by the protocol to very poor quality audio. It gets even worse of your device shows up as a headset inst4ad of heaphones/speaker since it has a mic return channel crammed into the very restricted bandwidth too. The way (mostly quality) vendors have worked around this prior to the latest Bluetooth protocol versions was to use raw data channels with negotiated compression formats and a special “escape hatch” protocol supported by Bluetooth (A2DP). Both sides had to negotiate a shared compression algorithm and implement it for sending the compressed audio so it could be decided at the destination. Poorer quality or older headphones, and older Bluetooth Linix stacks didn’t do this very well.
Not sure if any of that is applicable, but in general Bluetooth is always worse quality than wired because of bandwidth restrictions. And until Bluetooth 5.3 that added LE Audio and a related very efficient audio compression algorithm, it was a compatibility crap shoot.
Far and away the biggest thing I can recommend: Use the same distro yourself. If there ever are issues, you’ll almost certainly encounter them first and know how to fix them quickly. Ideally use it yourself for a bit before you put it on your mom’s computer so you can find any initial issues too.
I experienced that only when doing expert things on my system like trying to install new drivers.
I’ve been using 4 different immutable distros for a few years and literally the only “breaking” thing was when UBlue distros moved to Fedora 42, which no longer allowed you to use the ostree admin unlock --hot-fix hack to directly modify your system and made you build your own modified variant using their GitHub template repo.
I’m actually moving my wife to a UBlue distros specifically because I set it up remotely and it just auto updates.
I will warn however that Flatpaks can be a nightmare for basic things like browsers if you want to do things like use a webcam, microphone, or, god forbid, a USB device. Make sure you manually set that up in the (probably flatpak) you’re using before handing it over (probably by using Flatseal).
SELinux is used on all the Fedora Immutable distros, and the OpenSUSE Immutable distro. It’s actually much easier to do SELinux in Immutable distros in a lot of ways than non-immutable. Especially the bootc-style ones where even more of the system is defined and prebuilt before deployment.
AppArmor is OK, but the whole issue is that you have to know what to throw into it. That’s also its benefit, you can focus in the high risk things and ignore the low risk things. It keeps expanding profiles more and more though, and ironically the ultimate destination is everything being under MAC.