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

traceroute66 5 hours ago | parent | next [-]

> 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.

▲

devmor 3 hours ago | parent [-]

> Who, for example, still uses ISDN in 2026?

Most TV and radio stations.

▲

dezgeg 33 minutes ago | parent | next [-]

Do they use it via mainline Linux kernel's ISNDN drivers though (and not something proprietary)?

▲

traceroute66 3 hours ago | parent | prev [-]

> Most TV and radio stations.

I doubt it. And as I said, telcos have ceased new sales of ISDN and will be shutting down copper networks within 3–5 years.

Therefore if there are still TV and radio stations still using it, they will be forced to stop using it by circumstance, i.e. they will find their ISDN will cease working after the telco shuts down the kit in the exchange.

	▲	devmor 2 hours ago \| parent [-]
		You can doubt it all you want, ISDN is used internally in broadcast all over the world. Telcos shutting it down has nothing to do with them and won’t affect them. Losing support in software however, does.

▲

sigmoid10 5 hours ago | parent | prev | next [-]

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

	▲	bastawhiz 4 hours ago \| parent [-]
		You're being downvoted but I think you're right in a lot of ways. If you read through the patches for some of the removals, the reasons come down to: - Nobody is familiar with the code - Almost all of the recent fixes are from static analysis - Nobody is even sure if anyone uses the code This feels a lot like CPython culling stdlib modules and making them pypi packages. The people who rely on those things have a little bit of extra work if they want a recent kernel version, and everyone else benefits (directly or indirectly) by way of there being less stuff that needs attention.

▲

fluidcruft 5 hours ago | parent | prev | next [-]

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.

▲

goalieca 4 hours ago | parent | prev | next [-]

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.

	▲	catlifeonmars 3 hours ago \| parent [-]
		Would you say the vast majority are back seat drivers?

▲

baq 4 hours ago | parent | prev [-]

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