Standards Update, The Decline and Fall of POSIX?
Nicholas M. Stoughton
Submitted-by: ni...@usenix.org (Nicholas M. Stoughton)
Nicholas M. Stoughton <ni...@usenix.org>, Report Editor
The Decline and Fall of POSIX?
Nicholas M. Stoughton <ni...@usenix.org> reports on The
Decline and Fall of POSIX?
Mine's Bigger Than Yours
The March Internet Engineering Task Force (IETF) Meeting in
Los Angeles attracted well over 1100 attendees. They ranged
from those who wanted to find out more about the Internet
(i.e. were using it as an educational vehicle), through
interested observers, wanting to report back latest
developments to their companies, to a number of real
developers, actively building new standards.
Meanwhile, the IEEE Portable Applications Standards
Committee (PASC) continues to have a declining membership,
now down to well under 100 for the last three meetings
(actually 64 at the most recent meeting).
The IETF churn out large numbers of standards, with each
working group producing two or three a year. PASC has slowed
to a trickle, or so it seems. Actually, looking at the
output of the two groups side by side, the picture is not
nearly as dark as it first appears.
The average IETF standard is thirty or forty pages long. It
is written by engineers for engineers. Few application
developers need worry overtly about the nitty gritty of the
lower levels of the protocols between the parts of their
application, so long as they work. Most IETF standards have
working reference implementations to assist in describing
behavior. Therefore, the language in the standard need not
be as precise as required by a POSIX standard.
The average PASC standard is three or four hundred pages of
extremely carefully reviewed material. It takes between
three and six years to develop one of these beasts. Its
audience is a much wider proportion of application
developers and system implementors. It must be couched in
unambiguous terms, and not rely on anyone's ``common sense''
to determine the meaning of what is written.
IETF standards are built on ``rough consensus'' and
``working code''. Rough consensus is not actually defined
anywhere, and it is often up to the working group chair to
see how many heads in the room are nodding; ``a good hum''
is all that's needed. It does then go through various
- 2 -
subsequent levels of inspection and implementation before
becoming a full standard. The working code is often the
arbiter in cases of interpretation; if your implementation
can talk to mine, then it's probably OK.
PASC standards on the other hand have a very tightly defined
idea of consensus. The rules are rigidly applied. The ballot
groups are often large (POSIX.1a for example has 127
members) who have a small finite window to vote on a
particular draft. If 75% of the respondents approve (and 75%
of the group has to respond), then the draft is approved.
Most large standards go through about twelve drafts. IETF
documents (Requests for Comment, or RFCs) probably go
through four or five before they become ??draft?? standards.
So in fact, the POSIX process is roughly equivalent in
output to the IETF, but the resulting output is far more
formal a document. The reaction time -- the time from idea
to something concrete -- is a major problem, but the rate at
which work gets done is not substantially different.
But the shrinking size of PASC has other, more sinister,
connotations. Does a working group of four or five people
really represent the industry as a whole? Isn't some
commercial concern, such as X/Open, doing a better job,
faster, with more representation, than PASC?
I would argue strongly against this idea. I hope you will
agree with me too! The strength of PASC lies in the fact of
its openess, and its cross industry participation. X/Open,
while having a User Council, is basically funded and run by
and for the vendors. It does a fantastic job for them, and I
am not in any sense knocking that. PASC, on the other hand,
is not about the Working Groups themselves, but the wider
audience of people involved in building standards -- the
ballot groups in particular. Anyone can join a ballot group
(even non members of the IEEE, though their ballot need not
be regarded as binding). Anyone can influence a POSIX
standard provided the consensus agrees. End users of the
standards, both application developers and the implementors,
are able to voice their opinions, and can try to ensure that
the result is useful and acceptable. I can't do that to the
Single Unix Specification. But I can, and have, influenced
the content of POSIX.1, for example.
The debate on the declining attendance of PASC meetings is
raging around me as I write this. The three options we are
discussing are
+ Make no changes, we are doing OK
+ Stop developing new POSIX standards, our job is done
there. Change PASC to become purely a care and
maintenance group for the finished work.
- 3 -
+ Alter PASC's scope to take in other, sexier, work and
attract more people
That third option may have some merit. But PASC has done a
good job in defining application program interfaces for
portability. To branch out into other areas, like languages
or protocols, is not only a step into the unknown, but also
treads on the toes of other existing groups.
The current scope of PASC is based on the interfaces needed
to develop portable applications. They describe the
interface between the application and the environment in
which it is to run. The real question is how much has that
environment changed in the last 12 years or so that has
been working. Are we only working a small percentage of our
scope?
As a part of this debate, a new study group is to form at
the next meeting to look at some new functionality that
might be within our scope to work with. A notice for this
group appears in this issue.
The debate will continue for some months, I'm sure. Please
feel free to mail me with your opinions.
Glen.Seeds
Submitted-by: Glen....@fulcrum.com ("Glen.Seeds")
I have been a strong believer in and advocate of POSIX since the early
days when there was only one small group and one project. I have finally
concluded that it is now, unfortunately, no longer relevant to my
company, or indeed to most forward-looking IT companies.
The reason is simple: the UNIX industry has allowed itself to be
overtaken by events. UNIX started to lose the war when it failed to
provide an effective response to the cheap, high-productivity GUI
environments provided by the Mac and Windows. The OpenLook vs. Motif war
pretty much killed UNIX's chance here.
It had a nearly unbreakable lock on the server market, but lost it when
Microsoft released NT. Unfortunately, the major UNIX vendors were never
able to get together to provide genuine, cheap application portability.
Each insisted on having its own enhancements that erected portability
barriers. This created the opportunity for Microsoft, which had already
won the desktop war, to enter the server market - the UNIX vendors did
not have a credible defense on grounds of portability.
Our firm in particular has found that:
- Because our UNIX port mechanism was created before POSIX, POSIX is of
marginal benefit.
- While porting to and maintaining the product on NT was and is more
expensive than our UNIX ports, the difference is not big enough to be a
serious barrier.
- NT is the killer example of a WierdNIX - perfectly compliant, and
therefore able to pass almost all POSIX-based RFP's, but almost useless
in practical terms.
- Our server market is undergoing a substantial shift towards NT.
This state of affairs is sad, because these losses were avoidable, and a
win would have been good for everyone (except maybe Microsoft). I
personally hope that something prevents NT from taking over the world -
that kind of power is no better in Microsoft's hands than it was in
IBM's. However, that something is unlikely to be POSIX.
The POSIX group has done some great work, and if nothing else it has
left a solid legacy for system interface design. There is still some
valuable work happening in places such as Internationalization. For most
of us, though, it's time to move on.
/glen
Dave Cline
Submitted-by: dcl...@netcom.com (Dave Cline)
>But the shrinking size of PASC has other, more sinister,
>connotations. Does a working group of four or five people
>really represent the industry as a whole?
Of course not.
>Isn't some
>commercial concern, such as X/Open, doing a better job,
>faster, with more representation, than PASC?'
Yes -- and even there, many people feel that the
time to standardize is too long.
>I would argue strongly against this idea. I hope you will
>agree with me too! The strength of PASC lies in the fact of
>its openess, and its cross industry participation. X/Open,
>while having a User Council, is basically funded and run by
>and for the vendors.
I think that the idea that PASC standards are somhow more
democratic than X/Open standards isn't really very relevant
and may be historically incorrect.
The utility of a standard depends on its applicability,
timeliness, and vendor support. X/Open is winning
on all three of these fronts.
>the result is useful and acceptable. I can't do that to the
>Single Unix Specification. But I can, and have, influenced
>the content of POSIX.1, for example.
One of the reasons that X/Open can move faster is that
it doesn't have to try to satisfy all the special interest
groups -- far too many standards meeting attendees
feel they have to "influence the context of xxxx" or
they haven't done their job. It shows.
> + Stop developing new POSIX standards, our job is done
> there. Change PASC to become purely a care and
> maintenance group for the finished work.
I think this is the right choice.
James H. Haynes
Submitted-by: hay...@cats.ucsc.edu (James H. Haynes)
In article <4ps4k0$c...@cygnus.com>, Dave Cline <dcl...@netcom.com> wrote:
>>Isn't some
>>commercial concern, such as X/Open, doing a better job,
>>faster, with more representation, than PASC?'
>Yes -- and even there, many people feel that the
>time to standardize is too long.
Wouldn't it be even better if only one company supplied the software? Then
there wouldn't be any need for standards documents, except for the company's
internal confidental ones, because the product itself would be the standard.
The software would be by definition bug-free, because the way it actually
performs is the only specification for how it is supposed to perform. The
company could insure a steady revenue stream for itself and for its third-
party developers by introducing changes at a carefully calculated rate,
changes which eventually make earlier products obsolete. Since everybody
would use the software the company could afford to sell it for a pittance
per copy and still earn a handsome profit. The company could prevent some
upstart from attempting to duplicate the product by patenting portions of it,
and by frequently introducing small changes that are announced only to
the application developers under non-disclosure agreements.
(insert some kind of typographical caricature here for the irony-impaired)
J.T. Conklin
Submitted-by: jcon...@netcom.com (J.T. Conklin)
In article <4pqb36$1...@cygnus.com>,
Nicholas M. Stoughton <std-...@uunet.uu.net> wrote:
>Submitted-by: ni...@usenix.org (Nicholas M. Stoughton)
>But the shrinking size of PASC has other, more sinister,
>connotations. Does a working group of four or five people
>really represent the industry as a whole? Isn't some
>commercial concern, such as X/Open, doing a better job,
>faster, with more representation, than PASC?
In my work on the NetBSD Operating System, I've found that using the
POSIX standards has been very worthwhile. The required behavior is
tends to be much more completely and accurately discribed, and there
is usally a lengthy rationale describing how and why certain decisions
were made and what prior art was considered.
X/Open standards on the other hand, tend to be much less useful. For
many functions with different behavior on different operating system,
the SysV behavior was just taken. In other cases, obsolete interfaces
marked "withdrawn" in previous releases of the XPG have been re-
introduced. I, for one, have no enthusiasm for adding obsolete
interfaces that will likely be withdrawn again.
I have no problem with the rate of progress with the POSIX working
groups, because they produce the superior product. When things move
slowly, perhaps that's because the matter being standardized needs
time to be understood, ideas and approaches to be formulated, proof of
concepts to be written, etc. In these cases, the last thing the
industry needs is a hastily written, ill-thought out standard that's
been pushed through by a handful of OS vendors..
--jtc
Jim Kingdon
Submitted-by: kin...@harvey.cyclic.com (Jim Kingdon)
One of the key reasons, in my opinion, that the IETF standards process
has been a success is that their standards are widely and freely
available on the internet.
To the extent that POSIX has been implemented by a handful of
commercial vendors (which has never really been true in the BSD
world), having to buy standards on paper or CD-ROM is no big deal.
But what we are seeing now, especially with the popularity of NetBSD,
FreeBSD, Linux, Mach-based systems, and other free POSIX
implementations, is that people are implementing POSIX standards
without having copies of them.
One operating system standard for which on-line availability is key is
the Linux FSSTND (/usr vs. /var vs. /etc and so on). This standard
has been independently implemented by quite a few vendors (Red Hat,
Debian, Slackware, Craftworks, Yggdrasil, etc.), and thus can be
considered successful. Another standard available online, athough not
yet widely deployed, is Multiboot (interface between the operating
system and the boot loader). I would suspect that the fact that the
System V device driver standard is not online is an important reason
why it has not been deployed by FreeBSD, Linux, Mach, etc., despite
the fact that the developers of these systems often can be heard to
wish that device drivers were more portable among these systems.
Providing standards for free on the net might entail looking for new
funding for the IEEE (or maybe not--reselling IETF standards on CD-ROM
is a significant business, and one can imagine advertiser-supported
web sites or other possibilities), but I would urge the IEEE to accept
the challenge and look for solutions. If the IEEE cannot be
persuaded, then the unix standards community has to ask itself whether
these issues are important enough to reconsider the use of the IEEE as
a standards body for unix standards.