nVidia RIVA TNT - any success story?ll

Kenny Speer kenny.speer at comcast.net
Mon May 3 04:47:05 UTC 2004


Well, I won't argue with alot of your points, only the update the kernel 
on server issue.  For externel servers, I agree you must keep the 
servers secure, but this isn't necessarily accomplished by upgrading the 
kernel.  On production servers, the kernel is the last thing to get 
updated, why?  Because it's a running server which usually means 
revenue.  For internal servers, you have physical security, and since I 
primarily work for startups I don't have this issue (I also can't stand 
deprecated software, so I go against my own advice in this area).  But I 
have run into many many customers who simply refuse to touch a running 
server unless there is an absolute reason too (like it's about to 
break).  In any event, I do agree with many of your points.  I just wish 
that ATI gave me as much as NVidia does.  And to stay free from the M$ 
chains I will gladly deal with all of these issues and more. ;)

~kenny

Nico Kadel-Garcia wrote:
> ----- Original Message ----- 
> From: "Kenny Speer" <kenny.speer at comcast.net>
> To: "For testers of Fedora Core development releases"
> <fedora-test-list at redhat.com>
> Sent: Monday, May 03, 2004 12:16 AM
> Subject: Re: nVidia RIVA TNT - any success story?ll
> 
> 
> 
>>You're kidding right?  Did you RTFM on the drivers?  Run their "binary"
>>with -x and guess what?  You have the full source, complete and ready to
>>be hacked which I have done in order to get APM working when they
>>decided to comment all of the code out (i admit quite awhile ago).  Try
>>it again, while they might not be GPL (i didn't bother to verify) they
>>do provide the source.  I don't have an NVidia in this laptop but here
>>is your source:
> 
> 
> Look again. A lot of the driver magic is buried in the OpenGL libraries: the
> kernel modules provide just enough hooks for the libraries to access them,
> and the *libraries* are distributed as closed source binaries only. That is
> not open source, it's as little source as they can publish so that the
> varied Linux distributions can use it, barely.
> 
> Please also review the license agreements with their source and with their
> installers. It's not *nasty*, but it's a far cry from open source.
> 
> 
>>On your other pointsL
>>1.  have fun, there it is
>>2.  ok, you got me, but in reality if you really want optimized drivers
>>you always need to go to the vendor and they hardly want to let folks
>>redistribute due to business logic
>>3.  if you're looking for src, why is this a big deal?  With many many
>>features you need to mod config files by hand, this is the way of linux
>>today
> 
> 
> For some features, true. But the XFree86 and now the Xorg and other
> configuration tools get better and better at writing that stuff into the
> tools. It's exactly the closed nature of the chipsets and the API's that
> make creating such configuration tools so very difficult and inevitably well
> behind the cutting edge of the most recent chipsets. I strongly urge you to
> look at Eric Raymand's rant about the typical configuration tool from the
> open source community: it's hard to make friendly, robust configuration
> tools if the manufacturer's won't publish their specs.
> 
> 
>>4.  ok, well the average user doesn't update libraries making point 3
>>moot, removing and re-installing a kernel module can be easily scripted
>>for anyone who cares to do so
> 
> 
> Guess again. They update the libraries as part of the standard OS updates,
> for example when RedHat 8.0 went from XFree86 4.2.0 to 4.2.1. I ran into
> several different NVidia driver "enhanced" machines that had their X-Windows
> blow up and needed some RPM re-insallation and NVidia re-installation to
> fix.
> 
> 
>>5.  don't update your kernel as often, the average user doesn't change
>>their kernel, in fact this is why major vendors such as RH have the
>>*kernel* as skipped packages as the default for updates.
> 
> 
> ??? Friend, if you run servers that other people log into, you *must* keep
> your kernels up-to-date at least for security reasons. This includes
> "logging in" via HTTP and FTP, since some of the "local root" exploits
> really take very little access.
> 
> 
>>You could find many many ways to bash vendors, I personally would rather
>>like to see more act like NVidia.  Where are my Broadcom drivers for
>>54G?  Or the ATI drivers?  Or my ACPI support from my laptop vendor?
>>NVidia is farther along than any other vendor I know of in supporting
> 
> Linux.
> 
> Not compared to Siig and 3Ware: both are fabulous about Linux support
> (although they make IDE/SCSI/RAID cards, not video). For video, the
> selection is tougher, I admit. However, Virge actually used to be pretty
> good abou Linux.
> 
> 





More information about the fedora-test-list mailing list