[Gllug] Binary Only Modules are a cheap trick (was webcams on linux)

[Thomas Charles Robinson]

On Wed, 2003-02-19 at 10:47, David Pashley wrote:
> ----- Original Message -----
> From: "Dylan" <dylan at dylan.me.uk>
> To: <gllug at linux.co.uk>
> Sent: Tuesday, February 18, 2003 10:20 PM
> Subject: Re: [Gllug] webcams on linux
> 
> > I'd much rather have a functional piece of hardware with binary only
> > modules, than non-functional hardware!
> >
> There are at least 3 problems with binary modules.
> 
> 1. Any bugs you have to wait for the manufacturer to fix.
> 
> 2. You have to wait for the manufacturer to update the driver to work with
> new versions of the kernel/program (eg sane or gphoto2). Many modules come
> out for only one (or a selection of) kernel versions. This means you can
> only run those kernels. This is esp bad when they target kernels shipped
> with redhat or SuSE. These will probably not work on Debian for example.
>  You also get manufacturers (like nVidia) who ship binary objects and a
> small source code wrapper. When you try to move to a 2.[56] kernel, these
> drivers will not work.

<RANT>

I can back this up with hard experience. My PCI ADSL (conexant chipset -
Access Runner ADSL modem) card stopped working when I upgraded to Red
Hat 8.0. The message when the module loaded was something about the
module being compiled with a different version of gcc. So, as I had the
source for the module that came with the modem, I did what anyone else
would do and recompiled the module with the new gcc version from the
install. After the recompile I still couldn't load that module and was
getting the same error about kernel compiled with a different gcc
version as to the module. I check everything, compiled again. Still the
same. Ok, so you know where this is going. I checked the source code
make files and and dug out a 'proprietary' object module that is linked
after compilation of the rest of the code. ARRRGH! The only choice I now
have is to run an older kernel all for this one dependency!

There are loads of kernel enhancements that I can't have because I use
this stupid PCI Access Runner ADSL modem. If the manufacturer has to
keep up with kernel releases I can tell you that the support for linux
is not there.

It's a cheap trick. They even print 'linux compatible' on the box. They
think because they have spent a couple of quid on getting a system
working with their product that the job is done and can claim linux
compatibility. They don't understand Open Source relies on Openness!
Basically, they can't keep up with the pace. (BTW the rpm that came on
the CD with this product was the worst (and I mean worst) example of an
rpm package I had ever seen. I had to re-write most of the spec file to
even get the thing to re-compile on my OLD kernel in the first place).

Object only support will not work unless the vendors can keep pace with
the kernel developers. Let's face it, they're not going to 'waste' their
money on it. We end up paying the price. If they were to spend some time
effort and money on keeping up, I would gladly buy into it. I can't see
it happening though because they can't see how it works.

The fact that they try is good but somehow they don't understand the
process and they are not dedicated. They need to have impressed up them
the importance of the flexibility needed to keep pace with the changes.

> 3. You will recieve no help from the open source community. Thin about the
> taint flag in the kernel. If your kernel is tainted, and you have an
> unrelated problem, you will most likely be ignored or told to go away.

Try and contact the vendor sometime. You get (a) no reply or (b) sorry,
we can't help you at this time. Go away you rubbish vendors!!

</RANT>


--

While money doesn't buy love, it puts you in a great bargaining
position.


-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug