HDTenEightyP/NetNews huggingface dataset:
From: andrew@alice.att.com (Andrew Hume)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Date: 24 Dec 1992 23:26:17 -0800
Organization: AT&T Bell Laboratories, Murray Hill NJ
NNTP-Posting-Host: ftp.uu.net
Summary: so thats what canadian angst is!
X-Submissions: std-unix@uunet.uu.net

Submitted-by: andrew@alice.att.com (Andrew Hume)

In article <1hdndfINNi52@ftp.UU.NET>, stephe@mks.com (Stephen Walli) writes:
> 1. I haven't seen your spec (and I know its electronically available :-)  
>    but how big is it wrt POSIX.1?  I think size and scope has a lot to 
>    do with some of the problems in POSIX. 

	the spec all up is 120-odd pages, including system requirements etc.
so it is maybe a third of 9945-1 and some infinitesimal fraction of 1003.2.
the size is a second order effect, i think; the thing that hurts you most
is the precision you need, and the need to cover a bunch of extent systems.

> 2. I found the two book/two context problem really hurts usability.
>    ( I don't believe this is the simple publishing problem some people 
>     think it is.)  Are their similar concerns with your spec? 

	nup. we were smart enough to insist on the 5 parts of our spec
being published together as a single volume. and another standard being
done at the same time which uses two of our parts verbatim is also
including those two parts in their volume for mainly readability issues.

> 3. How many language bindings are there to your LIS? And what languages 
>    are they? 

	As we are a format standard, and not an application interface standard,
we have no languages as such. however, specific descriptor formats are
analogous to languages; we include one such binding (that is, one set of
descriptors) in the standard. (as an example, i know of some work on
another binding with rather different performance characteristics.)

> 4. Have you seen the current POSIX.1/LIS and POSIX.16 C-binding? 
>    If so, what did you think?

	regrettably, not for some time. is it possible to get something
electronic?


			andrew hume


Volume-Number: Volume 29, Number 95
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long
Date: 26 Dec 1992 14:24:04 -0800
Organization: I.E.C.C.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)

>the GKS LIS proved you could write Fortran programs in any language.

There's another kind or program?  Uh oh.

I think we need to step back a little and consider what appears to me to
be the root of all the standardization trouble: standards should codify
existing practice, or at worse choose from among a few existing versions
of existing practice, perhaps with some minimal glue where the selected
versions don't match up perfectly.  Invented standards usually fail.  ANSI
C came close to the existing practice ideal except for the locale glop
which, not surprisingly, is the least satisfactory part of the C standard.

What the GKS LIS really proved, of course, is that we don't know how to
design usable libraries other than by experimentation, and that a suitable
design for one language is probably not a suitable design for another.
These are interesting and useful lessons, but not very helpful for
practical standards design except as a warning of what not to do.

POSIX .1 and .2 did a reasonable job of codifying existing practice,
because there was (not by accident) a lot of existing practice to codify
so it looks like they'll be fairly successful.

The problems that people have pointed out with the POSIX tests demonstrate
that it is not appropriate to standardize test suites, particularly not
test suites that haven't themselves been tested by a significant amount of
use.

I'm all in favor of test suites.  I think there should be lots of them,
since they make the implementor's design so much easier, and raise the
user's confidence that a product that passed the tests probably works.
But test suites make poor standards.  When I was writing an early F77
compiler in 1978-79 (INfort, if anyone remembers if) the compiler passed
most of the tests long before I would have asked anyone to use it on real
code.  The tests were useful, but hardly definitive.  There were places
where the test suites were just wrong, even though they'd been in use for
many years to validate F66 compilers.

The argument may be made that various pressures require various sorts of
standards do allow competitive procurement and the like.  I don't believe
it.  A really bad Fortran POSIX binding would in practice mean that nobody
would write POSIX interface code in Fortran, but would more likely write
the interface in C and use some C to Fortran hack.  Ada is admittedly a
special case, given its dedicated customers, but even there a bad enough
standard would force people to circumvent it.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl

Volume-Number: Volume 29, Number 98
From: jmcarli@srv.pacbell.com (Jerry M. Carlin)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Date: 24 Dec 1992 17:17:07 -0800
Organization: Pacific * Bell
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: jmcarli@srv.pacbell.com (Jerry M. Carlin)

