NVIDIA Denies Opening Up Its Driver

[Jimmy]

We'll force them to be free.

[Redeeman]

That is the problem. You will kill the goose that lays the golden egg. Most people don't have a problem with proprietary drivers as long as they work and work reliably.

As soon as "they" lock out modules from the kernel the software isn't free as in freedom anymore. Someone else is dictating how I can use the software; end of story. At that point it becomes a fiefdom no better than the people they are "fighting", despite what Stalin... I mean Stallman says.

I don't understand the F/OSS community anymore. They are just as bad as the proprietary companies. There is no middle ground anymore. It's all me me me...
If you start complaining about not being able to use the hardware that you "paid" for then you didn't research the hardware you bought or even read the box. I don't buy Brillo pads and then complain they scratch my bath tub when i clean the tub with them.

patches to stop non-gpl modules from loading is no more "dictating how i can use the software" than some software not having a specific menu entry, despite having the feature..

stop with the useless and extremely bad comparisins, even if the linux kernel blocked the loading of non-gpl modules, you could still load them, you'd just have to excercise you FREEDDOM to do it.

just as gnome isnt removing your freedom when they remove all the features, they merely change their application, you are free to do as you please..

[duby229]

Owing to bugs, I've never had an issue with nVidia's OpenGL implementation. Their hardware is more than capable, unlike Intel's.


Says who?

nVidia's implementation works well enough, it has a few minor bugs, but it works pretty good. Much better then ATi's at this point., but that is besides the point. The point was that anybodies implementation will be adequate as long as it is 100% opengl compatible. That includes open source implementations.

And the vast majority of Linux users.....

[bridgman]

If an end user has to patch and rebuild the kernel in order to run something that is going to have a big impact on commercial users. The real question here is whether the major distros are going to support these changes or not.

This is where the threads always get really philosophical and rathole on the essential difference between "not making something easy to do" and "making something hard to do"

[Redeeman]

nVidia's implementation works well enough, it has a few minor bugs, but it works pretty good. Much better then ATi's at this point., but that is besides the point. The point was that anybodies implementation will be adequate as long as it is 100% opengl compatible. That includes open source implementations.

And the vast majority of Linux users.....

you dont seem to get that there is a vast amount of issues with the nvidia binary driver..

as posted in another thread, you might wanna read:

http://vizzzion.org/?blogentry=819

https://www.linuxfoundation.org/en/Linux_Graphics_Essay

[duby229]

That is the problem. You will kill the goose that lays the golden egg. Most people don't have a problem with proprietary drivers as long as they work and work reliably.

As soon as "they" lock out modules from the kernel the software isn't free as in freedom anymore. Someone else is dictating how I can use the software; end of story. At that point it becomes a fiefdom no better than the people they are "fighting", despite what Stalin... I mean Stallman says.

I don't understand the F/OSS community anymore. They are just as bad as the proprietary companies. There is no middle ground anymore. It's all me me me...
If you start complaining about not being able to use the hardware that you "paid" for then you didn't research the hardware you bought or even read the box. I don't buy Brillo pads and then complain they scratch my bath tub when i clean the tub with them.

That's not fair. Most people dont know the difference between a disc brake and a drum brake either... But what a car manufacturer has the responsibility of doing is choosing the brake that is going to be safest and most practical for the end user.

In every single possible way Open source drivers are the safest and most practical implementation. The sole requirement is 100% opengl compliance. An open driver is fully capable of providing exactly that.

Blue sky is what ATi, nVidia, and Intel have to worry about.

[duby229]

If an end user has to patch and rebuild the kernel in order to run something that is going to have a big impact on commercial users. The real question here is whether the major distros are going to support these changes or not.

This is where the threads always get really philosophical and rathole on the essential difference between "not making something easy to do" and "making something hard to do"

Modern Package management. Every single package manager that I know of in common use today support rolling updates, and security updates on the fly. There is nothing philosophical about it. An update gets released and the distribution tests it and pushes it out to the repositories. The end user gets a pop up in the tray icon telling them that an update is ready for his computer. He clicks ok and 20 seconds later he is done.

edit: which by the way is something that binary drivers make extremely difficult to do. With a binary driver every time the kernel gets updated you have to re-install the binary blob, whether it is the same version or not, and in many cases updating the kernel will break the binary blob due to it not supporting that newer kernel version. Which can often takes weeks or even months, and in ATi's case even quarters..

Compatibility, upgradeability, and stability are all much much much better on an open driver.

[bridgman]

That's not fair. Most people dont know the difference between a disc brake and a drum brake either... But what a car manufacturer has the responsibility of doing is choosing the brake that is going to be safest and most practical for the end user.

Probably a better analogy would be restricting the car to only run on paved roads unless you crawl underneath each vehicle and rip out some wires.

Modern Package management. Every single package manager that I know of in common use today support rolling updates, and security updates on the fly. There is nothing philosophical about it. An update gets released and the distribution tests it and pushes it out to the repositories. The end user gets a pop up in the tray icon telling them that an update is ready for his computer. He clicks ok and 20 seconds later he is done.

Sorry, I was trying to make a different point. If the kernel devs stick these changes in and the distros decide to rip them out again everything is simple. I don't know what is going to happen there. There's a good chance the distros will pass the changes through rather than do battle with the kernel devs.

With a binary driver every time the kernel gets updated you have to re-install the binary blob, whether it is the same version or not, and in many cases updating the kernel will break the binary blob due to it not supporting that newer kernel version.

Surely the same problem happens when a user is running an open source driver with their new card, requiring a bleeding-edge drm in the kernel. When you upgrade the kernel and pick up an older drm driver in the process the user is equally broken until they reinstall the driver.

A real solution would be to work with the HW vendors to ensure that appropriate proprietary kernel drivers were included and tested before each new kernel was distributed. I do agree that there would be some expectations re: making the kernel drivers smaller and less likely to "oops" -- again, that would be good for everyone.

Now *that* would be doing something good for the users

[Redeeman]

Surely the same problem happens when a user is running an open source driver with their new card, requiring a bleeding-edge drm in the kernel. When you upgrade the kernel and pick up an older drm driver in the process the user is equally broken until they reinstall the driver.

but that is only for non-released drivers, so you cant really compare that.

[Chris]

With a binary driver every time the kernel gets updated you have to re-install the binary blob, whether it is the same version or not

I had to reinstall an open source driver for my webcam when I updated my kernel. Being binary has nothing to do with that, it's solely because it wasn't part of the kernel sources.

and in many cases updating the kernel will break the binary blob due to it not supporting that newer kernel version.

Same thing happened to the aforementioned open source driver. Sure I could go in to try to fix it, but do you know what it's like to look at a kernel module source when you have no experience working in the kernel? :P In the end, I had to wait for the developers to update it.. just as if it was a binary blob.