[sf-lug] i586 ThinkPad CD-ROM problems
rick at linuxmafia.com
Tue Nov 13 14:28:12 PST 2007
Quoting Kristian Erik Hermansen (kristian.hermansen at gmail.com):
> /me hands RIck Moen a time machine... djb commits suicide
Heh. Although I won't go so far as to say that Dan's a nice guy (nor do
his most ardent fans), I _do_ admire him, both for his generous if
often-proprietary software (even though I prefer not to administer that
software) and -- especially -- for his hard-fought and successful battle
against the US government for crypto rights.
Anyway, continuing what I was saying before it got way too late and
myself far too tired, "lshw" is a nice hack, but actually offers no
information not already furnished by other tools, notably DMIdecode.
(Until this morning, I actually had no idea what DMI in this context
stood for. It's Desktop Management Interface, a standard (and queryable)
abstracted communications layer (lately deprecated in favour of a draft
replacement, DASH) for hardware/BIOS information. It's clear that at
least most of lshw's output comes from parsing DMI queries: That
functionality has actually has been present in various implementations
of DMIdecode for about eight years: I remember one I hacked on, a bit
Here's info on the DMI spec:
Here's the current commodity-type dmidecode utility, coded in C by Alan
My point about lshw is that it's a glorified dmidecode equivalent, and
thus knows only what's in the DMI registry. That will tend to include
_some_ string information partially or fully identifying the
manufacturer and model of the _motherboard_. In some cases,
particularly laptops from manufacturers using custom motherboard
designs, the identity of the _motherboard_ make/model will be closely
tied to, or identical to, that of the _machine make/model.
So, for example, Jason Turner got:
...because IBM manufactures its own motherboard. Note that it's the
make/model of the _motherboard_, not that of the surrounding machine.
Because this happened to be a laptop from a firm that used custom
motherboards, one does have what's tantamount to a machine make/model,
but only because machine and motherboard are closely allied, in this
Looking up "2645-4EU", Jason's product number (comprising machine type
and model), one _can_ find out that this is an IBM ThinkPad 600X -- but
only because the motherboard is unique to that machine model.
But note that, even at that, it didn't return "IBM ThinkPad 600X". You
have to match the data up, via Web search and use of your head.
Your example was:
product: HP Compaq 8510w
Again, this is techically the make/model of the _motherboard_ used in
your laptop, not the make/model. Again, as a maker of custom
motherboards for laptops, HP/Compaq has that motherboard uniquely
identified with a machine make/model.
My own server had:
product: NS440BX DP
This indicates (correctly) that the unit has an Intel NS400BX
"Nightshade" motherboard -- but is completely useless in determining the
_make/model of machine_, because Intel Nightshade motherboards were used
in scores of server machines in the late '90s.
Anyway, I do not routinely use "lshw" for hardware work, because (1) its
output is redundant to that of dmidecode, which I already had and is a
standard tool, and (2) (as with dmidecode) its output is quite verbose
and can be actively misleading.
 Having been obliged by being chief sysadmin at $FIRM to admin qmail,
and not enjoying the experience, I kept being asked _why_, from 1999 on.
Getting tired of this, I FAQed my answer, which lead, in due course, to
Dan writing me and making (absurd) legal threats. Having survived a
six-year Federal lawsuit as a teenager, and understanding what such
things are like, I take a dim view of some fsckwit computerists' quick
resort to phony litigation threats, so I politely referred Dan to my
attorney and beefed up my FAQ with examples of alternatives to all major
DJBware. Dan, for his part, reacted to the encounter by deciding to
call me names on one of his Web pages.
More information about the sf-lug