I just read back through this ticket, but I didn't understand exactly
what MAL wanted to have different from what this Python function
currently does:

http://allmydata.org/trac/tahoe/browser/src/allmydata/__init__.py?rev=20081125155118-92b7f-f74fc964ebd9d3c59afde68b6688c56ce20cca39#L31

MAL, could you please restate the changes you want?

By the way I think there is some confusion about what is standardized by
LSB.  As far as I know this one page is the complete spec:
http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html
and it doesn't specify the existence of any file that we can parse.  So
the quote you mention: "Linux System Base-compliant systems should have
a file called /etc/lsb_release, which may be in addition to a
distribution-specific file." is just wrong.  More's the pity -- most
implementations use a file named /etc/lsb-release, and we can parse
that, and if we do it is much faster than executing the lsb_release
executable in a subprocess.  The slowness of invoking subprocess is why
I was forced to back off from my original patch of merely using only
what the LSB offers.

A second problem with relying on LSB is, as I've mentioned, that some
Linux distributions don't come (by default) with the de-facto-standard
"lsb_release" executable although they do come with an /etc/lsb-release
file.

That's why my current strategy is:

1.  Parse the de-facto-nearly-standard /etc/lsb-release file.

2.  Ad-hoc techniques encoded into the Python Standard Library's
platform.dist().

3.  Execute the de-jure-standard "lsb_release" in a subprocess.

4.  Arch Linux