I won't blame the kernel devs for preventing Linux to become stuffed up with more proprietary software.
It's not like code quality really matters with Nvidia or Catalyst. What matters to them is hacking it up to run on the latest Ubuntu without crashing it so much that it's plainly obvious the user made a mistake when they installed it.
Also, by definition, you can't put GPL software in the Windows kernel, because there's no source code for the Windows kernel. Where would you put it? And why would you want to? You can just write a GPL Windows driver instead. You don't need to put it in the actual kernel (only Linux has that limitation where you're expected to put stuff in the kernel rather than just writing a driver like in the majority of other OSes.)
That's my point. The GPL has a special exception for this. Otherwise, it would NOT be possible to run GPL software on MS libc, and proprietary software on glibc.Quote:
2) You can run any software using Microsoft's libc. You can run any software using glibc. Both are equally legal.
The GPL wasn't written with kernels in mind though. The kernel should have provided an exception for external modules (like the NVidia driver) so that they can use kernel APIs.
I think you should take a look at the sale numbers of triple-A, graphically demanding titles over the years. How is that a "a small portion?"Quote:
Lol, yes maybe Linux will never appeal to the hardcore ricer-gamers but seriously they make up such a small portion of the gameplaying world and in essence they have already moved on from the PC to the dedicated consoles, the vast majority does not have or require ricer performance in order to enjoy games.
And? Where in the GPL's text is a distinction made between kernel and user space?Quote:
WTF are you babbling about? Microsoft's c-runtime-library (which incidentally is not part of the windows core installation, which is why programs keep installing them, leaving you with tons of versions on your harddrive) does not reside in Windows kernel anymore than glibc does, these are _user-space_ libraries.
Unless I missed the news, NVidia did not release a driver that uses DMABUF. If you've seen one, then yes, it would be a figment of your imagination.Quote:
So the proprietary NVidia driver is just a fidgment of our collective imagination then, as it cannot work, or are you saying it works but constantly crashes?
I can use my hardware just fine. NVidia provides me with a working driver and good customer support. I gave them my money, so that's what I expected from them. AMD on the other hand, took my money, gave me no working driver and no good support. Instead, they tell me how they gave me a bunch of useless source code. What am I supposed to do with that? Write the drivers myself? I paid them so that they give me finished, well working drivers.Quote:
Why are the kernel devs 'bigots' and not the proprietary vendors? If you want to talk 'immoral' or 'bigot' then certainly proprietary vendors doesn't have a leg to stand on as the whole concept of not being able to use the hardware you've bought to it's full extent anywhere you please because the hardware vendor won't provide necessary information for you to do so f**king reeks of 'bigotry'. Yet you decide that the proprietary hardware vendors 'rights' are being trampled here because they aren't allowed dictate the terms in which they interact with the Linux kernel?? Are you f**king insane?
NVidia did that, AMD didn't. IMO, AMD is doing the immoral thing here, not NVidia. NVidia seems to respect their paying customers.
I don't care about licenses. I care that the products I buy with my money are working.
The GPL does not make a distinction between user and kernelspace.Quote:
If the proprietary parts are implemented in user-space there is no legal issue, just like with NVidia's proprietary driver. What is your point?
NVidia doesn't request special treatment. They request fair treatment.Quote:
Bullshit, they are the exact opposite as they DON'T give NVidia any special favours
NVidia does not want to use open code in their drivers. Where did you see that? What they need is to communicate with the kernel.Quote:
NVIDIA are hypocrites, they don't want to open their driver but they think they should have the benefits of open drivers, in other words they think the world owes them the right to have the cake and eat it.
Again: The GPL does not know what a "kernel" is. There's no distinction between a proprietary userspace program using a glibc API, and a proprietary driver using a kernel API.
The problem is OpenGL itself : the reference implementation of OpenGL drivers IS CLOSED. Anybody who wants to develop a real OpenGL driver, looks at that reference code, and IS FORCED TO MAKE A CLOSED DRIVER.
STOP with stupid hate against NVIDIA.
It is not a fault of NVIDIA, if they wanted to develop an official OpenGL driver. Do you want an open source driver? Ok, but it will be a Mesa driver, programmed by people who had not access to the OpenGL reference code, and it will be slow and shitty like other current open source driver.
So the bad guys are not the NVIDIA guys, but the KRONOS group, who keep CLOSED the ironically named OpenGL...
If Kronos group decided to open for real the OpenGL, we could have excellent drivers for Linux.
I am personally fed up of reading every week these discussions...
If the problem was only the hardware documentation, ATI/AMD should have excellent open source drivers. But this is not the case. Actually, also the decent Intel drivers are slower than the Windows ones. Why? Because there are some more advanced software tricks in the closed reference implementation of OpenGL, I think.
And the open source drivers developers are struggling to re-invent today many things that already exist from many years, but that were never published.
So at the moment: no closed source = no official OpenGL driver = no serious Linux use in modern graphics fields. And now that OpenCL is becoming popular, the situation is even worse...