All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Shannon Hendrix <shannon@widomaker.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [somewhat OT] binary modules agaaaain
Date: Thu, 22 Apr 2004 12:19:58 -0400	[thread overview]
Message-ID: <20040422161957.GF16810@widomaker.com> (raw)
In-Reply-To: <200404201611.07832.bzolnier@elka.pw.edu.pl>

Tue, 20 Apr 2004 @ 16:11 +0200, Bartlomiej Zolnierkiewicz said:

> > A binary module is "considered good" if
> 
> This is a false assumption IMO no binary only modules can be "good".

True, but non-working hardware is even worse.

> I think that binary modules are evil because:
> 
> - they slow down development (indirectly - think about it)

I don't think this is true at all.

> - some vendors claim Linux support
>   while they only provide binary only modules

If they provide a binary for Linux, then they can claim Linux support.

We may not like it, but it is a legitimate claim.

> - less informed users tend to put blame on kernel or distribution
>   not the binary only module (!)

True, but this is just noise in the signal in terms of what the less
informed users think.

> I'm not a fanatic :-), I can see good sides of binary only modules:
> 
> - additional hardware and features is supported
> 
> - wider usage of Linux

- some driver code is tied up in legal issues that are not currently
  solvable

- For some hardware, only the company has enough knowledge to write
  a decent driver.  I can't blame a company for wanting to control
  the drivers for their hardware for quality reasons.

- As a user, I need to get work done, not play politics with my
  hardware.  I prefer open solutions, but each day I have work to
  do and can't afford to play politics with my hardware.

- I personally don't believe that building barriers to binary drives is
  helpful.  In fact, I think it ultimately means *less* open source
  from manufacturers.  I think of a good binary interface as a good
  ambassador.

> but I still think that cons > pros...

Of course.  We live in a highly imperfect world, and the computer
industry is among the most imperfect parts of it.

At the same time, we need to make sure that in our posturing and
political moves, we don't end up making things worse.

> > With this restrictions those "good" binary modules could be debugged, run
> > in a sandbox... The question remains if anybody will want to debug them:-)
> 
> In my opinion using binary only modules is equal to modifying your kernel
> but being unable to show your modifications so you are on your own and you
> shouldn't bring it on lkml.

Sounds illogical to me.

That's like saying that selling a turbocharger for a car is the same as
illegally copying the design of a car and selling it as your own.

> Useful thing will be to create mailing list about Linux kernel
> + binary only modules and to move discussion from lkml there...

True.  Also useful would be to get manufacturers involved in any
such list so you can hear from them.

-- 
shannon "AT" widomaker.com -- [4649 5920 4320 204e 4452 5420 5348 5920 4820
2056 2054 434d 2048 4d54 2045 204e 5259 4820 444e 0a53]

  parent reply	other threads:[~2004-04-22 17:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-19 15:53 [somewhat OT] binary modules agaaaain Guennadi Liakhovetski
2004-04-20  8:39 ` Geert Uytterhoeven
2004-04-20 10:23   ` Guennadi Liakhovetski
2004-04-20 14:11 ` Bartlomiej Zolnierkiewicz
2004-04-20 15:08   ` Guennadi Liakhovetski
2004-04-21  2:24     ` Horst von Brand
2004-04-22 14:13       ` Grzegorz Kulewski
2004-04-23 11:28     ` Andrew McGregor
2004-04-23 12:29       ` Richard B. Johnson
2004-04-24  2:29         ` Andrew McGregor
2004-04-22 16:19   ` Charles Shannon Hendrix [this message]
2004-04-22 18:55     ` Bartlomiej Zolnierkiewicz
     [not found] <1MJlZ-4mT-47@gated-at.bofh.it>
2004-04-24 10:03 ` Ihar 'Philips' Filipau
2004-04-24 20:00   ` Guennadi Liakhovetski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040422161957.GF16810@widomaker.com \
    --to=shannon@widomaker.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.