NVIDIA Releases Open-Source GPU Kernel Modules

[bug]

I get it, backwards compatibility can be a damned if you do, damned if you don't kind of situation; I understand that.

But let's face the facts here. Microsoft has tried multiple times to remove backwards compatibility support for older hardware in the past only to be faced with the Internet equivalent of an angry mob with pitchforks and torches. Case in point, Windows 11's removal of support for older processors. They received ungodly amounts of blowback for that. Truly a no-win scenario for Microsoft.

I'm not denying any of that. I'm just saying, they're different approaches and neither is objectively better that the other. Your wish for stable APIs in the Linux kernel just sounds like "grass is greener on the other side" argument to me.

 

[R-T-B]

You can put some of the blame on the Linux kernel itself, namely in the fact that every time you turn around, they change an internal API thus breaking shit. Now if only the kernel had a stable set external APIs that developers would be able to rely on not changing from this week to the next things would be great, but the Linux kernel community is allergic to this idea. Their answer to that issue is to just put your code in the mainline kernel tree and if things happen to break, we'll fix it for you.

But what if you don't want your code to be open source? Oops, sorry. We don't care about you.

And now that nvidia's kernel code is open source, this is a completely moot point really.

Anytime you have a closed binary targeting an actively updated kernel (windows kernel seldom updates) you were going to have a similar issue. It's progress vs stagnation at that point.

 

[trparky]

It's progress vs stagnation at that point.

And then you have the old adage... If it ain't broke, don't fix it. If it works, great. Don't touch it!

 

[bug]

And then you have the old adage... If it ain't broke, don't fix it. If it works, great. Don't touch it!

You're not a software developer, are you?

 

[trparky]

You're not a software developer, are you?

No, not professionally. I do tinker a bit and have written my own programs for my own needs but that's about it. The last big program I had that people were actively using has been retired for years.

 

[bug]

No, not professionally. I do tinker a bit and have written my own programs for my own needs but that's about it. The last big program I had that people were actively using has been retired for years.

Then let me explain why "if it works, don't fix it" doesn't work for software: developers come and go, in a few short years nobody will understand the code, even if it's still working. And working code still needs maintenance, be it for bug/security fixes or dealing with new CPU architectures.
It sucks, I know, but that's just a fact in the software development world. Every single project that I have worked on that was left as it is for 5+ years, inevitably ended up needing a complete rewrite.

 

[trparky]

Then let me explain why "if it works, don't fix it" doesn't work for software: developers come and go, in a few short years nobody will understand the code, even if it's still working. And working code still needs maintenance, be it for bug/security fixes or dealing with new CPU architectures.
It sucks, I know, but that's just a fact in the software development world. Every single project that I have worked on that was left as it is for 5+ years, inevitably ended up needing a complete rewrite.

But that's why a good developer comments his or her code so that later, when someone new comes along, they know what the hell is going on.

That was one thing that they hammered into our heads back when I was taking beginning programming classes in college. Comment your code! And when you're done commenting, comment some more. Make it damned sure that anyone will be able to look at your code and tell what the hell you did.

 

[bug]

But that's why a good developer comments his or her code so that later, when someone new comes along, they know what the hell is going on.

That only works to a degree (and trust me, everything that's not open-source, it's usually very poorly documented). For example, it's hard to document business decisions (e.g. we're not going to support more than 16 channels here, because manager X said we don't need that in prod), because that kind of documentation does not belong in the code. And everything that's not in the code get stale and forgotten.
There's CMMI certifications to work around that, but very few companies bother with those if they're not doing something critical, like software for planes or nuclear power plants.

 

[trparky]

No wonder why the same old tired security flaws keep coming back to bite us in the ass. You'd think that at some point we'd have fixed all the damn bugs already.

 

[bug]

No wonder why the same old tired security flaws keep coming back to bite us in the ass. You'd think that at some point we'd have fixed all the damn bugs already.

There's an additional reason for that. As language grow towards higher level, people just don't learn the basics anymore. For example, I'm working a lot with Java. And Java goes to great lengths to shield the programmer from the platform details and memory management. And when uncle Bob comes out with his "clean code" lecture, what do people understand? Write methods that are no more than dozen lines in length. If they're longer than that, break up the function. As if function calls were for free... Probably today half of the Java programmers don't understand how a function works anyway.

 

[fibre]

You can put some of the blame on the Linux kernel itself, namely in the fact that every time you turn around, they change an internal API thus breaking shit. Now if only the kernel had a stable set external APIs that developers would be able to rely on not changing from this week to the next things would be great, but the Linux kernel community is allergic to this idea. Their answer to that issue is to just put your code in the mainline kernel tree and if things happen to break, we'll fix it for you.

But what if you don't want your code to be open source? Oops, sorry. We don't care about you.

When Qualcomm drivers are already compiled, it's not only about API compatibility, but mainly about ABI compatibility which is even stricter. Since Linux kernel needs to evolve and the architecture is monolithic, it needs to break internal APIs, but keep external API (for userspace) stable. But it can't be that hard to assign two people to maintain drivers, right?