Slashdot Mirror
NVIDIA Licence Update (Linux Exception)
(startx) writes "I don't know how long this has been the case, but with the latest NVidia driver update comes a new installation method, which unifies the installation process almong all Linux distributions. Just for kicks I re-read the licence, and it has a new section labeled "2.1.2 Linux Exception" Basically GNU/Linux users are now free to redistribute the driver file. Not only this, but the FAQ section of the README file says you can redistribute in whatever form necessary, stating distributions are welcome to include it as a package as well. Woohoo!"
Great, they do this just AFTER I upgrade to Mandrake 9.1. If they would have done this before then it probably would have been included in the distro.
The GeekNights podcast is going strong. Listen!
Gentoo already has nvidia-glx and nvidia-kernel packages as part of Portage.
This will be a great help for distro packagers. Not the least of which, Knoppix would finally be able to play OpenGL games (Chromium!) straight out-of-the-box.
I applaud nVidia for their continuing support for Linux.
Like many others, I would be happier if the drivers were open-sourced, but realise that there is so much licensed technology in these cards, that getting permission from all the IP holders would be impossible, even if nVidia wanted to release the source.
Well done, nVidia.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Kirby
My guess they do it because they're afraid they may hose the config file. Let's face it, text config files can be problematic. One has to go to the effort of creating parse routines (easy in perl, but not it C), many of the files have their own format, and there is always the risk of misparsing part of it. Then to change one setting, the most simple way is often to just rewrite the entire file. Not an easy task, and an error in any step may hose the entire thing...
The M$ registry sucks, but at least it has an api (so you don't have to write all the code to read / change settings) and it is binary (so you only need to lock part of the file, and you don't have to rewrite all or most of the file just to change a single setting--assuming M$ didn't screw the design up, I don't know much about the arcane internals of the thing.
Using text files for configuration has advantages--such as being human readable--but it makes programming more difficult.
I was pleasantly surprised back when I got my new computer with a TNT2 that they provided nice (in my experience) fast 3D drivers. They haven't subscribed to the whole open-source/free software philosophy, they're just being smart. Giving source for their drivers may have some benefits, may have some costs, may not be possible for legal reasons. Giving away binary drivers makes sense - you're quite likely to influence a linux user's video card purchase with decent drivers. Making people download it from their website, or install it differently from any other package is just a pain in the ass and doesn't gain them anything.
There's no altruism here, just common sense. What's surprising is that so many big hardware manufacturers make things so hard.
Free Java games for your phone: Tontie, Sokoban
Right answer, but for the wrong reasons I suspect.
/etc or maybe /etc/X11 or perhaps /usr/X11R6/etc/X11 or any of the other locations (some of which are dynamic) listed at http://www.xfree86.org/~dawes/4.3.0/XF86Config.5.h tml. Compound this with the fact that different users may have different relevant config files of their own and you have a problem that the Windows registry probably can't solve either.
;).
Since most installs are done via shell script or makefile, it's not like this would be that hard to program-- sed or perl are likely to be involved and this isn't tough for either of them. I know it's not as simple as s/nv/nvidia/, but it's not that hard to make sure you only change the right lines and nothing else.
The real problem is finding the right config file to change. Are they in
Also, in this case, only X, one of its utilities, or the driver install are going to need access to the config file, so locking the whole file isn't an issue. You probably want the whole file locked during driver install, but this wouldn't prevent you from messing with other config files at the same time-- if you can find them
I do not have a signature
So everyone has to have either sed or perl installed? Different developers will make different choices. If it is done this way, everyone will probably need both, plus awk, plus [insert a bunch of programs here]. In fact this is the current state of most open source project. That is a lot of stuff, especially for those workstations who don't do any development.
Also a lot of programs are starting to use XML (even worse). For config files, it has all the disadvantages of a text file, but also it is not very readable (to a normal person). A little while ago, I was looking at a program, and it required the latest freaky xml library. Why? Because they decided to make the configuration file XML. Nothing else.
Also using perl doesn't solve the problem of being inefficient. If the line you modify changes size, at the very least, you will have to rewrite every bit of data from that line to the end of the file. It may not be a problem if you only need to change one small file, but large or many files will waste the user's time. Many settings are of constant size in binary files, and those which are not, can be dealt with. Indexing and moving stuff around doesn't work with text files, but it can with binary.
Yeah, you'll probably want a library to take care of the binary files, but it's being done for XML, and like you said, perl, sed or some other program is needed for flat text. Something for binary configs would be thousands of times easier to write and would be ten times smaller.
You bring up a good point here. One I didn't really think of. However, it's trivial to put a table of constant strings into a program. It'll miss the unknown paths, but I imagine only tweak monkeys would have such a set up. Just give them instructions I suppose...
Well, I wasn't saying the Windows registry would solve anything, I was giving an example of the bottom of the barrel going in the right direction. Their registry has countless design flaws, the most obvious are they put everything into two huge files. They probably were forced to go this way because all the stupid decisions they made caused text files to be completely unworkable.
Imagine if the registry was one huge text file. "Registry scan rate is now at 10 min per scan" "Blue screen! Blue screen!" "We're going down in flames cap'n." "Pull up! Pull up!" "Damn it Bill! You killed us all! Aaarrggghh!!!" ;-)
As for file locking: Yeah, being able to lock portions of a config wouldn't help installer programs much (assuming you aren't running programs at the same time), and it was a strech for me to mention it. But it would help where config files are used by multiple programs or multiple instances of programs.