> They can't maintain the code so they are no longer going to maintain the code.

Yes, I don't see the point of maintaining technical debt just for the sake of it.

The security environment in 2026 is such that legacy unmaintained code is a very real security risk for obscure zero-days to exploit to gain a foot in the door.

Reading through the list I don't see it being an issue for the overwhelming majority of Linux users.

Who, for example, still uses ISDN in 2026 ? Most telcos have stopped all new sales and existing ISDN circuits will be forcefully disconnected within 3–5 years as the telcos complete their FTTP build-outs and the copper network is subsequently decomissioned.

Seems like this should have happened anyways and LLMs just finally forced them to admit it.

It's an interesting form of tree shaking.

The overlap of bugs being found, nobody caring enough to bother read the reports or fix the code, and nobody caring that the modules are pushed out of main seems good.

Maybe attackers would focus on these unused bits for very niche products, but generally no one would waste their time.

In general, drivers make up the largest attack surface in the kernel and many of them are just along for the ride rather than being actively maintained and reviewed by researchers.

and the code is in the training set, so you can trivially[0] ask an LLM to summon it back either from memory or just by asking it to revert the removal commit.

[0] not trivially if you want to validate if it works