As I’ve commented elsewhere on this post and others have said, this is a change that affects pretty much no one. I didn’t even know MBR (legacy BIOS) partition tables on UEFI boot was possible, honestly.
By no longer putting in the effort to maintain this bit that no one uses, work can be put to something someone uses.
Also, with Linux, specific distros can get encrapified (kind of happened to Ubuntu), but as others have said, there’s usually always another distro to jump to at worst.
For those panicking about it, this is not something you need to worry about. Here’s what this actually does:
Enforce the use of GPT partition tables for all UEFI-based Fedora installations for x86 architecture. This removes support for installing Fedora in UEFI mode on MBR-partitioned disks on x86 systems
You probably have already been using GPT on your UEFI system since you had a UEFI system. Even if you somehow were using MBR, this probably;
As much as I resonate with the issues, in this case, this isn’t what they’re doing at all.
This drops support only for UEFI on the MBR partition scheme typically used by a BIOS setup, which I honestly didn’t even know was possible.
This ends support for no hardware - almost all distro installations on UEFI have defaulted to GPT partition tables for a long time.
That’s not what this is saying.
It’s only support for UEFI on the old MBR partition table - GPT partitioning has been the default for ages now.
I think is is more a c/Risa thing.
Also used it before, for Rounds I believe.
You're right that it was power-related - one of the options was an ASPM modification - but the issue seemed to be common to this chipset accross laptop brands.
The fix I used came from this post: https://bbs.archlinux.org/viewtopic.php?id=286109
My machine was a Thinkpad, but this article was also talking about problems on HP, Asus, etcetera. I think the 8852BE might just be cursed
To be fair, I was using an E series Thinkpad, but in my defense, the E series seems to have improved a lot in the past few years - this was luckily the only issue I've had. I've had much more difficult times with Linux on other laptops. Heck, even my desktop had more setup than this when I was first starting out, though it was because I was using a Broadcom Wi-Fi card, as I also dual-booted with a Hackintosh and macOS only supports Broadcom Wi-Fi chipsets.
Otherwise agree, but I did run into pain with Realtek on my Thinkpad - the module would sometimes crash and disconnect entirely (on a PCI-e level) from the system.
I did manage to find a fix, but I would not recommend Realtek to someone.
I once experimented with something similar, except it was supported to trigger my smart speaker and drop into another part of the house to tell me.
Honestly, I really need to replace my proprietary smart speaker system with something self-hosted; it’s just I only recently have had the time to start cinsidering.
Vulnerabilities certainly do exist, but I’m pretty sure the attacker has to be well-equipped
I’d call it a protection against data getting cracked in a petty theft, but if your attack vector is much more than that, there are other measures you should probably take. I think Clevis also works with Yubikeys and similar, meaning the system won’t decrypt without it plugged in.
Heck, I think I know someone who just keeps their boot partition with the keys on it on a flash drive and hide it on their person.
In my case, no; it’s all a single machine - it is in the initramfs and uses the system’s TPM to (relatively) securely store the keys.
It can be set up with an attestation server, but you certainly don’t have to do it. The Arch wiki has a really good article on getting it set up.
And that is still largely true - I’m still running XFCE with xorg on Debian, and I think the only issue I’ve had was Waydroid.
Will there come a day where what you say is true? Yes.
However, right now, a more apt example to convey your point is systemd; that’s true for most distros with a lot of community support. Even then, its hold isn’t absolute - Alpine seems like the most livable non-systemd distro, though I could be wrong.