[hfdb] Re: Grand Unified Hardware Database

[Richard Stallman]

      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.  

That seems unnecessarily complex.  Here's what I have in mind:

    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.  He edits this into
    the XML files and checks them into the public CVS repository.

That is much simpler.

    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.

This problem, if and when it matters to us, is not trivial.  Why would
an RDBMS would make any difference to it?  Look at concrete case.
Suppose there are two modem cards sold as FOO model 69 that need
different driver support.  What could we do?

My idea would be to invent two separate models, FOO model 69 type A
and FOO model 69 type A, and list each one.  Then we could add a
listing for FOO model 69 which explains in hand written text how to
tell whether you got type A or type B.  Or maybe explaining how to
make sure you get type B if you order one now.

I don't see that an RDBMS has anything to do with this.

                        Is it not valuable to track the bus type, standards,
    and at least some of the capabilities of the hardware? 

The question is not whether this is valuable but whether we can get
away without it, at least at first.  This project is limited by human
resources.  If we want it to fly, we have to lighten the load.  We
have to look for what we can throw out, not what we can add.

Perhaps a limited amount of information of this type will be a small
enough amount of work that we can afford to include it from the
outset.  If so, I have nothing against it.  More info that the user
might find useful is a good thing, as long as it doesn't mean so much
work that the project never gets off the ground.
                                                    
                                                            Don't we want to
    segregate printers from video cards from modems?  

Yes, but that's very easy.

    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.

The main purpose of this data base is so that people can determine
whether hardware model N made by company Y is ok to buy.  For that,
what we need is exactly the info that you've said is of no value.  Our
first goal is to include this much information.

We would also like to include whatever other useful information we can
afford to include.  ("Afford" means we actually have people to put the
information in.)

By using an extensible file format such as XML, we don't need to
design the data in advance.  We only need the design to keep ahead of
our increasing resources for actually entering such data.  Thus, for
instance, when someone wants to take the time to add the answer to
question Q for all or most of the modems in the data base, we need to
know how to represent the answer for question Q.  We do not need to
know this at the outset.

If you would like to design representations for useful kinds of data
for various devices, that is a useful thing to do as long as your plan
recognizes that in the first year we will only use a small fraction
of the design.

    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.

Here's what minimal data would look like.

   PCMCIA Modems:

     FOOBAR 33  max speed 28k
       GNU/Linux driver mumble   BSD driver frobozz
       * Note: to make this work on GNU/Linux,
         see http://helpme.gnu.org/discuss/foobar33.

     FOOBAR 65  max speed 56k
       GNU/Linux driver mumble   BSD driver frobozz

     FOOBAR 69  max speed 56k
       * Note: Two different kinds of modems are sold as "FOOBAR model 69".
         The FOOBAR 69A has a green LED, while the FOOBAR 69B has a red LED.
         You need 69A, since that's the one that works.

     FOOBAR 69A  max speed 56k
       GNU/Linux driver mumble   BSD driver frobozz

     FOOBAR 69B  max speed 56k
       Not supported

     QUUX 68    max speed 56k
       GNU/Linux driver mumble   BSD driver frobozz

The notes are just hand-written text.

We could imagine many ways to add more information that would
be useful, but let's take that one step at a time.