[hfdb] Re: Grand Unified Hardware Database

[James K. Lowden]

On Sun, 18 Jul 2004, Richard Stallman <address@hidden> wrote:
> 
> If you want to
> put the information in a DBMS, that's fine.  My concern is how to
> store and edit the data

Thanks for your reply, Richard.  We share that concern; it is why I joined
the project.  

You seem to be implying that "how to store and edit the data" is somehow
different from "put[ting] the information in a DBMS".   I don't see it
that way.  Here's the data flow we're working with AIUI:

1.  Data arrive.  Someone sends mail, fills out a form, contributes an
existing data store, whatever.  Now it's "here".  

2.  Zen & Co. massage data into a form consistent with what we already
have, and consistent with a data model we devise.  (The devising is my
primary contribution.)  

3.  Massaged data are loaded in the RDBMS.  

4.  Reports are issued in response to queries.  These may be static web
pages regenerated periodically, compatibility lists included with a given
distribution (of an OS, driver, application, or hardware), or on-line
web-based queries.  And others, of course.  

Steps #1 and #4 are data interchanges and thus benefit from the
self-describing verbose characteristics of XML.  The intermediate steps
are data consolidation work best performed with a normalized data model
and a modern RDBMS.  

>     We are embarking on a project that is afaict an order of magnitude
>     more complex than any "similar" project.
> 
> No, it is much simpler.  We want to tell people which hardware devices
> are supported by free software, and (if it is feasible) which drivers
> are available and where.  

You evidently think that problem is simpler than I do.  We seem to differ
in how we define "hardware devices" and "free software".  I assert neither
one is easily described.  It seems, however, I can't state my case
briefly....

For hardware, is it not necessary to describe the thing precisely?  It's
well known that vendors often sell radically different things with the
same model number.  Is it not valuable to track the bus type, standards,
and at least some of the capabilities of the hardware?  Don't we want to
segregate printers from video cards from modems?  

The software situation is even more complex.  What is your level of
granularity?  Is it enough to say "ATI cards X, Y, and Z are supported by
Debian Woody"?  I don't think so.  

Reducing the issue simply to drivers for a moment, what's a driver?  We
need a project, a release/revision, which OS(es) can use it.  And which
OS(es) do use it, and their versions/releases.  Then there's the question
of what the driver does i.e., what features of the hardware does the
driver support?  It's not enough to say this video card is supported by
the XFree86 SVGA driver if what you're interested in is Mesa support, or
running a game, or just want to see Gnome in 1600 x 1200 x 32BPP.  

If the database is just going to say "hardware made by Company Y is
supported in some form or fashion by Driver X" then I don't think it will
have any value at all.  That's just an invitation to start perusing
mailing list archives.  To be useful, it must be specific.  If it is
useful, vendors will help us keep it correct.  At least, they will help us
*add* information, which isn't nothing.  

I'm guessing our little RDBMS/XML debate is really just a proxy for a more
basic one: What is the scope of the project?  What, exactly, are we trying
to track, and for whom?  I have my ideas, some of which are outlined
above, and quite a few others have been tossed around just prior to our ML
coming online.  

Maybe a concrete example would help.  I suggest this:  Show me a mock
tabular report you'd like to see, something you imagine would benefit
someone we're trying to help, and tell me who that person is.  Just a half
dozen lines should do.  Or point me to something online and tell me what's
missing or overmuch in it.  Maybe if we can converge on what we're doing,
we'll agree on how.  

Regards, 

--jkl

P.S.  If you're subscribed to address@hidden, I'll stop cc'ing you.