A good one. I’ve also made an attempt before with this during the Patrick Starship Enterprise fiasco/masterpiece:

I should do one without SpongeQuimp, though.

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.

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;

1. Won’t break existing installations, as it’s merely support for installs of this type
2. Would not be a problem even if somehow the broke existing installs, as it’s not difficult to convert MBR to GPT.

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 posted this one a while back:

Despite that, I think there were some interesting things about that season, and despite the oddness that was that plot, Saru and iPad baby was somehow still enjoyable.

I just feel like they squandered their interesting new setting with season 4 (granted, I haven’t finished season 4); there were so many plots that could have sprung organically from the fall of the Emerald Chain and the rebuilding of the Federation, but no, we have to make up this stupid DMA as a big bad again, and we have to do another plot about dealing with grief.

Heck, we could have kept the DMA and still blown up Booker’s homeworld, but let his family live and instead have written a story about living in diasporas, rather than beating the dead horse that is DISCO’s take on individual grief.

I think is is more a c/Risa thing.

Also used it before, for Rounds I believe.

Now the big question is how do you say, “Rampant cultural appropriation/misrepresentation is Star Trek: Voyager”? 🤣

I mean, I’ve put several They Might Be Giants memes on here by now, so it’s probably fair someone else puts something out.

I am sorry I didn’t get this until you explained it. Only moderately familiar with Ramones discography.

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.

I use Clevis to auto-unlock my encrypted root partition with my TPM; this means when my boot partition is updated (E.G a kernel update), I have to update the PCR register values in my TPM. I do it with my little script /usr/bin/update_pcr:

#!/bin/bash
clevis luks regen -d /dev/nvme1n1p3 -s 1 tpm2

I run it with sudo and this handles it for me. The only issue is I can’t regenerate the binding immediately after the update; I have to reboot, manually enter my password to decrypt the drive, and then do it.

Now, if I were really fancy and could get it to correctly update the TPM binding immediately after the update, I would have something like an apt package shim with a hook that does it seamlessly. Honestly, I’m surprised that distributions haven’t developed robust support for this; the technology is clearly available (I’m using it), but no one seems to have made a user-friendly way for the common user to have TPM encryption in the installer.

Haven’t purchased it yet. I need to read it, but I’ve had a difficult time tracking down issue 30 in comic book stores - I got behind and have everything else in the other spin off series.

No! Why did you make me aware of this one?! Now I have to acquire it!

Honestly, this might be the best one they’ve ever made; before, I was quite partial to the Janeway one, which I gifted to my mother.