RH recommends using Windows? plus a Question!

[Michael K. Johnson]

But, like mandrake's, it is woefully lacking.

One thing I want to see happen is a self-service hardware compatibility
service that makes it easy for users to provide information on the
compatibility they are seeing with their hardware on Fedora, and for
which the information is well-enough organized that you can actually
have good searches for that information.

My basic concept is that there's a lot of information on the system
that you can get at with tools like lspci and dmidecode. Parse that
into units of hardware and present the user a GUI that lets them
make some easy assignments for how well things work (default is
"don't know" in order to avoid garbage) with definitions for the
levels, and places for comments for each piece of hardware. Then
this data is uploaded (signed with the user's gpg key?) in a
structured, parseable format (xml?) to a centralized database that
is both downloadable and web-searchable.

Any volunteers? :-)

(I'm cc'ing the devel list because I've noticed several people looking
for projects lately -- here's a candidate. If you are interested,
start the discussion, but I suggest keeping it on fedora-devel-list
since fedora-test-list is high-enough traffic as it is...)

michaelkjohnson

"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/

[Jef Spaleta]

Post by Michael K. Johnson
My basic concept is that there's a lot of information on the system
that you can get at with tools like lspci and dmidecode. Parse that
into units of hardware and present the user a GUI that lets them
make some easy assignments for how well things work (default is
"don't know" in order to avoid garbage) with definitions for the
levels, and places for comments for each piece of hardware. Then
this data is uploaded (signed with the user's gpg key?) in a
structured, parseable format (xml?) to a centralized database that
is both downloadable and web-searchable.

Hmm well lets see...what other things have a model like this...freedb.
Maybe there are lessons to be learned from freedb.

Some hard issues though for me...
Even if you do have people sign their specs with gpg...how do you really know
who's key's to trust. And how do you deal with conflicting reports. I'd imagine
certain popular off the shelf groups of hardware will have a lot of
reports...a lot of conflicting reports (depending on several factors of
the user's particular experience level). can't really limit this sort of
thing to a few trusted individuals..yer going to need a wide range of
people with a wide range of hardware for this to be useful.

And, how do you make sure the hardware database takes into account
specific hardware conflicts...not just broken hardware...but specific
issues with specific combinations of hardware.

Seems to me this sort of thing almost ends up being a specifically
tasked rework of bugzilla in a way....but with a mature way to cross
reference conflicting hardware reports that crop up. So that people can
do queries on a grouping of hardware so they can see if there are
specific incompatibilities when certain hardware is used together.
So maybe video card A works with motherboard 1 seamlessly...but not with
motherboard 2...having a way to query not just a piece of hardware and
see all known comments for it...but a way to query specific groupings of
hardware to narrow down relevant reports.

-jef"this monster is going to need a bit of care and feeding...maybe
even some sort of /. like moderation scheme to keep hardware comments
maintained"spaleta

[Michael K. Johnson]

Post by Jef Spaleta
Even if you do have people sign their specs with gpg...how do you really know
who's key's to trust.

Oh, that was just a throwaway idea, I'm not sure if it makes sense.
Maybe could be optional as a kind of +1 on the provenance that people
can use if they want to.

Post by Jef Spaleta
And how do you deal with conflicting reports.

Probably like reviews of products/books/etc. Like at Amazon, a book
gets, say, 3.5 stars with 10. So you read the comments and correlate
the clue level of the comment with the number of stars provided by the
reviewer.

The more reporters, the more you can trust the report.

Post by Jef Spaleta
I'd imagine
certain popular off the shelf groups of hardware will have a lot of
reports...a lot of conflicting reports (depending on several factors of
the user's particular experience level). can't really limit this sort of
thing to a few trusted individuals..yer going to need a wide range of
people with a wide range of hardware for this to be useful.

Absolutely! That's why it's got to be EASY to get good information or
there's not much point in doing it. I'd run it myself if it took
less than 10 minutes, and I know I'd never get around to it if it took
20.

Post by Jef Spaleta
And, how do you make sure the hardware database takes into account
specific hardware conflicts...not just broken hardware...but specific
issues with specific combinations of hardware.

The entire report has to be available whenever part of it is being
presented.

Say you are searching for video card foo. It has average rating bar.
You want to look into this more, so you click on "read all reports"
Reports that look interesting, you click on "see hardware" and you
have the entire hardware database for the machine (we probably
shouldn't include things like tag ids from dmidecode :-) and you
can see what the context is. Some main things (say motherboard
version, running kernel version, that type of thing) can be displayed
in short form with the review.

Then, if you really want to get fancy, you add the ability to add
comments to individual reports. You happen to know that the reason
the video card foo didn't work on that system is that there's a
conflict with bios version J.UNK on that particular motherboard.
So you post a annotation to that effect.

If you want to get really fancy, you do an advogato-like voting
structure so that consistently clueful reporters have their
ratings weighted higher in producing the averages.

Post by Jef Spaleta
-jef"this monster is going to need a bit of care and feeding...maybe
even some sort of /. like moderation scheme to keep hardware comments
maintained"spaleta

Absolutely, though I'd think that advogato or a combination of /. and
advogato voting systems for different parts (/. for individual
reports, advogato for reporters?) would make sense.


Anyway, it's clearly a lot of work, and I don't want to minimize
that.

michaelkjohnson

"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/

[Julien Olivier]

Post by Michael K. Johnson

But, like mandrake's, it is woefully lacking.

One thing I want to see happen is a self-service hardware compatibility
service that makes it easy for users to provide information on the
compatibility they are seeing with their hardware on Fedora, and for
which the information is well-enough organized that you can actually
have good searches for that information.
My basic concept is that there's a lot of information on the system
that you can get at with tools like lspci and dmidecode. Parse that
into units of hardware and present the user a GUI that lets them
make some easy assignments for how well things work (default is
"don't know" in order to avoid garbage) with definitions for the
levels, and places for comments for each piece of hardware. Then
this data is uploaded (signed with the user's gpg key?) in a
structured, parseable format (xml?) to a centralized database that
is both downloadable and web-searchable.
Any volunteers? :-)

I could be interested but I'm just wondering: why not use a web form to
fetch those information ? Isn't it easier to create a simple form in PHP
on redhat's website than create a GUI app ? Users will need an internet
connection to validate their form anyway, so I don't see the point to
have a desktop app. But maybe I'm missing something...

Post by Michael K. Johnson
(I'm cc'ing the devel list because I've noticed several people looking
for projects lately -- here's a candidate. If you are interested,
start the discussion, but I suggest keeping it on fedora-devel-list
since fedora-test-list is high-enough traffic as it is...)
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
--
fedora-devel-list mailing list
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Michael K. Johnson]

Post by Julien Olivier
I could be interested but I'm just wondering: why not use a web form to
fetch those information ? Isn't it easier to create a simple form in PHP
on redhat's website than create a GUI app ? Users will need an internet
connection to validate their form anyway, so I don't see the point to
have a desktop app. But maybe I'm missing something...

Your idea is "run this text application to create a file which you
then POST to a web site and it then provides you with web forms to
fill in" -- do I understand right?

My reasons for a GUI application:

o Seems easier for the novice user to select one "report my hardware"
icon from a menu than run a text program, then go through several
web pages to upload it and fill out forms about it. This is really
three points: Easier to find, fewer steps to completion, and
perhaps it might be possible to make the interface a bit smarter.

o Could conceivably do queries based on user input (this is vague)
and users could intentionally limit the hardware they report
(like if they don't want to publish to the whole world that they
have a $50,000 computer sitting in their basement or they have
hardware under NDA that they are required not to talk about and
really don't ever want that information going out of their network.

But that doesn't mean it's the only way this could work, I'm just sharing
my vision...

michaelkjohnson

"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/

[Julien Olivier]

Post by Michael K. Johnson

Post by Julien Olivier
I could be interested but I'm just wondering: why not use a web form to
fetch those information ? Isn't it easier to create a simple form in PHP
on redhat's website than create a GUI app ? Users will need an internet
connection to validate their form anyway, so I don't see the point to
have a desktop app. But maybe I'm missing something...

Your idea is "run this text application to create a file which you
then POST to a web site and it then provides you with web forms to
fill in" -- do I understand right?

Hmm... not at all :) My idea is:

-The user clicks on a link (for example http://hardwarde.redhat.com)
-He then fills a web form asking him which hardware he has and how it
works (in an "assistant/wizard/druid" form, like in bugzilla).
-He validates

Post by Michael K. Johnson
o Seems easier for the novice user to select one "report my hardware"
icon from a menu than run a text program, then go through several
web pages to upload it and fill out forms about it. This is really
three points: Easier to find, fewer steps to completion, and
perhaps it might be possible to make the interface a bit smarter.

Well, my idea was to click on "report my hardware" and be sent to the
right webpage through Mozilla or Epiphany. So I guess it's as simple as
using a GUI application.

Post by Michael K. Johnson
o Could conceivably do queries based on user input (this is vague)
and users could intentionally limit the hardware they report
(like if they don't want to publish to the whole world that they
have a $50,000 computer sitting in their basement or they have
hardware under NDA that they are required not to talk about and
really don't ever want that information going out of their network.
But that doesn't mean it's the only way this could work, I'm just sharing
my vision...
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
--
fedora-devel-list mailing list
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Michael K. Johnson]

Post by Julien Olivier
-The user clicks on a link (for example http://hardwarde.redhat.com)
-He then fills a web form asking him which hardware he has and how it
works (in an "assistant/wizard/druid" form, like in bugzilla).
-He validates

o Not sufficiently structured

o Not sufficiently complete

o Not sufficiently verified

o Too much work for the user for widespread compliance

o Such databases we already have, and they aren't in nearly
enough widespread use to be helpful.

michaelkjohnson

"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/

[Julien Olivier]

Aaargh, forget my proposition... it is stupid because it needs the user
to _know_ what hardware he has and fill everything himself. I understand
that a GUI application would have the advantage to be able to
"auto-detect" the hardware and do most of the work for the user.

That said, it could still be done the following way:

- When you click on "report my hardware", a cookie is generated
containing all the information required automatically.
- The website is opened, reads the cookie and pre-fills the form
- The user can modify the defaults choices and validates

The drawback:

- if your navigator is configured to refuse cookies, you're screwed...

[Behdad Esfahbod]

Post by Julien Olivier
Aaargh, forget my proposition... it is stupid because it needs the user
to _know_ what hardware he has and fill everything himself. I understand
that a GUI application would have the advantage to be able to
"auto-detect" the hardware and do most of the work for the user.
- When you click on "report my hardware", a cookie is generated
containing all the information required automatically.
- The website is opened, reads the cookie and pre-fills the form
- The user can modify the defaults choices and validates
- if your navigator is configured to refuse cookies, you're screwed...

This is a non-issue. What about this: App (no GUI) collects
needed info, POSTs that to the website, acquires a session-id,
launches browser with the session-id. BTW, offering the service
at the right time is quite important. Say, when the
hotplug/kudzu/... fails to configure a device, should offer the
user to report that.

behdad

[Julien Olivier]

Post by Behdad Esfahbod

Post by Julien Olivier
Aaargh, forget my proposition... it is stupid because it needs the user
to _know_ what hardware he has and fill everything himself. I understand
that a GUI application would have the advantage to be able to
"auto-detect" the hardware and do most of the work for the user.
- When you click on "report my hardware", a cookie is generated
containing all the information required automatically.
- The website is opened, reads the cookie and pre-fills the form
- The user can modify the defaults choices and validates
- if your navigator is configured to refuse cookies, you're screwed...

This is a non-issue. What about this: App (no GUI) collects
needed info, POSTs that to the website, acquires a session-id,
launches browser with the session-id.

Technically, it's a good idea but I can already hear comments about how
Fedora spies its users by sending reports of their users' hardware
without any human intervention... More over, it could well be that you
don't want your hardware information (all or partially) to be sent to
Fedora (for any reason). But maybe a solution could be to allow users to
configure which kind of information can/cannot be sent to Fedora. For
example, it could be configured at install time or in the firstboot
tool.

Post by Behdad Esfahbod
BTW, offering the service
at the right time is quite important. Say, when the
hotplug/kudzu/... fails to configure a device, should offer the
user to report that.

Of course, that would be very smart and useful.

Post by Behdad Esfahbod
behdad
--
fedora-devel-list mailing list
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Nicolas Mailhot]

Post by Julien Olivier

Post by Behdad Esfahbod
BTW, offering the service
at the right time is quite important. Say, when the
hotplug/kudzu/... fails to configure a device, should offer the
user to report that.

Of course, that would be very smart and useful.

Gosh, yet another reason to kill kudzu/firstboot on sight.
Let's not annoy users with this ok ?

Enough people will submit this info willingly if the tool is well made
you don't need to force-feed it to users. Last I've seen the pci db
maintains itself well enough without any of this crap.

Put big notices on bugzilla startup pages, default index.html, etc if
you want but do not resort to any M$-like "were do we want you to go
today" automated junkware.

Regards,

[Julien Olivier]

Post by Nicolas Mailhot
Gosh, yet another reason to kill kudzu/firstboot on sight.
Let's not annoy users with this ok ?
Enough people will submit this info willingly if the tool is well made
you don't need to force-feed it to users. Last I've seen the pci db
maintains itself well enough without any of this crap.
Put big notices on bugzilla startup pages, default index.html, etc if
you want but do not resort to any M$-like "were do we want you to go
today" automated junkware.

I'm not sure I understand how this is junkware... I mean that if I
install a new piece of hardware I've just bought and get an error
message stating that this hardware isn't supported/doesn't work with my
Linux distribution, I would be glad to know that I can easily report
this to my distribution vendor so that I can soon enjoy my new hardware
(and I really mean it :)). But maybe I'm the only one in this case ?

Post by Nicolas Mailhot
Regards,

[Nicolas Mailhot]

Post by Julien Olivier
I'm not sure I understand how this is junkware... I mean that if I
install a new piece of hardware I've just bought and get an error
message stating that this hardware isn't supported/doesn't work with my
Linux distribution, I would be glad to know that I can easily report
this to my distribution vendor so that I can soon enjoy my new hardware
(and I really mean it :)). But maybe I'm the only one in this case ?

What I meant is kudzu will fail, and re-fail at each boot, sometimes you
have parks of hardware that will each fail in the same way, and I don't
ever want to see "do you really, really, really not want to report"
popups on 20 boxes at every boot.

Put a reference in the release notes, put in in the default index.html,
put it on bugzilla startup page, but do not put ever think to put it in
startup scripts.

It's bad enough every single RH server I've seen have startup/shutdown
failures because someone assumed you have to have a sound card in each
and every system, without someone adding "helpful" hints yo report
hardware problems then. Let the user choose how and when he wants to
report. Do not try to "help" it make the decision.

Cheers,

[Julien Olivier]

Post by Nicolas Mailhot

Post by Julien Olivier
I'm not sure I understand how this is junkware... I mean that if I
install a new piece of hardware I've just bought and get an error
message stating that this hardware isn't supported/doesn't work with my
Linux distribution, I would be glad to know that I can easily report
this to my distribution vendor so that I can soon enjoy my new hardware
(and I really mean it :)). But maybe I'm the only one in this case ?

What I meant is kudzu will fail, and re-fail at each boot, sometimes you
have parks of hardware that will each fail in the same way, and I don't
ever want to see "do you really, really, really not want to report"
popups on 20 boxes at every boot.

OK, there I fully agree with you. If it has to happen, it should happen
only once.

Post by Nicolas Mailhot
Put a reference in the release notes, put in in the default index.html,
put it on bugzilla startup page, but do not put ever think to put it in
startup scripts.
It's bad enough every single RH server I've seen have startup/shutdown
failures because someone assumed you have to have a sound card in each
and every system, without someone adding "helpful" hints yo report
hardware problems then. Let the user choose how and when he wants to
report. Do not try to "help" it make the decision.

I too agree that kudzu should be deactivated by default on servers. But
we aren't talking of servers here, are we ?

Post by Nicolas Mailhot
Cheers,

[Maxwell Kanat-Alexander]

Due to privacy concerns, kudzu interacting with the Hardware Database
seems unlikely at this time, though we ought to consider it in the
future if we can get a survey that says that many users would be
interested in that sort of functionality.

Of course, if we did implement it, we'd do it in the least annoying way
possible. :-)

