Date: Sat, 01 Jun 1996 14:09:17 -0700 From: Darryl Okahata <darrylo@hpnmhjw.sr.hp.com> To: "Francisco Reyes" <reyes01@ibm.net> Cc: "Andrew V. Stesin" <stesin@elvisti.kiev.ua>, "John Fieber" <jfieber@indiana.edu>, "FreeBSD doc Mailing list" <doc@freebsd.org> Subject: Re: Hardware compatibility list. Second round. Message-ID: <199606012109.AA172603357@hpnmhjw.sr.hp.com> In-Reply-To: Your message of "Sat, 01 Jun 1996 12:27:44 EDT." <199606011641.QAA56153@pop01.ny.us.ibm.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> For each piece of hardware we could have a checkbox button indicating if it w
> orked or
> not or we could have another form for incompatible hardware. One possible goo
> d thing
Wouldn't it make more sense to assume that any listed hardware
works (which would be the usual case, otherwise people would probably
not be using them with FreeBSD ;-), and, if there are problems, list
them in some comments? With the above checkbox approach, I believe most
entries will have the box checked, making the checkboxes less useful.
> As for comments I am getting the feeling that the best is to either leave an
> entry field
> for a general comment that applies to all pieces or have a few lines for eac
> h part.
> Any comments on this? In the comments for the "compatible" hardware people co
> uld
> write work arounds they did to get the hardware working.
Why not have both? I can see cases where comments apply to a
particular component, and cases where comments apply to the entire
system.
> -> This is a good idea, but I think that it would also be useful to
> ->include information on hardware that could CURRENTLY cause problems,
> -> e.g.: * Mach64 vs serial ports.
> -> However ......
> -> 1. ...older than six months or more could be
> -> suspect
> -> 2. The OS revision(s) (2.1R, 2.2-960321-SNAP, etc.) to which it is known
> -> to apply. Many bugs that are in 2.1R will probably be fixed in 2.2. ;-
> )
>
> This is something we need to look into. It may be a little difficult to follo
> w up
> with imcompatible hardware. A possible approach is to keep incompatibilities
> in the list until someone says otherwise. A date stamp approach or looking at
> the entry after a new release of FreeBSD may be difficult to track since afte
> r
> we know we need to look into an entry what should we do about it? Delete it?
> Post a message requesting comments on whether it still doesn't work?
No, that's the reason for datestamps and OS revs. If an entry is,
say, more than a year old or more than two revs old, it's very suspect.
When a new FreeBSD release comes out, nothing HAS to be done with
the hardware list, although something probably SHOULD be done with it.
Let's take the most probable case: the hardware list is not updated ;-).
With date and OS revision stamps, anyone reading the hardware list, and
seeing that they have "problem hardware", can at least make at
intelligent guess at one of:
1. Their hardware has problems. They're using the same FreeBSD revision
mentioned in the problem hardware list.
2. Their hardware might have problems. They're using a newer release of
FreeBSD. In this case, they can ask in FreeBSD-questions to see if
(1) their hardware is still broken, or (2) the hardware list entry is
out-of-date. If it's out of date, we can use this as a trigger to
change the entry (someone could re-write the entry and mention that
it's fixed in FreeBSD 99.07, and send it off to the docs folks ;-).
I think we really need a section on hardware problems; a section on
known working hardware, while useful, is no where near as useful as a
"problem hardware" section.
I'd say that most people reading the hardware list will be doing so
to see if their *existing* hardware will work, with the people building
a new PC being next. It's not very useful as an "accomplishments list"
("See? BinkyCo's new 1000 Gigaflurb system runs FreeBSD and supports a
million users!"); such a list, while useful, is best put elsewhere.
Assuming most people reading the hardware list will be doing so to
see if their *existing* hardware will work, it's unlikely that they'll
find their particular combination of hardware listed in the list. There
are just too many commodity part makers out there. Because of this,
having a list of known problem parts or known problem part combinations
would be more useful.
-- Darryl Okahata
Internet: darrylo@sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606012109.AA172603357>