eric@snark.UUCP (Eric S. Raymond) (08/26/88)
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@snark.UUCP
Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718gwyn@smoke.ARPA (Doug Gwyn ) (08/27/88)
In article <dpeXV#37c3rr=eric@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >The upshot of all this is that uname is effectively useless. As I said when you first raised the issue. I've seen some very comprehensive attempts at auto-configuration, but they invariably fail when run in a strange environment that the author had been unaware of. For example, the BRL UNIX System V emulation for 4BSD, or some variation thereof, is fairly widely used, and there are two distinct operating environments on such systems (also on Pyramids, Apollos, Suns, and others). Plus, many of us use alternative mail systems, spooling systems, networking systems, and so forth. How is any automatic procedure supposed to figure out how to set up a specific consistent environment under such circumstances, particularly when one environment is only partial and relies on the other to fill in the gaps? I think the best practical solution to configuration is to get the system administrator (software importer) to edit a text file that describes the specific environmental characteristics. Then verify as far as possible that the configuration does indeed work..
chip@vector.UUCP (Chip Rosenthal) (09/01/88)
In article <dpeXV#37c3rr=eric@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >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)). A nit: under XENIX (SCO's version anyway), uname -n does indeed use uname(2) (errrr, I mean uname(S)..blah). It's uuname -l which reads /etc/systemid. I'm not sure how many people recompile their kernal to get a name in the uname structure. (And USENET is not a good representative sample to determine this. Chances are that if you are on USENET then you have done this. If you have SysV.) It might not be a good idea to depend upon even "uname -n" for a turnkey installation package. As long as we are discussing philosophies, I really prefer Larry Wall's "dist" approach, where you base your configuration upon the specific capabilities rather than the OS flavor. -- Chip Rosenthal chip@vector.UUCP | I've been a wizard since my childhood. Dallas Semiconductor 214-450-0486 | And I've earned some respect for my art.
tanner@ki4pv.uucp (Dr. T. Andrews) (09/03/88)
In article <531@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: > A nit: under XENIX (SCO's version anyway), uname -n does indeed use > uname(2) (errrr, I mean uname(S)..blah). Most of the time, the this yields a bunch of NUL (zero) bytes for the system name, making it possible for a clever program to know to try for /etc/systemid (kernel not patched or re-built). However, the latest "improvement" that I have seen puts three '+' chars in there. Now, how is THAT for a useful system name? Time to hack the prog to understand both NUL and '+' I guess. -- ...!bikini.cis.ufl.edu!ki4pv!tanner ...!bpa!cdin-1!cdis-1!ki4pv!tanner or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!tanner
chip@ateng.uucp (Chip Salzenberg) (09/08/88)
According to tanner@ki4pv.uucp (Dr. T. Andrews): >In article <531@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: >> A nit: under XENIX (SCO's version anyway), uname -n does indeed use >> uname(2) (errrr, I mean uname(S)..blah). > >Most of the time, the this yields a bunch of NUL (zero) bytes for the >system name, making it possible for a clever program to know to try >for /etc/systemid (kernel not patched or re-built). This is not the best solution. If the Xenix kernel has a nodename, but the sysadmin uses /etc/uuinstall or otherwise changes /etc/systemid, then uucp will use the latter, ignoring uname(S). All uucp-aware Xenix programs should imitate this behavior. Or just use "uuname -l", of course. :-) -- Chip Salzenberg <chip@ateng.uu.net> or <uunet!ateng!chip> A T Engineering My employer may or may not agree with me. The urgent leaves no time for the important.