The effect you describe is exactly like taking a pair of cards, one red, the other green and sealing each in an envelope while blindfolded. Then you mail one to yourself and the other to your friend. Once you see that you have a red card, you know immmediately that your friend has a green one. But the cards themselves have not travelled faster than light!
Umm, what you have described here is not an example of instantaneous communication between you and your friend. When you open up the envelope and find out what the color of your card is, no information is transmitted between you and your friend; its all still contained in your vicinity.
I noticed that way back in June 1988 on one of the installments of GNU's Bulletin (vol. 1, no. 5), you urged people to avoid purchasing Macintoshes or writing programs targetting the Macintosh platform, as a protest against Apple's role in the look-and-feel copyright lawsuits.
Do you still urge developers not to write code for the Macintosh platform? Even code that falls under the GPL? Obviously you're not completely ignoring Apple, since you wrote a commentary on their attempt at an open source license some months back.
I would think that the benefits of pushing GPL'd code onto as many platforms as possible, (thus further spreading the GNU Message and making more people aware of the benefits of Free Software), would outweigh the drawbacks of providing support for a platform that is backed by a company whose business practices one does not agree with.
I'd say that its more a "will to reproduce" that's at the core of everything.
A will to live is a natural accompaniment to that, (at least as long as one is capable of reproduction), but I think that a "will to live" alone would not bring about emotions like "love" and "jealousy"
In fact, arguably "love" oftentimes comes in direct conflict with one's will to live...
>> How plausible is it that we communicate >> with aliens through music and not something >> more advanced, like mathematics?
Umm, I think you need to look into music theory a little more. There are numerous links between music and mathematics. So in that sense, music between the common ground between alien races doesn't seem implausible at all.
Disclaimer: I am neither a X nor a GTK+ nor a Motif hacker.
From just listening to the conversation, I don't think you've argued your position well, Jamie.
The argument above yours is that you can't just read the documentation for the Motif libraries and then write an X application. You need to read the Motif documentation *and* the X library documentation.
Now, if you're the type of person to read both library's doc ANYWAY, then, yes, adding an XmDrawLine function would just complicate things.
But the point of an abstraction layer is to make it unnecessary to have to look at the underlying levels if you don't want to. So redundant functionality can be tolerable, if it simplifies the work of the developer (not having to wade through so much documentation).
I'd say that the having every class extend from Object is a feature of java, not a bug.
But i do agree that having to downcast all of the time is stupid and inefficient. THat's why there were three research projects going on in parallel to add Generic (Polymorphic) Types to Java. One of them was done here at MIT, but it seems that people tend to like Bell Labs' GJ better (I can understand why)
And as far as the MP3 watch goes, I don't understand the point of having rechargeable batteries. I have owned Casio watches for years, and the main reason I buy the waterproof ones is so I never have to take it off. If I have to take the MP3 watch off my wrist every night to recharge the batteries, then I'm going to be walking around my house staring at the blank wrist where my watch is supposed to be.
I take my watch off every night, and put it down with my keys and wallet and such. So I don't think putting a rechargable battery in a watch is stupid at all.
The part I don't understand is how they think that people are going to be happy with headphone wire going from their wrist to their heads...it sounds like numerous accidents waiting to happen. Maybe if one strung the wire through one's sleeve, keeping it under one's shirt, then it could work. But that sounds kinda uncomfortable...
Well, "hate" is a strong word, but I do know that one of Peter David's "But I Digreess..." articles in an old issue of CBG (we're talking like four or five years ago) totally railed one of the issues of Sandman's The Kindly Ones storyline
But, Peter David was looking at the issue from the viewpoint of a "single issue reader", not a reader of the whole collective storyline. So it makes a lot of sense that he wouldn't appreciate the work.
My point is that I bet there's a lot of people out there who think Sandman was crap. They probably also collected Youngblood.
I'd say that the reason that MIT gives us projects with "robots killing other robots" isn't because they prepare us for a career in robot-making; its so we don't go crazy when we take classes like 6.170 (Laboratory in Software Engineering)
(Don't get me wrong, I've realized since I took it that 6.170 is chock full of good stuff that is very applicable to industry programming (specification, testing, documentation, design...) but there are fine lines between what SHOULD be practiced in the industry, what IS practiced in the industry, and what a delirious student is going to practice when she's been up three nights in a row)
Robots killing robots is *FUN*
More importantly, its a very large project involving both realtime constraints and complex problem solving, and it grabs our attention enough to test our real ability to reach lofty goals
I would just like to note that there are alternatives that make parallel programming more tractable for both the programmer and the compiler.
One of these alternatives that I am studying now is Functional Programming. When all you work with are sets of subexpressions to evaluate, rather than a strictly ordered series of statements, then suddenly all this parallelism that was impossible for the compiler to find in the sequential (ie C) version become apparent for the compiler of the functional version. Plus functional programs can be easier to verify and make provable statements about.
Now, the only real problem that I know of for Functional Languages is that your objects usually need to be immutable. But this actually isn't such a bad thing; mutability isn't needed in many cases that it is used in. And that way you don't need to maintain state between processors (ie no semaphores needed)
Actually, another problem is side-effects (in other words, I/O) but I don't want to get into that
I know that one can support Mutable objects in functional languages, but I admit that I have not yet studied how this affects the parallizability of a functional program.
The point is, the programming world may be able to write extremely parallel programs, if they were willing to try out different programming paradigms and see how they mesh with SMPs...I'd be happily surprised if such a paradigm shift happened for efficiency purposes (to better support SMPs) and yet also caused an increase in probability of program correctness just due to the other benefits of functional programming.
I would just like to note that there are alternatives that make parallel programming more tractable for both the programmer and the compiler.
One of these alternatives that I am studying now is Functional Programming. When all you work with are sets of subexpressions to evaluate, rather than a strictly ordered series of statements, then suddenly all this parallelism that was impossible for the compiler to find in the sequential (ie C) version become apparent for the compiler of the functional version. Plus functional programs can be easier to verify and make provable statements about.
Now, the only real problem that I know of for Functional Languages is that your objects usually need to be immutable. But this actually isn't such a bad thing; mutability isn't needed in many cases that it is used in. And that way you don't need to maintain state between processors (ie no semaphores needed)
Actually, another problem is side-effects (in other words, I/O) but I don't want to get into that
I know that one can support Mutable objects in functional languages, but I admit that I have not yet studied how this affects the parallizability of a functional program.
The point is, the programming world may be able to write extremely parallel programs, if they were willing to try out different programming paradigms and see how they mesh with SMPs...I'd be happily surprised if such a paradigm shift happened for efficiency purposes (to better support SMPs) and yet also caused an increase in probability of program correctness
There are reasons to prefer one company over another that aren't based just on their products. There are also moral issues here.
Check out http://www.faceintel.com/ to read about how badly Intel treats its employees and you'll see some of the moral issues I'm talking about. After I read this, I decided that not one more cent of my money was going to be put toward buying a processor made by Intel
Now, first of all, I want to make something clear: I love jikes. It is blazingly fast, and the obvious choice during the develop/test/debug cycle. Plus I like its error messages on incorrect code better than Javac's.
However, I have a contention with the following statement: "IBM actually implements java better than Sun"
If this is a comment on Jikes (as opposed to, for example, IBM's JIT compiler), its a misleading comment. Jikes and Javac are like apples and oranges. Jikes was designed to be a fast java compiler, plain and simple. This means that it does few optimizations to the output bytecode when compared to Javac. Which in turn means that Jikes-produced code may execute more slowly than Javac-produced code.
(I say might because a good JIT compiler may be able to perform the same optimizations that Javac does on the output from Jikes, thus making the usefulness of Javac's work moot)
So lets just keep these sorts of issues in mind when discussing compilers.
Who knows, these guys may actually have something substantial?
I wouldn't have said that, except by the time I bothered looking at the site, on several spots they've added comments about they're working hard now to revise their information as a result of comments made by the slashdot community
So, I wonder...now that I've made comments about their comments, perhaps they'll make comments regarding my comments about their comments?
Not that my comments actually have any more substance than their website does.
Anyway, just thought that a lot of the naysayers could perhaps benefit from a second look at the site.
I highly suggest both of you read the following paper:
Richard P. Gabriel. Worse is better. From LISP: good news, bad news, how to win BIG, AI Expert 6, 6 (June, 1991) pages 33-35
It's funny reading it now (considers UNIX and C to be poorly hacked together) but its main point is that OverDesigning something kills you because in the end its the easier design that propagates because (surprise) its easier to implement.
Mozilla may have a problem here, but I don't think so. The simple fact that the source is out there means that we can continue to work with it *if* we want to, regardless of what AOLscape does. That's a pretty big "if" though...I for one think that it would probably be easier to port Lynx to X than it would be to fix Netscape to the degree that I'd like...
But have you considered that the reason that are accepting the quality of BladeEnc's output is that you haven't heard anything better?
I also used BladeEnc for a while, but I've since switched to Lame. It seems (to me) to be faster and produce better quality than BladeEnc.
Now, I'm REALLY not trying to say that everyone should use Lame, and in fact I'm thrilled that BladeEnc is being released under the LGPL (I'll download the source and do a comparison later to see how far its come since I used it). what I am saying is: Why are you ripping all of your CDs without even doing a comparison of the different options you have for encoding them first?
Again, if you didn't know about your other options, then there's nothing wrong with going ahead with what you do have, but I just hope that discerning readers out there will just step back and give the alternatives a try.
This is an interesting reaction for a company to take in response to email flames.
I'm not surprised when journalists decide to devote one of their columns to the flame-mail they've received, but exactly HOW is it in Mindcraft's best interest to post this page and link to it off their homepage?
Its not saying "hey, mindcraft is the place to go for fair and accurate judgement" All its saying is "linux users are all a bunch of illiterate zealots" And whose purposes does that serve? Mindcraft doesn't benefit from such a statement, but Microsoft does. ("Would your network to an OS for which you can only get Administrators like *this*...?!?")
Not that I think that Redmond put them up to this; I suspect they came up with the idea all on their own.
In any case, I certainly am embarrassed to be associated with the people who wrote this claptrap. Oh well...guess it's time to move to GNU/Hurd.
Even so, this does show that the current system may be out of wack.
Perhaps only some forms of comment-downgrading should count against one's user total? Like Flamebait or Troll, while Offtopic and Redundant will only affect the single comment and not your alignment?
Designing a proper comment rating system is hard work, to be sure. I wonder if Godel's theorem that no set of logical axioms can be both consistent and complete extends to ANY SYSTEM, be it a comment-rating system, or an OS? Heh...reminds me of the other comment here suggesting a formal proof of an OS...microkernel territory there...probably the extending of Godel to any system is one of those truisms that can't be proven...totally meta...
Have either of you actually learned how to use Unix? It has a fairly consistent underlying model which allows the user to do things in a straightforward, managable way: by piping the output of one command into another, until the final filtered product is produced.
Yes, it does this all at the command line with somewhat obscure commands such as 'grep' or 'cat'. But what do you expect? Unix wasn't designed for a point-and-click GUI system; those COST too much and are more cumbersome to use when you want to get things done. Typing has always been faster than moving a mouse around, even if it requires taking some time to memorize commands and learning how to find the commands you don't know (thank god for tab-completion)
In any case, I suggest you look into the history behind the design of these systems before you make judgements about things appearing hell-bent on not making themselves easy to learn and integrate. Inconsistent design will always reign as the top reason that a product is hard to use.
This is a redundant comment, but necessary because while this information is available elsewhere in this thread, its much deeper in the tree of comments/replys and this information should be located closer to the root of the tree.
--------------------- Remember the LPF by John Allsup
The organisation (or what ever there is of it these days) that was about this type of thing, is the League for Programming Freedom.
This is also a good (in name at least) place to look as to where to start setting up such a legal fund. What WOULD be a good idea (if the funds could be generated for it) is to sort out the legal situation in as many countries as possible, and let everybody know where they stand w.r.t the law of their land (I'm a UK citizen). -------- John Allsup email: jda570@bham.ac.uk
What he's implicitly saying is that OSS did produce the best driver.
Glide is closed-source. Though Carmack notes that it is fast, this person found it to be buggy. And in many arenas (though not all), correctness is much more important than speed.
g200 glx has open hardware specs, and they imply in this post that they're using an OSS driver. As far as they can tell, it has no bugs.
Thus, by some metrics, OSS *has* produced the best driver.
Slashdot Mirror
Dude, get your Richard Gabriel quotes straight before you start putting Scheme and UNIX in the same category.
UNIX goes with C in "Worse is Better" (not "Small is Better")
Scheme belongs with LISP in "The Right Thing"
And for people who have no idea what I'm talking about, check out the following link.
(yes, there was once a time when UNIX was looked down upon as a hack. truly we did not know how low things could get...)
The effect you describe is exactly like taking a pair of cards, one red, the other green and sealing each in an envelope while blindfolded. Then you mail one to yourself and the other to your friend. Once you see that you have a red card, you know immmediately that your friend has a green one. But the cards themselves have not travelled faster than light!
Umm, what you have described here is not an example of instantaneous communication between you and your friend. When you open up the envelope and find out what the color of your card is, no information is transmitted between you and your friend; its all still contained in your vicinity.
-Felix
Mr Stallman-
I noticed that way back in June 1988 on one of the installments of GNU's Bulletin (vol. 1, no. 5), you urged people to avoid purchasing Macintoshes or writing programs targetting the Macintosh platform, as a protest against Apple's role in the look-and-feel copyright lawsuits.
Do you still urge developers not to write code for the Macintosh platform? Even code that falls under the GPL? Obviously you're not completely ignoring Apple, since you wrote a commentary on their attempt at an open source license some months back.
I would think that the benefits of pushing GPL'd code onto as many platforms as possible, (thus further spreading the GNU Message and making more people aware of the benefits of Free Software), would outweigh the drawbacks of providing support for a platform that is backed by a company whose business practices one does not agree with.
-Felix
I'd say that its more a "will to reproduce" that's at the core of everything.
A will to live is a natural accompaniment to that, (at least as long as one is capable of reproduction), but I think that a "will to live" alone would not bring about emotions like "love" and "jealousy"
In fact, arguably "love" oftentimes comes in direct conflict with one's will to live...
>> How plausible is it that we communicate
>> with aliens through music and not something
>> more advanced, like mathematics?
Umm, I think you need to look into music theory
a little more. There are numerous links between
music and mathematics. So in that sense, music
between the common ground between alien races
doesn't seem implausible at all.
Disclaimer: I am neither a X nor a GTK+ nor a Motif hacker.
From just listening to the conversation, I don't think you've argued your position well, Jamie.
The argument above yours is that you can't just read the documentation for the Motif libraries and then write an X application. You need to read the Motif documentation *and* the X library documentation.
Now, if you're the type of person to read both library's doc ANYWAY, then, yes, adding an XmDrawLine function would just complicate things.
But the point of an abstraction layer is to make it unnecessary to have to look at the underlying levels if you don't want to. So redundant functionality can be tolerable, if it simplifies the work of the developer (not having to wade through so much documentation).
I'd say that the having every class extend from Object is a feature of java, not a bug.
But i do agree that having to downcast all of the time is stupid and inefficient. THat's why there were three research projects going on in parallel to add Generic (Polymorphic) Types to Java. One of them was done here at MIT, but it seems that people tend to like Bell Labs' GJ better (I can understand why)
Basically, think Templates, but better. C:)
I take my watch off every night, and put it down with my keys and wallet and such. So I don't think putting a rechargable battery in a watch is stupid at all.
The part I don't understand is how they think that people are going to be happy with headphone wire going from their wrist to their heads...it sounds like numerous accidents waiting to happen. Maybe if one strung the wire through one's sleeve, keeping it under one's shirt, then it could work. But that sounds kinda uncomfortable...
Felix
Well, "hate" is a strong word, but
I do know that one of Peter David's "But I Digreess..." articles in an old issue of CBG
(we're talking like four or five years ago) totally railed one of the issues of Sandman's The Kindly Ones storyline
But, Peter David was looking at the issue from the viewpoint of a "single issue reader", not a reader of the whole collective storyline. So it makes a lot of sense that he wouldn't appreciate the work.
My point is that I bet there's a lot of people out there who think Sandman was crap. They probably also collected Youngblood.
-Felix (aka Omega Red)
As any fan of Neil Gaiman would agree, I'm
pretty sure the intended spelling is "Morpheus"
I'd say that the reason that MIT gives us projects with "robots killing other robots" isn't because they prepare us for a career in robot-making; its so we don't go crazy when we take classes like 6.170 (Laboratory in Software Engineering)
(Don't get me wrong, I've realized since I took it that 6.170 is chock full of good stuff that is very applicable to industry programming (specification, testing, documentation, design...) but there are fine lines between what SHOULD be practiced in the industry, what IS practiced in the industry, and what a delirious student is going to practice when she's been up three nights in a row)
Robots killing robots is *FUN*
More importantly, its a very large project involving both realtime constraints and complex problem solving, and it grabs our attention enough to test our real ability to reach lofty goals
I would just like to note that there are alternatives that make parallel programming more tractable for both the programmer and the compiler.
One of these alternatives that I am studying now is Functional Programming. When all you work with are sets of subexpressions to evaluate, rather than a strictly ordered series of statements, then suddenly all this parallelism that was impossible for the compiler to find in the sequential (ie C) version become apparent for the compiler of the functional version. Plus functional programs can be easier to verify and make provable statements about.
Now, the only real problem that I know of for Functional Languages is that your objects usually need to be immutable. But this actually isn't such a bad thing; mutability isn't needed in many cases that it is used in. And that way you don't need to maintain state between processors (ie no semaphores needed)
Actually, another problem is side-effects (in other words, I/O) but I don't want to get into that
I know that one can support Mutable objects in functional languages, but I admit that I have not yet studied how this affects the parallizability of a functional program.
The point is, the programming world may be able to write extremely parallel programs, if they were willing to try out different programming paradigms and see how they mesh with SMPs...I'd be happily surprised if such a paradigm shift happened for efficiency purposes (to better support SMPs) and yet also caused an increase in probability of program correctness just due to the other benefits of functional programming.
-Felix
I would just like to note that there are alternatives that make parallel programming more tractable for both the programmer and the compiler.
One of these alternatives that I am studying now is Functional Programming. When all you work with are sets of subexpressions to evaluate, rather than a strictly ordered series of statements, then suddenly all this parallelism that was impossible for the compiler to find in the sequential (ie C) version become apparent for the compiler of the functional version. Plus functional programs can be easier to verify and make provable statements about.
Now, the only real problem that I know of for Functional Languages is that your objects usually need to be immutable. But this actually isn't such a bad thing; mutability isn't needed in many cases that it is used in. And that way you don't need to maintain state between processors (ie no semaphores needed)
Actually, another problem is side-effects (in other words, I/O) but I don't want to get into that
I know that one can support Mutable objects in functional languages, but I admit that I have not yet studied how this affects the parallizability of a functional program.
The point is, the programming world may be able to write extremely parallel programs, if they were willing to try out different programming paradigms and see how they mesh with SMPs...I'd be happily surprised if such a paradigm shift happened for efficiency purposes (to better support SMPs) and yet also caused an increase in probability of program correctness
-Felix
There are reasons to prefer one company over another that aren't based just on their products. There are also moral issues here.
Check out
http://www.faceintel.com/
to read about how badly Intel treats its employees and you'll see some of the moral issues I'm talking about. After I read this, I decided that not one more cent of my money was going to be put toward buying a processor made by Intel
Now, first of all, I want to make something clear: I love jikes. It is blazingly fast, and the obvious choice during the develop/test/debug cycle. Plus I like its error messages on incorrect code better than Javac's.
However, I have a contention with the following statement: "IBM actually implements java better than Sun"
If this is a comment on Jikes (as opposed to, for example, IBM's JIT compiler), its a misleading comment. Jikes and Javac are like apples and oranges. Jikes was designed to be a fast java compiler, plain and simple. This means that it does few optimizations to the output bytecode when compared to Javac. Which in turn means that Jikes-produced code may execute more slowly than Javac-produced code.
(I say might because a good JIT compiler may be able to perform the same optimizations that Javac does on the output from Jikes, thus making the usefulness of Javac's work moot)
So lets just keep these sorts of issues in mind when discussing compilers.
That said, YAY IBM!
Scott-
< martin>
Stop drawing dinosaur pictures and get back to working on your thesis.
</martin>
C;)
-Felix
Who knows, these guys may actually have something substantial?
I wouldn't have said that, except by the time I bothered looking at the site, on several spots they've added comments about they're working hard now to revise their information as a result of comments made by the slashdot community
So, I wonder...now that I've made comments about their comments, perhaps they'll make comments regarding my comments about their comments?
Not that my comments actually have any more substance than their website does.
Anyway, just thought that a lot of the naysayers could perhaps benefit from a second look at the site.
Ferix
I highly suggest both of you read the following paper:
Richard P. Gabriel. Worse is better. From LISP: good news, bad news, how to win BIG, AI Expert 6, 6 (June, 1991) pages 33-35
It's funny reading it now (considers UNIX and C to be poorly hacked together) but its main point is that OverDesigning something kills you because in the end its the easier design that propagates because (surprise) its easier to implement.
Mozilla may have a problem here, but I don't think so. The simple fact that the source is out there means that we can continue to work with it *if* we want to, regardless of what AOLscape does. That's a pretty big "if" though...I for one think that it would probably be easier to port Lynx to X than it would be to fix Netscape to the degree that I'd like...
Felix
Not to get into an Encoder-War or anything...
But have you considered that the reason that are accepting the quality of BladeEnc's output is that you haven't heard anything better?
I also used BladeEnc for a while, but I've since switched to Lame. It seems (to me) to be faster and produce better quality than BladeEnc.
Now, I'm REALLY not trying to say that everyone should use Lame, and in fact I'm thrilled that BladeEnc is being released under the LGPL (I'll download the source and do a comparison later to see how far its come since I used it). what I am saying is: Why are you ripping all of your CDs without even doing a comparison of the different options you have for encoding them first?
Again, if you didn't know about your other options, then there's nothing wrong with going ahead with what you do have, but I just hope that discerning readers out there will just step back and give the alternatives a try.
ferix
SIGH
I meant:
"would you trust your network to an OS for which you could only get Administrators like *this*...?!?"
C:P
This is an interesting reaction for a company to take in response to email flames.
I'm not surprised when journalists decide to devote one of their columns to the flame-mail they've received, but exactly HOW is it in Mindcraft's best interest to post this page and link to it off their homepage?
Its not saying "hey, mindcraft is the place to go for fair and accurate judgement" All its saying is "linux users are all a bunch of illiterate zealots" And whose purposes does that serve? Mindcraft doesn't benefit from such a statement, but Microsoft does. ("Would your network to an OS for which you can only get Administrators like *this*...?!?")
Not that I think that Redmond put them up to this; I suspect they came up with the idea all on their own.
In any case, I certainly am embarrassed to be associated with the people who wrote this claptrap. Oh well...guess it's time to move to GNU/Hurd.
-Felix
Even so, this does show that the current system may be out of wack.
Perhaps only some forms of comment-downgrading should count against one's user total? Like Flamebait or Troll, while Offtopic and Redundant will only affect the single comment and not your alignment?
Designing a proper comment rating system is hard work, to be sure. I wonder if Godel's theorem that no set of logical axioms can be both consistent and complete extends to ANY SYSTEM, be it a comment-rating system, or an OS? Heh...reminds me of the other comment here suggesting a formal proof of an OS...microkernel territory there...probably the extending of Godel to any system is one of those truisms that can't be proven...totally meta...
Felix
Have either of you actually learned how to use Unix? It has a fairly consistent underlying model which allows the user to do things in a straightforward, managable way: by piping the output of one command into another, until the final filtered product is produced.
Yes, it does this all at the command line with somewhat obscure commands such as 'grep' or 'cat'. But what do you expect? Unix wasn't designed for a point-and-click GUI system; those COST too much and are more cumbersome to use when you want to get things done. Typing has always been faster than moving a mouse around, even if it requires taking some time to memorize commands and learning how to find the commands you don't know (thank god for tab-completion)
In any case, I suggest you look into the history behind the design of these systems before you make judgements about things appearing hell-bent on not making themselves easy to learn and integrate. Inconsistent design will always reign as the top reason that a product is hard to use.
Felix
This is a redundant comment, but necessary because while this information is available elsewhere in this thread, its much deeper in the tree of comments/replys and this information should be located closer to the root of the tree.
---------------------
Remember the LPF
by John Allsup
The organisation (or what ever there is of it these days) that was about this type of thing, is the League for Programming Freedom.
see http://lpf.ai.mit.edu/
This is also a good (in name at least) place to look as to where to start setting up such a legal fund. What WOULD be a good idea (if the funds could be generated for it) is to sort out the legal situation in as many countries as possible, and let everybody know where they stand w.r.t the law of their land (I'm a UK citizen).
-------- John Allsup email: jda570@bham.ac.uk
Felix
What he's implicitly saying is that OSS did produce the best driver.
Glide is closed-source. Though Carmack notes that it is fast, this person found it to be buggy. And in many arenas (though not all), correctness is much more important than speed.
g200 glx has open hardware specs, and they imply in this post that they're using an OSS driver. As far as they can tell, it has no bugs.
Thus, by some metrics, OSS *has* produced the best driver.
Ferix