-M

[Behdad Esfahbod]

Post by Nicolas Mailhot

Post by Julien Olivier

Post by Behdad Esfahbod
BTW, offering the service
at the right time is quite important. Say, when the
hotplug/kudzu/... fails to configure a device, should offer the
user to report that.

Of course, that would be very smart and useful.

Gosh, yet another reason to kill kudzu/firstboot on sight.
Let's not annoy users with this ok ?
Enough people will submit this info willingly if the tool is well made
you don't need to force-feed it to users. Last I've seen the pci db
maintains itself well enough without any of this crap.
Put big notices on bugzilla startup pages, default index.html, etc if
you want but do not resort to any M$-like "were do we want you to go
today" automated junkware.

There should be a page saying "I couldn't configure yours"
(perhaps with a single Ok button). Just put at the other corner,
an small button reading "Report ..."...

Post by Nicolas Mailhot
Regards,

[Nicolas Mailhot]

Post by Behdad Esfahbod

Post by Nicolas Mailhot

Post by Julien Olivier

Post by Behdad Esfahbod
BTW, offering the service
at the right time is quite important. Say, when the
hotplug/kudzu/... fails to configure a device, should offer the
user to report that.

Of course, that would be very smart and useful.

Gosh, yet another reason to kill kudzu/firstboot on sight.
Let's not annoy users with this ok ?
Enough people will submit this info willingly if the tool is well made
you don't need to force-feed it to users. Last I've seen the pci db
maintains itself well enough without any of this crap.
Put big notices on bugzilla startup pages, default index.html, etc if
you want but do not resort to any M$-like "were do we want you to go
today" automated junkware.

