> 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.
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.
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.
>You can doubt it all you want, ISDN is used internally in broadcast all over the world
Since you claim to be a domain expert, give me hard named examples with independently verifiable links. At this stage I want facts, not anecdotes.
Because right now, my semi-educated guess is they are all using IP-based streaming codecs and protocols for remote contributions, outside broadcast, studio links and pretty much everything else under the sun.
No, he's right. I have a friend who does voiceover work and is and announcer for the UK Channel 4. He does all his work from home using an ISDN link. It's a huge pita for him because the telcos don't want to know indeed, but it's the usual story with legacy workflows.
I think it's also a fully switched system so you are guaranteed bandwidth with no packet drops or buffering which is clearly useful for broadcast work.
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.
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
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.