Will Newton wrote:
> 
> On Tuesday 18 Sep 2001 4:36 pm, you wrote:
> 
> > > Look at it this way: a couple of security holes have been found in the
> > > DRI drivers, and fixed. What's in the nVidia drivers?
> >
> > What's in any binary application or driver you install?
> 
> I don't know. Er, that's my point...

Although security through obscurity is not a good solution, it is
effective to a certain degree. To my knowledge, no security holes have
been found in the NVIDIA drivers. They need to be found to be exploited,
and finding them is more difficult w/ binary only. Security holes can
remain in open source software for long periods of time before they are
discovered. The same is true with binary only.

> > > People are willing to use them, so fair enough. But whilst I have a
> > > reasonable choice I will use an open source driver.
> >
> > Unfortunately, your reasonable choice doesn't look like it's going to last
> > much longer.
> 
> So what do you propose to do about it? Take a perverse glee in arguing that
> something bad is going to happen, and trying to shoot down anyone who
> believes otherwise? Not sure I see what you are trying to achieve.

 Something bad has already happened. The DRI team is no longer working
on the project full time. What are you trying to achieve by bashing
NVIDIA?

 The whole reason this discussion started is because DRI development is
going to grind to a halt. This is the problem which we should be trying
to solve, not hammering on the only 3D chip maker that is supporting
Linux (and supporting it quite well, I might add). NVIDIA provides
binary-only drivers, and has well known and well respected Linux hackers
doing it. For some people, binary only is not acceptable. Guess what?
Your open source alternatives are in danger of going away. What is
required at this point is a viable alternative. Instead of preaching the
horrors of closed source software, you should be trying to find a
reasonable way of ensuring the continued presence of open drivers.
NVIDIA is not the enemy. They're not doing things they way you want to
see them done, but they are providing enormous benefit to Linux by
making their drivers available. 

> > > Seriously, if I had a G400, I would help fixing bugs in it.
> >
> > Not everyone has the programming skills to do that.  And even many of
> > those that do, don't want to have to fix the bugs in a driver just to get
> > their hardware working :-)
> 
> They shouldn't have to. But there are users who can. Look at the Utah GLX
> project - that was necessitated by id software releasing games. 

 Not true. If you knew your history, Dave Schmenk (now at NVIDIA) began
a GLX implementation for Linux. Terrence Ripperda (also now at NVIDIA)
picked up the project and continued development. This project eventually
evolved into what is known today as Utah GLX. Quake3 and John Carmack
came much later. It was NVIDIA who released the first usable "Utah"
driver. 

> John Carmack
> did some development because (besides being very cool indeed) he was a
> corporate user of Linux 3D software. 

 He didn't do it for the money. He did it because he felt it was the
Right Thing(tm). He has gone on record as saying that the Quake3 Linux
sales sucked.

> So maybe we can get some help from
> people out there creating 3D packages? (Maya, Blender, Softimage?) 

 These people are using the NVIDIA drivers. They're already using
binary-only software, so binary only drivers aren't a big deal to them. 

> Also Linux
> distros are surely getting bug reports about this, I know the market is not
> very good right now, but maybe you can spare a developer to help? If DRI has
> corporate backing (and hopefully from a better company than VA Linux) it will
> achieve more. The difference between a company like RedHat or NaN saying e.g.
> "our software needs drivers on Linux, have you plans to do this or release
> specs?" is always going to have more effect than hackers asking for docs by
> themselves.

 Absolutely. Ben OShea's post (which you responded to) makes a great
deal of sense.

-Mark
------------------------------------------------------------
Mark B. Allan                   NASA Ames Research Center
QSS Group, Inc.                 Neuro-Engineering Lab
650 - 604 - 0537 (office)       Mail Stop 269-2
650 - 604 - 0461 (lab)          Moffett Field, CA 94035
650 - 604 - 3594 (fax)          [EMAIL PROTECTED]
http://ic.arc.nasa.gov/ic/ne.html
------------------------------------------------------------

_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to