There should be a page saying "I couldn't configure yours"
(perhaps with a single Ok button). Just put at the other corner,
an small button reading "Report ..."...

That's an ok too much.
Just do 20 installs on a row or a big integration run with every single
app considering "it's just another screen" and you'll start noticing
such things.

There are no free interactive screens. That's one of the lessons the HiG
people learned.

[Kreg Steppe]

I would definatly opt-in for something like this.
I would also suggest that if there was a problem installing something,
and you opt-in have it check the DB for any notes to a solution and
display them instead of just reporting it.

Post by Julien Olivier

Post by Behdad Esfahbod

Post by Julien Olivier
Aaargh, forget my proposition... it is stupid because it needs the user
to _know_ what hardware he has and fill everything himself. I understand
that a GUI application would have the advantage to be able to
"auto-detect" the hardware and do most of the work for the user.
- When you click on "report my hardware", a cookie is generated
containing all the information required automatically.
- The website is opened, reads the cookie and pre-fills the form
- The user can modify the defaults choices and validates
- if your navigator is configured to refuse cookies, you're screwed...

This is a non-issue. What about this: App (no GUI) collects
needed info, POSTs that to the website, acquires a session-id,
launches browser with the session-id.

Technically, it's a good idea but I can already hear comments about how
Fedora spies its users by sending reports of their users' hardware
without any human intervention... More over, it could well be that you
don't want your hardware information (all or partially) to be sent to
Fedora (for any reason). But maybe a solution could be to allow users to
configure which kind of information can/cannot be sent to Fedora. For
example, it could be configured at install time or in the firstboot
tool.

Post by Behdad Esfahbod
BTW, offering the service
at the right time is quite important. Say, when the
hotplug/kudzu/... fails to configure a device, should offer the
user to report that.

Of course, that would be very smart and useful.

Post by Behdad Esfahbod
behdad
--
fedora-devel-list mailing list
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Jef Spaleta]

Post by Michael K. Johnson
Say you are searching for video card foo. It has average rating bar.
You want to look into this more, so you click on "read all reports"
Reports that look interesting, you click on "see hardware" and you
have the entire hardware database for the machine (we probably
shouldn't include things like tag ids from dmidecode :-) and you
can see what the context is. Some main things (say motherboard
version, running kernel version, that type of thing) can be displayed
in short form with the review.

Well i was thinking take it a step further down the fancy metric...and
allow people to specify a few core components in one query and have
crossed referenced reports pop up in a most/least relevant listing.
I'd imagine there will be a metric crapload of reports for certain video
cards. Being able to narrow down by picking your mobo and maybe even
your monitor could help sort the initial list of reports you are going
to pull up, just by bringing any relevant mobo/card issues up to the
top.

Post by Michael K. Johnson
Then, if you really want to get fancy, you add the ability to add
comments to individual reports. You happen to know that the reason
the video card foo didn't work on that system is that there's a
conflict with bios version J.UNK on that particular motherboard.
So you post a annotation to that effect.

Hmm..is it wise to make it point and click easy to list brokenness in a
hardware database that is completely seperate from bugzilla? I'd really
hate to lose useful bugreports to comments in the hardware database and
make developers have to troll the hardware reviews as well to find out
if a piece of hardware has a problem. A review based hardware database
makes some sense as an end-user tool for people choosing hardware to
use, but i don't know if it makes sense as a tool for developers to keep
track of specific hardware issues...and i'd hate to see review comments
become the prefered end-user way to report problems...but have bugzilla
be the preferred developer way to track problems.

Post by Michael K. Johnson
If you want to get really fancy, you do an advogato-like voting
structure so that consistently clueful reporters have their
ratings weighted higher in producing the averages.

Well i vote for mocking up the forum side of this with a pre-existing
forum codebase if at all possible. A specially crafted advogato reporter
client to script the hardware reports to submit would be simple for
someone to bootstrap together i would imagine. But would a stock
advogato forum provide enough initial usefulness as a target forum
platform to play with? Is linux-usb.org device database a useful example
of this sort of thing minus the advogato ranking system?

http://www.qbik.ch/usb/devices/

-jef"just looking for a good pre-existing starting point"spaleta

[Michael K. Johnson]

Post by Jef Spaleta
I'd imagine there will be a metric crapload of reports for certain video
cards. Being able to narrow down by picking your mobo and maybe even
your monitor could help sort the initial list of reports you are going
to pull up, just by bringing any relevant mobo/card issues up to the
top.

Sure, I was just trying to keep the example simple. :-)

Post by Jef Spaleta
Hmm..is it wise to make it point and click easy to list brokenness in a
hardware database that is completely seperate from bugzilla? I'd really
hate to lose useful bugreports to comments in the hardware database and
make developers have to troll the hardware reviews as well to find out
if a piece of hardware has a problem. A review based hardware database
makes some sense as an end-user tool for people choosing hardware to
use, but i don't know if it makes sense as a tool for developers to keep
track of specific hardware issues...and i'd hate to see review comments
become the prefered end-user way to report problems...but have bugzilla
be the preferred developer way to track problems.

Well, it would be nice to have someplace to point people when the
answer is RESOLVED->NOTABUG (hardware not supported)

You'd definitely want to have the ability to file a bug report in
bugzilla and say "my hardware report is at URL foo" for easy access.
bugzilla really isn't set up for this kind of information AFAIK...

(Now Dave will chime in and tell me that bugzilla can butter my
bread for me, of course.)

Post by Jef Spaleta
Well i vote for mocking up the forum side of this with a pre-existing
forum codebase if at all possible. A specially crafted advogato reporter
client to script the hardware reports to submit would be simple for
someone to bootstrap together i would imagine. But would a stock
advogato forum provide enough initial usefulness as a target forum
platform to play with? Is linux-usb.org device database a useful example
of this sort of thing minus the advogato ranking system?
http://www.qbik.ch/usb/devices/

Mmmm, I'm thinking a lot more structured information and cross-linking.
I'm not sure how useful it is without that. I think you really want
a database behind it in order to do interesting queries, especially
the kinds of queries you have proposed. :-)

michaelkjohnson

"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/

[Warren Togami]

Post by Jef Spaleta
Hmm..is it wise to make it point and click easy to list brokenness in a
hardware database that is completely seperate from bugzilla? I'd really
hate to lose useful bugreports to comments in the hardware database and
make developers have to troll the hardware reviews as well to find out
if a piece of hardware has a problem. A review based hardware database
makes some sense as an end-user tool for people choosing hardware to
use, but i don't know if it makes sense as a tool for developers to keep
track of specific hardware issues...and i'd hate to see review comments
become the prefered end-user way to report problems...but have bugzilla
be the preferred developer way to track problems.

When Michael, the kernel guy, proposes a GUI solution, it must be for
good reason. =)

End-users NEED a simple way to submit hardware information where they
don't need to learn about tools like lspci, dmesg, dmidecode, etc. It
saves us time by having a large pool of submitted data, allowing us to
see trends and avoid asking for information. Furthermore, fewer poorly
written Bugzilla entries from end-users would waste our time.

As long as the topic contains "Windows" this seems like a good time to
mention what I saw in recent Windows betas that I thought was a really
good idea. When Windows was unable to find a built-in driver for an
unknown piece of hardware, it searched a database on the Internet.
While this mechanism was useless in the AMD64 Windows beta that I tried
since ZERO DRIVERS were available, I really see the potential for us to
harness this same idea.

