NVIDIA Is Better For Closed-Source Linux GPU Drivers, AMD Wins For Open-Source 185
An anonymous reader writes "Phoronix last week tested 65 graphics cards on open source drivers under Linux and the best result was generally with the open source AMD Radeon drivers. This week they put out a 35-graphics-card comparison using the proprietary AMD/NVIDIA drivers (with the other 30 cards being too old for the latest main drivers) under Ubuntu 14.04. The winner for proprietary GPU driver support on Linux was NVIDIA, which shouldn't come as much of a surprise given that Valve and other Linux game developers are frequently recommending NVIDIA graphics for their game titles while AMD Catalyst support doesn't usually come to games until later. The Radeon OpenGL performance with Catalyst had some problems, but at least its performance per Watt was respectable. Open-source fans are encouraged to use AMD hardware on Linux while those just wanting the best performance and overall experience should see NVIDIA with their binary driver."
There is also these... (Score:1, Insightful)
...for you guys who like closed source stuff:
funny.exe
boobies.exe
yourprize.doc
Have fun!
Hello there, Captain Obvious (Score:3, Insightful)
One note:
AMD OpenSource drivers are best OpenSource drivers out there, but shitty drivers per se.
NVIDIA drivers are great drivers, but not OpenSource.
This is the real difference and conclusion. Don't try to hide it.
Re:That's Odd. (Score:5, Insightful)
Re:Just don't upgrade the kernel with nvidia close (Score:2, Insightful)
For the developer, yes. For the user, fuck no. And since this is all precisely about how what's good for the user, then it really isn't relevant how nice it is for the developer, ignoring the whole point is precisely that no matter how nice it is for the developer, developers still consistently hide settings in the registry.
Short of some very special circumstances, the difference is parsing a binary or text file are unnoticeable to a user. As for being unreliable to parse, perhaps in a very esoteric way that's true--ie, the developers job might be harder, but very rarely do users get bitten with those corner cases short of disk corruption. But as a user, the main thing you'll notice is that in Windows, Linux, or whatever, that sometimes a developer uses a text box for a boolean option or goes for decimal instead of hex or whatever and hence the user doesn't know what all is a "proper" answer and it's then that parsing becomes an issue. Regardless, separate config file interpreters also come with separate config files which can at least hint at where all config options are.
And yes, this is the other side of the coin. In an effort to be more "standard", we've come across xkcd's observation that it just creates more of a mess. So, ones that actually followed the old standard of ~/.$program[.$ext] make it easy, for the user, to know where config options are, back them up if they want (or delete them to go back to the defaults), and generally be reasonably certain all the major user options are there to be fiddled with. With Windows? It's the same problem of files being in various config files plus settings scattered all over the registry. Windows itself is especially guilty of this.
Well, that's good and all. But it's just an API. The major thing preventing a standard API in Linux to do the same thing is the inertia of old standards and people unwilling to rewrite everything to fit the new system. The it be one binary hive or many scattered text files is rather beside the point from an API perspective (well, not entirely, but it's close enough most the time). And of course, .gconf trying to be the Linux registry...well...xkcd.
And this final point is where you seriously fail. Windows doesn't have *a* configuration manager. It does have *a* registry editor. Each program has to contain its own configuration management glued to a backend API be it the Windows registry or a config file. Yet in the end, it's the fact that every program is different and many options are either mutually exclusive or have potentially deep nested dependencies that leaves one to either (1) include a lot of text in your config file and have sane resolutions for conflicting options or (2) have a UI that preemptively protects against conflicts and still has to deal with user mucking around behind the scenes or (3) just not giving the user access to most configuration management with (3) being the most common problem with Windows and (1) being a rather lazy developer approach under the *nix philosophy which remain the norms.
I think that sums up why pretend that the registry and regedit are magical panaceas really misses the point.