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