In addition to simply submitting data, our system should be able to pull
up links to more information about the specific hardware that we are
using. Very often workarounds exist for problems, and it would save us
even more time if users learned about them automatically.

Warren

[Tom Diehl]

Post by Warren Togami
As long as the topic contains "Windows" this seems like a good time to
mention what I saw in recent Windows betas that I thought was a really
good idea. When Windows was unable to find a built-in driver for an
unknown piece of hardware, it searched a database on the Internet.
While this mechanism was useless in the AMD64 Windows beta that I tried
since ZERO DRIVERS were available, I really see the potential for us to
harness this same idea.

AFAIK it has been in windoze since W2K. I have used it many times. You just
need the NIC drivers installed and working and the rest is pretty much
automagic.

Post by Warren Togami
In addition to simply submitting data, our system should be able to pull
up links to more information about the specific hardware that we are
using. Very often workarounds exist for problems, and it would save us
even more time if users learned about them automatically.

+1

[Xose Vazquez Perez]

Post by Michael K. Johnson
One thing I want to see happen is a self-service hardware compatibility
service that makes it easy for users to provide information on the
compatibility they are seeing with their hardware on Fedora, and for
which the information is well-enough organized that you can actually
have good searches for that information.

There is two sources of good information: linux-kernel and Xfree86.
Nearly all devices carry a PCI_ID information inside. Linux kernel and Xfree86
usually collect it to load the correct device driver.

This is a big project, and is better to split it in chunks,
basic PCI HW(SCSI, VIDEO, NET...) first and latter more(USB....):

1- HW detection by Anaconda and kuzdzu

pcitable from hwdata package is the best place to begin.
I have done some work and I am waiting for Martin Mares from http://pciids.sf.net
to send updates to hwdata maintainers.

2 - Documentation about HW supported.

Greg KH <***@kroah.com> said me in linux-kernel nl that devices supported
by kernel are "already listed in the MODULE_DEVICE_TABLE and can be parsed
later by userspace tools quite easily."

Xfree86 :-?

Volunteers? where are python wizards :-) ?

I hope to see some documentation as FreeBSD has:
http://www.freebsd.org/releases/5.1R/hardware-i386.html

[Maxwell Kanat-Alexander]

All right. We had a bit of discussion on this in #fedora-devel. Here's
a quick summary of what the project seems to need.

(1) A database that holds hardware information
(2) A GUI tool to submit that information
(3) A web interface to use that information

Requirements and Functionality
------------------------------

Primary Purpose of the System: To allow users to know if their hardware
works with Fedora/Red Hat Linux.

Secondary Purpose: To allow users to resolve hardware issues with Red
Hat Linux products.

How this is accomplished: By creating a database of hardware and how
well it works.

Specific Implementation: Creating the database from end-user data,
which has the added advantage of giving people the opportunity to
participate in the Fedora project.

Value of the Product: If well-designed, the product will allow both
Fedora and Enterprise customers to have confidence that their hardware
works with our software.

This leads to the following requirements:

* The system needs to hold hardware information in a logical fashion.

(Meaning, the more specific fields that we can get about the hardware
outside of a "comments" field, the better.)

* The system needs to be easily cross-indexable.
* The system needs to be as easy as possible for the end-user to use.
* It must be likely that the average end-user will submit their
information.
* The submission must take no longer than 10 minutes, though under 5
minutes would be ideal.
* The system must be flexible enough to adapt to new types of hardware
that we cannot predict.
* The end-user of the web product must be able to determine the quality
of the data that they are presented with.
* The end-users privacy must be protected to the exact degree they
desire.

What to use
-----------

When it comes to (1), we'll want a real database solution, probably
based on PostgreSQL. Ideally, I'd like to see if there's some high-level
solution already in existence that can be modified according to our
parameters. We could build from the database up, but the incredible
amount of effort that this project requires could be considerably
lessened by some higher-level tool.

Any suggestions in this area?

For (2), we'll probably have to roll our own. Does _anything_ like this
already exist in the open-source world?

For (3), it's clear that there are components of various systems that
will do various parts of what we need.
For example, if we want to rank comments, Advogato has been suggested,
for the reason of algorithmic quality and code quality.
Slashdot is an alternative, however that seemed to be not as well-liked
initially.
Are there any less well-known Open Source projects that would suit
these needs better than Advogato?

As far as the actual browsing of the hardware, are there any projects
that would give us a leg up here?

Now, it would be possible to use a sort of modified Bugzilla to do what
we want. The problem seems to be that Bugzilla is a system much more
complex than our hardware database is going to be. The volume of our
hardware database is going to be pretty high, and a Bugzilla with a high
level of submission requires a lot of maintenance, volunteer and
otherwise (witness bugzilla.mozilla.org).

In general, it seems that Bugzilla is out, from consensus. Feel free to
argue -- we're at the "throwing ideas around" stage.

Languages
---------

GUI: PyGTK. It's clearly the Red Hat standard for GUI projects.

Backend: SQL and Python. Some C if required for interfacing with Open
Source Projects we use.

Web Interface: PHP or Python. Once again, this might also depend
somewhat on the other projects we integrate.

Other Implementation Notes
--------------------------

We have a lot of tools that can get data for us:

lspci, dmidecode, dmesg

What I _don't_ really think would be fun would be parsing the text
output of those programs. MKJ thought it would be ideal if dmidecode
could give us XML. Anybody know if there's a tool that already does
this, or something we could start with? hwbrowser seems to make sense of
that data somehow -- is there a way to get data out of it? Who's the
maintainer of hwbrowser?

It would be a good idea to have people submit data and have a "No
Problems Reported" status.

The program would probably be a small applet that exists in the tray
until run. After that, it should disappear forever. The alternative is
an icon on the user's desktop saying "submit your hardware information"
or something like that.

Priorities
----------

(1) A backend which accepts data.
(2) A method of populating the backend.
(3) A method of browsing the submitted data.
(4) A method of using the submitted data to resolve problems.
(5) Connecting the submitted data to driver downloads. (A great idea
from Warren.)

Cost
----

* One computer to act as the DB server, etc.
* One computer to run development versions.
* Bandwidth -- I'm not sure on this one, how much do you think it would
take?


Okay, this is just a rapid sketch! More suggestions!! If I can get a
space somewhere, I can maintain this document as a web page. I'm sure I
left a lot of stuff out. It's a big project. :-)

Also, who wants to actually work on this, and on what part?

-Max K-A

[Warren Togami]

Post by Maxwell Kanat-Alexander
Languages
---------
GUI: PyGTK. It's clearly the Red Hat standard for GUI projects.
Backend: SQL and Python. Some C if required for interfacing with Open
Source Projects we use.
Web Interface: PHP or Python. Once again, this might also depend
somewhat on the other projects we integrate.

This is also a clear case for XMLRPC-like communication between client
and server.

Post by Maxwell Kanat-Alexander
Other Implementation Notes
--------------------------
lspci, dmidecode, dmesg
What I _don't_ really think would be fun would be parsing the text
output of those programs. MKJ thought it would be ideal if dmidecode
could give us XML. Anybody know if there's a tool that already does
this, or something we could start with? hwbrowser seems to make sense of
that data somehow -- is there a way to get data out of it? Who's the
maintainer of hwbrowser?

lspci and some other data can be communicated easily parsed from the
numeric form:

[***@laptop root]# lspci -n
00:00.0 Class 0600: 1106:0305 (rev 03)
00:01.0 Class 0604: 1106:8305
00:07.0 Class 0601: 1106:0686 (rev 40)
00:07.1 Class 0101: 1106:0571 (rev 06)
00:07.2 Class 0c03: 1106:3038 (rev 1a)
00:07.3 Class 0c03: 1106:3038 (rev 1a)
00:07.4 Class 0601: 1106:3057 (rev 40)
00:07.5 Class 0401: 1106:3058 (rev 50)
00:07.6 Class 0780: 1106:3068 (rev 30)
00:0a.0 Class 0607: 104c:ac51
00:0a.1 Class 0607: 104c:ac51
00:0e.0 Class 0c00: 104c:8020
00:10.0 Class 0200: 10ec:8139 (rev 10)
01:00.0 Class 0300: 1002:4c4d (rev 64)

Ultimately all of this and other data should be converted into XML and
communicated over the Internet. The pygtk applications on the client
side displays human readable information based upon a lookup table from
this data. That particular part isn't the challenge.

