All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Louis <glouis@dynamicro.ca>
To: linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Tue, 24 Jun 2008 07:33:47 -0400	[thread overview]
Message-ID: <20080624113347.GA5246@hp0.dynamicro.ca> (raw)
In-Reply-To: <20080623130917.GB1369@1wt.eu>

Willy Tarreau wrote:

> > (Of course, the best way to rebut that argument [ that outside the
> > developer community, nobody cares whether drivers are proprietary ]
> > would be for end-users to vote with their feet, but for a lot of
> > us, me included, that's not a practical option.)
> 
> The problem is exactly what you describe in your last sentence. Hardware
> manufacturers are well aware of that and make no effort to provide correct
> drivers when they (think they) have a monopoly in certain areas.
> 
> What would be needed would be a public list of alternative hardware for
> known existing hardware.
...
> Willy

That is Utopian, I fear.  For example, what notebook supports the
installation of alternative hardware?  Go to another notebook, you
suggest?  Easy said: when I was buying the machine on which this is
being written, the choice of notebooks with 1920x1200 displays (a sine
qua non as far as I was concerned) was _extremely_ limited.  (There
actually was an open-source driver for the video of the one I picked,
but I could never get it to work.)  Similar difficulties exist for a
lot of special-purpose hardware; viable alternatives are rare.  Your
proposed list could certainly help ferret out such rarities, but I
doubt that it would suffice to make the problem go away.  I suspect,
too, that it would be a beast to maintain, given the need to track all
the features of all the versions of all the hardware items that were
listed.

Then again, my proposed list (a parallel to Greg KH's developer list,
but for end-users) probably wouldn't suffice either.  But it would be
relatively easy to create, and if it got big enough, and if some
manufacturers were hesitating about going open-source, it might tip a
scale or two.

In another message on this list, Greg KH says he has no objection to my
proposal but doesn't want to do it himself (a reasonable position given
the workload he's carrying already).  I'll try to set something up and
will ANNOUNCE it here if I succeed.

-- 
| G r e g  L o u i s         | gpg public key:         0x6D9E3E64 |
|  http://www.bgl.nu/~glouis |   (on my website or any keyserver) |

  reply	other threads:[~2008-06-24 11:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-23  5:01 [ANNOUNCE] Position Statement on Linux Kernel Modules Greg KH
2008-06-23 10:00 ` Jiri Kosina
2008-06-23 14:24   ` Greg KH
2008-06-23 11:29 ` Greg Louis
2008-06-23 13:09   ` Willy Tarreau
2008-06-24 11:33     ` Greg Louis [this message]
2008-06-24 15:02       ` David Newall
2008-06-23 18:12   ` Greg KH
2008-06-23 18:15 ` Måns Rullgård
  -- strict thread matches above, loose matches on Subject: below --
2008-06-23 13:02 Matthew
2008-06-23 13:21 ` Willy Tarreau
2008-06-25 22:45   ` jdow
2008-06-25 23:11     ` Willy Tarreau
2008-06-28  3:28       ` jdow
2008-06-23 18:11 ` Greg KH

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=20080624113347.GA5246@hp0.dynamicro.ca \
    --to=glouis@dynamicro.ca \
    --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.