There is yet another problem: scope. I'm in the process of reviewing
1003.6 draft 13. Lots of good work went into it and there is lots that I
can agree with but my biggest problem is what they left out. IMHO 1003.6
won't REALLY be complete until the year 2000, if then, given that I&A and
lots of other things are not currently in the standard.  Even for what is
being standardized, my biggest problem is usability.  For example, you can
have audit, but no commands (none!) that deal with audit.

I'm not sure what the answer is, but if we're not careful it will
be Windows NT:-(

-- 
Jerry M. Carlin	(510) 823-2441 jmcarli@srv.pacbell.com
Alchemical Engineer and Virtual Realist

Volume-Number: Volume 29, Number 94
From: stephe@usenix.org (Stephen R. Walli)
Newsgroups: comp.std.unix
Subject: Standards Update, ISO WG15 (POSIX) Rapporteur Group on Co-ordination of Profile Activities
Date: 29 Dec 1992 14:26:26 -0800
Organization: USENIX Standards Watchdog Committee
Reply-To: std-unix@uunet.uu.net
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: stephe@usenix.org (Stephen R. Walli)

Kevin Lewis <klewis@gucci.enet.dec.com> reports on the October 23-24,
1992 meeting in Utrecht, NL:

The IEEE Technical Committee on Operating Systems - Standards
Subcommittee (TCOS-SS) forwards POSIX documents through an ANSI
technical advisory group to ISO Working Group 15 (WG15) for approval
as international standards.  WG15 has a number of rapporteur groups,
which are small groups of experts on various ISO POSIX related topics.

This was the third meeting of the Rapporteur Group on Co- ordination
of Profile Activities (RGCPA).  It was my first.  The meeting lasted a
day and a half.  There were actually more observers in the room than
members.  About 15-18 people attended, of which 75% were IEEE POSIX
attendees. Seeing all the familiar faces from a week of IEEE POSIX
meetings underscored the high percentage of overlap between the IEEE
and ISO POSIX working groups.

The work of this Rapporteur group is to co-ordinate profiling
activities that would be of interest to WG15 as follows:

   - the process of addressing user requirements for profile
     harmonization,

   - the development of the appropriate approach to sub-setting WG15
     standards within profiles,

   - the treatment within profiles of the options that exist within a
     standard that is part of the profile.

Recognizing that there are other organizations dealing with profile
issues, the group put forward a resolution to WG15 that the TCOS
Profile Steering Committee and X/Open be encouraged to establish
Category C liaison with WG15 RGCPA.

Reflecting back on this meeting, it seemed to me that the real purpose
of this group is to serve as a radar, seeking out any and all profile
activities anywhere in the globe that would be pertinent to the work
of WG15 and SC22.  From my own vantage point, it appeared to be
accomplishing his purpose.

The next meeting of this group will be on May 10-11, 1993 in
Heidelburg, Germany.

Volume-Number: Volume 30, Number 13
From: stephe@mks.com (Stephen Walli)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long
Date: 24 Dec 1992 17:12:38 -0800
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: stephe@mks.com (Stephen Walli)


>In article 1halvbINN9kd@ftp.UU.NET, stephe@usenix.org (Stephen R. Walli) writes:
>Actually, producing a language independent specification plus language
>bindings is already an existing practice for API standards.  Both the
>ISO/ANSI GKS and PHIGS standards have this form.  The only aspect of the
>POSIX effort that cuts new ground is the use of LI specifications to
>approximate existing APIs.

When IEEE POSIX began the LIS efforts, the ISO GKS model was investigated
and found to be wanting. Hopefully without sounding trite, the GKS LIS 
proved you could write Fortran programs in any language.  POSIX is trying 
to come up with a model that will take into account different language 
models, the three it has to take into account immediately being: C, Ada, F77.
A lot of effort has gone into this. The IEEE POSIX person responsible 
for the TCOS LIS Guidelines *is* the liaison to ISO WG11 (Language Binding
Techniques) and we have already overreached the WG11 work in a number of 
areas. Operating system APIs are apples. Graphic objects are oranges. 

The requirements placed on POSIX were different from the start in that
there were anywhere from 6-12 Fortran programmers, and 20-30 Ada
programmers looking over our shoulders at any one point in time.  These
were people who were active in their own working groups, so only had
time to provide critical comment over the wall. In separate
conversations, I have heard a number of Ada programmers complain
bitterly about the GKS Ada binding.


------------------------------------------------------------------------------
Stephen R. Walli,       stephe@mks.com | Standards are commercial and  
Mortice Kern Systems Inc.              | international politics dressed up  
phone: +1 (519) 884-2251               | as technical arguments. 


Volume-Number: Volume 29, Number 92
From: casey@anchovy.wpd.sgi.com (Casey Schaufler)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Date: 29 Dec 1992 14:14:57 -0800
Organization: Silicon Graphics, Inc., Mountain View, CA
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: casey@anchovy.wpd.sgi.com (Casey Schaufler)

> I thought the audit commands were being done as an addendum to 1003.2.
> Has this idea been dropped?

All of 1003.6 should be considered an addendum.

> Not to mention the fact (opinion?) that the interfaces specified by 1003.6
> are so complex that verification and minimality of the TCB is extremely
> (impossible?) difficult to assure.

The POSIX ACL spec is Most Heinous. The priviledge mechanism is designed
primarily to ease retrofitting existing sysadmin programs, not to provide
for the principle of least priviledge. The audit section doesn't actually
nail anything down.

> Anybody know where I can get a copy of the Trusix spec?

The Trusix spec is available from the NSA. Don't strain any muscles getting
it, however. The Trusix working group (which I was privileged to be part of)
did not (in my opinion) produce anything of real value, primarily because
they didn't want to be incompatible with the POSIX efforts.

	-casey

Volume-Number: Volume 30, Number 4
From: jfh@rpp386.uucp (John F. Haugh II)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long
Date: 27 Dec 1992 18:21:12 -0800
Organization: Los Tejanos SCUBA Club and Beer Joint, Austin, Tejas
Reply-To: jfh@rpp386.uucp (John F. Haugh II)
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: jfh@rpp386.uucp (John F. Haugh II)

In article <1hjd0sINNobl@ftp.UU.NET> knighten@SSD.intel.com (Bob Knighten) writes:
>This is a commonly expressed claim ("standards should codify existing
>practice") and it may even be true for software, but I would certainly like to
>hear some justification.  Certainly it is not true for a great many other
>standards, such as many computer hardware standards, standards for electrical
>fixtures and building standards, where specification of a standard often
>preceeds the existence of any product.  Indeed there are numerous situations
>where this is enforced by law.

I know that in certain of these circumstances, where the standard predates
the production of something which meets these standards, that the standard
is derived from an existing standard plus some incremental refinement.  The
area I am most familiar with is the American Bureau of Shipping standards
as they apply to maritime vessels.  The size of a piece of steel in a certain
location in a ship is not pulled out of thin air.  Rather, that piece of
steel is specified based on existing practice, and the specification is
altered using practical experience (like, did any boats built that way sink
recently ...), not the desire to make life easier on steel foundries.

Were software standards derived in a manner similar to those produced by
engineers in the more physical disciplines, perhaps software would be as
compatible as telephone equipment and as reliable as a screwdriver ...

-- 
John F. Haugh II                  [  TSAKC  ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151           [ DoF #17 ]        @'s: jfh@rpp386.cactus.org


Volume-Number: Volume 30, Number 2
From: stephe@usenix.org (Stephen R. Walli)
Newsgroups: comp.std.unix
Subject: Standards Update, The Distributed Security Study Group
Date: 29 Dec 1992 14:23:02 -0800
Organization: USENIX Standards Watchdog Committee
Reply-To: std-unix@uunet.uu.net
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: stephe@usenix.org (Stephen R. Walli)

Dave Rogers <drogers@datlog.co.uk> reports on the October 19-23, 1992
meeting in Utrecht, NL:

The POSIX Distributed Security Study Group (DSSG) met for the third
and last time in Utrecht.  This is the end of the six month lifetime
of the study group.  The group continues to be well supported and the
Utrecht meeting brought a few new faces into the group, particularly
European, but also a Canadian.

The DSSG made progress with the approach of defining a security
framework for POSIX by mapping the ECMA ``Open Systems Security - A
Security Framework'' onto a POSIX environment with encouraging
results.  The draft framework produced has been used to make an
initial identification of the services requiring Application Program
Interfaces and has mapped known existing or emerging implementations
onto the APIs identified.  Other standards activities in this area
have also been identified.

A white paper titled ``A Distributed Security Framework For POSIX''
has been published presenting the work done to date with the specific
objective of stimulating discussion and comment.

The DSSG has recommended the formation of a new POSIX working group to
produce a ``Guide to Security within Distributed POSIX Systems'' using
the white paper produced by the DSSG as the base document.  A project
authorization request (PAR) for this work has been submitted and will
be considered by the POSIX SEC at the January meeting.  An objective
of this Guide is to produce a definition of the security services and
APIs required throughout POSIX so that the adequacy of future PARs on
meeting the defined security requirements can be assessed.

If anyone is interested in obtaining a copy of the white paper or
wants more information then contact the DSSG Chair:

David Rogers,
+44 81-863-0383 or
+44 256-59222 x4083
Data Logic Ltd,
Queens House,
Kymberely Road
Harrow, Middx.,
UK, HA1 1YD
email: drogers@datlog.co.uk

Volume-Number: Volume 30, Number 5
From: jgd@csd4.csd.uwm.edu (John G Dobnick)
Newsgroups: comp.std.unix
Subject: POSIX Question
Date: 23 Dec 1992 13:31:48 -0800
Organization: University of Wisconsin - Milwaukee
Reply-To: jgd@csd4.csd.uwm.edu
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: jgd@csd4.csd.uwm.edu (John G Dobnick)

I lack access to the POSIX standards, either adopted or proposed, so
this seems a good place to ask this.

Does the user interface standard (or whatever it's called) make
any reference to the "vacation" program -- i.e., is vacation(1) 
a required or optional part of a POSIX implementation.

I'm basically looking for a yes or no answer, although if this
_is_ part of POSIX, a short note about its similarity to the BSD
vacation program would also be appreciated.

(I hope that wasn't _too_ unintelligable.)

Also, if there is an FAQ repository for such things as the Tables of
Contents of the various POSIX sections, a pointer to this would
also be appreciated.

Thanks much,

-- 
John G Dobnick                          ATTnet: (414) 229-5727
Computing Services Division             INTERNET: jgd@uwm.edu
University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd

Volume-Number: Volume 29, Number 85
From: bitbug@netcom.com (James Buster)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Date: 25 Dec 1992 15:55:10 -0800
Organization: Lynx Real-Time Systems, Inc.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: bitbug@netcom.com (James Buster)

In article <1hdnejINNi74@ftp.UU.NET> jmcarli@srv.pacbell.com (Jerry M. Carlin) writes:
>There is yet another problem: scope. I'm in the process of reviewing
>1003.6 draft 13. Lots of good work went into it and there is lots that I
>can agree with but my biggest problem is what they left out. IMHO 1003.6
>won't REALLY be complete until the year 2000, if then, given that I&A and
>lots of other things are not currently in the standard.  Even for what is
>being standardized, my biggest problem is usability.  For example, you can
>have audit, but no commands (none!) that deal with audit.

I thought the audit commands were being done as an addendum to 1003.2.
Has this idea been dropped?

Not to mention the fact (opinion?) that the interfaces specified by 1003.6
are so complex that verification and minimality of the TCB is extremely
(impossible?) difficult to assure. Anybody know where I can get a copy of
the Trusix spec?

-- 
James Buster
bitbug@netcom.com

Volume-Number: Volume 29, Number 97
From: ig25@fg20.rz.uni-karlsruhe.de (Thomas Koenig)
Newsgroups: comp.std.unix
Subject: Is fopen("fifo","a") legal?
Date: 23 Dec 1992 13:30:39 -0800
Organization: University of Karlsruhe, Germany
Reply-To: ig25@rz.uni-karlsruhe.de
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: ig25@fg20.rz.uni-karlsruhe.de (Thomas Koenig)

Is it legal in a POSIX - conforming system to open a fifo for append? 

In other words, would I have to stat() every file I wish to append to
and see wether it is a fifo or not?

-- 
Thomas Koenig, ig25@rz.uni-karlsruhe.de, ig25@dkauni2.bitnet
The joy of engineering is to find a straight line on a double logarithmic
diagram.


Volume-Number: Volume 29, Number 84
From: karish@pangea.Stanford.EDU (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: Is fopen("fifo","a") legal?
Date: 23 Dec 1992 18:19:03 -0800
Organization: Mindcraft, Inc.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)

In article <1halpvINN9fe@ftp.UU.NET> ig25@rz.uni-karlsruhe.de
(Thomas Koenig) writes:

>Is it legal in a POSIX - conforming system to open a fifo for append? 

I don't see why not.  Writes to a FIFO are always at
end-of-file, whether it's opened for "write" or for 
"append".

--
Chuck Karish          karish@mindcraft.com
(415) 323-9000 x117   karish@pangea.stanford.edu

Volume-Number: Volume 29, Number 89
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.unix
Subject: codifying existing practice
Date: 26 Dec 1992 21:59:22 -0800
Organization: U of Toronto Zoology
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: henry@zoo.toronto.edu (Henry Spencer)

In article <1hjd0sINNobl@ftp.UU.NET> knighten@SSD.intel.com (Bob Knighten) writes:
>This is a commonly expressed claim ("standards should codify existing
>practice") and it may even be true for software, but I would certainly like to
>hear some justification.  Certainly it is not true for a great many other
>standards, such as many computer hardware standards, standards for electrical
>fixtures and building standards, where specification of a standard often
>preceeds the existence of any product...

Perhaps a better, if more cumbersome, way of phrasing the principle would
be "codify areas that are thoroughly understood".  The most successful
standards, even in the areas you mention, usually codify things that have
at least been demonstrated in the laboratory, and often they codify fairly
minor variations of existing practice.  The crucial point is that we either
know the specific formulation works, or we understand the design space in
the neighborhood well enough that we can confidently predict it will work.
This is emphatically not true of many of the well-meaning attempts at
software standardization currently underway.

-- 
"God willing... we shall return."       | Henry Spencer @ U of Toronto Zoology
       -Gene Cernan, the Moon, Dec 1972 |  henry@zoo.toronto.edu  utzoo!henry

Volume-Number: Volume 29, Number 100
From: karish@pangea.Stanford.EDU (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Date: 25 Dec 1992 15:53:47 -0800
Organization: Mindcraft, Inc.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)

In article <1hdndfINNi52@ftp.UU.NET> stephe@mks.com (Stephen Walli) writes:
>To give a real example: POSIX.4 (Real-time Extensions to POSIX.1) is almost
>done. It will go in front of the IEEE Standards Board in June. There are no
>test methods. To construct test methods, they should do so in an LIS form, 
>plus C binding. But then the standard is not yet in LIS form. Plain old 
>fashioned C. If I found out, as a poor individual programmer in the 
>industry, that this useful specification was being withheld by the IEEE 
>standards board because it didn't have this other thing (of NO value to 
>me as programmer) called test methods, I would yell VERY LOUDLY at ANSI, 
>which certifies the IEEE to produce standards. 

Remember that a lot of the functionality in POSIX.4 is invented,
either extending what's in existing implementations or specifying
the behavior differently.

It will be even more important for this standard than for POSIX.1
and POSIX.2 to have agreed-upon test methods.

The fact that the IEEE Standards Board won't publish the standard yet
does nothing to prevent OS vendors from implementing the C binding,
and thus has little effect on the individual programmer's ability to
use its features.  The tradeoff, from the programmer's point of view,
is that the sooner test methods are agreed upon, the sooner it will
be possible to write portable code that can be expected to work on
all POSIX.4 systems that support the applicable option(s).  Language
independence is of lesser importance to C programmers, except as it
impedes the rest of the process.

--
Chuck Karish          karish@mindcraft.com
(415) 323-9000 x117   karish@pangea.stanford.edu

Volume-Number: Volume 29, Number 96