POSIX bashing (Was Re: Retaining file permissions)

[Donn Terry]

>I think that POSIX is an attempt at an implementation of a bare-bones OS.
>There are too many things there which are simply done wrong.  I agree with
>Jon on this one.

Without taking too much umbrage, there are some flaws in this argument that
show a lack of knowledge of what POSIX is:

1) POSIX is not, and never, ever ever, will be an implementation.  It is an
   interface specification, and ONLY an interface specification.
   "Bare-bones" is true today, but not as a goal but just due to its
   relative youth.  (In fact, it is so bare bones that an implementation
   that was solely what is in the POSIX of today would be useless; it must
   be extended to be a useful system: It doesn't *yet* even contain any
   commands.  That's OK because of its goals: see (2) below.)

2) POSIX is intended to be an interface specification for *portable*
   applications across a broad range of systems.  That is not the same
   as *all* applications, or even the same as *all useful* applications.
   Applications written to POSIX can be portable across a VERY large
   range of systems (more than just UN*X, although that's clearly "home").
   It isn't intended as a standard for (just) "UN*X".

   Specifically, the missing "number of blocks" field represents a
   common, but NOT universal concept.  Since the number of *portable*
   applications that reasonably would use such a field is small, it was
   not included, in the interest of not excluding implementations

   - That doesn't mean that it can't be provided by an implementation.
   - That doesn't mean that it can't be mandated by a profile (that is
     a spec like the X/Open Portability Guide, the SVID, or the OSF AES.)
   - That doesn't mean that the application is not portable among a
     smaller range of systems that provide such a field.  (In this case,
     the applications that would portably use the field are probably
     tied exactly to the systems that have the concept at all, and thus
     (probably) provide the field.

3) POSIX isn't yet complete, or even close.  

   - There are a lot of complaints about POSIX being "incomplete" in 
     that it doesn't specify functionality in a certain area.  
   - There are also a lot of complaints about the books being too thick.
     (How else would you get completeness and precision.)
   - There are also a lot of complaints about the process going too 
     rapidly.
   - There are also a lot of complaints about it not being "loose" enough
     to accommodate everyone.  (E.g. the current rules on the semantics
     of fork() preclude a fully conformant MS-DOS implementation.)
   - There are complaints (such as this one) that it isn't "tight" enough
     or that it's incomplete and not reaching completeness rapidly enough.

   Choose your devil.

   Additionally, there will always be new needs.  There will also be
   concepts that are not broadly accepted at one time, that due to
   changing market conditions, will be acceptable later.  Thus the
   standard will evolve to reflect needs even after the current "catch
   up" period is completed.

   Maybe the missing field will someday in the future become so common in 
   implementations that it can be standardized.

4) Lastly, please don't whine about it: come help us make it right.  If
   you think it's wrong, don't take potshots at it about how it's broken
   or "braindamaged".  Join us and help us make it right.  Even if you
   don't always get your way (and believe me, noone ever does, because
   one man's "braindamaged" is another's "perfect" and another's "it will
   break my customers applications") you will understand why the decisions
   were made, and what the benefits are; you may also be the person
   who tips the balance on something you care about.

   The next meeting is at the Swissotel, Chicago, April 15-19.  You
   can register at the door, or preregister.  You can participate by mail.
   (Look for a posting in comp.std.unix in the near future that will
   cover that as well as other things.)  I'd like to say participation
   is free, but it simply can't be.  Meeting rooms and copying cost money,
   and for something the size of POSIX we just have run totally out of
   Sugardaddies to pay for such things.

Donn Terry
Chair, IEEE 1003.1
My comments reflect only my own opinions, not those of either the IEEE
or my employer.  (IEEE yells at me to make that clear.)