Standards compliance vs. real UNIX

[Jeff d'Arcy]

scottl at convergent.com (Scott Lurndal):
>Since there is no standards requirement for /dev/kmem (and our implementation
>of SVR4.0 for the 88100 does not even have one), how portable is any library
>that attempts to extract data from an operating system?   To be called unix, 
>you must provide certain functionality (defined by the SVID and perhaps
>XPG3).  You do not have to internally look anything like unix as provided 
>by AT&T (System V) or Berkeley (BSD 4.x); certainly you don't have to use
>the same symbol names!

Yeah, I've seen a few other vendors who are "minimally compliant" but not truly
conformant to U*X norms, and you know what?  They're annoying as hell!  Renamed
utilities, lack of a /dev/kmem interface, and missing or broken library/syscall
options (such as ioctls) are just some of the symptoms.  Companies who create
these almost-UNIX OSes conform to the standards only because they're afraid of
customers who demand standards compliance, but if you look deeper you see that
they're really not *committed* to open systems and interoperability, that they
retain the now-discredited proprietary mentality which used to be such a pain.

In the particular case of /dev/kmem it's certainly not necessary to use the
same symbol names, but it sure would be nice to have the *interface* (or at
least *some* interface) available so that kernel hackers can at least get to
the information they want from user-land.  You never know *which* variable we
might want to look at next, so it would be polite to leave something with a
namelist lying around too, although I know of only one vendor which fails in
that particular regard.

BTW, please respond to jdarcy at encore.com rather than the address in the .sig
(which I'm too lazy to change just now) or the header.  This is my last day
here.
-- 

Jeff d'Arcy, Generic MTS, Sequoia Systems Inc. <jdarcy%seqp4 at m2c.org>
         Time flies like an arrow; fruit flies like a banana