Post by Maxwell Kanat-Alexander
It would be a good idea to have people submit data and have a "No
Problems Reported" status.
The program would probably be a small applet that exists in the tray
until run. After that, it should disappear forever. The alternative is
an icon on the user's desktop saying "submit your hardware information"
or something like that.

I hope this applet would not be within the default Gnome/KDE profile,
because then it would pop up on the user desktop of all users at least
once. This is not ideal for massive multi-user systems like LTSP.

I believe this may be ideal for firstboot, and also choosable from the
System menu. Perhaps there are better ideas...

Warren

[Maxwell Kanat-Alexander]

Post by Warren Togami
This is also a clear case for XMLRPC-like communication between client
and server.

That makes sense.

Post by Warren Togami
Ultimately all of this and other data should be converted into XML and
communicated over the Internet. The pygtk applications on the client
side displays human readable information based upon a lookup table from
this data.

Agreed. Is there a pre-existing source of data that we could use for
that lookup table?

Post by Warren Togami
I hope this applet would not be within the default Gnome/KDE profile,
because then it would pop up on the user desktop of all users at least
once. This is not ideal for massive multi-user systems like LTSP.

I would think that it would only come up once, system-wide.

Post by Warren Togami
I believe this may be ideal for firstboot, and also choosable from the
System menu. Perhaps there are better ideas...

We discussed having it on firstboot. Here's the pros and cons:

Pro: Doesn't clutter up user space after firstboot.
Pro: Easy to draw users' attention

Con: I heard a "nobody likes firstboot already" that may or may not be
true.
Con: It's hard to determine whether or not hardware works on the first
boot.

The only real problem is the last one. I think it would be great to get
the data on firstboot, and then we could have a lot of "No Problems
Reported" on a lot of hardware.
What are our options then for getting further data about what hardware
works and what doesn't?

Here's the info we can get at firstboot:

(1) What hardware the user has.
(2) Do we have drivers for it?
(3) Some simple diagnostics, maybe.

Perhaps we can just leave it up to more advanced users to report when
they have hardware problems, and leave it to the more basic users to
just search the advanced users' reports. That is, we'd have a "Submit
Hardware Information" in the System Tools.

-M

[Stuart Children]

Hi all

Post by Maxwell Kanat-Alexander

Post by Warren Togami
I believe this may be ideal for firstboot, and also choosable from the
System menu. Perhaps there are better ideas...

Pro: Doesn't clutter up user space after firstboot.
Pro: Easy to draw users' attention
Con: I heard a "nobody likes firstboot already" that may or may not be
true.
Con: It's hard to determine whether or not hardware works on the first
boot.

Just a thought: how about linking to [a page about] it from
file:///usr/share/doc/HTML/index.html? That way it is presented to the
user when they fire up a web browser for the first time. Everyone should
see it. Yet it's simple to get rid of - most people I expect change
their homepage anyway. Even if they don't there's no real added
annoyance because the application itself hasn't been loaded up.

The only issues I can see here are:
1) It's easy for people to ignore.
2) People have to read about it and then execute the program themselves
rather than it just popping up itself.
3) People who don't install/use a web browser won't see it at all.

1) and 2) could be argued as benefits though! :) However, to address the
above:
1) Redesign index.html so it looks more interesting. Put clear headings
like "Need help?", "Developers", "Updates", etc.
2) Can be lessened by telling people where to look in the system menu to
launch the program.
3) This is only an issue if it such people are amoungst those you're
trying to target. I would suspect not.

The same could apply to other applications.

Cheers

[Maxwell Kanat-Alexander]

Post by Stuart Children
Just a thought: how about linking to [a page about] it from
file:///usr/share/doc/HTML/index.html?

This seems like a possible option.

Perhaps we collect the initial information about the hardware on
firstboot, and then we explain in index.html how to report further
difficulty, and that it's a Great Way to Contribute!

-M

[Nicolas Mailhot]

Post by Maxwell Kanat-Alexander
Other Implementation Notes
--------------------------
lspci, dmidecode, dmesg

lsusb, some sort of lspcsi/lsata and the acpi guys will want
/proc/acpi/dst (and some of those can crash a system sometimes)

usb is very important - you can get half your devices hooked on it
nowadays.

I'm deeply sceptical about any gui implementation from scratch - a
form-based tool at first to test what exact information is needed seems
more logical (but I'm not the one writing the code:)

The db could be hosted at a vendor-neutral location like osdl, and a
system "card" accessible via a simple url so it can be referenced in the
various bugzillas out there. (you aren't talking about replacing
bugzilla are you ?)

There may also probably be ways to have per-component views to allow
linking to external info (vendor description pages, bios downloads,
linuxprinting db entry, linux driver homepage, newsgroup, etc)

Anyway this is a wonderful idea, and it should be shared will all the
other linux project that need hardware dbs.

Cheers,

[Alan Cox]

Post by Nicolas Mailhot

Post by Maxwell Kanat-Alexander
lspci, dmidecode, dmesg

lsusb, some sort of lspcsi/lsata and the acpi guys will want
/proc/acpi/dst (and some of those can crash a system sometimes)

/proc/pnpbios is another one if PnP BIOS is in use and can also have
some similar problems. Also cardinfo for pcmcica devices

[Maxwell Kanat-Alexander]

Post by Nicolas Mailhot
I'm deeply sceptical about any gui implementation from scratch - a
form-based tool at first to test what exact information is needed seems
more logical (but I'm not the one writing the code:)

What sort of tool were you thinking of?

Post by Nicolas Mailhot
The db could be hosted at a vendor-neutral location like osdl

I was thinking that it would be nice to have an all-Linux Hardware
Compatibility Database. The engineering problems would be immense, of
course, starting with the simple logical problems of how to do it at
all.

It might be better to design a single system that would be easily
portable by other vendors.

Post by Nicolas Mailhot
, and a
system "card" accessible via a simple url so it can be referenced in the
various bugzillas out there.

That's a good idea.

Post by Nicolas Mailhot
(you aren't talking about replacing
bugzilla are you ?)

Absolutely not. :-)

Post by Nicolas Mailhot
There may also probably be ways to have per-component views to allow
linking to external info (vendor description pages, bios downloads,
linuxprinting db entry, linux driver homepage, newsgroup, etc)

That is certainly a necessity, I'd think. I wonder how we'd get that
information -- automate it somehow, or get it from users, or have
volunteers populate it, or...?

Post by Nicolas Mailhot
Anyway this is a wonderful idea, and it should be shared will all the
other linux project that need hardware dbs.

I think it would be a great step forward for Linux in general, and
certainly a great asset to Fedora. :-)

-M

[Nicolas Mailhot]

Post by Maxwell Kanat-Alexander

Post by Nicolas Mailhot
I'm deeply sceptical about any gui implementation from scratch - a
form-based tool at first to test what exact information is needed seems
more logical (but I'm not the one writing the code:)

What sort of tool were you thinking of?

Stupid form with attachements like in bugzilla.
After a few months once everyone has agreed on the exact attachement
list/url list then it'll be time to write the gui client (keeping the
form interface since that's the one you'll need to perform searches and
this way people can report even if the gui tool is not installed on
their distro).

Post by Maxwell Kanat-Alexander

Post by Nicolas Mailhot
There may also probably be ways to have per-component views to allow
linking to external info (vendor description pages, bios downloads,
linuxprinting db entry, linux driver homepage, newsgroup, etc)

That is certainly a necessity, I'd think. I wonder how we'd get that
information -- automate it somehow, or get it from users, or have
volunteers populate it, or...?

1. Ask it from users each time they add a component without full info
(ie bug users till someone completed all the fields for a particular
hardware id)

and/or

2. Send a mail to interested groups each time a component is entered (ie
send to linuxprinting.org when people add a new printer, to ati when
people add a new ati card, etc)

Btw there should probably be a gateway to hotplug/dbus people somewhere.

Cheers,

[Julien Olivier]

Post by Nicolas Mailhot

Post by Maxwell Kanat-Alexander

Post by Nicolas Mailhot
I'm deeply sceptical about any gui implementation from scratch - a
form-based tool at first to test what exact information is needed seems
more logical (but I'm not the one writing the code:)

What sort of tool were you thinking of?

Stupid form with attachements like in bugzilla.
After a few months once everyone has agreed on the exact attachement
list/url list then it'll be time to write the gui client (keeping the
form interface since that's the one you'll need to perform searches and
this way people can report even if the gui tool is not installed on
their distro).

