home *** CD-ROM | disk | FTP | other *** search
- From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>
-
- In article <617@longway.TIC.COM> std-unix@uunet.uu.net writes:
- >From: kjm@hermes.chpc.utexas.edu (Kenneth J. Montgomery)
- >Question: do you believe that 1003.1 fits into this [i.e. poorly-
- >engineered] category?
-
- Only partly, and in my opinion that was mostly due to the rush with
- which it was prepared, partly due to NIST publishing a POSIX FIPS
- prematurely. Note that 1003.1 is now having to clean up some of the
- rough spots. I found during the 1003.1 balloting that it was almost
- impossible to figure out what we were voting on, as it was changing
- underfoot; there was no final vote on the resulting modified document,
- just 1003.1 technical reviewers' opinions that they had resolved all
- balloting objections. However, some of their changes would have
- led to new balloting objections if I had known about them in time to
- object. I don't think the intense time pressure really served the
- potential POSIX community very well.
-
- Fortunately, almost everyone involved with drafting IEEE 1003.1-1988
- knew pretty much what any "UNIX-based" system had to provide, and in
- what form; consequently there was only a moderate amount of invention
- (notably in providing system configuration parameters and terminal mode
- functions), with most of the standard being firmly based on existing
- practice. Occasionally we had to fight hard to make sure it wasn't
- limited to JUST what already existed; for example, for a while pipe
- semantics were specified such that cross-coupled full-duplex streams
- could not be used to implement them, which would have been a major
- lossage. We also were able to insist on genuine UNIX file system
- semantics for the most part, despite pressure from NFS vendors to
- bless NFS's inferior behavior.
-
- So, I think 1003.1 is somewhat useful; at least it got UCB to come up
- an improved terminal handler!
-
- Volume-Number: Volume 19, Number 48
-
-