On Sun, Oct 30, 2005 at 12:24:27PM -0600, Les Mikesell wrote:
> > I'm well aware of the reasons... But support for their hardware (or
> > rather usability of it) suffers because of them.
>
> If you are going to assign blame here, consider that there are
> several parties involved in creating this problem and that
If you are refering to the kernel developers, their decision is based
on not allowing a fixed API to stand in the way of making the OS
better. This is the right decision; failure to adhere to such a
policy is one of the things that has made, for example, Microsoft
Windows so unstable over the years. Their initial design was flawed,
but they could not fix it without breaking everyone. So it stayed
broken. And it remains broken today... Yay!
> other popular OS's do not cause end-user problems by refusing
> to include vendor-supplied binaries.
I'm assuming that here, you mean other free OSes. Vendors which only
sell their software for profit must be excluded, because they do not
give away the source code and binaries for their OS, and therefore
need not be concerned about paying licensing fees or signing NDAs.
They have that luxury -- they can afford it. Linux is free software,
and as such does not have the same luxury. Why can't Linux vendors
afford to pay license fees? If most of their users aren't paying for
the software, how can they collect them? It's a fundamental necessity
of free software.
Now, it's certainly possible that Red Hat could enter into some sort
of agreement with NVidia to distribute their drivers with the OS. It
may even be the case that NVidia would not charge them license fees
for distributing the drivers with Fedora, though I have my doubts.
However, in absence of such an agreement, Red Hat MUST NOT distribute
the drivers:
2.1.1 Rights. Customer may install and use one copy of
the SOFTWARE on a single computer, and except for making
one back-up copy of the Software, may not otherwise copy
the SOFTWARE. This LICENSE of SOFTWARE may not be shared
or used concurrently on different computers.
[From the license agreement for NVidia's Linux drivers]
Nevermind that this clause is completely preposterous, and that NVidia
is being retarded. The end-user is free to download the software as
many times as they like, agreeing to this agreement each time, and use
it on as many systems as they have such hardware... Nevertheless the
terms of the EULA prohibit copying and distributing the drivers.
[Driver software does one thing only: drive hardware. A license to
use it should be automatic for anyone owning that peice of hardware,
e.g. 1 piece of hardware = 1 license to use the correspoding driver,
including any and all updates.]
> Nvidia can't legally change their position no matter how much the
> GPL crowd wants to pretend that it is their fault.
Why not?
> > 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?
>
> But they do make an effort to provide native drivers.
Well, we're using different definitions of "native" here. I mean
native in the sense of code which is included and properly integrated
into the kernel source tree.
> > > 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 reason here is not technical.
Yes, it is. It is a technical decision on the part of the kernel
developers which causes this to be (essentially) impossible for the
vendor. The decision is to make the kernel better, at the cost of
stability.
> > The kernel is very actively developed.
>
> Is that an excuse for not freezing a driver api so vendors can
> supply optimized drivers that don't have to be re-written every few
> months?
Yes it is. If the API is wrong, it needs to be fixed. It can't be
kept just because it will break 3rd party code. Integrating the
driver into the kernel source solves the problem, because when the API
changes, all driver code that uses it will get fixed at the same time.
That said, I do agree to some extent; see below.
> Other OS's have managed to solve this problem.
You mean like Windows? It's a lot better than it used to be, but I've
seen far too many blue screens for that to hold water with me... If
you're talking about other OSes, I can't really speak to that. I have
little familiarity with the other free Unixes or with Mac OS X.
Other commercial OSes may be more stable, but most of them also
support a much smaller selection of hardware (I'm thinking commercial
Unix here, mostly).
> > 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.
>
> If you follow the fedora list you'd be well aware that crashes
> happen as a result of a lot of the other drivers as well. You can't
> blame that all on vendor binaries.
Indeed. But as I said, Fedora is meant to be a cutting-edge
development platform. The drivers are bound to be broken.
FWIW, I do disagree with the kernel development model to this extent:
If the kernel is supposed to be stable, it ought to be. It remains
true as it has been historically so that early releases of the stable
kernel really are development kernels in disguise. ;-) I think the
kernel developers ought to adopt a 3-tier approach to testing the
kernel, much like Debian does with their distribution. [I'm not
saying that Debian's development model is inherently better than any
other -- I happen to think that their model makes stable releases of
the distro far too infrequent -- but I think it would be well suited
to kernel development.] The trouble is, of course, getting enough
users to use testing kernels to make bug identification and fixing
feasable. And I believe this is the argument for the model we are
stuck with now.
But an in-depth descussion of these issues is really not on-topic for
this list, I think. :)
>
> > 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.
>
> Or use an OS with a more stable design...
Indeed. Fedora is not meant to be that, and isn't. It's important to
remember context when having such discussions... That's why I said in
a different message that I don't think Fedora is necessarily the right
choice for someone who's just breaking into Linux. You WILL have
problems... it's not stable. Get over that, or use something else.
> > > 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.
>
> But you can say that about a lot of other drivers too. I crash
> regularly if I try to run raid with a firewire drive included and
> that's all built from source, no one else to blame.
There is a big difference though. With the mainstream kernel,
stability is generally a function of how many people are using a
particular device in a particular configuration. Popular devices are
generally extremely stable. NVidia graphics cards SHOULD be such a
device, since they are quite popular, but they are not.
>
> > > 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.
>
> I don't think that has anything to do with their choice not to do
> it.
Well, you mean they could obtain license agreements to distribute the
drivers. While true, this is financially infeasable. OSS OS vendors
give away a lot more software than they sell; they'd still be liable
for license fees for each copy downloaded, for which they aren't
receiving any money. That's a big problem.
There's also the problem of supporting someone else's binary only
code. That's a nightmare.
> It doesn't make any sense other than some kind of political
> statement in an unsupported product like fedora, though.
See above about money. Some vendors probably are happy to give away
such license agreements... OTOH those vendors' hardware probably
already has a maintstream kernel, for exactly that reason. Of course,
I do not do business with these companies, so I can't really say what
sort of compensation they would expect.
What I can tell you is this: business is about making money. It's
true that some companies, mostly privately owned ones, do take
political stands. But in the end it's about making money. If it were
in Red Hat's best interest to distribute the drivers, I'm sure they
would. For reasons that you and I will never completely understand,
it apparently isn't. I for one don't find that very surprising, given
the respective natures of free software and business.
