From: (Nicholas M. Stoughton)
Subject: Standards Update, POSIX.1: System API
Date: 1995/04/12
Message-ID: <3mh8j0$>
X-Deja-AN: 100371656
approved: (Moderator, Sean Eric Fagan)
organization: USENIX Standards Report Editor
newsgroups: comp.std.unix

Submitted-by: (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <>, Report Editor

POSIX.1: System API

Nick Stoughton <> reports on the January
16-20, 1995 meeting in Ft Lauderdale, FL:

If You Can't Beat 'Em, Join 'Em

Well, after tiring of twisting people's arms (usually
unsuccessfully) to snitch on the work of the POSIX.1 Working
Group, where I am usually to be found during a POSIX meeting
myself, I thought I would have to submit at least one real
snitch report myself.  Show everyone how its really done ...
but the only trouble is, I have all those other great
snitch's on the other groups to live up to!

POSIX.1 is a small group, typically only about 6 or 7 show
up at a meeting.  Until this meeting, it had only two items
of work: POSIX.1a and Interpretation requests.  However, a
new Project Authorization Request has just been passed and
assigned to this group, so perhaps I'll have some more
people to dragoon in April!

Another Year, Another Draft

The great highlight of the January meeting was that Lee
Damico, our technical editor, had managed to ship draft 12
of POSIX.1a to the IEEE a week before the meeting.  This was
after many late nights, weekends, and even sacrificed
Christmas vacation trying to get all the ballot resolutions
into the draft.

Several sections were substantially rewritten after the
first round of ballotting; most notably the checkpoint-
restart interfaces.  These are highly contentious for a
number of reasons:

  - They are not based on existing practice, and are
    substantially invention by the committee.  As a Usenix
    and Europen (the European equivalent of Usenix)
    representative, this makes me decidedly uneasy.
    However, they are optional, and I don't believe they are
    unimplementable. Lets hope some brave reader tries to
    build these interfaces before the standard is published
    so we can have some existing practice and experience to
    work with!

  - Two different groups within POSIX require them for
    future extensions.  The Batch profile, which was

- 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002 -

    responsible for wording the original (up to Draft 11)
    version, needs some interfaces to allow long running
    jobs to be stopped in their tracks and restarted later.
    In addition, the work being done by the Services for
    Reliable, Available, Serviceable Systems (SRASS) working
    group need interfaces to checkpoint processes if the
    system is failing, to allow those processes to be
    restarted later in, potentially, a quite different
    environment after various devices have disappeared and
    so on.

The batch and SRASS arguments look set to roll on for some
time; the two groups want quite different things.  However,
it is also undesirable to have two different checkpoint
interfaces, one for batch, one for SRASS. The ballot group
just hate the whole idea because it is invention. But if we
remove the interfaces, then these two follow-on groups are
in trouble.

The other recurrent long-running argument in POSIX.1 is over
the interpretation of trailing slash characters on
pathnames.  Historically, System V based systems ignored all
trailing slashes, whatever. BSD based systems only permitted
trailing slashes on pathnames that were existing
directories. In draft 12, the BSD behavior is demanded. From
an engineering perspective, this is a much cleaner answer.
However, the weight of existing System V platforms that
would lose compliance as a result of this is substantial.

>From the application developer's, as opposed to the system
implementor's, point of view, it is a good change. If you
wrote an application that depended on trailing slash
behavior before POSIX.1a, it was not portable. After the
publication (well, we have to be optimistic), such an
application _w_i_l_l be portable.

For most system implementors it is not too hard a change to
get working in a future release, and most have at least one
release a year.

News Flash

As ballot co-ordinator for POSIX.1, I can tell you that the
ballot on draft 12 closed on time, with a 44% affirmative
vote. Most of the ballots look as if we should be able to
work through them quickly, so progress can be expected in

Volume-Number: Volume 35, Number 26

			  SCO's Case Against IBM

November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and 
Linux user, talks about the benefits of code availability and the merits 
of the SCO vs IBM lawsuit. See SCO vs IBM.

Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review
or criticism.