Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: Help us defend against VMS! -- DEC perspective
Message-ID: <7439@brl-smoke.ARPA>
Date: 11 Mar 88 22:37:41 GMT
References: <8803101924.AA03437@decwrl.dec.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 50

In article <8803101924.AA03437@decwrl.dec.com> devine@cookie.dec.com (Bob Devine) writes:
>Should it be an open standard or should it be controlled by AT&T?

"False dichotomy."

It could be both, or this may not even be the most important issue.

>  As we get closer to final approval of the Posix standard, AT&T
>seems to be regretting letting the Genie out of the profitable bottle.
>Each new version of System V has become more onerous, why?

I don't know what you mean by this.  SVR3.0 incorporated tremendous
improvements that should be of great value to future UNIX users.
In particular, STREAMS is an extremely important technology.  The
file system switch is also important, but more to implementors than
directly to end users.  SVR3.0 is the first AT&T UNIX system release
that I would rate as technically the equal of, or superior to, 4.nBSD
on all major counts.

SVR3.1 appears to have continued the tradition of removing unnecessary
constraints that got in the way of international use of UNIX.  SVR4.0,
from what I have heard, will continue the tradition of merging in
those features of 4.nBSD that people find most useful.  What is
onerous about all this?

If you refer to the requirement that VARs advertising their systems
as UNIX System V conform to the SVID, why is that a problem?  It's
exactly what many customers want, and what has been specified in many
government procurement actions.  While on this topic, the NBS-proposed
POSIX-based FIPS is by no means a suitable replacement for the SVID;
it does not provide nearly as comprehensive and "crisp" a specification
as the SVID does; therefore it does not meet end-user needs nearly so
well.  When asked, my recommendation is always to supplement POSIX
in the specs with ANSI C and SVID requirements, in such a way that
conflicts among the requirements have a well-determined resolution.

>The AT&T reps to Posix have now voted against final approval, again why?

Presumably, like more than a quarter of the balloting group (how many
more I don't know), they found unacceptable technical errors in Draft 12
of IEEE Std 1003.1.  There is going to be another recirculation round
of a new draft of the proposed standard; perhaps the problems will be
fixed so that AT&T representatives, the USENIX representative (who is
a well-known supporter of the 4.nBSD UNIX variants), I, and others could
change our negative ballots to favor adopting the new draft as the
final-use standard.

Please, if you're going to push the DEC "party line", don't misrepresent
the actual situation (such as implying that AT&T representatives are
trying to torpedo POSIX); when exposed, it unduly weakens your case.