> You don't see Windows driver developers having their drivers broken by updates every few months.

At the cost of Windows kernel development being a huge PITA because effectively everything in the driver development kit becomes an ossified API that can't ever change, no matter if there are bugs or there are more efficient ways to get something done.

The Linux kernel developers can do whatever they want to get the best (most performant, most energy saving, ...) system because they don't need to worry about breaking someone else's proprietary code. Device manufacturers can always do the right thing and provide well-written modules to upstream - but many don't because (rightfully) the Linux kernel team demands good code quality which is expensive AF. Just look at the state of most non-Pixel/Samsung code dumps, if you're dedicated enough you'll find tons of vulnerabilities and code smell.

>no matter if there are bugs or there are more efficient ways to get something done.

Stability is worth it. After 30 years of development the kernel developers should be able to come up with a solid design for a stable api for drivers that they don't expect to radically change in a way they can't support.

Stability is worth it to you. Others can hold different opinions and make different decisions, and until and unless you -- or someone like minded -- becomes the leader of a major open source kernel project used in billions of devices, the opinions of those others will rule the day.

All developers love stability of the platform they are building on. Good platforms recognize this.

Because the kernel developers are not beholden to chipset manufacturers who want to spend the shortest possible time writing a close-source driver and then forgetting about it. They're there to work on whatever they enjoy, as well as whatever their (paying) stakeholders care about.

The solution to all this is pretty simple: release the source to these drivers. I guarantee members of the community -- or, hell, companies who rely on these drivers in their end-products -- will maintain the more popular/generally-useful ones, and will update them to work with newer kernels.

Certainly the ideal would be to mainline these drivers in the first place, but that's a long, difficult process and I frankly don't blame the chipset manufacturers for not caring to go through it.

Also, real classy to call the people who design and build the kernel that runs on billions of devices around the world "lazy and incompetent". Methinks you just don't know what you're talking about.

Chipset providers are not interested in showing off their trade secrets to the entire world.

>Also, real classy to call the people who design and build the kernel that runs on billions of devices around the world "lazy and incompetent"

I never did that. The parent comment did call manufacters that and I suggested that the kernel developers are at some fault.

It's less kernel developers then a certain subset of companies providing proprietary drivers only.

Most linux kernel changes are limited enough so that updating a driver is not an issue, IFF you have the source code.

That is how a huge number of drivers are maintained in-tree, if they had to do major changes to all the drivers every time anything changes they wouldn't really get anything done.

Only if you don't have the source code is driver breakage an issue.

But Linux approach to proprietary drivers was always that there is no official support when there is no source code.

Why stop at kernel space. You might as well break all of user space every so often. If everything is open source it shouldn't be an issue to fix all broken Linux software right?

People don't want you to break their code.

> You might as well break all of user space every so often. If everything is open source it shouldn't be an issue to fix all broken Linux software right?

What an uninformed take.

The Linux kernel has a strict "don't break userspace" policy, because they know that userspace is not released in lock step with the kernel. Having this policy is certainly a burden on them to get things right, but they've decided the trade offs make it worth it.

They have also chosen that the trade offs involved in having a stable driver API are not worth it.

> People don't want you to break their code.

Then maybe "people" (in this case device manufacturers who write crap drivers) should pony up the money and time to get their drivers mainlined so they don't have to worry about this problem. The Linux kernel team doesn't owe them anything.

>because they know that userspace is not released in lock step with the kernel

They also know out of tree drivers are not released lock step with the kernel.

>They have also chosen that the trade offs involved in having a stable driver API are not worth it.

It sucks for driver developers to not have a stable API regardless if they think its worth it or not.

>should pony up the money and time to get their drivers mainlined so they don't have to worry about this problem.

They don't want to reveal their trade secrets.

>The Linux kernel team doesn't owe them anything.

Which is why Google ended up offering the stable API to driver developers.

It happens all the time with Glibc, Glib, GTK, Qt, etc

Those breaking changes often are years apart which I sn much better than what the kernel currently offers.