You could probably build a tool that assesses the risk of any given PR based on this and several other signals. PRs with enough risk should require justification and sign off.
This is from the article: „If there are any genuine users of these drivers remaining that are still running an upstream kernel, the drivers can always be reverted / merged back but otherwise they are gone without anyone maintaining them.“
blackstrat@lemmy.fwgx.uk
on 30 Nov 16:31
nextcollapse
Why clear them out if they still work and are useful? Seems like a backwards step. What’s that phrase that people throw about:sometimes things are just done and don’t need changing.
MyNameIsRichard@lemmy.ml
on 30 Nov 16:40
nextcollapse
As the kernel moves on changes could be introduced that make them difficult to compile with the new kernel. Unmaintained doesn’t only mean not adding new features, it means keeping up with the rest of the code.
BastingChemina@slrpnk.net
on 30 Nov 17:42
nextcollapse
From another article
The GDM724x is removed for supporting the GCT GDM724x LTE chip based USB modem devices. This driver was merged back in 2013 but is being removed now as the driver isn’t being maintained and yields a maintenance workload, the manufacturer GCT doesn’t respond to any emails/support, there doesn’t appear to be any of the said chips easily available for purchase, there is not any hardware documentation available, and no apparent usage of this driver remaining in the Linux community. Removing the driver clears out 3.6k lines of code and lowers the maintenance burden for other kernel developers.
There was also a vulnerability discovered in July linked to this driver.
So yeah I understand that they chose to remove some drivers from the kernel.
But that’s true of all code in the kernel. If any change can break something then all broken bits will need fixing. Why not remove all drivers in case an update breaks them. Things can’t be preemptively fixed before breaking changes are made. A driver can be complete and only need updating if someone else breaks stuff, so leave it alone until then and only remove it I’d no one comes to fix it.
If any change can break something then all broken bits will need fixing.
Right. So the less decrepit, old code that contains annoying little time bombs, the less time spent fixing things.
But that’s true of all code in the kernel. […] Why not remove all drivers in case an update breaks them.
And how many people actually need these ancient drivers maintained? More than zero, sure, but how many more than zero?
Maintenance effort is a finite resource. Choosing where it gets spent is an executive decision. Every dev hour you assign to debugging some ancient driver that one or two enthusiasts might still want someday is a dev hour not spent on development of some new feature, or fixing a problem affecting thousands, potentially millions of known, current, active users.
We can’t maintain all code forever. At some point the theoretical value it may have is outweighed by its cost to keep alive, and it gets cut.
A driver can be complete and only need updating if someone else breaks stuff, so leave it alone until then and only remove it I’d no one comes to fix it.
That’s sort of where we’re at now, in a way.
Yes, all of these drivers presumably are still fully functional at the time of cutting. But the devs have essentially all decided, “We are not fixing these anymore” already. If any of these break for any reason, they would all be immediate candidates for axing by your system.
The reason they aren’t just left in with a “we’ll just run it until it dies, then!” mentality is because a project like the Linux kernel doesn’t want to be full of software with undefined mystery behavior where they can reasonably avoid it.
A chunk of code being part of it at all is an implicit promise of, “This is intended to function as-documented. If it does not, we are responsible to fix it.” But we already know no one will fix it. So instead it just becomes, “This chunk of code may or may not work. We don’t know and we don’t care, lol. Use at your own risk. If you can prove it’s broken, we’ll just remove it”.
The Linux kernel does not want to be full of code like that. All of its code should be reliable to build things on. If it’s coming out, it needs to be announced in advance so users have time to migrate. A “we will run it until it suddenly breaks” system doesn’t afford that. The feature ideally has to be sunset while it’s still functional.
“Unstable code, use at your own risk” projects are better relegated to optional packages. If someone wants to bundle up these ancient drivers and offer them as an optional package, they are free to do so. If there ends up being zero will from anyone to do even that, I guess it’s more evidence to how little the functionality was actually demanded.
They don’t just decide to remove a driver on a whim, there’s a whole process which involves reaching out to the original maintainers and seeing if anyone else wants to take it on among other things. Internet search is so poor these days, I can’t find the information on it.
No. The less code for a given set of functionality the better… often. Removing functionality just to reduce code is daft. Otherwise stop adding any features. Remove all features of the kernel until machines only just boot. Lot less code!
the less code the better because the more code the higher the maintenance burden
keeping code around isn’t free. it makes refactoring harder, it makes compilation times longer, it makes the kernel larger, it makes it harder to guarantee device compatibility. that’s all part of maintaining software, but it makes no sense to waste work maintaining shit noone is using, work that could’ve been used to implement new features and/or maintain existing code that’s actually in use
what the kernel is doing is the correct approach. unless they’re sure there’s someone using the thing: old, unmaintained code = bin
petsoi@discuss.tchncs.de
on 30 Nov 18:17
nextcollapse
Unmaintained code in the kernel is really bad due to possible vulnerabilities. If you want to keep it, it must be maintained.
ProgrammingSocks@pawb.social
on 30 Nov 21:47
nextcollapse
Have you SEEN the base install size for Windows 11?
because nobody is updating them and the one person that did before was seemingly the only user. Nobody could find any evidence of it being used. When was the last time you ever heard about fieldbus?
the article mentions support for a another interface is also being added, for lab equipment that actually does still get used.
threaded - newest
Deleting 107k lines of code is so much more based than adding 107k lines
It really is. I always make a note to point out how much code is removed in PRs I review
Code is a liability.
You could probably build a tool that assesses the risk of any given PR based on this and several other signals. PRs with enough risk should require justification and sign off.
Wait I was using one of those drivers!
o well
Heads will roll if my LS-120 drive stops working!
Is there somewhere to get these drivers if you want to run really old hardware?
Running an older kernel isn’t an option? Otherwise compiling your own kernel with the drivers should be possible I assume.
Someone could publish them as dynamic kernel modules.
I was devastated when I couldn’t use my floppy drives anymore.
The Software Publishers Association has finally won:
It is no longer possible to copy that floppy. :-(
Does this have anything to do with the recent removal of Russian maintainers?
No
This normal for staging merge?
Yay bloat be gone \O/
This seems like a bad idea… What about people using hardware that needs those
This is from the article: „If there are any genuine users of these drivers remaining that are still running an upstream kernel, the drivers can always be reverted / merged back but otherwise they are gone without anyone maintaining them.“
All well and good for people who know how to do that
A lot of users won’t even know what a kernel is let alone why their printer has stopped working or that they need to raise a GitHub issue
You’re very mistaken if you think the kernel in your IoT device ever got updated beyond what it shipped with.
The truth hurts.
These aren’t printer drivers, but drivers for a Meson coax NIC that hasn’t been in business for a decade type of thing.
Really popular old drivers stay for a loong time, like the floppy driver that just got removed last year.
Nobody needing a modern kernel is using a floppy drive.
I reserve the right to use my copy of “Mario is Missing!” from 1993.
.
Why clear them out if they still work and are useful? Seems like a backwards step. What’s that phrase that people throw about:sometimes things are just done and don’t need changing.
As the kernel moves on changes could be introduced that make them difficult to compile with the new kernel. Unmaintained doesn’t only mean not adding new features, it means keeping up with the rest of the code.
From another article
There was also a vulnerability discovered in July linked to this driver.
So yeah I understand that they chose to remove some drivers from the kernel.
But that’s true of all code in the kernel. If any change can break something then all broken bits will need fixing. Why not remove all drivers in case an update breaks them. Things can’t be preemptively fixed before breaking changes are made. A driver can be complete and only need updating if someone else breaks stuff, so leave it alone until then and only remove it I’d no one comes to fix it.
Removing functionality just in case is daft.
It’s a divesting of unwanted responsibility.
Right. So the less decrepit, old code that contains annoying little time bombs, the less time spent fixing things.
And how many people actually need these ancient drivers maintained? More than zero, sure, but how many more than zero?
Maintenance effort is a finite resource. Choosing where it gets spent is an executive decision. Every dev hour you assign to debugging some ancient driver that one or two enthusiasts might still want someday is a dev hour not spent on development of some new feature, or fixing a problem affecting thousands, potentially millions of known, current, active users.
We can’t maintain all code forever. At some point the theoretical value it may have is outweighed by its cost to keep alive, and it gets cut.
That’s sort of where we’re at now, in a way.
Yes, all of these drivers presumably are still fully functional at the time of cutting. But the devs have essentially all decided, “We are not fixing these anymore” already. If any of these break for any reason, they would all be immediate candidates for axing by your system.
The reason they aren’t just left in with a “we’ll just run it until it dies, then!” mentality is because a project like the Linux kernel doesn’t want to be full of software with undefined mystery behavior where they can reasonably avoid it.
A chunk of code being part of it at all is an implicit promise of, “This is intended to function as-documented. If it does not, we are responsible to fix it.” But we already know no one will fix it. So instead it just becomes, “This chunk of code may or may not work. We don’t know and we don’t care, lol. Use at your own risk. If you can prove it’s broken, we’ll just remove it”.
The Linux kernel does not want to be full of code like that. All of its code should be reliable to build things on. If it’s coming out, it needs to be announced in advance so users have time to migrate. A “we will run it until it suddenly breaks” system doesn’t afford that. The feature ideally has to be sunset while it’s still functional.
“Unstable code, use at your own risk” projects are better relegated to optional packages. If someone wants to bundle up these ancient drivers and offer them as an optional package, they are free to do so. If there ends up being zero will from anyone to do even that, I guess it’s more evidence to how little the functionality was actually demanded.
They don’t just decide to remove a driver on a whim, there’s a whole process which involves reaching out to the original maintainers and seeing if anyone else wants to take it on among other things. Internet search is so poor these days, I can’t find the information on it.
the less code the better
No. The less code for a given set of functionality the better… often. Removing functionality just to reduce code is daft. Otherwise stop adding any features. Remove all features of the kernel until machines only just boot. Lot less code!
the less code the better because the more code the higher the maintenance burden
keeping code around isn’t free. it makes refactoring harder, it makes compilation times longer, it makes the kernel larger, it makes it harder to guarantee device compatibility. that’s all part of maintaining software, but it makes no sense to waste work maintaining shit noone is using, work that could’ve been used to implement new features and/or maintain existing code that’s actually in use
what the kernel is doing is the correct approach. unless they’re sure there’s someone using the thing: old, unmaintained code = bin
Unmaintained code in the kernel is really bad due to possible vulnerabilities. If you want to keep it, it must be maintained.
Have you SEEN the base install size for Windows 11?
because nobody is updating them and the one person that did before was seemingly the only user. Nobody could find any evidence of it being used. When was the last time you ever heard about fieldbus?
the article mentions support for a another interface is also being added, for lab equipment that actually does still get used.
xkcd.com/1172/
this is so supremely cursed