I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem?
> now we're left with useless crap in the kernel.
The article is specifically about removing the now-useless crap, and the removal patches were submitted by Intel. I don't see how Intel is doing anything wrong here.
Presumably deleting code is not very hard if it is unmaintained or a burden.
> Why can't these companies just build their own modules? Why is it everyone else's problem?
They're not upstreaming this so their own internal dev lives are easier. They'd rather just keep using whatever development repo they already are without dealing with upstream reviews and requirements. They were upstreaming this so that everyone could have support for the hardware upon release.
And, to that end, "corporations" upstreaming high quality support for their hardware, as intel has been doing, benefits linux. Throwing shade at them for preparing day-1 support for hardware they ended up canceling seems counter-intuitive.
Partially because in difference to the strict backward compatibility guarantees of the Linux user interface there are no such (strict) guarantees for the kernel interface.
In the end this is both grate for Linux and Intel (and Nvidea, Amd, etc.):
- kernel developers can make sure their code doesn't brake vendor code, this isn't just about being nice to vendors but about being able to do large internal refactoring which affect many/all kernel modules in a small way (good for both, in case of not yet released and in rare cases internal only hardware mainly for the vendor)
- kernel developers can see how the kernel is used and where there might be problems with the current kernel interface and design (good for Linux)
- kernel developers can enforce a certain minimal level of code quality or not allow hacks which would lead to serve security issues or incompatibilities (good for Linux)
- it's much easier to make sure that different drivers/kernel modules don't conflict in subtle ways (good for both Linux and vendors)
- customers buying the hardware often can use it from release date without needing custom kernels (good for everyone)
- abandoned drivers/modules can be picked up and maintained by 3rd parties allowing longer usage of otherwise no longer supported hardware
Lastly while companies like Intel do not own Linux they are some of the main contributors of financial resources often more then covering any additional costs caused by this (I mean for server hardware and more powerful embedding hardware Linux strongly dominates the marked and it's also one of the main markets for Intel, Amd, Nvidea and one of the main building blocks for companies like Google).
Anyway this is good for everyone and in _total_ reduces the amount of work involved in making Linux work with all kinds of hardware.
And as everyone else has told you, this is so that support for hardware is in Linux and in distros BEFORE users have to taint their kernels and create crazy bugs kernel devs have to deal with.
Only if you adhere to their standards, until very recently you couldn't even do rust. If i made something fully working in rust today it still wouldn't get accepted.
And the reason for that is mostly that providing a stable interface is a) a ton of work, and b) would make distributing closed source drivers easier which is something Linus hates.
Furthermore the whole point of modules on Linux is that you can completely disable them, or if they're built as modules they'll only be loaded if needed (in some cases this is done on-demand automatically if the relevant hardware is detected, in other cases it might be done via logic in your initrd).
To get the code ready for when the hardware is available.
> I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem?
A lot of companies and individuals can step up to maintain the code once it's there and working. If it's important, they will and they have. Only dead-dead systems like the 80386 get removed; or, in this case, vaporware that never materialized to begin with.
Modules are bad because they're code that isn't subject to the same review as normal kernel code, may be closed-source or under some obnoxious license, and probably is going to be more difficult to install than just a kernel update.
So we want it to be "everyone else's problem" because that means anyone else can step up if a company fires the people maintaining the code for hardware the kernel team still wants to support. With a module, it might be the case that the module only works on some range of kernels and is very difficult to replicate its functionality on more modern ones once the original company drops out. That's not a good position to be in if you rely on being able to run modern Linux on that hardware.
Because if it gets truly abandoned, the kernel folk are generally pretty good at ripping it out. And the idea is that supporting weird cases off and on will lead to a more general kernel that will be able to attack future needs for everyone a little better.