FC4 does not work, "out of the box" for me; GUI/X11 fails

Matthew Saltzman mjs at ces.clemson.edu
Sun Oct 30 19:40:33 UTC 2005


On Sun, 30 Oct 2005, Derek Martin wrote:

> On Sun, Oct 30, 2005 at 04:53:38AM -0500, Matthew Saltzman wrote:
>>> They are clearly not up to the task.  Not that we should expect they
>>> would be; it's a pretty big task...  But it becomes a small task if
>>> nvidia either releases source code for their drivers, or releases
>>> complete specs to their hardware, so that a driver can be written and
>>> maintained as part of the Linux kernel proper.
>>
>> But (rightly or wrongly) video card makers consider these two pieces of
>> information to be their competitive edge.  So you are not likely to see
>> them releasing either, at least for their latest cards.  Also, Linux users
>> still aren't a very large fraction of their customer base.
>
> I'm well aware of the reasons...  But support for their hardware (or
> rather usability of it) suffers because of them.

I never claimed it didn't, just recapped the reasons.

>
> As for what fraction of their customer base uses Linux, those are some
> statistics I'd like to see...  But I think it raises some interesting
> questions, like what percentage of their users actually use both? What
> percentage of Linux users who DON'T use their hardware would switch if
> there were native drivers?
>
> Also don't forget that there are other free OSes, such as the *BSD
> family (and still others as well).  All of these would benefit from
> such a release as well...  When you add up all users of all free OSes,
> how does that compare to say, users of Mac OS X?  I'm not sure, but I
> believe I have read that it is much larger...

And yet vendors need to make a judgment about whether the return is worth 
the effort or the perceived sacrifice of a competitive edge.

>
>> It also would be a small task if there were standards that allowed them to
>> write a single installer that would work with any distribution, without
>> having to deal with loads of special cases.
>
> This is largely impossible.  In this case we're dealing with the
> kernel, so the reasons are slightly different (but very similar) than
> for application programs.
>
> The kernel is very actively developed.  The distribution vendors often
> make their own custom modifications, to enhance functionality or
> performance, or just to fix bugs.  For a hardware vendor to maintain
> its own binary-only driver which is compatible with all of these
> varying kernels is a task which is, practically speaking, essentially
> impossible.  So, from time to time, with various kernels, their driver
> will crash your system.

A clean, stable, nonrestrictive module interface would help.  I don't know 
a lot about kernel internals, but I've seen references to discussions 
about changes that break old ABIs and about deliberately making life 
difficult for proprietary module vendors.

>
> I found this to be the case with a recent release of their driver and
> glx libs in combination with a recent release of the kernel.  After
> updating from Livna maybe a month ago, my system locked up hard with
> the latest kernel and glx stuff when X tried to start, even after
> rebooting several times.  Reverting to an older glx library fixed the
> problem for me.

At lease NVIDIA is reasonably responsive to these issues when they come 
up.

>
> I guess I do not "blame" them for wanting to keep their trade secrets,
> but when the newest release of their drivers crashes your system, the
> above is the direct cause, even if you can argue that the "fault"
> isn't theirs...  The only practical solution is for them to release
> the code, whether or not they are willing to do so.

Then I suspect we are kind of stuck with the impractical alternatives. 
The X.org NVIDIA driver is fine if you don't need 3D.  The X.org ATI 
driver is fine if you don't mind older hardware.  The NVIDIA 3D driver is 
probably the best among propriatary ones.  ATI doesn't seem to be so 
responsive with their proprietary drivers.  I don't know much about other 
cards, but there don't seem to be many other high-performance 3D options.

>
>> Nevertheless, I've found that the NVIDIA drivers work reasonably well.
>
> Usually.  Unless they crash your system, which happens from time to
> time, i.e. this was not the first time.  Also with certain earlier
> versions of their driver, my system would experience random lock-ups
> while I was using it (which for my money is a lot more annoying than
> crashing at boot time).  Both the last version I used and the version
> I am using now don't seem to suffer from that problem...
>
>> You could also "blame" Red Hat and Fedora for their policy of not
>> including proprietary/binary-only packages in their distributions.
>
> No, I think you really can't; in many cases (if not all) it is illegal
> for them to do so, which is a large part of why they don't do it.
> Even if it is not illegal in your country, it might be in many
> others...  Their hands are tied.  But, this is why we have the extras
> and Livna RPM repositories...

Sure, but of course it does affect usability.  But there are other distros 
that do include these features.  Either they (or their users) are on risky
legal ground or they have made the appropriate arrangements and paid the 
fees.  Or they are offshore, in which case, I don't know what the legal 
implications are for them or their US users.

>
>> I admire them for sticking to their guns on this issue, but it does
>> affect usability, particularly with respect to cartain hardware
>> drivers and multimedia codecs.
>
> Which are illegal for them to redistribute, because they are
> proprietary.  Or, they would have to pay licensing fees in some cases,
> which means they would have to charge you (more) for their products.
> I agree this is inconvenient, but I'd much rather suffer some
> inconvenience than see Red Hat sued out of existence...  Don't you
> agree?  :-)

Of course.

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs




More information about the fedora-list mailing list