Another advantage of having a form ala bugzilla is that if your modem
doesn't work on Linux, if you have a Windows (or any other OS) partition
you still can boot to it and report your hardware failure. That said,
you could as well do it through bugzilla too.

[Behdad Esfahbod]

Post by Nicolas Mailhot
Btw there should probably be a gateway to hotplug/dbus people somewhere.

And perhaps hal in the future.

Post by Nicolas Mailhot
Cheers,

[Maxwell Kanat-Alexander]

Post by Nicolas Mailhot
this way people can report even if the gui tool is not installed on
their distro).

This is an important ability -- that if people have another O/S they
can boot up and report problems with, they ought to be able to do it
_somehow_. (Not saying that the method they use will be the one
everybody uses, but they ought to have a method.)

Post by Nicolas Mailhot
1. Ask it from users each time they add a component without full info
(ie bug users till someone completed all the fields for a particular
hardware id)

I think that this might work, particularly if we hold a lot of
information in a Vendor table so that certain things only have to be
worked out once.

I'll bet that certain vendors have a way that we could even process the
device info and automagically create a link to the driver. I can think
of a table structure and program logic right now that could make this
optional and easy.

Post by Nicolas Mailhot
2. Send a mail to interested groups each time a component is entered (ie
send to linuxprinting.org when people add a new printer, to ati when
people add a new ati card, etc)

We ought to allow people to subscribe! Let them know that they can get
information. Also, this way they can tell their users "Our hardware
works with Red Hat Linux" and be kept up to date on what hardware that's
true for.

Post by Nicolas Mailhot
Btw there should probably be a gateway to hotplug/dbus people somewhere.

Oh? Why them specifically?

-M

[David Zeuthen]

Post by Maxwell Kanat-Alexander
Other Implementation Notes
--------------------------
lspci, dmidecode, dmesg
What I _don't_ really think would be fun would be parsing the text
output of those programs. MKJ thought it would be ideal if dmidecode
could give us XML. Anybody know if there's a tool that already does
this, or something we could start with? hwbrowser seems to make sense of
that data somehow -- is there a way to get data out of it? Who's the
maintainer of hwbrowser?

May I propose to use the freedesktop.org HAL I'm working on? This
project is supposed to be a database of all hardware on the system, see

http://freedesktop.org/~hal/spec-0.2-pre/hal-spec.html

The HAL will have both hardware details as well as other properties that
may be merged per-device or per-user. For instance this is a HAL device
describing my sound card

device_id = '/org/freedesktop/Hal/devices/pci.00:08.0'
Bus = 'pci' (string)
GotDeviceInfo = false (bool)
State = NEED_DEVICE_INFO (int)
pci.className = 'Multimedia audio controller' (string)
pci.programmingInterface = 0 (0x0) (int)
pci.subClass = 1 (0x1) (int)
pci.class = 4 (0x4) (int)
pci.revision = 16 (0x10) (int)
pci.subsysDeviceName = '009e' (string)
pci.subsysDeviceId = 158 (0x9e) (int)
pci.subsysVendorName = 'Dell Computer Corporation' (string)
pci.subsysVendorId = 4136 (0x1028) (int)
pci.deviceName = 'ES1978 Maestro 2E' (string)
pci.vendorName = 'ESS Technology' (string)
pci.deviceId = 6520 (0x1978) (int)
pci.vendorId = 4701 (0x125d) (int)
pci.function = 0 (0x0) (int)
pci.slot = 8 (0x8) (int)
pci.busNumber = 0 (0x0) (int)

The idea is that Device Info Files can provide more properties. Now, it
would be extremely cool if the hardware database could actually provide
device info files..

Now, HAL is not finished and there are big changes from the 0.1 version,
but I expect to finish version 0.2 late this or early next month. This
version will support USB and PCI devices but it will be very easy to add
new kinds of types such as IEEE1394. HAL will depend only on D-BUS and
expat.

Thanks,
David

[Maxwell Kanat-Alexander]

Post by David Zeuthen
May I propose to use the freedesktop.org HAL I'm working on? This
project is supposed to be a database of all hardware on the system, see
http://freedesktop.org/~hal/spec-0.2-pre/hal-spec.html

This sounds like just what I was looking for. Is this data going to be
held centrally by freedesktop.org, or is it going to be in a distributed
tool?

-M

[David Zeuthen]

Post by Maxwell Kanat-Alexander

Post by David Zeuthen
May I propose to use the freedesktop.org HAL I'm working on? This
project is supposed to be a database of all hardware on the system, see
http://freedesktop.org/~hal/spec-0.2-pre/hal-spec.html

This sounds like just what I was looking for. Is this data going to be
held centrally by freedesktop.org, or is it going to be in a distributed
tool?

Oh that's a really good question. HAL is a quite new initiative so right
now the focus have only been on what is stored on the desktop system and
how desktop applications access it.

There's been quite a lot of discussion on the xdg-list about the device
information file format (I call them .fdi files - for Free Device
Information) and the conclusion was that these files will be XML and
resemble the Progeny discover file format with few changes. The
conclusion was also that for every device a .fdi file is nice to have
since it's difficult to know what capabilities a device got.

Now, it would be really cool to have deployable software for driving
this database that you are suggesting along with a web service or HTTP
interface that desktop applications can access so people can download
the .fdi files and/or required OS packages with driver software etc.

Deployment-wise freedesktop.org could possibly host a database, the
Fedora project could host one and maybe, someday, hardware vendors
and/or OEM's could host one.

Thanks,
David

[Maxwell Kanat-Alexander]

Post by David Zeuthen
There's been quite a lot of discussion on the xdg-list about the device
information file format (I call them .fdi files - for Free Device
Information) and the conclusion was that these files will be XML and
resemble the Progeny discover file format with few changes.

All right. Sounds a lot like what we were thinking of, as well.

Perhaps our tool could generate these files.

Or, instead, perhaps the server could generate them from the database,
which would be good since we could keep more up-to-date on file-format
changes and it would be easy (at 3 AM, I'd hope) to refresh your entire
freedesktop.org DB.

Post by David Zeuthen
Deployment-wise freedesktop.org could possibly host a database, the
Fedora project could host one and maybe, someday, hardware vendors
and/or OEM's could host one.

Sure. Maybe Fedora could host the central information database itself,
and freedesktop.org could hold the fdi database. The fdi database would
hold the automated access for the HAL, and the Fedora database would
host the user-searching-for-hardware-info side.

And, of course, if hardware vendors wanted to pitch in somehow as well,
nobody would object! :-)


It definitely sounds like we could work together on a lot of things!

-M

[David Zeuthen]

Post by Maxwell Kanat-Alexander

Post by David Zeuthen
There's been quite a lot of discussion on the xdg-list about the device
information file format (I call them .fdi files - for Free Device
Information) and the conclusion was that these files will be XML and
resemble the Progeny discover file format with few changes.

All right. Sounds a lot like what we were thinking of, as well.
Perhaps our tool could generate these files.
Or, instead, perhaps the server could generate them from the database,
which would be good since we could keep more up-to-date on file-format
changes and it would be easy (at 3 AM, I'd hope) to refresh your entire
freedesktop.org DB.

Yeah - of course in the ideal situation the device vendor ships the .fdi
file on standard media and/or submits it to your database. However, the
community will initially have to create these files.

Now, .fdi files should also be signed so there must be some way of
moderating what comes from your database; maybe some karma/voting system
for contributing users would fit the bill here?

Post by Maxwell Kanat-Alexander

Post by David Zeuthen
Deployment-wise freedesktop.org could possibly host a database, the
Fedora project could host one and maybe, someday, hardware vendors
and/or OEM's could host one.

Sure. Maybe Fedora could host the central information database itself,
and freedesktop.org could hold the fdi database. The fdi database would
hold the automated access for the HAL, and the Fedora database would
host the user-searching-for-hardware-info side.
And, of course, if hardware vendors wanted to pitch in somehow as well,
nobody would object! :-)
It definitely sounds like we could work together on a lot of things!

Definately! I will however concentrate on getting hal 0.2 finished so it
works with PCI and USB devices and storage. When that is done I'll look
into packaging it for FC1 and see how it fits in. Automated retrival of
.fdi files from a database such as yours and signing stuff is something
that will come after that

Btw, I intend that each device object in HAL to export a lot of device
specific information (right now only USB is documented, but I got PCI
working as well); perhaps it would be good already now to agree on
naming conventions (e.g. I call it usb.bDeviceClass) for specific
hardware properties?

