David Welton proposed the creation of a Linux Incompatibility List, a wiki-type web site used for tracking hardware devices that are currently known to not work with the Linux kernel. Alan Cox [interview] suggested, "I think the 'compatibility list' side is the more important. Trying to punish non helpful products/vendors isn't as productive as helping stuff that is Linux friendly." David suggested that the incompatibility list is likely to be small, and thus easier to maintain. He went on to add, "by the way, the concept is not really about punishing vendors, and I don't want it to come off looking like that. It's about 'this piece of hardware does not work with Linux'. Who knows, maybe the fault is with the kernel maintainers:-) It might be nice if that gave some incentive to the manufacturers to help bring the driver up to speed, though." No link was provided to the wiki, as David instead requested that people email him directly so he could gauge interest. (His email can be obtained from the email archive linked at the bottom of this article.)

Alan went on to note that an automatically generated compatibility list had also been discussed. He explained, "Its already been kicked around on the Fedora list to actually build such a database automatically. I've seen similar Debian proposals a long time ago. That means some time post install you'd let the user fire up a system report tool which would ask things like, 'Does sound work', and then fire off PCI id/rating info to a central site. That would help deal with the data collection much as the Debian folks collect package popularity statistics."

Update: Find the web page at http://leenooks.com/1.

From: David N. Welton [email blocked]
To:  linux-kernel mailing list
Subject: Linux Incompatibility List
Date: 	21 Aug 2004 21:41:04 +0200

Hi,

I'm reviving an idea I implemented several years ago, namely the Linux
Incompatibility List.

The idea is simple: most hardware works fine with Linux, and the
situation is generally pretty good, with Linux increasingly showing up
on the corporate radar.

However, there are devices that don't work with Linux, for various
reasons (no specs, too new and no one has written a driver, etc...),

and it's easier to keep track of those devices so that people can
avoid them (or the hero types can write drivers for them).

I have a site up that will serve as the focus of these efforts, but in
order to guage interest/response and ramp up gradually, I'd like to
ask that those interested in participating in the effort send me
information via email.  I'll respond with the wiki's address, so that
they may then have a look around.

I think (correct me if I'm wrong) the information we would want to
collect is:

Product Name:

Manufacturer:

Model Number:

Chipset:

How bad it is (1 to 10, 9 being it almost works and has only minor
bugs):

Reason (no specs, driver still being worked on, ...):

Url for more info:

An email address of yours that we may publish (so that we can contact
you if someone says "no, that works just fine!"):

Notes:

Ideas/comments/suggestions are welcome at this stage.

Thankyou for your time,
-- 
David N. Welton
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/
       Photos: http://www.dedasys.com/photos/



From: Alan Cox [email blocked]
Subject: Re: Linux Incompatibility List
Date: 	Sun, 22 Aug 2004 12:14:52 +0100

On Sad, 2004-08-21 at 20:41, David N. Welton wrote:

I think the "compatibility list" side is the more important. Trying to
punish non helpful products/vendors isn't as productive as helping stuff
that is Linux friendly.

> Product Name:
> 
> Manufacturer:
> 
> Model Number:
> 
> Chipset:

At what level is "Product" - do you need a category. How do you want
to classify devices. I think this matters because you want eventually
to be able to deal with things like tools that let users rate their
setup functionality and submit it automatically.
> 
> How bad it is (1 to 10, 9 being it almost works and has only minor
> bugs):
> 
> Reason (no specs, driver still being worked on, ...):
> 
> Url for more info:
> 
> An email address of yours that we may publish (so that we can contact
> you if someone says "no, that works just fine!"):

Wikipedia has a discussion page tagged to each article/entry. This works
extremely well because it provides a public forum for discussion of what
does/doesn't work, why and when.

Could you add "Kernel.org bugzilla #" for not working ones, both to help
people track them and to encourage submissions ?

Alan



From: David N. Welton [email blocked]
Subject: Re: Linux Incompatibility List
Date: 	22 Aug 2004 22:48:58 +0200

Alan Cox [email blocked] writes:

> On Sad, 2004-08-21 at 20:41, David N. Welton wrote:

> I think the "compatibility list" side is the more important. Trying
> to punish non helpful products/vendors isn't as productive as
> helping stuff that is Linux friendly.

A "compatibility list" is going to be pretty big, and hard to keep up
to date.  My thinking is that keeping track of a few notable things
that don't work is easier than running after all the stuff that does.

Of course, if automation can be brought to bear, that might make
either one much easier, but I'm dubious, because "it doesn't work" is
a vague concept, and really ought to be researched some.

A third concept "look, these guys support Linux really well!" (not
just "ok, it works") might also be easy to do.

By the way, the concept is not really about punishing vendors, and I
don't want it to come off looking like that.  It's about "this piece
of hardware does not work with Linux".  Who knows, maybe the fault is
with the kernel maintainers:-)  It might be nice if that gave some
incentive to the manufacturers to help bring the driver up to speed,
though.

> At what level is "Product" - do you need a category. How do you want
> to classify devices. I think this matters because you want
> eventually to be able to deal with things like tools that let users
> rate their setup functionality and submit it automatically.

I'd be worried about people who are just irritated that their system
didn't work out of the box hitting a button to submit this
information.

I suppose some sort of vote system could be put in place so that the 1
guy who didn't get the hardware to work gets outvoted by the 10 who
did, but there is more incentive to hit the button when you are
irritated than when everything 'just worked'.

> > How bad it is (1 to 10, 9 being it almost works and has only minor
> > bugs):

> > Reason (no specs, driver still being worked on, ...):

