41–50 of 130 posts
can such drivers be moved out of kernel? what exactly stops that? why do they even need to be in kernel repo and not brought at/after install time?
People have been asking this question since Linux was first invented…
Seems like there should be some "level of maintenance" metric for modules and distros can pick which they include by default and which are packaged separately based on what they care about. Arch users will build the world but an EL user who needs an unmaintained module would have to explicitly install kmod-isdn or even build it themselves
Xbox/PS controllers, for example. I believe some old RAID controller and WiFi drivers are removed too. Whatever they don't want to support.
> and since nobody stepped up to help us deal with the influx of the AI-generated bug reports we need to move it out of tree to protect our sanity.
This thread from the linux-hams mailing list [2] has more insight into this decision. I guess the silver lining is that, more modern protocols (in userspace), written in modern languages will become the norm for HAM radio on linux now.
[1] : https://lwn.net/ml/all/20260421021824.1293976-1-kuba@kernel....>
[2] : https://lore.kernel.org/linux-hams/CAEoi9W5su6bssb9hELQkfAs7...>
Be real with yourself, do you know anyone using ISA or PCI in 2026? Everything is built on PCI-E except in specific industrial settings or on ancient hardware that's only relevant for retrocomputing. Is anyone using the ATM network protocol anymore? MPLS and MetroE mostly replaced ATM, and now MPLS is being largely supplanted by SDWAN technologies and normal Internet connections. I have been doing networking nearly my entire career in some capacity, the last time I touched X.25 or Frame Relay was in the early 2000s, the last time I touched ATM was in the mid early 2000s... the last time I touched ISDN was in the mid 2010s, and that was an IDSL setup, which is itself a dead technology. The last laptop I owned that had a PCMCIA card slot was manufactured in 2008.
I don't want to see these capabilities completely disappear, but there's no reason they should ship in the mainline kernel in 2026. They should be separated kernel modules in their own tree.
can such drivers be moved out of kernel? what exactly stops that? why do they even need to be in kernel repo and not brought at/after install time?
I wrote and maintained 10GbE drivers for a small company in the 2000s, and just the SHIM file for our driver on Linux to massage over API differences was well over 1000 lines. I think it was close to the same size as the entire driver for one of the BSDs.
They can't maintain the code so they are no longer going to maintain the code.
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.
Realistically, that list of components are mostly things that have not been used in modern computing devices for over a decade. Nothing prevents someone from providing a module from out of the kernel tree to ship these drivers or delivering some of these capabilities in user space, and if they are unused and unmaintained I would rather they're not shipped in the kernel. Be real with yourself, do you know anyone using…
can such drivers be moved out of kernel? what exactly stops that? why do they even need to be in kernel repo and not brought at/after install time?
> why do they even need to be in kernel People have been asking this question since Linux was first invented…
While I know that it may have been a security liability, I'm particularly sad that they're removing the AX.25 module from the kernel. > and since nobody stepped up to help us deal with the influx of the AI-generated bug reports we need to move it out of tree to protect our sanity. This thread from the linux-hams mailing list [2] has more insight into this decision. I guess the silver lining is that, more modern proto…
That's really it. The list of things that "need" to be in the kernel is shrinking steadily, and the downsides of having C code running in elevated privilege levels are increasing. None of that is about LLMs at all, except to the extent that it's a notable inflection point in a decades-scale curve.
The future, and we basically all agree, puts complexities like protocol handling and state in daemons and leaves only the hardware, process and I/O management in the kernel.
Basically, Tannenbaum was right about the design but wrong about the schedule and path to get there.