Slashdot Mirror
Should Linux Use Proprietary Drivers?
Richard Gray writes "Should Linux accept proprietary video/graphics drivers from likes of Nvidia and ATI ? The GPL written by FSF says that the license prohibits proprietary drivers. From the article: 'To write open-source graphics drivers without help from Nvidia or ATI is tough. Efforts to reverse-engineer open-source equivalents often are months behind and produce only 'rudimentary' drivers, said Michael Larabel, founder of a high-end Linux hardware site Phoronix ... Torvalds has argued that some proprietary modules should be permissible because they're not derived from the Linux kernel, but were originally designed to work with other operating systems.' The FSF however, sharply disagrees. 'If the kernel were pure GPL in its license terms...you couldn't link proprietary video drivers into it, whether dynamically or statically.' Where do you fall on this issue?"
You're missing the capitalistic incentive.
Nvidias and ATIs "value proposition" is the hardware. The driver is just a required evil.
Opening up the driver projects would mean they could get OSS loving hippies to do all the grunt MTRR/PAT/Register/MMIO/OpenGL hackery for them and they could concentrate on the actual hardware.
It's like AMD or Intel selling an OS. And saying "you must use this OS with this processor". That trick didn't fan out to well for IBM (System/360 anyone?) and wouldn't work for x86 processors either.
Why are GPUs any different?
Tom
Someday, I'll have a real sig.
I used to think having a Linux kernel driver ABI would be a good thing. But then I started to change once I read about the OpenBSD ilk and their trials with wireless, RAID, etc. (and their recent "blob" song). My attitude these days is "not in my kernel".
Binary blobs prevent peer review for security. They are in themselves a security risk as any vendor could use them to inject God-only-knows what hooks into the kernel (Sony rootkit native on Linux, anyone?). And I'd be more inclined trust the quality of code from the Linux community above and beyond anything proprietary.
I'd rather go without. If we must have binary drivers, they should either be run in user-space through a strict Free-software gateway or provided as a safe byte-code for a driver virtual machine.
I think the point NVidia is making is that the driver is a big part of the package they're selling. A buggy driver will make the entire package, including the hardware, look bad.
You obviously never used the early versions of NVidia's Linux (and later FreeBSD and Solaris) drivers. No one expects any software to be 100% bug free (yes, I know there are exceptions to that but on the whole this is true). And if you counter this; I offer up ATI's drivers, including their Windows drivers, as repost. I have yet to have an ATI product that did not suffer miserably from driver problems under any OS.
If writing a graphics driver is indeed very complex, the chance of FOSS developers including bugs is quite realistic. The simple fact that FOSS developers have not been able to produce good GPU drivers despite reverse-engineering demonstrates the level of complexity involved.
Do you know anything about reverse engineering? It is a hack no matter how you look at it. You are trying to guess what something does by observing it. How can this be compared to knowing what something does because you have the documentation right in front of you. Nice troll. Or not.
Such version would come at the expense of NVidia's reputation; if ATI keeps their drivers closed, ATI will have the more stable package in the typical consumers' eye.
How did you come to that conclusion?
I won't be buying or recommending any more ATI products unless they show a marked improvement in the quality of their drivers. Both for Windows and Linux.
Open sourcing the drivers might make me consider going back to their products.
Firstly that is a very arrogant approach, some of the best developers in the world work on open source stuff, saying it is to hard is just stupid.
Or maybe it's just code for "We haven't got documentation for this stuff, and rely on the collective experience of our developers over generations of the product to keep writing drivers. Driver writing is not a revenue center but a cost center for us, and in order to contain costs, we're not going to make the upfront investment required to throw our developers at documenting this stuff to the point where we won't be embarassed."
Intellectual property issues like cross-patent licensing and 3rd party code could be addressed relatively cheaply when compared to addressing systematic deficiencies in documentation and code style. Such an effort would turn the cost structure of a hardware company on its head.
Yes, they would ultimately experience an advantage from having unpaid volunteers improving their code. However, in order for those volunteers to improve the stuff, the stuff's already got to be in good shape anyway.