> > Url for more info:

> > An email address of yours that we may publish (so that we can contact
> > you if someone says "no, that works just fine!"):

> Wikipedia has a discussion page tagged to each article/entry. This
> works extremely well because it provides a public forum for
> discussion of what does/doesn't work, why and when.

It's a wiki, so for now I think placing comments on the bottom of the
page would be sensible.  We'll see if and how it grows.

> Could you add "Kernel.org bugzilla #" for not working ones, both to
> help people track them and to encourage submissions ?

Excellent idea.

Thanks for your thoughts,
-- 
David N. Welton
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/
       Photos: http://www.dedasys.com/photos/



From: Alan Cox [email blocked]
Subject: Re: Linux Incompatibility List
Date: 	Sun, 22 Aug 2004 21:45:27 +0100

On Sul, 2004-08-22 at 21:48, David N. Welton wrote:
> A "compatibility list" is going to be pretty big, and hard to keep up
> to date.  My thinking is that keeping track of a few notable things
> that don't work is easier than running after all the stuff that does.

Its already been kicked around on the Fedora list to actually build such
a database automatically. I've seen similar Debian proposals a long time
ago. That means some time post install you'd let the user
fire up a system report tool which would ask things like

	"Does sound work"

and then fire off PCI id/rating info to a central site. That would help
deal with the data collection much as the Debian folks collect package
popularity statistics.

> I suppose some sort of vote system could be put in place so that the 1
> guy who didn't get the hardware to work gets outvoted by the 10 who
> did, but there is more incentive to hit the button when you are
> irritated than when everything 'just worked'.

If you get enough data then the deviation tells you how varied and how
reliable the opinions are likely to be, all this implies databases not
WIki however


Alan

From: Joseph Pingenot [email blocked]
Subject: Re: Linux Incompatibility List
Date: 	Sat, 21 Aug 2004 15:16:33 -0500

>From David N. Welton on Saturday, 21 August, 2004:
>Ideas/comments/suggestions are welcome at this stage.

Sounds interesting; is there a vendor blacklist (i.e. vendors that are
  either hostile toward or simply don't care about Linux and their products
  just won't ever work with Linux?)

-- 
Joseph===============================================[email blocked]
      Graduate Student in Physics, Freelance Free Software Developer



From: Wakko Warner [email blocked]
Subject: Re: Linux Incompatibility List
Date: 	Sat, 21 Aug 2004 16:20:58 -0400

> >Ideas/comments/suggestions are welcome at this stage.
> 
> Sounds interesting; is there a vendor blacklist (i.e. vendors that are
>   either hostile toward or simply don't care about Linux and their products
>   just won't ever work with Linux?)

Broadcom's wireless chips come to mind...

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals



From: Lee Revell [email blocked] 
Subject: Re: Linux Incompatibility List
Date: 	Sat, 21 Aug 2004 16:31:14 -0400

On Sat, 2004-08-21 at 16:20, Wakko Warner wrote:
> > >Ideas/comments/suggestions are welcome at this stage.
> > 
> > Sounds interesting; is there a vendor blacklist (i.e. vendors that are
> >   either hostile toward or simply don't care about Linux and their products
> >   just won't ever work with Linux?)
> 
> Broadcom's wireless chips come to mind...

Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
reverse-engineered.

To add insult to injury they have a stupid 20+page 'Nvidia Linux
Advantage' whitepaper on their site that conveniently fails to mention
the above.  They probably spent more money for some marketroid to put
that together than they ever spent on actually supporting Linux.

Lee



From: Alan Cox [email blocked]
Subject: Re: Linux Incompatibility List
Date: 	Sun, 22 Aug 2004 12:10:15 +0100

On Sad, 2004-08-21 at 21:31, Lee Revell wrote:
> Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
> reverse-engineered.

The X 2D driver isnt too easy to read (although with the rivatv notes
its quite easy). That was written by Nvidia employees and provided by
Nvidia.

Alan



From: Dave Jones [email blocked]
Subject: Re: Linux Incompatibility List
Date: 	Sun, 22 Aug 2004 13:42:00 +0100

On Sun, Aug 22, 2004 at 12:10:15PM +0100, Alan Cox wrote:
 > On Sad, 2004-08-21 at 21:31, Lee Revell wrote:
 > > Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
 > > reverse-engineered.
 > 
 > The X 2D driver isnt too easy to read (although with the rivatv notes
 > its quite easy). That was written by Nvidia employees and provided by
 > Nvidia.

As was the nForce AGP GART driver. Some folks in NVidia are trying
to do the right thing wherever possible.

		Dave



From: [email blocked] (Eric W. Biederman)
Subject: Re: Linux Incompatibility List
Date: 	23 Aug 2004 00:31:58 -0600

Dave Jones [email blocked] writes:

> On Sun, Aug 22, 2004 at 12:10:15PM +0100, Alan Cox wrote:
>  > On Sad, 2004-08-21 at 21:31, Lee Revell wrote:
>  > > Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
>  > > reverse-engineered.
>  > 
>  > The X 2D driver isnt too easy to read (although with the rivatv notes
>  > its quite easy). That was written by Nvidia employees and provided by
>  > Nvidia.
> 
> As was the nForce AGP GART driver. Some folks in NVidia are trying
> to do the right thing wherever possible.

This will be an interesting space to watch I guess.

Tyan is working on an LinuxBIOS to Nvidia's most recent
Opteron chipset as well.    And Nvidia seems to be helping.

Eric

• Archive of above thread
• KernelTrap interview with Alan Cox
• KernelTrap interview with Dave Jones