🚀 go-pugleaf

From: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Date:     Tue, 20 Jan 87 4:59:34 EST
Organization: Ballistic Research Lab (BRL), APG, MD.

In article <6881@ut-sally.UUCP> std-unix@ut-sally.UUCP:
>(2)  Applications should be able to use a standard interface to send
>mail.
>(3)  The same is true of a spooler.  You can provide a fancy spooler,
>but please let dumb programs invoke it by the same old name as long as
>they only depend on the dumb options, e.g. "lpr" and "lpr -p".

I am in full agreement that a SUBSET of "mail" and "lp" (or "lpr")
interfaces should be standardized, just not the whole package (for
instance, definitely NOT the interactive mail-reading interface).
My command-set proposal to 1003.2 contained several such cases of
limited subsets of what was in the SVID.  I view 1003.2 primarily
as a collections of tools for use by application programs, not as
things a naive user would confront directly.

>We have failed if we create yet another
>variant that's not a subset of most of the existing ones.

There is little value in restricting the 1003 standards to lowest-
common denominator subsets of existing UNIX implementations, since
many interesting and useful applications simply cannot be written
to work well within such a limited subset.  Consequently, the 1003.1
trial-use standard already differs in several (relatively minor, we
hope) ways from existing UNIX systems.  POSIX conformance will require
a certain amount of change to existing systems.  We've been working
fairly closely with AT&T SVID people on this issue, in an attempt to
ensure that a system can be simultaneously SVID and POSIX compliant
without requiring separate "universes" (libraries, etc.).

As one of the original separate-universe implementors, I wish to
state that any such implementation should be viewed as an interim
measure while we attempt to converge on a single universal standard.
(I believe this is what Sun is attempting to do.)  It will sure be
nice to be able to quit worrying about annoying trivial system
variations and get to work on better applications.

Volume-Number: Volume 9, Number 27