This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig76C210C440B1A32FD4B59793
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Magnus Eriksson wrote:
> Hi.  Long time no see.

:-)

>>   Let's say that you're about to buy new hardware for a new computer.
>> Let's hypothetically say that there's a large system compatibility
>> database somewhere. Would you prefer that:
>=20
>   I think you're going to have to end up with something inbetween 1 and=

> 3, with the specific circumstances deciding exactly where.  (I agree
> with Martijn on why 2 is unlikely to work.)

   Yeah; I gave it some more thought, and I decided to go with the
following solution:

   There's a "hardware table", which has a "category" column. In the
category, there's both "Graphics board" and "Graphics chip" entries. In
addition, there's an "item container" table which can be used to
associate hardware with other pieces of hardware. This way, you can
create a "Graphics chip" entry which can be associated to several boards
 (be it graphics or mother boards).

   Observational readers will notice how I'm completely ignoring the
KISS rule. :-)

   The problem will obviously be that filling in all the details will
take more time than what I was hoping (and more complicated database
queries (but users won't notice that). But OTOH, I thought about it a
little; it's not like it's a one man job, and it's something you do only
once for every piece of hardware you get. Also, if you don't feel like
filling out all the extra details, someone else can do it later.

>   If the database is to be useful for, well, users, I think boards need=

> to be listed -- if you're going shopping for hardware and don't already=

> know everything about what you're going to buy, you want some names to
> keep an eye open for.  For certain things (graphic cards?), chipset wil=
l
> be enough, for other things not.

   Exactly -- but some stores aren't very good at getting the specs
right. (For instance, go to www.jmedata.se and check the Sempron
processor specs; they aren't correct, AFAICT. (I know CPU's aren't the
best of examples..)). For that reason I think it's more convenient to at
least try to have full board names as often as possible.

>   It would also be useful, imho, to at least have some free-text "extra=

> info" field for when you know the implementation is weird, or you need =
a
> specific firmware version, etc.

   Already thought of that. I have two ratings which can be associated
to a system (be it operating system, or X system (think: XFree86,
x.org), etc) and a hardware item:
1) Support: Fully supported, limited support, supported with additional
software, unsupported
2) Reliability: Stable, unstable

>> Discussions, tips, ideas are welcome.
>>
>> (No, it's not NetBSD specific).
>=20
> I have some ideas, but they'll have to wait until I can hold a cohorent=

> thought for more than ten seconds.  :-)

:-) Mail me any ideas you have.

--=20
Kind Regards,
Jan Danielsson
Te audire non possum. Musa sapientum fixa est in aure.


--------------enig76C210C440B1A32FD4B59793
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)

iD8DBQFEQqkc8wBCTJQ8HEIRAlD+AKDT/1sWqE3Fl9l2QN8DLTqHCKQ3mQCfVzi/
MuLejhm5+OgNlX9KrQQuX/E=
=hgu4
-----END PGP SIGNATURE-----

--------------enig76C210C440B1A32FD4B59793--