Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!hpfcdc!donn
From: donn@hpfcdc.HP.COM (Donn Terry)
Newsgroups: comp.unix.wizards
Subject: Re: POSIX bashing (Was Re: Retaining file permissions)
Message-ID: <5980071@hpfcdc.HP.COM>
Date: 12 Mar 91 16:44:33 GMT
References: <3419@unisoft.UUCP>
Organization: HP Fort Collins, Co.
Lines: 79

>Doesn't the idea of extensions and optional features diminish the
>usefullness of certain minimal levels of functionality?  Wouldn't it have
>been better if these had been place in the dot-1 core?

1) There are lots of features that might have been put in POSIX; we simply
   havn't gotten there yet.

   Yes, not having certain capabilities limits the range of applications
   that might be written as "conforming applications".

2) Options are a tool for compromise: 
   - sometimes options are used to get agreement on the standard at all.
     (Job control:  if it wasn't optional it probably wouldn't have been
     there at all.  However, it's now become commonplace in
     implementations that used to resist it.)
   - sometimes options are used because not all users want it.  Should
     high levels of security interfaces be required of all implementations?
     How about checkpoint/restart?  Realtime?  These can be expensive
     (and sometimes irritating "features") that not all users want.  Thus
     programs that need these features can use them, but limit their
     operation to those systems that provide them.  (In a standard fashion.)

3) What is minimally required is very much subject to debate.  POSIX.1 is
   pretty minimal, yet job control, Berkeley-style signals, and several
   other "minimal" functions met with very strong opposition.  The flames
   around waitpid(), although vital to fix blatant bugs in popen()/pclose()
   and system(), were spectacular.

   One persons's minimal is another's creeping featurisim.

Again, you can't please all of the people all of the time, and in the case
of POSIX there's also simply the amount of time it takes to get the work
done.

One other observation on this discussion, associated with another response:
the POSIX signals are not quite like any existing implementation; there
are other features that have that same characteristic.  There's a real
reason for that, but one which is not obvious:

As is often observed, UN*X isn't really very well documented; the code
is the true documentation.  This is true of all implementations I know of.
However, when you try to write it down in a form that can be implemented
correctly from the documentation (a requirement for a valid standard),
you find that you can't:

  - Because you don't really know what it does.  (Experiments and codereading
    were a big part of the POSIX work.)
  - Because you simply can't warp the English (or French) language far enough
    to explain what's really going on.
  - Because it's inconsistent between historical implementations that tried
    to guess what was intended, and guessed differently (not necessarily
    wrongly, just differently).  (And you don't want to break existing
    implementations (which usually means breaking existing applications),
    which would be a real disservice to the intended users.)
  - Because when you write down what it really does, you realize that it
    "just happened" and the behavior is nonsensical (either due to
    flawed initial implementation or historical evolution).  (Much
    historical code is that way; every time I've tried to *thoroughly*
    document something that wasn't coded to a formal design or which had
    been frequently hacked, I've found things that "just happened" that
    don't make sense once written down.)  (This is the distinction
    between "works most of the time" and "works right, period".)

Signals historically had all these problems.  (E.g.  the fact that the
same signal arriving "too rapidly" could cause an unexpected abort; try
requiring that in a standard!)  Berkeley signals didn't have as many of
the problems, but couldn't be reconciled to coexist with System V
signals (without breaking applications).  Additionally, the interface
wasn't extendable beyond 32 signals (bits) (or whatever a long was).
The new interface is extendable and can be reconciled with both "old"
signal systems in a reasonable way to avoid breaking applications.

We didn't make the changes to signals (or anything else) "just because
we felt like it".  There was a lot of debate (some of it rather "noisy")
on the topic to try and hammer out something that was livable for the
long term, and which did not break (very many) existing applications.  

Donn Terry
Speaking only for myself, again.