[mythtv-users] Is NVIDIA worth the bother?

[Brad Templeton]

On Mon, Sep 28, 2009 at 04:52:39PM -0400, Eric Sharkey wrote:
> On Mon, Sep 28, 2009 at 4:04 PM, David Brodbeck <gull at gull.us> wrote:
> > On Fri, September 25, 2009 7:24 am, Eric Sharkey wrote:
> >> And
> >> dealing with the fact that your kernel is officially tainted at that
> >> point.
> >
> > Is this really a problem if you're not a kernel developer?  To me the
> > "taint flag" has always just seemed like one of those political things.
> 
> I personally haven't had a problem with this issue.  There are two
> ways in which the tainted flag can be problematic.  One is kernel devs
> that refuse to even help diagnose a problem on a tainted kernel.
> Another are drivers or other modules that refuse to load with a
> tainted kernel.
> 
> The latter case is the real purpose of the tainted flag.  Since
> there's been some disagreement about the GPL and exactly what
> constitutes creation of a derivative work, the tainted flag allows
> both view points to coexist more or less peacefully.  When authoring a
> module, strict GPL adherents may choose to forbid the module to load
> into a tainted kernel to prevent the module from linking with
> incompatible code.  On the other hand, those module authors who don't
> see loading a module into a kernel as creating a derivative work can
> simply ignore the flag.
> 
> Most module authors appear to be in the latter camp, at least
> officially.  I suspect that some of them do feel that a derivative
> work is created, but still choose to ignore the flag anyway on
> practical or pragmatic grounds, with the desire to open their work to
> a larger audience.

It gets stranger when you bring firmware into the mix.   Perhaps I am mistaken,
but I have not heard of anybody doing code that will not allow it to run
on a system that has "soft" propietary firmware loaded into a card or
device.  Ie. your system loads the proprietary firmware into the device and
then the driver talks to this device.

Now I don't see any difference between that, and a proprietary module that
looks like a black box and is talked to by an open source driver in the
kernel.  But some people do.  However, all the differences they talk about
are not artifacts of the desires of the author of any of the code (proprietary
or open) but rather of the way linux is architected, with a monolithic kernel.

If linux had a microkernel and drivers could live outside of it the debate
would be different.  And I have to say I am bothered by the fact that the debate
woudl be different because of a decision like that.   That makes me feel the debate
is not based on anything real, but purely on an idea of an ideology.

The real ideology in GPL is software authors don't want others making proprietary
changes to their code and then distributing that code (for money or otherwise.)
I can see that entirely.   But this is a case where the proprietary authors have
no desire to be linked with a monolithic kernel, indeed they would love nothing
more than to not have to be linked with such a kernel with all the hassles that
involves.   They want to write a driver that's as independent from changes in
the kernel as they can make it, and it's linux's fault that they can't.

So why people would want to punish that to support the real and understandable
ideology of "don't change _my_ code and lock it up" escapes me.