`uname' survey results -- bad news, it's #@!!%@# useless

[Eric S. Raymond]

Some of you may recall that, a while back, I posted a request for uname
output from many different machines. My hope was that it could be used for
machines running System III or System V to extract things like the release
level and processor type in some quasi-uniform way.

Several hundred responses later, this hope has been rudely shattered.

I am irresistably reminded of something one of Robert Heinlein's characters,
a writer giving advice on how to sell manuscripts, once said. Roughly, it was:
"You have to give editors something to piss on. Then they like the flavor
better, so they buy it".

The useless garbage reported by many of the sites that responded to the survey
leads me to conclude that a great many UNIX vendors feel a sort of compulsion
to urinate on the distribution somewhere, and that uname(2) is a favorite
target. Perhaps this a form of corporate territorial marking.

Common forms of brain-damage include:

1. Reporting the site name from the sysname (-s) field. This field is
   supposed to contain a generic OS name (UNIX, UTS, HP-UX). Even some AT&T
   machines (including my 3B1) make this mistake.

2. Non-support of the -m option (Masscomp RTU) or returning something that
   ain't nohow a processor type (SCO XENIX, many versions of which return '3'
   for some utterly inexplicable reason).

3. Total confusion in the version and release fields (-r and -v options).
   The 'release' field should contain the AT&T release level (1.x, 2.x, 3.x)
   and the version field is reserved for vendor-specific release info.
   Naturally, many vendors invert the two. Others report bizarre internal
   release-number formats (or even release dates) in the -r field.

In at least one class of systems (older 68K and 80286 XENIXes) the porting
people blithely decided to 'improve' uname's output to something that looks
like a list of shell assignments. This complicates life wonderfully for
portable autoconfiguration scripts.
   
The nodename field (-n) is about the only thing almost everyone seems to get
right, though some sites do report it empty. And uuname -l is more reliable
for that purpose (XENIXes and perhaps some other systems extract uname -n's
output from /etc/systemid rather than a kernel ID area via uname(2)).

The upshot of all this is that uname is effectively useless. It would be
nice if the vendors were to fix their messes but it's too late in the game
for that to make a lot of practical difference. My autoconfiguration tools
certainly won't be able to use uname.

-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      UUCP: ...!{uunet,att,rutgers}!snark!eric = eric at snark.UUCP
      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718