We'll force them to be free.
Announcement
Collapse
No announcement yet.
NVIDIA Denies Opening Up Its Driver
Collapse
X
-
Originally posted by ickusslime View PostThat 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.
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..
Comment
-
Originally posted by Chris View PostOwing to bugs, I've never had an issue with nVidia's OpenGL implementation. Their hardware is more than capable, unlike Intel's.
Says who?
And the vast majority of Linux users.....
Comment
-
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"Test signature
Comment
-
Originally posted by duby229 View PostnVidia'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.....
as posted in another thread, you might wanna read:
Comment
-
Originally posted by ickusslime View PostThat 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.
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.
Comment
-
Originally posted by bridgman View PostIf 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"
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.Last edited by duby229; 25 June 2008, 08:40 PM.
Comment
-
Originally posted by duby229 View PostThat'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.
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.
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.
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 usersLast edited by bridgman; 25 June 2008, 09:20 PM.Test signature
Comment
-
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.
Comment
-
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.
Comment
Comment