On 11/10/2017 01:17 PM, Nathaniel McCallum wrote:
The more I look at lshw, the more I'm ambivalent (I'm not
just not for it either). It certainly collects a lot of relevant
information. However, I see the following problems.
1. lshw tries to make things human readable. This is bad for
databases. We want to record things like immutable numeric hardware
IDs rather than the current contents of pci.ids. lshw does provide
-numeric, but this just adds the numbers to the human readable
That seems like it would be a good improvement for upstream.
2. lshw collects a lot of data we may not be interested in. For
example, it reports the four different kinds of floppy disk drives my
BIOS supports. Also, L1, L2 and L3 cache. There is a bunch of stuff
like this. Is it useful? Some of it definitely is. But transferring
unwanted data over the wire is not being a good netizen. Also, some
people pay for data per MB transferred. We should be respectful.
3. lshw supports '-sanitize', but this merely replaces the values with
'[REMOVED]'. See above for why we don't want to transmit this data.
4. lshw reports bus configuration. I'm not sure if this is relevant or
how we would want to map this data. For example, if Dell uses the same
hardware in a bunch of laptops then we can deduplicate this to one
"hardware profile." But if bus configuration is part of this profile,
then we will have much higher cardinality. If this information is
important to have, we can make it work. But if not, it would be better
to try to save storage.
These three issues seem easily solvable by some client-side filtering
before sending it to the server.
5. lshw doesn't seem to have a way to separate "system
"transient hardware." To be fair, this may be impossible. But it would
be nice to understand the difference between, say, my bluetooth radio
and my YubiKey. I can't easily remove the former but I can the latter.
This also goes to cardinality reduction.
That does sound nice and I don't know whether or not it is possible, but
it doesn't sound unique to lshw and if there's a solution I imagine lshw
would like to have it.
6. lshw mixes things that are transient with things that are
permanent. We can remove the timestamps with -notime. But, for
example, it reports the kernel module currently assigned to a piece of
hardware. This is probably relevant information, but we will have to
carefully separate the data based on its lifespan.
I think we'll want the module information. I do agree we need to
think carefully about how to model the data.
Generally, I agree that lshw isn't perfect, but it seems like there's a
lot of value in it and we can help improve it where it makes sense.
Where it doesn't make sense, we can easily manipulate and supplement the
data client-side. Of course, my opinion may change dramatically once we
actually implement this :)