Thanks,
David

[Maxwell Kanat-Alexander]

Post by David Zeuthen
Now, .fdi files should also be signed so there must be some way of
moderating what comes from your database; maybe some karma/voting system
for contributing users would fit the bill here?

We've talked about this over here, as well. We were sort of tentatively
planning on using Advogato somehow. Also, we could flag "high
contention" devices and volunteer admins could look at them, in
particularly intense cases.

Post by David Zeuthen
Definately! I will however concentrate on getting hal 0.2 finished so it
works with PCI and USB devices and storage. When that is done I'll look
into packaging it for FC1 and see how it fits in. Automated retrival of
.fdi files from a database such as yours and signing stuff is something
that will come after that.

All right. Should I join the xdg-list so that I can keep up-to-date on
this situation?

Post by David Zeuthen
Btw, I intend that each device object in HAL to export a lot of device
specific information (right now only USB is documented, but I got PCI
working as well); perhaps it would be good already now to agree on
naming conventions (e.g. I call it usb.bDeviceClass) for specific
hardware properties?

Yes, it would be a really good idea to talk about naming conventions.
:-) For me, the priority is on flexibility. There are going to be buses
we can't imagine, and devices we can't imagine, and we want to be able
to use them some day. :-) Any naming convention that translates easily
into XML and makes sense without being too specific is good by me.

I'm so thrilled to find that there's a project that's moving in even
somewhat the same direction as us. :-)

-M

[David Zeuthen]

Post by Maxwell Kanat-Alexander

Post by David Zeuthen
Definately! I will however concentrate on getting hal 0.2 finished so it
works with PCI and USB devices and storage. When that is done I'll look
into packaging it for FC1 and see how it fits in. Automated retrival of
.fdi files from a database such as yours and signing stuff is something
that will come after that.

All right. Should I join the xdg-list so that I can keep up-to-date on
this situation?

That would be great as hal is discussed there.

Post by Maxwell Kanat-Alexander

Post by David Zeuthen
Btw, I intend that each device object in HAL to export a lot of device
specific information (right now only USB is documented, but I got PCI
working as well); perhaps it would be good already now to agree on
naming conventions (e.g. I call it usb.bDeviceClass) for specific
hardware properties?

Yes, it would be a really good idea to talk about naming conventions.
:-) For me, the priority is on flexibility. There are going to be buses
we can't imagine, and devices we can't imagine, and we want to be able
to use them some day. :-) Any naming convention that translates easily
into XML and makes sense without being too specific is good by me.

Ok, all that stuff will go into the hal spec as support for new buses is
added; it should easily translate into XML as each bus is in a separate
namespace. It would be good to use the naming conventions from the bus
specs but it seems those are not necessarily freely available.

Many thanks,
David

[Alan Cox]

Post by David Zeuthen
Oh that's a really good question. HAL is a quite new initiative so right
now the focus have only been on what is stored on the desktop system and
how desktop applications access it.

Dumb question - should "provide an XML description for the database"
be something each HAL module is defined to do ?

[David Zeuthen]

Post by Alan Cox

Post by David Zeuthen
Oh that's a really good question. HAL is a quite new initiative so right
now the focus have only been on what is stored on the desktop system and
how desktop applications access it.

Dumb question - should "provide an XML description for the database"
be something each HAL module is defined to do ?

Yes. For every bus-type there are/will be thorough requirements on
well-defined hardware specific properties that will always be available
for every device on that bus-type. And yeah, generating the XML is easy
as python got D-BUS bindings, so it's really as simple as

import dbus
bus = dbus.Bus(dbus.Bus.TYPE_SYSTEM)
hal_service = bus.get_service("org.freedesktop.Hal")
hal_manager = hal_service.get_object("/org/freedesktop/Hal/Manager",
"org.freedesktop.Hal.Manager")
device_names = hal_manager.GetAllDevices()
for name in device_names:
device = hal_service.get_object(name, "org.freedesktop.Hal.Device")
properties = device.GetAllProperties()

and then selecting what subset to dump to XML. The spec currently only
mentions USB but I also got PCI working..

Thanks,
David

[Sean Millichamp]

Post by Maxwell Kanat-Alexander
Primary Purpose of the System: To allow users to know if their hardware
works with Fedora/Red Hat Linux.

When cataloging hardware things like PCI ids and chipsets obviously need
to be tracked because ultimately that is what Linux tends to care about
and that seems to be what most of the discussion is around.

However, from a user's standpoint they are much more likely to be
looking at brand names and models. I think it is very important that if
there is no way to conclusively determine a brandname/model from the
hardware systematically then there should be a spot for the user to
enter the brand and model as the product is sold and marketed.

I can do all the legwork finding a motherboard, looking up what
northbridge and southbridge it has on it and then searching the web for
any reports of problems with Linux but the average user isn't likely to
ever get more detailed then saying "I have a motherboard made by XXXX,
it's model number is YYYY, and the revision is ZZZ". Actually, even
getting the revision might be too much for most.

This sort of brand/model information will help people select Linux
compatible components before they ever purchase anything without having
to become experts on all the chipsets that go into it.

Sean

[Nicolas Mailhot]

Post by Sean Millichamp

Post by Maxwell Kanat-Alexander
Primary Purpose of the System: To allow users to know if their hardware
works with Fedora/Red Hat Linux.

When cataloging hardware things like PCI ids and chipsets obviously need
to be tracked because ultimately that is what Linux tends to care about
and that seems to be what most of the discussion is around.
However, from a user's standpoint they are much more likely to be
looking at brand names and models. I think it is very important that if
there is no way to conclusively determine a brandname/model from the
hardware systematically then there should be a spot for the user to
enter the brand and model as the product is sold and marketed.

Ie use the pci db and feed it too.
Manufacturer is usually not too difficult to guess (with pci and usb
devices). Model is not (even under other OSes).

Of course, you always have the problem of "branded" mass-market
hardware, when the id returned is the OEM one and the shiny logo on the
box something else.

Cheers,

[Maxwell Kanat-Alexander]

Post by Sean Millichamp
However, from a user's standpoint they are much more likely to be
looking at brand names and models. I think it is very important that if
there is no way to conclusively determine a brandname/model from the
hardware systematically then there should be a spot for the user to
enter the brand and model as the product is sold and marketed.

Now this is an interesting point, here. Ideally, we'd be able to
determine what we'd need from dmidecode and lspci. However, take the
example of my M-Audio Delta 44 (a soundcard with notorious ALSA
OSS-emulation problems). lspci reports it as an ICE Ensemble 1712
[Envy24] which is correct if you want the chipset. However, the level of
support for different Envy24 cards is actually different.

So here's what we do:

Allow users to enter the specific name of their hardware. When they do
this, they are presented with a drop-down box containing the other
entries that users have put in for this PCI id, and an "Other" to put in
their own. It's an optional entry. This keeps the data integrity fairly
high while allowing us to collect the relevant information.

-M

[Laurent GUERBY]

I've been thinking about something like that in the past few weeks.

I believe the project to collect and exploit hardware information
could be separated in three parts:

1. Software to collect the hardware data using various tools and
producing a harware data file.

2. Storage servers to collect user submitted hardware data files.

3. Software or web service to exploit the data files in storage
servers and their mirrors.

The simplest possible thing I can think of that would work under this
scheme:

1. The file format could be just a compressed text file recalling the
software version used, command issued without any filtering:

bash$ simple_lhw_collector.sh | gzip > my_lhw_data.gz
bash$ zcat my_lhw_data.gz
%lhwdata:version:simple_lhw_collector.sh version 0.0.0-pre-alpha0-ok-you-re-warned
%lhwdata:usertime:20031105T2223Z
%lhwdata:userinfo
Anonymous (default of course)
%lhwdata:command:cat /proc/version
Linux version 2.4.20-20.9 (***@stripples.devel.redhat.com) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Mon Aug 18 11:45:58 EDT 2003
%lhwdata:command:lspci
00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corp. 82815 815 Chipset AGP Bridge (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corp. 82801BAM ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801BAM IDE U100 (rev 02)
00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 Go] (rev b2)
02:03.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI Audio Accelerator (rev 10)
02:06.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01)
02:0f.0 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller
02:0f.1 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller
02:0f.2 FireWire (IEEE 1394): Texas Instruments PCI4451 IEEE-1394 Controller
07:00.0 USB Controller: NEC Corporation USB (rev 41)
07:00.1 USB Controller: NEC Corporation USB (rev 41)
07:00.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
%lwdata:command:...
...
%lwdata:end
bash$

