It's very easy to disable Secure Boot, or run shim which is signed by Microsoft and can explicitly boot untrusted code if setup (with local user interaction) to do so.

No, this is not true at all. Microsoft requires their system vendors (Dell, HP, etc) to allow users to enroll their own Secure Boot keys through their “Designed for Windows” certification.

Further, many distributions are already compatible with Secure Boot and work out of the box. Whether or not giving Microsoft the UEFI root of trust was a good idea is questionable, but what they DO have is a long, established history of supporting Linux secure boot. They sign a UEFI shim that allows distributions to sign their kernels with their own, distribution-controlled keys in a way that just works on 99% of PCs.

> It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all failed

This conspiracy was never true and never happened. First off, note that the first version of the thing in the article you’re commenting on relied on a Fedora shim loader which Microsoft signed. Second off, note that almost all modern motherboards let you enroll your own UEFI keys and do not rely on exclusively the Microsoft keys.

The only place this is was becoming an issue for Linux was early Secure Boot implementations where the vendor was too lazy to allow key enrollment, and that era has generally passed.

> It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all

SecureBoot exists on servers too. And that's the domain of Linux, not Windows.

Microsoft should never have had so much influence in SecureBoot but there's no way they're getting rid of Linux on servers. Microsoft is mostly irrelevant there.

> The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.

That's also a weird take. It's antivirus vendors who are going to be fine forever: they rely on Microsoft to write crappy insecure software. And that is a given.