This should allow us to survive future linux changes in userland tools
and to allow people developping more serious harware data file formats
or databases to get all the data they need. My estimate is that such a
file should be less than 20k compressed.

User information should be opt-in of course, with the user telling if
she wants to be contacted when new drivers or whatever are available
so she can give a hand testing.

Developpers are free to write whatever lhw file generator they like
(TUI, GUI, Qt, GTK+, PHP, ...), lhw collectors for the enterprise
running as a sophisticated distributed system ot collect data on your
company harware (ok a bit too much :).

2. The storage servers could be anything such as anonymous ftp upload,
web site with upload form, XML services, could be accessed from the
data collecting software,... To allow easy collecting and mirroring,
a standard flat file and directory could be used by all storage
systems and their mirrors, for example the official "fedora"
collecting site could be structured as follows:

http://www.fedora.us/lhw/200311/20031105/fedora-lhw-000042.gz
http://www.fedora.us/lhw/200311/20031105/fedora-lhw-000043.gz

So it's easy to mirror and aggregate since it's write once, never
move, rename or change (the date is obviously the server date at the
time of submission, and the number a serial id for the day). A
collecting site could just mirror all files with any technology (ftp
mirror, rsync). Big bandwidth mirrors could just offer monthly tar so
anyone has an easy access to all the user data.

When a user submits something to a storage server, she should get the
URL to the collected file, that would do as an id.

3. The fun part is the service part. May be google would index
compressed text files (may be served by a transparently uncompressing
web server), otherwise anyone is free to develop any software or web
site:

- we've done our best to collect in a simple way all possible harware
data without commiting to a particular database format. In particular
we can improve the data collector to follow future Linux developments
without changing the existing data.

- we made it easy to assemble, mirror and process the hardware
data. Everyone as a fair access to it, from the small kernel
developper looking for a driver to develop and debug, to the major
Linux companies.

What do people think about the general idea? May be Red Hat could
contribute some data to a first version (probably legal issues, I'm
not a lawyer)?

I've no idea on the number of systems we should expect, as I said we
should be able to host 50 000 systems per gigabyte, and there's no
need to have a central server to begin with, so people
can contribute their repository URL to the fedora
wiki.

Laurent

[Alan Cox]

One thing in favour of a generic format however (eg XML) is that
someone could write a windows version. That way you can also
collect stats on stuff that doesnt work..

[Laurent GUERBY]

Post by Alan Cox
One thing in favour of a generic format however (eg XML) is that
someone could write a windows version. That way you can also
collect stats on stuff that doesnt work..

There's nothing that prevent a window based tool
to generate a flat text file in the line of
the format I proposed (you just have to be imaginative
for :command: sections :). A specialized boot disk or ISO
could also do the job and write the file on
a vfat fs (USB key?) if any is available, then you could
use your favorite Windows & Internet Explorer version
to upload the resulting file.

The ultimate advantage over XML is that you could post
it to lkml or any linux list when you have a problem without getting
flames about HTML mails not allowed :) :).

Laurent

[Maxwell Kanat-Alexander]

Post by Laurent GUERBY
The ultimate advantage over XML is that you could post
it to lkml or any linux list when you have a problem without getting
flames about HTML mails not allowed :) :).

This would be handled by the idea of a "System Card" -- a URL that
uniquely identifies a certain system in the database.

You could include the link anywhere.

-M

[Maxwell Kanat-Alexander]

Post by Alan Cox
One thing in favour of a generic format however (eg XML) is that
someone could write a windows version. That way you can also
collect stats on stuff that doesnt work..

Another thing in favor of it is that it's flexible. We're not in a
hurry to make the system, so why not make it as flexible as possible?

Of course, this is still the "throw ideas around" stage. Whatever we
decide here is best will probably be the initial roadmap of the project,
though even that's subject to change over time.

-M

[Mike A. Harris]

Post by Alan Cox
One thing in favour of a generic format however (eg XML) is that
someone could write a windows version. That way you can also
collect stats on stuff that doesnt work..

There's a rather humourous double entendre in that sentence
depending on how you read/interpret it. ;o)

Was that intentional? ;o)

[Maxwell Kanat-Alexander]

I'm working on the updated spec/summary with all of the new suggestions
added in. It should be up as HTML tomorrow night, most likely, or
possibly tomorrow during the day. I'm not entirely sure what web space
I'll use for it. If anybody would like to volunteer some web space, I'd
be most gratified.

It would be up today, but I've got a date. :-)

-M

[Michael K. Johnson]

Post by Maxwell Kanat-Alexander
What I _don't_ really think would be fun would be parsing the text
output of those programs. MKJ thought it would be ideal if dmidecode
could give us XML. Anybody know if there's a tool that already does
this, or something we could start with? hwbrowser seems to make sense of
that data somehow -- is there a way to get data out of it? Who's the
maintainer of hwbrowser?

I don't know if there's a version of dmidecode that prints xml, but I
can't imagine that it would be remotely difficult to add, nor that it
would make the source code less clean.

http://www.nongnu.org/dmidecode/

Also note that there are a few other tools that come with dmidecode that
might have useful information for this project.

michaelkjohnson

"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/

[Alan Cox]

Post by Michael K. Johnson
I don't know if there's a version of dmidecode that prints xml, but I
can't imagine that it would be remotely difficult to add, nor that it
would make the source code less clean.

The newest version does yes

[Dave Jones]

Post by Michael K. Johnson
I don't know if there's a version of dmidecode that prints xml, but I
can't imagine that it would be remotely difficult to add, nor that it
would make the source code less clean.
http://www.nongnu.org/dmidecode/
Also note that there are a few other tools that come with dmidecode that
might have useful information for this project.

Beware that a lot of BIOS vendors put utter garbage in their DMI tables.

Dave

[Maxwell Kanat-Alexander]

Post by Dave Jones
Beware that a lot of BIOS vendors put utter garbage in their DMI tables.
Dave

Do you know if there's any sense to this garbage? I've noticed a lot of
"System Manufacturer: System Manufacturer" sort of things -- is this a
common pattern, or do we just have to figure it out in some fuzzy way?

-M

[Dave Jones]

Post by Maxwell Kanat-Alexander

Post by Dave Jones
Beware that a lot of BIOS vendors put utter garbage in their DMI tables.
Dave

Do you know if there's any sense to this garbage? I've noticed a lot of
"System Manufacturer: System Manufacturer" sort of things -- is this a
common pattern, or do we just have to figure it out in some fuzzy way?

Sometimes its empty fields, sometimes random characters, sometimes
complete lies (Like saying it has a full length EISA slot in a laptop)

Dave

[Maxwell Kanat-Alexander]

Post by Dave Jones

Post by Maxwell Kanat-Alexander

Post by Dave Jones
Beware that a lot of BIOS vendors put utter garbage in their DMI tables.

Do you know if there's any sense to this garbage? I've noticed a lot of
"System Manufacturer: System Manufacturer" sort of things -- is this a
common pattern, or do we just have to figure it out in some fuzzy way?

Sometimes its empty fields, sometimes random characters, sometimes
complete lies (Like saying it has a full length EISA slot in a laptop)

Sigh. I guess we'll have to fuzz it one way or another. We'll have to
check for certain impossible things, too, like that full-length EISA
slot in a laptop.

-M

[Bill Nottingham]

Post by Maxwell Kanat-Alexander

Post by Dave Jones
Sometimes its empty fields, sometimes random characters, sometimes
complete lies (Like saying it has a full length EISA slot in a laptop)

Sigh. I guess we'll have to fuzz it one way or another. We'll have to
check for certain impossible things, too, like that full-length EISA
slot in a laptop.

In general, I don't think you need to use DMI for anything other than:

- system type
- system model/serial number
- bios mfr/rev

Any of the other stuff (memory installed, slot types, etc.) is
either mostly irrelevant, or can be gotten by other means.

Bill

[Maxwell Kanat-Alexander]

Post by Bill Nottingham
- system type
- system model/serial number
- bios mfr/rev
Any of the other stuff (memory installed, slot types, etc.) is
either mostly irrelevant, or can be gotten by other means.

Right, that makes sense. We'll have to decide which tool is the
"authoritative" source of information for each field.

-M

[Michael K. Johnson]

Post by Dave Jones
Beware that a lot of BIOS vendors put utter garbage in their DMI tables.

Well, then their carelessness will show up in a public database. :-)

michaelkjohnson

"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/