Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.24

Internet Message Format | 1991-09-03 | 318KB

From [e-mail]  Sat Jun 15 14:08:07 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA03848; Sat, 15 Jun 91 14:08:07 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00836; Sat, 15 Jun 91 14:08:00 -0400
Newsgroups: comp.std.unix
From: "James Buster [e-mail]" <public!bitbug>
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: BTR Public Access UNIX, MtnView CA. Contact: Customer Service [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 13 Jun 1991 04:41:29 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (James Buster [e-mail])

In article <[e-mail]> [e-mail] (Sean Eric Fagan) writes:
>of C Language Translation_).  I looked into this, way back when I was
>involved with development system work, and came up with a couple of
>solutions, at least one of which will likely be used.  (They're both fairly
>obvious.)

So, for us morons out there, what are the "fairly obvious" solutions you
are thinking of?
--
                James Buster
                   [e-mail]
        Seen on an MLS machine: Live Free or Die!


Volume-Number: Volume 24, Number 2

From [e-mail]  Sat Jun 15 14:08:35 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA03946; Sat, 15 Jun 91 14:08:35 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00884; Sat, 15 Jun 91 14:08:29 -0400
Newsgroups: comp.std.unix
From: Sean Eric Fagan <[e-mail]>
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Kithrup Enterprises, Ltd.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 13 Jun 1991 18:38:47 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Sean Eric Fagan)

In article <[e-mail]> [e-mail] (Michael I Bushnell) writes:
>HP is *already* claiming Posix compliance, and you say one of the
>solutions "will likely be used".  *That* is precisely the problem.

No, that is not the problem.  I do not work for HP, nor have I ever in the
past.  As far as I know, HP solved the problem quite nicely.  For the
company I was working for, which was *not* HP, I and one other person spent
a few weeks looking into the name-space pollution problem, how to solve it,
and what it would affect in terms of compatibility with old programs and
binaries.

Another poster asks what the two "fairly obvious" methods are.  One is to have
an "ansi-only" mode, a "posix-only" mode, and a "normal" mode, probably
toggled by command-line switches.  Each "mode" would have its own
header-file tree assosciated with it, with only the header-files defined by
that standard (normal would, of course, have everything), as well as a
special library and startup-file.

The other way is a bit harder, but allows backwards-compatibility to work
more easily (at least with supposedly-compliant programs).  Essentially, you
have all "illegal" symbols be "safe" (__select, for example).  All library
routines are written to use the __ names; then, you have the linker accept
an option that tells it to try to ignore the leading __ if there are
unresolved externals.  You still need header-file work, of course, but that
does help the name-pollution problem.  If I remember correctly, both HP and
AT&T did something similar.

--
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
[e-mail]  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.


Volume-Number: Volume 24, Number 3

From [e-mail]  Sat Jun 15 14:08:47 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA03998; Sat, 15 Jun 91 14:08:47 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00892; Sat, 15 Jun 91 14:08:36 -0400
Newsgroups: comp.std.unix
From: Ian Lance Taylor <[e-mail]>
Subject: Maximum values for MIN and TIME?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Fri, 14 Jun 1991 01:42:38 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ian Lance Taylor)

I want to read up to 4096 characters from the terminal in
non-canonical mode.  I want to wait until the characters arrive (with
a timeout).  It seems sensible to me to set MIN to the number of
characters I want to read and use alarm for a timeout.  But what is
the maximum value that I can set MIN to on a POSIX system?  Does the
standard specify this anywhere?  On System V the maximum is probably
255, but it's pretty easy to imagine an implementation for which the
maximum is 127.  I assume the maximum value is <= MAX_INPUT; are there
any other constraints?  I've only seen the 1988 copy of the standard,
so apologies if this is covered in the 1990 revision.
--
Ian Taylor                   [e-mail]                 uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``If he could have moved, he would have gotten up and gone after the man
to thank him for wearing something so marvelously interesting.''


Volume-Number: Volume 24, Number 4

From [e-mail]  Sat Jun 15 14:08:52 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA04010; Sat, 15 Jun 91 14:08:52 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00913; Sat, 15 Jun 91 14:08:45 -0400
Newsgroups: comp.std.unix
From: Donald Lewine <[e-mail]>
Subject: POSIX and ANSI C in one system
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Data General Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Date: Wed, 12 Jun 1991 19:39:17 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Donald Lewine)

In article <[e-mail]>, [e-mail] (Michael I Bushnell) writes:
|> Since
|> nobody but the FSF seems to want real Posix.1 compliance and ANSI C
|> compliance in one system,  . . .

Just for the record: Revision 4.32 of the DG/UX operating system
has received certification from NIST for conformance with the
POSIX.1 standard with ANSI C bindings.  The conformance testing was
done by Mindcraft.

We did use gcc from the FSF.

--------------------------------------------------------------------
Donald A. Lewine                [phone] Voice
Data General Corporation        [phone] FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580  U.S.A.

uucp: uunet!dg!lewine   Internet: [e-mail]


Volume-Number: Volume 24, Number 5

From [e-mail]  Sat Jun 15 14:08:57 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA04024; Sat, 15 Jun 91 14:08:57 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00917; Sat, 15 Jun 91 14:08:47 -0400
Newsgroups: comp.std.unix
From: Gil Tene <[e-mail]>
Subject: what is the status of 1003.4 ?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
Reply-To: Gil Tene <[e-mail]>
X-Submissions: [e-mail]
Organization: Technion, Israel Inst. of Technology
Date: Fri, 14 Jun 1991 14:02:15 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Gil Tene)

Hello people,

I am interested in knowing the current status of POSIX 1003.4. I have
read some articles (quite) a while back, but haven't seen anything new
on the subject.

Maybe you people out there can help me ?

-    When is a final version of 1003.4 expected to be adopted ?

-    What will 1003.4 include ? what sub-1003.4 parts are there ?
    (e.g. 1003.4a, etc.)

-    Where/how can I get my hands on the drafts ?

-    What is the current "trend" in the industry with regard
    to meeting 1003.4 standards ? How soon can we expect
    to see 1003.4 support in major releases of vendors ?
    (SVR4, OSF/1, SunOS, HP-UX, Ultrix, etc.)

I think this may be of interest to the entire group (comp.std.unix
and comp.realtime). I will summerize any e-mail responses, but would
also like to see a more wide-spread discussion.

AdvThanks,

-- Gil.
--
--------------------------------------------------------------------
-- Gil Tene            "Some days it just doesn't pay    --
-- [e-mail]  to go to sleep in the morning." --
--------------------------------------------------------------------


Volume-Number: Volume 24, Number 6

From [e-mail]  Sat Jun 15 14:09:04 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA04067; Sat, 15 Jun 91 14:09:04 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00932; Sat, 15 Jun 91 14:08:55 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: Is this POSIX compliant?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Date: Fri, 14 Jun 1991 17:53:02 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Stephen R. van den Berg) wrote:

] Could someone knowledgable please tell me if the following include files,
] the mentioned identifiers and the include files they are 'allocated' to are
] all conform the POSIX standard?  (I dont't have any POSIX literature,
] so all the data I present here are educated guesses).

I emailed my answer to Stephen like a good net.user, but now I see
that an incorrect answer has been posted to the newsgroup, so I feel
obliged to waste more bandwidth by correcting it.

[e-mail] (Donald Lewine) writes:

]|>
]  #include <unistd.h>
]  ^^^^^^^^^^^^^^^^^^  unistd.h contains the prototypes for the
]                      functions you list and should be included in
]                      an ANSI C system.

Except that open() is in <fcntl.h>, not <unistd.h>.  Also the comments
regarding prototypes and ANSI C are misleading.  The original poster asked
about "POSIX", he didn't specify "POSIX with ANSI C", so I assume he wants
answers which apply equally well to POSIX with either common C or ANSI C.

]|> #include <stddef.h>        /* EOF */
]                   NO.  EOF is defined in <stdio.h>.
]                   <stddef.h> defines:
]                   NULL, offsetof, ptrdiff_t, size_t, wchar_t

<stddef.h> is not required by POSIX.1.

]|> #include <stdlib.h>        /* getenv() memmove() malloc() realloc()
]|>                    free() strtol() size_t */
]                   memmove() is in <string.h>  all others are
]                   in <stdlib.h>

memmove() and strtol() are not required by POSIX.1.

]|> #include <signal.h>        /* signal() kill() */

signal() is not required by POSIX.1.

]A complete listing of the POSIX headers is in Appendix A of the
]POSIX Programmer's Guide available for $34.95 from:
(address deleted)
]In my not so humble opinion, the POSIX Programmer's Guide is
]required reading for anyone who wants to write programs that
]work on all POSIX systems.

I hope it wasn't the source of the errors above.

--
Geoff Clare <[e-mail]>  (Dumb American mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]


Volume-Number: Volume 24, Number 7

From [e-mail]  Sat Jun 15 14:22:24 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA06732; Sat, 15 Jun 91 14:22:24 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02301; Sat, 15 Jun 91 14:22:12 -0400
Newsgroups: comp.std.unix
From: Fred Zlotnick <[e-mail]>
Subject: Re: Is this POSIX compliant?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]>
Date: Wed, 12 Jun 1991 23:01:07 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Fred Zlotnick)

In article <[e-mail]> [e-mail]
(Don Lewine) writes:
>In article <[e-mail]>, [e-mail]
>(Stephen R. van den Berg) writes:
>|> Could someone knowledgable please tell me if the following include files,
>|> the mentioned identifiers and the include files they are 'allocated' to are
>|> all conform the POSIX standard?
>
>To solve this problem at less than half the price of the IEEE
>standard, and get much more information, see below. . .

    [ Many correct comments omitted... ]

>|> #include <stdlib.h>        /* getenv() memmove() malloc() realloc()
>|>                    free() strtol() size_t */
>                   memmove() is in <string.h>  all others are
>                   in <stdlib.h>

memmove() is not supported by POSIX.1.  Clause 8.1 of the POSIX.1 standard
lists 110 functions from the C standard and states that

    POSIX.1 with the C Language binding comprises these functions,
    the extensions to them described in this clause, and the rest
    of the requirements stipulated in [this standard].

The C standard specifies 22 functions in <string.h>.  Only 14 of them
are listed in POSIX.1, and memmove() is not one of these.  Thus a strictly
conforming POSIX.1 application should not use memmove().

I was going to avoid using this newsgroup for advertising, but since
Donald has already broken the ice, I might mention that you can also
find the contents of all POSIX.1 and ANSI C headers in Appendix D of
my book, "The POSIX.1 Standard: a Programmer's Guide", available for
$29.95 from

    Benjamin/Cummings Publishing Company
    390 Bridge Parkway
    Redwood City, 94065
    (800) 950-BOOK for information
    [phone] for orders

or at better bookstores almost everywhere.  My opinion of my book is
as unhumble as Don's opinion of his.  (And I'm sure that he has written
a very fine book.)
--
Fred Zlotnick                       |    #include <std.disclaimer>
[e-mail]                  |    #include <brilliant.quote>
...!{decwrl,ames}!mindcrf!fred      |


Volume-Number: Volume 24, Number 8

From [e-mail]  Sat Jun 15 16:37:57 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA23836; Sat, 15 Jun 91 16:37:57 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13704; Sat, 15 Jun 91 16:37:46 -0400
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: Standards Update, IEEE 1003.2: Shell and Utilities
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]>
Date: Sat, 15 Jun 1991 19:58:30 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Peter Collinson) writes:
> The group is also looking for a new family of compression utilities,
> now that the Lempel-Ziv-Welch family of commands have been removed
> from the standard.  The main requirements for a substitute are:
>    o The algorithm should be expressed (expressible) in a
>      language independent form
>    o The algorithm should be free of patent issues

My compression method, Y coding, appears to be free of all patents,
including LZW. There's nothing language-dependent about the method or
current file format. My reference implementation, yabbawhap (see
comp.sources.unix volume 24), works on a variety of UNIX and non-UNIX
systems, and produces better results than compress at reasonable speed.

Another possibility is Ross Williams' LZRW1, which produces worse
results than compress but is blindingly fast.

---Dan


Volume-Number: Volume 24, Number 9

From [e-mail]  Sun Jun 16 01:16:22 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA10086; Sun, 16 Jun 91 01:16:22 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15384; Sun, 16 Jun 91 01:16:16 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 16 Jun 1991 02:27:52 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Doug Gwyn)

>All library routines are written to use the __ names; then, you have the
>linker accept an option that tells it to try to ignore the leading __ if
>there are unresolved externals.

Actually you don't need to hack the linker; you could supply a batch of
glue routines in the library like this:

    * select -- system call interface for use by applications
    *        (C library must invoke __select instead of select)
        global    __select
        entry    select
    select    jmp    __select

That way both applications that supply their own select() and those that
expect select() to be linked from the system library are happy.

The only reasons I can think of for hacking the linker instead are
    (a) debugging looks neater
    (b) a tiny amount of time is saved by not branching
    (c) C library maintenance is slightly easier


[ This covers functions, but not data.  Such as _iob -- mod ]

Volume-Number: Volume 24, Number 10

From [e-mail]  Wed Jun 19 01:16:44 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA02665; Wed, 19 Jun 91 01:16:44 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06829; Wed, 19 Jun 91 01:16:38 -0400
Newsgroups: comp.std.unix
From: Andrew Hume <[e-mail]>
Subject: P1003.17
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
Date: Mon, 17 Jun 1991 13:57:39 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andrew Hume)

    The latest login; has three (!) reports on the january 1991
meeting of P1003.17 and P1224. In particular, I was
interested in the object management PAR and the controversy
that aroused two additional articles.
    The problem is that I can't quite figure out what the problem
really is. Perhaps if I go through what I think is going on, then
someone will correct me.

    XDS and X.400 defines objects and their encodings via ASN.1.
(This latter means that the BNF-like specifications of the objects
is written in the ASN.1 syntax and that there is a corresponding
well defined encoding into a byte stream.) There is some grouping
of these objects into ``packages'' (I don't know what this means
or implies). XDS and X.400 define an interface for accessing
these objects. That is, a byte level encoding of commands
mixed with objects.

    I think the 1003.17 work is about defining multiple
``versions'' of these interfaces, with the idea that each version
might be a value-added or extended interface. so far, so good.
Scott complains (rightly) that it sucks that vendors can extend
these packages and that users can't. Enzo doesn't say whether he
agrees but says that it seems technically infeasible.

    Could someone comment whether this is a fair summary?
My initial take on this is that it may be technically infeasible
to dynamically support new objects but this should have been a goal
of the work until conclusively shown to be infeasible. (It actually
isn't anyway; it is easy to see how new objects could be handled
as long as you were willing to pay a performance hit for the new objects.
It can be done by analyzing the byte stream interpretively rather than
with compiled code; again, just for the new objects).

    andrew hume
    [e-mail]


Volume-Number: Volume 24, Number 11

From [e-mail]  Wed Jun 19 01:16:54 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA02718; Wed, 19 Jun 91 01:16:54 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06850; Wed, 19 Jun 91 01:16:47 -0400
Newsgroups: comp.std.unix
From: Dave Decot <[e-mail]>
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hewlett Packard, Cupertino
References: <[e-mail]>
Date: Tue, 18 Jun 1991 03:11:51 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dave Decot)

>> HP solved this, I believe (at least, according to an article in _The Journal
>> of C Language Translation_).  I looked into this, way back when I was
>> involved with development system work, and came up with a couple of
>> solutions, at least one of which will likely be used.  (They're both fairly
>> obvious.)
>
> HP is *already* claiming Posix compliance, and you say one of the
> solutions "will likely be used".  *That* is precisely the problem.
>
>     -mib

Well, it's not a problem in HP's case.  HP first released POSIX.1 conformance
(and XPG3 and ANSI C conformance) in HP-UX 7.0 (completed in November of 1989).

That release included support for secondary definitions as described in the
referenced JoCLT article, and used it to prevent link-time namespace pollution.

I believe that "will be used" was referring to the poster's own system,
not HP-UX.

Dave Decot, HP
Disclaimer: my opinions only.


Volume-Number: Volume 24, Number 12

From [e-mail]  Wed Jun 19 01:17:11 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AB02758; Wed, 19 Jun 91 01:17:11 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06860; Wed, 19 Jun 91 01:16:51 -0400
Newsgroups: comp.std.unix
From: "Stephen R. Walli" <speaker!stephe>
Subject: Re: what is the status of 1003.4 ?
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 18 Jun 1991 13:52:40 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen R. Walli)

In response to Gil Tene's POSIX.4 questions:

> I am interested in knowing the current status of POSIX 1003.4. I have
> read some articles (quite) a while back, but haven't seen anything new
> on the subject.

There is a snitch report on its way within the week on the status of
POSIX.4 after the April meeting in Chicago.

> Maybe you people out there can help me ?
> -    When is a final version of 1003.4 expected to be adopted ?

Good question. It really depends on the already strained volunteer resources
of its tech editors and tech reviewers. (I'm one of them, so I can say this.)
Draft 11 is due out anytime for ballot. Even if the technical content remains
relatively untouched, there is still language independent specifications to be
written (which I'm responsible for, so yell at me) and test assertions.

> -    What will 1003.4 include ? what sub-1003.4 parts are there ?
>     (e.g. 1003.4a, etc.)

1003.4
------
Draft 9 which went out for ballot in March 1990 contained chapters on the
following services:

binary semaphores, process memory locking, shared memory, priority
scheduling, events, clocks and timers, IPC message passing, synch I/O,
asynch I/O, realtime files.

Draft 10 ``fixed'' signals to replace events, and added memory mapped files
to the shared memory chapter.

Draft 11 will likely make major changes to (or remove) IPC, in favour of work
being done in POSIX.12 (Protocol Independent Interfaces).

1003.4a
-------
Threads interfaces. It is currently in ballot.

1003.4b
-------
More real-time interfaces. Descibed in the forthcoming snitch.

1003.13
-------
Realtime Profiles. The group is building a small set of profiles of the
realtime interfaces from a scaled down embedded profile up to a kitchen-sink
do-everything profile.

> -    Where/how can I get my hands on the drafts ?

IEEE Standards Office,
445 Hoes Lane,
P.O.Box 1331,
Piscataway, NJ, USA,
08855-1331

phone:
[phone]

> -    What is the current "trend" in the industry with regard
>     to meeting 1003.4 standards ? How soon can we expect
>     to see 1003.4 support in major releases of vendors ?
>     (SVR4, OSF/1, SunOS, HP-UX, Ultrix, etc.)

Ask the vendors. No, really. Standard market-speak answers include:

i)   We're tracking the standard.
     (Some of them actually are contributing, instead of reading about it
      in ever changing ballot drafts.)

ii)  We already have real-time. (Guess who this is. The only problem is that
     it isn't standard and their eyes glaze over and they become non-commital
     after that.)

iii) We aren't pursuing the realtime market at this time, but if our customers
     ask for it, we'll provide it. (I've heard one vendor claim not to be
     pursuing the market in realtime, only to have someone else there
     express real surprise at this statement when I repeated it in a
     quiet corner.)

I will not risk the wrath of friends and enemies by mentioning products I
know of that are seriously implementing the draft document interface, because
I'm bound to miss someone and some stuff was non-disclosure material.

Hope this helps.
regards,
stephe
+-----------------------------------------------------------------------------+
Stephen R. Walli                               SRW Software
phone: [phone]                          572 Foxrun Court,
fax:   [phone]                          Oshawa, Ontario, Canada,
speaker![e-mail]   -OR-                  L1K 1N9
uunet!watmath!mks!speaker!stephe
+-----------------------------------------------------------------------------+



Volume-Number: Volume 24, Number 13

From [e-mail]  Wed Jun 19 18:02:05 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA29393; Wed, 19 Jun 91 18:02:05 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21151; Wed, 19 Jun 91 18:01:48 -0400
Newsgroups: comp.std.unix
From: [e-mail]
Subject: P1003.17
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 19 Jun 1991 11:35:57 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

Andy Hume fairly summarizes part of my objection to the tack that P1003.17 and
P1224 are taking with respect to objects; viz. that vendors can extend whereas
users cannot.  I agree with Andy that extension is not, as Ezno suggests,
"technically infeasible".  Andy points to one possibility.  There are clearly
others.  Lisp and Smalltalk systems have been doing this for years so we know
it can be done. (We're talking existence, folks, not efficiency.)

My other objection was that the XDS/XOM user will be presented with a
different "standard compliant" interface by each vendor *AND* it is left as an
exercise for the user to "impedance match" between them.  This is not a
standard by any definition I know.  The vendor gets to declare POSIX standard
compliance and the the user has been left with the task of defining and
implementing a common interface on top of different vendor-specific
implementations.  Huh?  (Unless, of course, the user only uses one vendor but
in this case we have a degenerate standard ... one thing is always exactly
like itself whatever the thing is!).

Interestingly, P1003.17 and P1224 are being driven by X/Open.  X/Open's
own Long Term Vision states:

    "An environment in which users have access to all of the information
     needed to carry out their job, without contstraints imposed by
                                        ===============================
     incompatibility of technology or data."
         =====================================

But, vendor incompatibility is exactly what XOM provides.  Thus, I seems to me
that the base technology that X/Open is trying to hustle through POSIX (XDS
and XOM) violates its own charter never mind the spirit of POSIX.

Actually, I wouldn't be worrying so much if XOM were just a bunch of helper
routines at the bottom of XDS and X.400.  But the fact is that name space
management (threads, files, you name it) is the name of the game.  XOM could
be trotted out as a good way to manage names everywhere in POSIX and indeed it
might be.  But not if it locks names away in lots of little bunkers to which
only the vendors have the keys.

                            Cheers, Scott


Volume-Number: Volume 24, Number 14

From [e-mail]  Thu Jun 20 20:03:00 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA02949; Thu, 20 Jun 91 20:03:00 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09181; Thu, 20 Jun 91 20:02:42 -0400
Newsgroups: comp.std.unix
From: Shane McCarron <[e-mail]>
Subject: Re: P1003.17
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]>;
Date: Thu, 20 Jun 1991 11:56:20 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Shane McCarron)

> Andy Hume fairly summarizes part of my objection to the tack that P1003.17 and
> P1224 are taking with respect to objects; viz. that vendors can extend whereas
> users cannot.  I agree with Andy that extension is not, as Ezno suggests,
> "technically infeasible".  Andy points to one possibility.  There are clearly
> others.  Lisp and Smalltalk systems have been doing this for years so we know
> it can be done. (We're talking existence, folks, not efficiency.)

Note that the XOM interface is NOT an object management interface
(regardless of what the title says).  It is just a set of interfaces
for manipulating opaque data types across a network of heterogeneous
systems.  If you called it XDR you wouldn't be far from correct.
Certainlky XDR is extensible, so logically XOM could be too.  However,
XOM isn't designed to be extensible, and XDR is.  XOM is designed to
solve an extremely specific problem - and by all accounts it solves
that problem.

> My other objection was that the XDS/XOM user will be presented with a
> different "standard compliant" interface by each vendor *AND* it is left as an
> exercise for the user to "impedance match" between them.  This is not a
> standard by any definition I know.  The vendor gets to declare POSIX standard
> compliance and the the user has been left with the task of defining and
> implementing a common interface on top of different vendor-specific
> implementations.  Huh?  (Unless, of course, the user only uses one vendor but
> in this case we have a degenerate standard ... one thing is always exactly
> like itself whatever the thing is!).

I don't understand this contention.  It is impossible to present a
different standard compliant interface  - the language bindings are
the standard, and they are being specified by the committee.  Also,
note that the XOM activity is NOT a POSIX standard.  Frankly, the XDS
activity shouldn't be either, but we haven't fixed taht yet.  XOM is
P1224 - only P1003 committees are POSIX.

> But, vendor incompatibility is exactly what XOM provides.  Thus, I seems to me
> that the base technology that X/Open is trying to hustle through POSIX (XDS
> and XOM) violates its own charter never mind the spirit of POSIX.

Again, I don't understand this.  The underlying protocols for XDS are
defined by X.500, so communication between machines will work.  XOM
just provides interfaces to encode C language specific data types in
ways that are compatible across the network (unless I am very much
mistaken - that happens sometimes).

> Actually, I wouldn't be worrying so much if XOM were just a bunch of helper
> routines at the bottom of XDS and X.400.  But the fact is that name space
> management (threads, files, you name it) is the name of the game.  XOM could
> be trotted out as a good way to manage names everywhere in POSIX and indeed it
> might be.  But not if it locks names away in lots of little bunkers to which
> only the vendors have the keys.

XOM will never be promoted as a generalized namespace manager,
especially not for things within POSIX.  It is not a POSIX service.
Generalized namespace management will have to wait for some
interesting consortia based work to mature (e.g. DCE).

--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]


Volume-Number: Volume 24, Number 15

From [e-mail]  Thu Jun 20 20:17:09 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA05782; Thu, 20 Jun 91 20:17:09 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12365; Thu, 20 Jun 91 20:17:01 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 19 Jun 1991 20:05:26 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Sean Eric Fagan) writes:
> have all "illegal" symbols be "safe" (__select, for example).  All library
> routines are written to use the __ names; then, you have the linker accept
> an option that tells it to try to ignore the leading __ if there are
> unresolved externals.

You could implement this simply by having the library contain duplicate
symbol table entries for __x and x, with the same offset. You could
handle it in a separate pass after compilation before creating the
library. No extra work should be needed in the librarian, compiler, or
linker!
--
Peter da Silva; Ferranti International Controls Corporation; [phone];
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"


Volume-Number: Volume 24, Number 16

From [e-mail]  Sun Jun 23 20:48:00 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA12422; Sun, 23 Jun 91 20:48:00 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28824; Sun, 23 Jun 91 20:47:48 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Report on POSIX.17 - Name Space/Directory Services
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Sun, 23 Jun 1991 23:48:17 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on POSIX.17 - Name Space/Directory Services


Mark Hazzard <[e-mail]> reports on the  meeting
in Chicago, Illinois:

Summary

The POSIX.17 group is generating a user to directory services API, for
example an API to an X.500 Directory User Agent (DUA).  We are
referring to a network idea of a directory, not the ``file which
contains file entries'' defined in POSIX.1.  It is not limited to just
the X.500 functionality. We are using XAPIA - X/Open's Directory
Services specification (XDS) as a basis for work.  XDS is an object
oriented interface and requires a companion specification for object
management (XOM).

XOM is a stand-alone specification with general applicability beyond
the API to directory services.  It will be used by IEEE 1224.1 (X.400
API) and possibly other POSIX groups, and is being standardized by
IEEE 1224.

We made significant progress on a third draft of the document in
Chicago, with the language independent specification work still to be
done. We hope to mock ballot the document sometime after the July
working group meeting.  POSIX.12 (Protocol Independent Interfaces) and
POSIX.17 worked together this week and arrived at a number of
scenarios for coordinating the work. POSIX.17 is taking steps to
determine if their work overlaps with the proposed work of certain
ISO/SC21 (OSI) working groups.

Status

Commitment within the group remains adequate, but there's more than
enough work to go around.

Chris Harding, our Technical Editor (from X/Open), brought a second
draft of the specification to the meeting.  We made significant
progress towards producing a third draft with emphasis on format
cleanup, model, overview sections and test assertions.

The ``homework'' assignments on Language Independent Specification
(LIS) weren't completed and additional work on LIS was put on hold
until the outcome of the SEC meeting.  There seemed to be some
confusion as to the applicability of the LIS requirement for POSIX.17
and other Distributed Services APIs.  The SEC reaffirmed the LIS
requirement.  The LIS work was reassigned to the Technical Editor.

The big debate on generalizing the Object Management API never
materialized.  (Refer to the three snitch reports on the New Orleans
1991 meeting.) I strongly suspect this was largely due to the absence
of Scott ``Owls in the bushes'' Guthrey at the Chicago meeting.

Requirements from POSIX.12

The group met with POSIX.12 (Protocol Independent Interfaces) to get
their requirements for the POSIX.17 API.  They expressed the desire
(necessity?) to:

   - access existing directory services (e.g.  DNS) via the
     POSIX.17 API

   - map the existing BSD API (e.g. gethostbyname,
     getservbyname, etc.) onto the POSIX.17 API.

We discussed at length how these and other requirements should best be
met, and produced three different scenarios describing relationships
between the user application, the directory API(s), the directory
service(s) and the transport service (accessed via POSIX.12's
Simplified Network Interface).

In the first scenario, the transport provider (SNI) would talk
directly to all directory services e.g.  DNS, X.500, etc.  Each
directory service resolver would be accessed through its native
interface, of which POSIX.17 would be just another API.

In scenario two, POSIX.17 would be the only API and would be used to
access all directory services.  To access a non- X.500 DUA, the
underlying implementation might have to translate POSIX.17 calls into
the appropriate format and invoke the corresponding resolver.

In the final scenario, POSIX.17 would again be the only API, but only
one resolver (X.500 DUA) would be used to query a single composite
information base (DIB) containing information on all objects (e.g.
DNS Resource Records and X.500 Distinguished Names).

In each of the scenarios, impact to the POSIX.17 API will be minimal.
However, significant impact is anticipated for the underlying
implementation and directory information base.

We discussed the relative merits of each and decided that at some
future time a single API, resolver (agent), directory service and
information base just might be the best for POSIX systems.  We also
recognized that POSIX systems will need to interoperate with non-POSIX
systems for the foreseeable future, and that fact won't be lost on
implementors.

Live long and prosper! or Extending the life of our standard

The base document defines both the API and the collection of objects
managed through the API, called a ``package.''

We believe that packages will be much more dynamic than the API
itself, and could be unbundled from the API to give the API greater
stability.  We actioned the Distributed Services Steering Committee
(DSSC) to recommend a common solution, as this problem is shared by
other networking groups.  We expect the DSSC to take this issue up in
Santa Clara.

Mock Ballot

We decided to try to mock ballot our document sometime after the July
meeting. After reaching agreement on the minimum document content for
mock ballot, we assigned actions to get this work done.  We wish to
solicit input on requirements and feedback on our LIS and Test
Assertion work.

Is SC21 doing APIs too?

With the granting of any IEEE project request (PAR) comes a
responsibility to coordinate with other de jure standards bodies, the
list of which is included on the PAR itself.  In fulfilling this
obligation, the group has learned (and dutifully reported to the SEC)
that ISO SC21 is considering working on APIs to OSI application level
services.  This work has a potential to overlap the SC22 supported work
being done by IEEE TCOS/POSIX (e.g.  POSIX.17, P1224, P1238).

In Closing ...

The group made good solid progress in Chicago, and our document is
beginning to ``flesh out.'' We think we understand what's required for
test assertions and language independence, and have done several
things to make the base document more readable.  If we can maintain
``critical mass'' within the group, we have a good chance of going to
mock ballot yet this year.  There's a lot of work to do, so if anyone
out there can make it to Santa Clara in July ...











Volume-Number: Volume 24, Number 17

From [e-mail]  Sun Jun 23 20:48:32 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA12458; Sun, 23 Jun 91 20:48:32 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28855; Sun, 23 Jun 91 20:48:04 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Report on POSIX.4, .4a, .4b, .13: POSIX Realtime Extensions
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Sun, 23 Jun 1991 23:49:11 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on POSIX.4, .4a, .4b, .13: POSIX Realtime Extensions


Bill O. Gallmeister <uunet!lynx!bog> reports on the April
15-19, 1991 meeting in Chicago, IL:

Summary

This week, the working group advised the technical reviewer for IPC
Message Passing to either delete or severely prune back the IPC
chapter.  The large group also agreed to work closely with the
POSIX.12 sockets group on their interface to ensure that a ``Real-Time
Protocol,'' could be implemented on top of sockets to meet real-time
message passing requirements.

Work was done to harmonize POSIX.4 binary semaphores and POSIX.4a
(Threads) mutexes and condition variables.  A mutex is a lock
semaphore, so that only one person has access to a resource at a time
- MUTually EXclusive access.

We also began to explore work for POSIX.4b (the Yet More Real-Time
proposal).  Work here possibly includes the Ada Catalogue of Interface
Features and Options (CIFO).

Work continued on the Application Profiles, Test Assertions, and the
Language Independent Specification.

There will probably be a new recirculation of POSIX.4 before the Santa
Clara meeting.  POSIX.4a will probably not be recirculated before then.

Report

IPC

The IPC chapter in POSIX.4 is a bone of contention.  In my estimation,
it retains the largest number of unresolved negative ballots in all of
POSIX.4.  Most objections center on the fact that the interface
doesn't look much like anything seen in UNIX before, and on doubts
that the interface can be implemented efficiently.

A small group spent this week looking at IPC and ways to deal with
it.  They came up with some startling recommendations.  First, they
noted that the sockets interface, which most of us are familiar with
from BSD, is currently undergoing standardization by POSIX.12 (Protocol
Independent Interfaces).  They noted that all the needs of real-time
and transaction-processing IPC could be met by a new sockets protocol,
perhaps with a few extensions to the sockets interface itself.  There
are generally two socket protocols on a UNIX system: the UNIX domain
protocol, which communicates with other processes on the same machine,
and the Internet protocol, which does the network thing.  A real-time
protocol would be akin to these.  The small group recommended that we
work with POSIX.12 to ensure that such a real-time protocol could be
defined.

In addition, they made specific suggestions for trimming back the
current IPC chapter, if it is not removed altogether.  These
suggestions included removing non-copy IPC modes and some of the more
baroque asynchronous modes of the interface.  Another option would be
to delete the POSIX.4 IPC chapter entirely and await POSIX.12 sockets
and a real-time extension on top of that-probably a three-year wait.

The votes, when taken, were 17-5 in favor of deleting the chapter, and
29-2 in favor of trimming the chapter severely.  However, when given
the choice of deleting POSIX.4 IPC or pruning it, the vote was 21 to
15 in favor of deleting, and only two working group members admitted
that they would ballot against the draft if IPC was removed.

Synchronization

POSIX.4 specifies a binary semaphores interface; POSIX.4a (Threads)
specifies mutexes and condition variables.  These two facilities,
while rather similar in the abstract, are quite different in the
current drafts.  A group attempted this week to bring the two closer
together.

Mutexes and condition variables are based in the memory of the
process, while binary semaphores are accessed via an opaque object
that might be a memory address, but might not.  It had been noted in
New Orleans that POSIX.4 binary semaphores worked between threads in a
process, but that thread mutexes and condition variables did not work
between separate processes.  This lack of parity has been the source
of many ballot objections to both POSIX.4 and POSIX.4a.

The small group came up with a model of how synchronization was
expected to work in the vast majority of cases.  Mutexes, condition
variables, and binary semaphores are all implemented in user memory,
much like how thread mutexes are currently implemented.  In addition,
an extension to this implementation allows the memory-based
implementation to operate in shared memory between processes.


Because some machines (such as Crays) do not possess the hardware for
memory sharing, a more abstract interface to process synchronization
is required.  (Those machines will not implement binary semaphores
like most other people, but will do something different.)

The working group approved a number of small changes to harmonize
POSIX.4 and POSIX.4a with regards to process and thread
synchronization based on this model.  The working group also demanded
some documentation explaining the different models and requirements
motivating the different facilities and interfaces.  Hopefully, such
documentation will clear up the confusion currently surrounding the two
interfaces.

POSIX.4b

POSIX.4b has as its goal the standardization of some of the less
mainstream features of real-time systems.  These are basically areas
that the POSIX.4 group decided to defer until ``later.'' During this
meeting, small groups worked on interfaces for timeouts on all
blocking system calls, for enhanced memory allocation, and for direct
application use of interrupts.  The documents for all three of these
areas are quite immature, and the small groups spent their time trying
to identify models and requirements.  I believe the first draft of
POSIX.4b will be generated in Santa Clara.  Other possible work items
for this proposal include extensions to the existing synchronization
primitives, and the Ada Catalogue of Interface Features and Options
(CIFO).

The timeouts group received some conflicting advice.  Many people do
not want this interface at all.  Of those who did, there was strong
consensus for new function calls for each blocking call, i.e., we'd
have timeout_read(), which could time out after a certain interval of
time, since read() is a blocking call.

The memory allocation group is concerned with being able to allocate
from specific pools of memory-memory presumably having some special
characteristic.  They were directed to see whether mmap(), from the
Shared Memory and Mapped Files chapter, would suit the requirements.

The interrupt access group came up with a model something like signal
handlers for attaching a process directly to an interrupt.  Additional
semantics of the interface still need to be defined, (e.g. can system
calls be made from a user ``interrupt handler.'')

Application Profiles

The real-time applications profiles group is well on its way to
producing a draft which defines multiple profiles: an embedded
profile, a profile one up from that, a mid-size profile, and a kitchen
sink profile.

The kitchen sink profile is easy: it includes everything.  At the
lower layer is an embedded profile which will hopefully be very
small.  It specifies the threads interface, but would like to not
include the process interface, i.e. no fork or exec.  It has read,
write, and open, but no other file interface.  The target for such a
system would be an embedded system, perhaps without an MMU.  Much of
POSIX.1, and in fact much of POSIX.4, is irrelevant to such a system.
The largest area to be addressed now is the ability to remove pieces
from POSIX.1 (i.e., fork() and exec()) and still have a ``POSIX''
system. POSIX.1 is not set up to allow such selective removal of
interfaces.

Test Assertions and Language Independent Specifications

Small groups (of one each) continued to work on the test assertions
and the language independent interfaces for POSIX.4.  Not much
progress was made, due to the pressing requirements of other issues
and the fact that much of this work is best done late at night hunched
over one's terminal.  This work will continue and should be more
advanced at the Santa Clara meeting.
































Volume-Number: Volume 24, Number 18

From [e-mail]  Mon Jun 24 15:18:37 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA22259; Mon, 24 Jun 91 15:18:37 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29513; Mon, 24 Jun 91 15:18:27 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: Report on POSIX.4, .4a, .4b, .13: POSIX Realtime Extensions
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]>
Date: Mon, 24 Jun 1991 17:29:45 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter da Silva)

There are two points in this report I'd like to comment on, one of which is
a request for further information.

In article <[e-mail]> [e-mail] (Peter Collinson) writes:
> The large group also agreed to work closely with the
> POSIX.12 sockets group on their interface to ensure that a ``Real-Time
> Protocol,'' could be implemented on top of sockets to meet real-time
> message passing requirements.

ARGH!

Yes, yes. I understand the reasoning. The IPC doesn't look very UNIXish. It
does, however, look very real-time-ish. Sockets don't.

IMHO, in any case, sockets don't look very UNIX-ish either.

> The timeouts group received some conflicting advice.  Many people do
> not want this interface at all.  Of those who did, there was strong
> consensus for new function calls for each blocking call, i.e., we'd
> have timeout_read(), which could time out after a certain interval of
> time, since read() is a blocking call.

What's wrong with using a conventional event-flag/signal and multi-way-wait
interface, with timers being one of the events to wait on? That would solve
the problem, and file descriptors could be used as the flag identifiers.
--
Peter da Silva; Ferranti International Controls Corporation; [phone];
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"


Volume-Number: Volume 24, Number 19

From [e-mail]  Tue Jun 25 18:04:04 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA29174; Tue, 25 Jun 91 18:04:04 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14815; Tue, 25 Jun 91 18:03:48 -0400
Xref: kithrup comp.std.unix:235 comp.org.ieee:192
Newsgroups: comp.std.unix,comp.org.ieee
From: "Stephen R. Walli" <speaker!stephe>
Subject: TCOS Rules&Regs and IR Voting
Message-Id: <[e-mail]>
Followup-To: comp.org.ieee
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 25 Jun 1991 03:36:34 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

There's a Mini Ballot attached to the latest circulation of the TCOS/SSC
Operating Procedures. It has to do with the removal of voting privileges from
the Institutional Representatives. I'm posting this set of ponderings because
I want to understand why IRs shouldn't have voting privileges. I need some
education here.

- I don't like the fact that they recast the current voting situation into a
  "no" vote situation in the text, then asked for guidance.

- Let's look at the IRs.

  USENIX, Uniforum, EurOpen, GUIDE, DECUS
  ---------------------------------------
  There are user groups which for the most part are financially accessible to
  the average technical person, regardless of their employer, in a similar
  way to the IEEE and IEEE/CS.

  X/Open, OSF, UI
  ---------------
  There's the vendor consortia. These are not-for-profit (revenue neutral,
  non-profit, etc.) organizations with membership fees WELL outside of the
  individual. The high cost of membership provides members with a different
  set of benefits, such as early access to source code of the products
  built by these organizations. (I realize this doesn't apply to X/Open. I'm
  not sure what the return for their high cost of admission is.)

  IRs represent both user communities and vendor (producer) communities.
  This fits the multiple viewpoint policy of balloting groups within the
  IEEE.

- TCOS/SEC is responsible for the business/financial side of the standards
  budget, and the creation and policing of WGs and Steering Committees. The
  IRs represent their communities (vendor and user) at the policy level the
  same way that individual members represent those viewpoints at the technical
  level within a WG. This is why IRs should be voting members. It is a
  continuation of the open standards process that is a pillar of the IEEE
  standards platform.

  (Chairpeople are responsible for their individual projects, and are not
  responsible for TCOS/SEC policy co-ordination with their WG.)

- The "Them" (IRs) outnumbering "Us" ("... individual professional members
  of the IEEE...") phrasing in the Mini Ballot is a little inflamatory.
  My guess is that most of the IRs are members of the IEEE anyway, since
  they are involved and are probably balloting members. I would
  hope there isn't a suggestion that IRs are unprofessional in this statement.
  There are by my count, 17 chairpeople, plus 4 steering committees, plus
  TCOS/SEC officers. There are 8 IRs. The proliferation of project WGs and
  necessary steering committees seems to be faster than new IR acceptance.
  Besides, it's not a numbers game.

- This next point does not involve the IR voting status, but illustrates a
  point. Somewhere along the line, it was decided that IRs with the ability to
  ballot draft documents would receive "special" status. While their ballots
  do not weigh any heavier for consideration, their names are published
  seperately at the front of the standard as IRs. Somewhere in the standards
  acceptance heirarchy, people feel it is important to draw attention to these
  institutions in the acceptance of the standard. It somehow seems
  inappropriate that they do not carry voting weight within the policy world
  of TCOS/SEC.

So what am I missing? Why shouldn't IRs have the vote?

Disclaimer:
The above opinions are strictly my own, and since I work for myself, they
also represent my company's. People still love to disagree with them and
correct them along the way.
+-----------------------------------------------------------------------------+
Stephen R. Walli                               SRW Software
phone: [phone]                          572 Foxrun Court,
fax:   [phone]                          Oshawa, Ontario, Canada,
speaker![e-mail]   -OR-                  L1K 1N9
uunet!watmath!mks!speaker!stephe
+-----------------------------------------------------------------------------+

[ Note followup's, please -- mod ]

Volume-Number: Volume 24, Number 20

From [e-mail]  Tue Jun 25 18:04:39 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA29273; Tue, 25 Jun 91 18:04:39 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14897; Tue, 25 Jun 91 18:04:08 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Report on POSIX.7: System Administration
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Tue, 25 Jun 1991 18:39:08 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
1003.7: System Administration


Martin Kirk <[e-mail]> reports on the April 15-19,
1991 meeting in Chicago, IL:

Summary

POSIX.7 is getting back on its feet again, having come through a rocky
period in its history. The Project Management Committee (PMC) has
reviewed the project and recommended that it be split into a number of
sub-projects, organized by POSIX.7. Likely candidates are print
management, software management and user environment management.

Report

The April 1991 POSIX meeting in Chicago may turn out to be the final
step in the rehabilitation of the POSIX.7 Systems Administration
working group.

Probably as a result of its occasionally controversial past, POSIX.7
was among the first batch of working groups to be reviewed by the
newly created Project Management Committee (PMC).

It is possible to speculate on whether POSIX.7 would have met the
PMC's project approval criteria had it been in existence two years
ago.  One of the most pertinent criteria would probably have been the
existence of a suitable base document.  A likely candidate would have
been the NIST proposed draft System Administration document, though it
might have been difficult to demonstrate the right kind of consensus
around it!

Anyway, the PMC was not in existence then and POSIX.7 was duly
created.  The first couple of meetings were spent investigating the
possibility of standardising the existing systems administration
commands that we all know and love.  The working group decided that
there was little benefit to be gained from solving the single machine
problem in a world that was rapidly moving towards a norm of
heterogeneous networks, and set off on its trek into the rather more
esoteric realms of object-oriented systems management for networks of
heterogeneous machines.

Inevitably this change of direction led to charges that the group was
inventing hand-over-fist, rather than following the ``traditional''
standards model of codifying existing practice.  (No-one ever argued
that the group had gone beyond its scope, which was cunningly worded
to allow the group to do almost anything).

Moving into the world of distributed systems management opened up
various cans of wriggling things with labels like ``interoperability''
and ``frameworks.'' (This was when I discovered that ratholes were
full of worms).  It was at this point that an over-enthusiastic
embracing of object- oriented concepts led to the promulgation of a
command line interface that was tremendously orthogonal, but completely
different to all known existing practice.

Interoperability proved to be a particularly thorny problem.
Everybody could agree that it was essential, but there was no emerging
consensus as to how it would be achieved.

In hindsight, this was the lowest point of POSIX.7's fortunes.  From
this point the rehabilitation commenced.  The first stage was an
agreement among the group to limit the scope of its activities (but
not its objectives).  The group decided to concentrate on two
particular aspects, the definition of the managed objects required for
systems management, and the definition of management tasks - the
administrator's view of the job in hand.  This decision allowed the
group to close the door on the ratholes and concentrate on areas where
it was able to make progress.

Part of the motivation for this decision was recognition that the
problem space is vast and that trying to attack it over too large a
front was a suicidal manoeuvre.  There was also an increased awareness
of the related work of other organizations, such as the OSI Network
Management Forum, the OSI Implementer's Workshop Network Management
SIG, and X/Open.  As this other work comes to fruition, it will be
available for use by POSIX.7 and will likely solve some of the
thornier problems, such as interoperability.

So what happened in Chicago to raise hopes that the rehabilitation is
almost complete?  For some time the group had been aware that some
functional areas were much closer to reaching a consensus than others,
and it had been considering how it might better organize the work in
order to ``get something out of the door.'' The result of the PMC
review of POSIX.7 was a recommendation that the existing project
should be split into a series of sub-projects, each representing a
functional area within the overall problem space, and each leading to
a separately balloted document.  The existing project would be
retained as an ``umbrella'' to handle the co-ordination issues arising
from the split.

This is necessary if the parts are to form a coherent whole.  New
projects would be raised to cover a first set of functional areas.  No
more than two or three of these functional sub-projects would be
active at any time. This would keep the group focussed on a set of
limited and achievable goals.  New projects would be instantiated as
existing ones move into the balloting phase.

One of the benefits of this approach is that each of the new
sub-projects must pass the PMC's project approval criteria before it
is recommended.  The proposal will be properly scrutinized to ensure
that the project is likely to succeed within reasonable timeframes.  A
result of the earlier decision to concentrate on managed objects and
management tasks will be to relate the new projects much more closely
to existing interfaces, thus removing one of the rods which the group
had fashioned for others to beat it with.  An obvious source of
candidate management tasks can be found in the existing administrative
command set on the systems around us, and it would be a perverse
decision indeed to introduce gratuitous changes to the style of that
interface.

The first set of sub-projects are likely to be Print Management,
Software Management, and User Environment Management.  These three
represent areas where the work of the group is well advanced and where
there is strong commitment of energies.

The Print Management work is based on the MIT Palladium printing
system, which has the benefit of being well-aligned with the emerging
ISO distributed printing standard, DIS 10164.  The Print Management
sub-group within POSIX.7 has been working with the Palladium documents
for over a year and this work is probably the closest to being
complete.

Software Management has enjoyed a resurgence of interest within
POSIX.7 over the last 6 months, with source material being drawn from
DEC, HP, AT&T and Siemens-Nixdorf.  The small group that has been
working in this area has been comparing the various technologies and
(not surprisingly?)  finding a great deal of commonality between then
in terms of their underlying concepts and functionality.  The task of
identifying a common model and a common set of functions is well
advanced and bodes well for the future.  (Indeed, the rate of progress
is positively alarming!)

The third area, User Environment Management is a logical candidate for
inclusion in the initial set of sub-projects.  Much of systems
management is concerned with the management of users and their
interactions with other components of the system.  Many management
tasks need to be able to refer to users and it seems to be appropriate
to tackle this area at an early stage.  (For some inexplicable reason,
the ``add user'' operation seems to be the universal example always
brought up when talking about some aspect of systems administration -
another motivating factor.)

Looking beyond the confines of POSIX.7 into the wider world, the
original decision to adopt an object-oriented approach to the problem
of systems administration is at last being vindicated.
Object-oriented concepts lie at the heart of the OSF Distributed
Management Environment request for technology (RFT), the UI Systems
Management SIG and the X/Open Systems Management working group.  It
looks as if history will show POSIX.7's decision to have been a far-
sighted move rather than turning up a blind alley.

[The above opinions do not necessarily represent those of the IEEE, my
employers, or even myself!].











































Volume-Number: Volume 24, Number 22

From [e-mail]  Tue Jun 25 18:04:55 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA29313; Tue, 25 Jun 91 18:04:55 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14902; Tue, 25 Jun 91 18:04:09 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Report on P1224: X.400 API
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Tue, 25 Jun 1991 18:35:54 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on P1224: X.400 API


Steve Trus <[e-mail]> reports on the April
15-19, 1991 meeting in Chicago, IL:

Introduction

P1224 is the IEEE working group standardizing an application program
interface (API) for X.400 and also for a companion, OSI Object
Management (OM).  The work will result in two documents.  Interfaces
developed by the X.400 API Association and X/Open have provided the
basis for the standards.  The X.400 API consists of two parts: an
application interface and a gateway interface.  Both of these are
based on the 1988 CCITT X.400 Series of Recommendations.

The P1224 working group has the following officers:

   - Steve Trus, Chairman (NIST)

   - Tim Carter, Vice Chairman (IBM)

   - Iain Devine, Technical Editor, Secretary (X/Open)

The Chicago meeting was very productive for the P1224 working group.
We have been gaining momentum over the past three meetings, and are
well under way to producing an IEEE standard.

The goal of the group is to have a draft of the X.400 API and the
Object Management APIs by the July meeting, and to ballot the
documents after the October meeting.

Report

At the Chicago meeting the group continued modifying the base
documents to produce the draft API documents for ballot. This work
includes:

  1.  editing the documents to meet the style and format
      requirements of the IEEE,

  2.  adding a language independent specification of the
      interfaces to the documents, and

  3.  developing the required conformance test assertions.

The language independent specification of the Object Management API is
complete, and the technical editor has made most of the required style
changes. These changes will be complete and the language independent
specification will be incorporated into the document by the July
meeting.  Work on the style modifications to the X.400 document will
also be complete by the July meeting.  The X.400 language independent
specification should be complete and incorporated at this time.

The group spent most of the week developing the required test methods
for the Object Management Specification.  A representative of the Test
Methods working group (POSIX.3) assisted us with this development.
Members of the group agreed to develop test methods for functions
assigned to them by the next meeting.  This task will need to be
completed before the complete ballot of the document.

Balloting Plans

We discussed balloting plans and we would like to begin balloting the
Object Management Specification and the X.400 API in October.  These
ballots would not include the test methods, and balloting cannot
complete without them.

We are developing the list of people who will be invited to ballot
these documents, along with the IEEE formed balloting group.  This
list will include the X.400 API Association, X/Open Limited, the NIST
X.400 Workshop, and the Electronic Mail Association.

PAR Restructuring

The original Project Authorization Request (PAR) for the P1224 group
was written when the baseline document contained an X.400 gateway API
and the related OSI Object Management specification.  Currently, the
X.400 API document contains the user agent interfaces, the gateway
interfaces. The OSI Object Management specification is contained in a
separate document.  To accommodate these changes a revised PAR was
written at the January meeting for the X.400 API, and a new PAR was
written for the OSI Object Management specification.  These PARs were
approved by the IEEE TCOS SEC at this meeting.

In Closing ...

P1224 is making good progress. Homework assignments were delegated at
the Chicago meeting to be completed by the Santa Clara meeting.  The
primary focus of the Santa Clara meeting will be to review the Draft
X.400 and Object Management APIs, and to continue working on test
methods for the interfaces.



























































Volume-Number: Volume 24, Number 21

From [e-mail]  Tue Jun 25 18:05:10 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA29432; Tue, 25 Jun 91 18:05:10 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15065; Tue, 25 Jun 91 18:04:38 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Report on 1003.3: POSIX Test Methods and Conformance
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Tue, 25 Jun 1991 18:53:47 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on 1003.3: POSIX Test Methods and Conformance


Andrew Twigger <[e-mail]> reports on the April 15-19,
1991 meeting in Chicago, IL:

Summary

The POSIX.2 (Shell and Utilities) working group made good progress
writing test assertions this week, with POSIX.3's (Test Methods and
Conformance) help. Many working groups, however, are discovering that
writing test assertions requires a non-trivial effort. This week also
saw the delivery of the newly published ``IEEE 1003.3-1991 - Test
Methods for Measuring Conformance to POSIX''. Concerns are still being
raised over NIST's certification policies.

Report

Chicago will probably go down in history as the meeting where test
methods invaded the POSIX working groups with a vengeance.  After
years of mild abuse and jesting (mostly aimed at NIST), the SCCT
(Steering Committee on Conformance Testing) seems to be succeeding in
the goal of ensuring that POSIX standards are balloted with test method
specifications.  Despite rumours during the week that a wake had been
arranged for the SCCT Chair, most of the screams were heard from
working groups, who having been previously informed that test methods
would be easy to write and would only take a couple of meetings, were
finding that this was a far from straightforward task.

While most of the remaining members of the original POSIX.3 working
group continued work with the remaining members of POSIX.2 in
generating assertions for the POSIX.2 standard, a few of the POSIX.3
elders started helping other working groups to develop test methods
for their standards.  The POSIX.3.2 group (i.e POSIX.3 + POSIX.2) met
for three days during the week and spent all of that time writing
assertions in small groups of three or four people.

Some of the more difficult aspects of POSIX.2 were tackled,
specifically Basic Regular Expressions and the Make utility.  Most of
the smaller utilities have assertions written already although most of
these need to be updated to align with the current draft.  It is hoped
that enough of the work will have been completed after the October
balloting commencing in the first half of 1992.

Other working groups that have started producing test methods include
POSIX.4, POSIX.6, POSIX.8, POSIX.15, POSIX.17 and P1224.1, P1224.2.
Most of these groups are at an early stage in their test method
development and are producing a wide variety of problems for the
``experts'' to address.  Several of these groups have noted that the
formal process of producing test assertions has uncovered a variety of
deficiencies in their drafts; so perhaps there is some benefit in test
methods after all!

The highlight of the week was the arrival of the latest of the series
of POSIX standards, IEEE 1003.3-1991.  This document was made
available at the extraordinary discounted price of $15.00 per copy,
which works out to 30 cents a page!  Still I suppose that considering
the number of committee hours that went into the document, it's a real
bargain.  (One working group member calculated an industry cost in
excess of $5,000 per page.)

Other concerns which arose during the week relate to NIST's adopted
certification policies and procedures.  Many working groups continue
to be concerned about these. This has been a long running battle
involving both accredited testing centres and implementation suppliers
in assisting NIST in the refining of their policies.

The current major cause for concern is whether there would be equality
in the certification process or whether a particular implementor would
gain advantage from receiving the first conformance certificate.  NIST
was not explicit as to the procedures that they would employ to deal
with the initial surge of certification requests, but made assurances
that everybody would be satisfied when the process was completed.
This seemed to satisfy nobody!  We'll have to wait until Santa Clara
to see whether NIST is really here to help us.


Volume-Number: Volume 24, Number 23

From [e-mail]  Tue Jun 25 18:05:17 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA29448; Tue, 25 Jun 91 18:05:17 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15075; Tue, 25 Jun 91 18:04:42 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Standards Update, X3J16: C++
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Tue, 25 Jun 1991 19:03:47 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on X3J16: C++


Mike Vilot <[e-mail]> reports on the March, 1991 meeting in
Nashua, New Hampshire:

Current Status

The ANSI X3J16 committee began its second year of technical meetings.
As expected, the work grew more detailed, with the Core Language and
Environment working groups being the focus of most of X3J16's work.

March meeting

Digital Equipment hosted the Nashua meeting.  The week's major
activities focused on understanding the myriad details of the proposed
clarifications and changes to the current working document.

X3J16's sub-groups focused on the key topics listed in the goals
statement developed at the March, 1990 meeting.  They worked by
electronic mail between meetings, and reported their progress.

International Concerns

Steve Carter, of Bellcore, presented the major international
concerns.

Due to the concerns expressed at the November meeting about conversion
to a Type I (international) X3 process, Steve came prepared with
material explaining the implications of the change.  To all
appearances, the change seems benign to the technical work of the
committee.  The change would have the positive effect of getting
international involvement.  It has the potential to delay the
development of the standard, due to the need to synchronize U.S.  and
ISO balloting.

The full X3J16 committee almost decided to vote to adopt the change,
but ran out of the quorum necessary to pass the motion on Friday
morning.

Editorial

Jonathan Shopiro, of AT&T, presented the Editorial group's
work.

The most significant change from the November version was the
incorporation of the exception handling proposal.  Jonathan also
described an editorial change that simplified the treatment of names
and name lookup, merging the concepts that had previously been treated
under the topics of dominance and name hiding.  Martin O'Riordan, of
Microsoft, questioned whether this was a purely editorial change, or a
change to the language semantics.  Martin and others reqeusted time to
look over the change before agreeing to it.

As I mentioned last time, the person who volunteered to edit the
Rationale document has not been heard from since last summer.  Susan
Waggoner, of USWest, has taken on that responsibility.

Formal Syntax

James Roskind, an independent consultant, presented the work
of the Formal Syntax group.

The bulk of the discussion concerned a proposal by Reg Charney of
Program Conversions, Inc. to rename the non- terminals in the
grammar.  Although there was much discussion about the virtues of
regularizing the naming versus the evils of gratuitous changes, the
committee decided, in the end, to adopt the proposal.

Eric Krohn, of Bellcore, presented the syntactic ambiguities involving
the newly-adopted throw-expression syntax for exceptions.  The
discussion clarified the issues, and a final resolution is likely next
meeting.

Tom Penello, of Metaware, gave an interesting presentation on the
inherent problems with ambiguous grammars.  He established the fact
that an ambigous grammar makes the question of a conforming
implementation undecidable.  He also illustrated that arbitrary rules
to resolve grammatical ambiguities has the side-effect of rejecting
valid programs.

He then went on to explain the syntactic ambiguities of the template
syntax, arising from the conflict over using the ``>'' symbol as both
a relational operator and a template argument list delimiter.
Although he proposed a grammar rewrite that solved the problem, he
decided not to recommend it on aesthetic grounds.

There seems to be an appreciation within X3J16 as a whole for the
technical issues involved in making the grammar correct.  There also
seems to be a sentiment in favor of letting the semantic rules settle
most of the complex issues.

Core Language

Andy Koenig, of AT&T, presented the Core Language group's
work.

Document X3J16/91-0005 describes the group's discussion about the
linkage of typedef names and anonymous classes.  The group decided it
was an Environmental issue, and handed it off to the Environment group.

The group discussed objects created under a condition, and resolved to
consider those objects governed by an implicit block scope, as if the
programmer had explicitly supplied a compound statement.  Discussion
is summarized in X3J16/91- 0021.

Document 91-0019 covers the discussion of lifetimes for temporary
objects created by the compiler.  This issue has not reached closure,
although the issues were clarified.

Environment

Peter Chapin, of Vermont Technical College, presented the
work of the Environment group.

Document X3J16/91-0011 describes the group's discussion about C/C++
compatibility issues.  This discussion is continuing.

The group discussed at length the one definition rule - enforcing the
rule that a program must have exactly one definition for a given
function, even in the presence of multiple inclusions of inline
functions and the potential need for the compiler to generate such
functions out of line.  Document X3J16/91-0024 summarizes the
discussion.

There is a proposal to include a section in the standard on required
warnings.  Laura Yaker, now at Mentor Graphics, presented some ideas
of the sorts of things that might be considered as required warnings.
The discussion indicated that this is a difficult issue to
standardize, since there is so much variation in environments and
implementations.  This ongoing discussion is summarized in
X3J16/91-0014.

Another ongoing discussion concerns static initialization order for
objects in different translation units.  Document X3J16/91-0012
summarizes this discussion.

There was some discussion on specifying translation limits in the
standard.  The discussion seemed to generate more heat than light, and
nothing was decided.

Lastly, the linkage of types discussion continues, and is summarized
in X3J16/91-0023.  Peter described several alternate rules to insure
type-safe linkage of types.  A central issue is whether the linkage
specification is part of the type.  There are interesting arguments
for and against this.

Libraries

I presented the Library group's work.

There has been some progress on formulating proposals for submission
to X3J16.  Aron Insinga of DEC presented his proposal to apply
templates to the definition of the standard string class.  His
progress has been slowed by the lack of an available implementation
supporting templates.

Steve Clamage of TauMetric presented proposed resolutions for almost
all of the compatibility issues regarding the C library.  Most of the
small type insecurities can be handled in a reasonably straightforward
manner.  There are more substantial issues regarding signals,
exceptions and the facilities provided by longjmp().

The iostreams proposal continues to receive comment.  Many of the
UNIX-specific issues have been removed.  Addressing these concerns
raised an interesting point - should the C++ standard adopt the
practice of the C standard, in describing only that certain 'types'
exist, or should it describe them as classes and specify their
required operations?  There was some concern that describing classes
would be inefficient, but other concerns that the vague wording
without a class description would introduce too much variability among
implementations.

Language Extensions

Bjarne Stroustrup, of AT&T, presented the work of the
Extensions group.

The group is working through a long list of proposals for changes to
the language.  A significant number of them came from the Core
language group, due to an evaluation of what Andy Koenig calls for
changing the wording of the standard would have the effect of changing
the meaning of the language.

The current list of language extension proposals includes overloading
of the ``.'' operator, a proposal for handling national character set
issues with digraphs and new keywords, and the adoption of the
``inherited'' keyword (as in Apple's implementation).

The largest issue lurking in the Extensions category is the addition
of support for run-time type information.  There will be much
discussion on this topic over the next months.

C Compatibility

Tom Plum, of Plum-Hall, presented the work of the C
Compatibility group.

The group continued its investigation of the vocabulary differences
between C and C++.  They decided to categorize their efforts into
groups, covering the language, environment, and library.  One likely
outcome of their work will be a proposal to adopt the same model of
sequence points used by X3J11.

Next events

The next three X3J16 1991 meetings (and their hosts) will
be:

   o June 17-21, Lund Sweden (Lund Institute of Technology)

   o November 11-15, Toronto Canada (IBM)

   o March 1992, Austin TX (TI)

Zortech announced plans to host one of the other two 1992 meetings in
London.

Membership on an X3 committee is open to any individual or
organization with expertise and material interest in the topic
addressed by the committee.  The cost for membership is $250.  Contact
the chair or vice chair for details.

Chair:
   Dmitry Lenkov
   HP California Language Lab
   19447 Pruneridge Avenue MS 47 LE
   Cupertino,
   CA 95014
   + 1 [phone]
   FAX: [phone]
   email [e-mail]

Vice Chair:
   William M. Miller
   Glockenspiel, Ltd
   P.O.Box 366
   Sudbury,
   MA 01776-0003
   [phone]
   email [e-mail]
























































Volume-Number: Volume 24, Number 24

From [e-mail]  Tue Jun 25 20:48:14 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA06248; Tue, 25 Jun 91 20:48:14 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16225; Tue, 25 Jun 91 20:48:07 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: Report on POSIX.7: System Administration
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]>
Date: Tue, 25 Jun 1991 23:35:40 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Peter Collinson) writes:
>... There was also an increased awareness
>of the related work of other organizations, such as the OSI Network
>Management Forum, the OSI Implementer's Workshop Network Management
>SIG, and X/Open.  As this other work comes to fruition, it will be
>available for use by POSIX.7 and will likely solve some of the
>thornier problems, such as interoperability.

Why does it worry me that this list of related organizations does not
mention the IETF and the SNMP/MIB work -- the network-management
protocols and facilities that are in far wider use than any of the
above, with a far greater level of demonstrated interoperability?
--
"We're thinking about upgrading from    | Henry Spencer @ U of Toronto Zoology
SunOS 4.1.1 to SunOS 3.5."              |  [e-mail]  utzoo!henry


Volume-Number: Volume 24, Number 24

From [e-mail]  Wed Jun 26 02:04:07 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA26186; Wed, 26 Jun 91 02:04:07 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29404; Wed, 26 Jun 91 02:03:44 -0400
Newsgroups: comp.std.unix
From: Randall Atkinson <[e-mail]>
Subject: Re: Report on POSIX.7: System Administration
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: University of Virginia
References: <[e-mail]> <[e-mail]>,
Date: Wed, 26 Jun 1991 01:17:20 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Randall Atkinson)

In article <[e-mail]>,
  Peter Collinson <[e-mail]> writes:
>Submitted-by: [e-mail] (Peter Collinson)
>
>USENIX Standards Watchdog Committee
>Stephen R. Walli <[e-mail]>, Report Editor
>1003.7: System Administration
>
>Martin Kirk <[e-mail]> reports on the April 15-19,
>1991 meeting in Chicago, IL:

>Inevitably this change of direction led to charges that the group was
>inventing hand-over-fist, rather than following the ``traditional''
>standards model of codifying existing practice.

  Judging from comments below, they are still ignoring existing
practice in historical UNIX-derived systems in some cases.
If true, this is A Bad Thing.

>Part of the motivation for this decision was recognition that the
>problem space is vast and that trying to attack it over too large a
>front was a suicidal manoeuvre.  There was also an increased awareness
>of the related work of other organizations, such as the OSI Network
>Management Forum, the OSI Implementer's Workshop Network Management
>SIG, and X/Open.  As this other work comes to fruition, it will be
>available for use by POSIX.7 and will likely solve some of the
>thornier problems, such as interoperability.

  One would certainly hope that they are also tracking and taking
advantage of the good sized installed base that is already using SNMP
regularly.  With the draft security extensions now published by the
IETF, SNMP has a good body of real-world experience.  It would be best
if the POSIX.7 group tried to use that leverage to devise a good
standard.  This isn't an OSI vs. TCP/IP thing; they should take
advantage of the experience of both groups.

  While network management is becoming better understood, it isn't
entirely a solved problem yet and I hope the POSIX.7 folks will be
careful in what they choose to standardise.

>  An obvious source of candidate management tasks can be found in the
> existing administrative command set on the systems around us, and it
> would be a perverse decision indeed to introduce gratuitous changes to
> the style of that interface.

Not only the style but also the content.  Standardise what already
is historical practice and try to avoid inventing new features
without actual implementation and user experience.

>The Print Management work is based on the MIT Palladium printing
>system, which has the benefit of being well-aligned with the emerging
>ISO distributed printing standard, DIS 10164.

Palladium reportedly has an interface unlike those on historical
systems.  I'd much rather see lp/lpr and lprm/lpstat be standardised
as user interfaces than something unfamiliar to virtually all of
the existing users.

>Software Management has enjoyed a resurgence of interest within
>POSIX.7 over the last 6 months, with source material being drawn from
>DEC, HP, AT&T and Siemens-Nixdorf.

But is it based on historical systems ?
What kinds of tools are being standardised here ?

>The third area, User Environment Management is a logical candidate for
>inclusion in the initial set of sub-projects.

What is being managed here besides user-addition ?
Could someone give examples maybe ?

Randall Atkinson
[e-mail]





Volume-Number: Volume 24, Number 25

From [e-mail]  Wed Jun 26 23:04:39 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA25382; Wed, 26 Jun 91 23:04:39 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22362; Wed, 26 Jun 91 23:04:11 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Report on 1003.12: Protocol Independent Interfaces
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Wed, 26 Jun 1991 23:03:11 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on 1003.12: Protocol Independent Interfaces

Mike Karels <[e-mail]> reports on the April
15-19, 1991 meeting in Chicago, IL:

Summary

The POSIX.12 (Protocol Independent Interfaces, PII) working group
spent the April meeting planning strategy for its new direction and
coordinating with other groups.  The group will produce a standard
encompassing both the BSD sockets and X/Open Transport Interface
(XTI).  Liasison meetings were held with X/Open representatives, the
Name Space/Directory Services group (POSIX.17) and the Real-Time group
(POSIX.4). The group discussed language independent specification
issues with Paul Rabin.

Report

POSIX.12 (Protocol Independent Interfaces, PII) spent the April
meeting adjusting to its new direction and coordinating with other
groups.  At the last meeting, the group decided to abandon its
previous strategy of producing a new Detailed Network Interface (DNI)
with the best features of both the socket and X/Open Transport
interfaces (XTI).  XTI is derived from AT&T's Transport Level Interface
(TLI).  After reviewing input from users and vendors, the group
decided instead to produce a standard including both existing
interfaces.  In addition, the standard will include the Simple Network
Interface (SNI), which would insulate the programmer from lower-level
details.

The April meeting included discussions of the changes or additions
that were needed for the existing interfaces to become standards.  A
poll had been sent to several mailing lists and news groups, but few
concrete suggestions were received.  Most of the suggestions for
extensions have come from inside the working group.  Suggestions for
changes in sockets have come mostly from the Berkeley representatives,
and suggestions for XTI have come mainly from people active in the
X/Open technical community.

A fair amount of time was devoted to the proposal for extending XTI
option management by Gerhard Kieselmann.  The proposal allows much
more flexible option management by encoding option values with types
and lengths.  The encoding is similar to the encoding of ancillary
data in the 4.3-Reno send and receive calls.  The main point of
contention was whether the transport provider should maintain both
current settings and default settings to be used for any future
connections.

The discussions of extensions to the socket interface was confined to
a description of the recent Berkeley changes (4.3-Reno) to the socket
interface.

The meeting schedule was nearly filled with coordination meetings with
other groups.  Petr Janacek of X/Open reported on the status of future
XTI specifications.  Other than the option management proposal
mentioned above, the XPG4 version of XTI has been finalized.  It is
hoped that the XPG5 version of XTI would be aligned with the POSIX
version.  At the last meeting, POSIX.12 asked X/Open for editorial
assistance in producing a POSIX version of XTI.  Petr replied that the
budget did not allow for assistance at this time, but that an on-line
version of XTI would be made available.

Paul Rabin met with the PII group to discuss issues surrounding POSIX
language independent specifications.  The working group currently
hopes to produce a single language independent specification for DNI;
there would be two C language bindings, namely sockets and XTI.  This
should prevent the necessity of providing two interfaces for languages
other than C, but makes the language independent specification more
difficult to produce.

The POSIX.12 group also met with members of the Name Space/Directory
Services group (POSIX.17) to discuss the DNI dependency on the
Directory Services interfaces.  There are some problems in this area;
the NS/DS group currently intends to provide an interface only to the
X.500 directory service, while the PII group assumes an interface that
could include other services such as the Internet Domain Name System.
The NS/DS group intends to provide a full-featured low-level interface
to the directory service based on the X/Open X.500 API.  However, they
also plan to include simplified higher-level interfaces to answer
needs such as this one.

The final coordination meetings were with members of the Real-Time
group.  The current Real-Time draft includes an interprocess
communication (IPC) facility that many believe is too complex and does
not extend gracefully to handle networked systems.  Many hoped that
the IPC interface could be replaced by the 1003.12 interface, with
real-time extensions as necessary.  A group is working on a straw-man
proposal in time for the July meeting.


Volume-Number: Volume 24, Number 26

From [e-mail]  Fri Jun 28 01:49:02 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA07355; Fri, 28 Jun 91 01:49:02 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14738; Fri, 28 Jun 91 01:48:30 -0400
Newsgroups: comp.std.unix
From: Martin Kirk <[e-mail]>
Subject: Re: P1003.7 comments
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: X/Open Company Ltd
Date: Thu, 27 Jun 1991 13:45:13 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Martin Kirk)

Henry Spencer ([e-mail]) writes

> Why does it worry me that this list of related organizations does not
> mention the IETF and the SNMP/MIB work -- the network-management
> protocols and facilities that are in far wider use than any of the
> above, with a far greater level of demonstrated interoperability.

and Randall Atkinson ([e-mail]) writes

>  Judging from comments below, they are still ignoring existing
> practice in historical UNIX-derived systems in some cases.
> If true, this is A Bad Thing.

The intent was to convey the opposite impression. I think that
wherever possible the work will reflect existing practise.

> >Part of the motivation for this decision was recognition that the
> >problem space is vast and that trying to attack it over too large a
> >front was a suicidal manoeuvre.  There was also an increased awareness
> >of the related work of other organizations, such as the OSI Network
> >Management Forum, the OSI Implementer's Workshop Network Management
> >SIG, and X/Open.  As this other work comes to fruition, it will be
> >available for use by POSIX.7 and will likely solve some of the
> >thornier problems, such as interoperability.

>   One would certainly hope that they are also tracking and taking
> advantage of the good sized installed base that is already using SNMP
> regularly.  With the draft security extensions now published by the
> IETF, SNMP has a good body of real-world experience.  It would be best
> if the POSIX.7 group tried to use that leverage to devise a good
> standard.  This isn't an OSI vs. TCP/IP thing; they should take
> advantage of the experience of both groups.

The list wasn't intended to be exhaustive or exclusive. The issue here
is that P1003.7 is explicitly avoiding interoperability mechanisms at
the moment. Nothing in the current P1003.7 work should preclude the
use of OSI, TCP/IP, RPC, or a piece of wet string to achieve
interoperability. Of course, some care needs to be taken to ensure that
this actually is the case... At some point it will be necessary to
prduce some specification of specific interoperability mechanisms,
(presumably in the form of profiles), and at that time these should be
taken from existing practice.

>   While network management is becoming better understood, it isn't
> entirely a solved problem yet and I hope the POSIX.7 folks will be
> careful in what they choose to standardise.

The general model of using managed objects for management seems to
work. I personally suspect that as it has really only been used in a
network management environment there will probably be a need for
extensions to bring it into the systems management arena.

> >  An obvious source of candidate management tasks can be found in the
> > existing administrative command set on the systems around us, and it
> > would be a perverse decision indeed to introduce gratuitous changes to
> > the style of that interface.

> Not only the style but also the content.  Standardise what already
> is historical practice and try to avoid inventing new features
> without actual implementation and user experience.

I agree. Both the form and the function should be preserved wherever
possible.

> >The Print Management work is based on the MIT Palladium printing
> >system, which has the benefit of being well-aligned with the emerging
> >ISO distributed printing standard, DIS 10164.

> Palladium reportedly has an interface unlike those on historical
> systems.  I'd much rather see lp/lpr and lprm/lpstat be standardised
> as user interfaces than something unfamiliar to virtually all of
> the existing users.

I understanding that a mapping of lp/lpr and lprm/lpstat into
Palladium has been defined. This may be useful in providing for
transition/compatibility/subsetting.

> >Software Management has enjoyed a resurgence of interest within
> >POSIX.7 over the last 6 months, with source material being drawn from
> >DEC, HP, AT&T and Siemens-Nixdorf.

> But is it based on historical systems ?
> What kinds of tools are being standardised here ?

Software installation and removal etc. The submisssions are based on
existing vendors tools in this area.

> >The third area, User Environment Management is a logical candidate for
> >inclusion in the initial set of sub-projects.

> What is being managed here besides user-addition ?
> Could someone give examples maybe ?

Addition/Deletion/Modification of users and groups. There is an
interesting question here as to what the "user environment" should
contain - skeleton startup files, certain environment variables, etc.
The rationale for doing this first is that many other things that are
managed have relationships to users, making this a common dependency
for manyother areas. Also, for some reason, adding a user seems to be
the universal example used in system management discussions.

======================================================================
The opinions expressed above are not necessarily those of anything or
any one except me.
======================================================================

Martin Kirk    [e-mail]        Tel: [phone]

======================================================================


Volume-Number: Volume 24, Number 27

From [e-mail]  Fri Jun 28 05:49:12 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA06576; Fri, 28 Jun 91 05:49:12 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08911; Fri, 28 Jun 91 05:48:42 -0400
Newsgroups: comp.std.unix
From: Chris Harding <[e-mail]>
Subject: POSIX.17
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Data Logic, Harrow England
Date: Fri, 28 Jun 1991 07:48:41 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chris Harding)

I participate in the POSIX .17 work as technical editor and previously
participated in the production of the base document from which the
POSIX standard is being derived. I am concerned that some of the comments
which I understand Scott Guthery recently posted to comp.stds.unix may
give the wrong idea of what is going on and would like to set the record
straight.

Scott seems to have two objections:

    1)  that the "object management" mechanism used by the emerging P1003.17
    and P1224 standards is extensible by vendors but not by users

    2)  that these standards do not effectively constrain the vendor, so
    that the user must "impedence match" between different (but
    still compliant) implementations.

Although the first of these objections is untrue as stated, there is a
valid point behind it. I will come to this later. The second objection,
however, is not only wrong but is arguing against a feature which, rather
than limiting the user, actually makes the API more "open".

Let me justify this last statement.

The movement towards "open" systems arose largely from the desire of users
not to be "locked in" to vendors' proprietary implementations. The concept
evolved of an "open" system as one in which there was a standard interface
to applications programs.  An applications program written to this interface
would then be portable between different vendors' systems and the user would
no longer be "locked in".

But this, the original "open systems" concept, is actually somewhat naive,
since it (implicitly) assumes that the user will just buy one system and
write one application program to run on it. What he really wants to do is
to buy several different systems and also buy - from several different
vendors - several different software packages to run on them. The concept
of "open" system must be expanded to address these needs.

The "object management" mechanism used by P1003.17 and P1224
(it isn't really anything to do with Object Management in the sense of
Smalltalk etc. and use of the phrase is a bit confusing) provides a
standard representation of information that can be used by different
software packages running on the same system. It also allows for the fact
that different implementations may include different options from the
same standard (and how many standards are there that don't have any
options?) and for the fact that a software package may be released in
several versions, each with different features (and how many software
packages are there that don't have several versions? - only the
unsuccessful ones where nobody bought the first version). In fact, it
really addresses the issues that arise when trying to run different
software packages (possibly from different vendors) on a single system.

It is in this sense that the emerging P1003.17 and P1224 standards are
more "open" than most "open systems" standards and, far from limiting
the users, are really giving users much more freedom of choice.

Although they provide this extra flexibility, it is not true to say
that the emerging P1003.17 and P1224 standards fail to constrain the
implementation properly. They define behaviour on which the application
can rely. They force the implementation, where it provides a feature, to
provide it in an exactly and unequivocally specified way. In short,
they do constrain the implementation in the way that standards should.

Coming back to the first objection, the point at issue is, who can extend
the classes of object used by P1003.17 and P1224? The answer is, and
sensibly can only be, that the standards bodies responsible for defining
P1003.17 and P1224 are the only people who can extend them in a way that
is binding on the whole community of vendors and users.

Having said this, either a vendor or a user may also extend these classes
to describe a proprietary feature (in the case of a vendor) or a specific
requirement (in the case of a user). It is true that vendors are more
likely than users to make such extensions but there is nothing in the
methodology that would prevent a user from doing so. So (for example) the
Military might introduce some new classes of object if it wished to define
a special version of the X.400 API for Military use.

The valid point behind the objection is that the "object management"
methodology used by P1003.17 and P1224 does not have a "class" concept
with the properties of extensibility enjoyed by the "class" concepts
of Smalltalk and some other languages. This is a fair criticism.
However, the methodology does have (as I have tried to show above)
other properties which Smalltalk classes do not have and which are
far more valuable in the context of the sophisticated "open-ness"
requirements with which we now have to deal. Although it is an elegant
feature, a real need for "extensibility" has yet to be demonstrated.
Let's get the "open-ness" requirements sorted out first.
Perhaps "extensibility" can be added later.

Regards,

Chris
-------------------------------------------------------------------------
Chris Harding                   Tel:                [phone]
Data Logic                      Fax:                [phone]
Queens House                    Telex:              888103
Greenhill Way                   APIA SprintMail:    C.HARDING
HARROW HA1 1YR                  X/Open E-mail:      [e-mail]
U.K.                            Other E-mail:       [e-mail]


Volume-Number: Volume 24, Number 28

From [e-mail]  Fri Jun 28 05:49:34 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA06599; Fri, 28 Jun 91 05:49:34 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08919; Fri, 28 Jun 91 05:48:54 -0400
Newsgroups: comp.std.unix
From: Peter Collinson <[e-mail]>
Subject: Report on 1003.6: Security Extensions
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Date: Fri, 28 Jun 1991 08:12:43 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on POSIX.6: Security Extensions


Ana Maria De Alvare <[e-mail]> reports on the April
15-19, 1991 meeting in Chicago, IL:

Summary

The POSIX.6 group spent the week preparing draft 11 of their document
for internal ``mock'' ballot. They began work on their test assertions
document. The IEEE balloting group formation process is now officially
closed.

The Privilege subgroup discussed a proposal to remove the global
constant POSIX_PRIV_EFFECTIVE from the draft. The Audit subgroup will
not be able to address the portable audit format before balloting
begins, but they will define the audit trail header. The liaison group
between POSIX.6, POSIX.7 (System Administration) and the Distributed
Services groups will report back to the TCOS-SS Sponsor Executive
Committee (SEC) at the July meeting, recommending a new coordination
group be formed.

Report

The POSIX.6 group met for the entire week in Chicago. The group
concentrated their efforts on cleaning up draft 10 of the document.
The balloting solicitation process has been closed.  If you requested
to be in the balloting group, please confirm you are on the list by
calling the IEEE, Anna Kacznarek (908-562-3811).

A major action item was the creation of the test assertions document
for POSIX.6.  This will be a separate parallel document.  The
definitions and overview sections of POSIX.6 were addressed this
week.  Each subgroup will be responsible for creating the test
assertions for the document sections they are working on.  The
subgroups will maintain consistency between the test assertions and
the POSIX.6 document.  Modifications to the POSIX.6 document will
signal modifications to the test assertion document.

In the next meeting we are planning to integrate test assertion
sections from POSIX.3.1 (Test Assertions for POSIX.1) into our
document.  Dave Rogers (Data Logic) and I are co-chairing this
effort.  If you are interested in participating in the test assertion
work, please let me know ([e-mail] or 415-335-7309).

POSIX.6 will mock ballot draft 11 within the working group before
July.  We plan to review written comments to this mock ballot at the
July meeting.  If all the written comments are addressed, we will try
to ship the document for IEEE ballot after July.  We could then start
resolving the ballot objections at the October meeting.

Privileges

Secureware's VP of Marketing proposed eliminating from the standard
the system global constant, POSIX_PRIV_EFFECTIVE, which turns on/off
all the privileges already set by the process or set by the file
privileges in effect.  The system global constant can increase or
decrease the effective privilege set.

The argument against the system global constant was that when
POSIX_PRIV_EFFECTIVE is on, a privilege aware program (i.e. a trusted
application) will have effective privileges on before it uses them.
This violates the concept of least privilege, since the process
contains more privileges than it needs.  It is the responsibility of
that trusted application to turn off all effective privileges and then
turn them on one by one as it needs them.

Another argument against the global constant is that it gives the
system manager a central point to turn on/off privileges.  With the
new scheme, programs that turn ``priv_effective'' on are consciously
given permission to do so, a point that brings higher granularity.

A vote was taken and the group decided to eliminate the system global
constant, POSIX_PRIV_EFFECTIVE and use ``priv_effective'' as an
additional file privilege.  The standard now contains three privilege
sets associated with a process, (inheritable, permitted, effective)
and two privilege flags (``allowed'' and ``forced'') associated with
each privilege on a file. The two file privilege flags are:

   - Allowed - a flag associated with a file privilege that will
     authorize it to be on during the execution of that program, if
     the process possesses that privilege.

   - Forced - a flag associated with a file privilege that will be on
     during the execution of that program even if the process does not
     possess that privilege.  This allows for old setuid programs to
     continue to work under POSIX.6 without source code modifications.

The new file privilege ``priv_effective'' will turn on the process's
effective privilege set.  If your file has ``priv_effective', your
file makes effective all of the privileges that are on after
calculating ``allowed'' and ``forced'' flags against the process's
inheritable flags.

A process possesses three sets of privilege flags:  inheritable,
permitted, and effective.  For a process to access a file, the
process's effective privilege set (built from its inherited and
permitted sets) is tested against the file's privilege set. To be able
to pass a privilege from the inheritable set (from its parent
process), to the permitted set, the system will test the process's
inheritable privilege against the file's ``allowed'' and ``forced''
flags for that privilege.  If the file privilege's ``allowed'' flag is
set, then the privilege is turned on in the process's permitted set.
If the file privilege's ``forced'' flag is set, then the privilege is
turned on in the process's permitted set even if the privilege was not
inherited.

To be on in the process's effective set, the system compares the
inheritable privilege against the file's ``allowed'', and ``forced''
flags. If the process's inherited privilege is in the file's
``allowed'' set and the file's ``priv_effective'' privilege is set,
then the privilege becomes effective.  If the process's inherited
privilege is in the file's ``forced'' set and the file's
``priv_effective'' privilege is set, then the privilege becomes
effective.  In other words, to be set effective the file's
``priv_effective'' flag must be on.

Some of you might think that this scheme still gives me a trusted
application with effective privileges turned on.  The list of programs
with privileges turned on, however, is smaller than using the system
global constant.  In addition the effective privilege set is not on
for all processes.

All of this can become very confusing.  Sometimes I have trouble
understanding all of the benefits.  Every time I read the document new
questions come to mind.  Sometimes I agree and other times I don't.
Hopefully the mock ballot will call attention to any ambiguous areas
left in the draft document.

Access Controls

Both the discretionary and mandatory access control subgroups (DAC and
MAC) are ready for our internal mock ballot. The primary DAC related
changes for draft 10 concerned default access control list (ACL)
behaviour and the command
    chacl
which changes the ACL.  The MAC group had no hot issues to discuss.


1.  Audit

The Audit group finished modifying the draft and writing the rationale
for integrity protection, header flexibility, and cross references.
The group felt they cannot address the portable audit format before
balloting, however, they are planning to define the audit trail header
containing:

   - POSIX audit indicator field,

   - version ID,

   - data format indicator (type XDR, little endian, big
     endian),

   - time zone offset,

   - machine id, and

   - audit style.
The audit file format remains up in the air.

POSIX.6/POSIX.7/Distributed Services Liaison

The liaison group met on Wednesday.  Mike Ressler stepped down and I
became the chair of the group.  We discussed the status of the group
and what we should bring forward to the TCOS-SS Sponsor Executive
Committee (SEC). Everyone agreed that we have enough information to
create a report to the SEC discussing the problems we discovered and
to make recommendations.

I will present our report at the July meeting with the help of the
liaison group.  The report will include an overview of each subgroups
objectives, a list of problem areas discovered during our meetings,
and recommendations to solve these problems.  I hope that SEC acts
upon our recommendations.

One recommendation we want immediate action on is the lack of a
mechanism to ensure that one POSIX extension can interoperate with
another POSIX extension.  An example of this interoperability issue is
having POSIX.6 and POSIX.8 (Transparent File Access) on the same
system.  We are proposing a new group be formed which will check that
POSIX standards interoperate with each other or to at least document
where different POSIX extensions cannot interoperate.


Volume-Number: Volume 24, Number 29

From [e-mail]  Fri Jun 28 15:33:46 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA13215; Fri, 28 Jun 91 15:33:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20788; Fri, 28 Jun 91 15:33:39 -0400
Newsgroups: comp.std.unix
From: "Jerry M. Carlin" <[e-mail]>
Subject: Re: Report on 1003.6: Security Extensions
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Pacific * Bell
References: <[e-mail]>
Date: Fri, 28 Jun 1991 15:52:49 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jerry M. Carlin)

The BIG problem I see with 1003.6 is lack of I&A; identification and
authentication. What has been lacking for a LONG time is decent login.c,
passwd.c etc functionality including ability to develop local rules
passwords. We've seen a number of reimplementations of these functions
on the net precisely because the current ones are so bad & inconsistant.

The group has worked very hard on things that I see as having little if
any commercial usefulness such as MAC. I suppose MAC will be useful to
sell to the government but MAC is not useful to the world of applicatons,
transactions and databases.

This is like building a vault but putting no lock on the door or at least
leaving it to someone else to worry about the lock.

I'm not sure if P1003.6 committee is coming up with a horse, camel or
genetic combination but it sure has no head!
--
Jerry M. Carlin    [phone] [e-mail]
To dream the impossible dream. To fight the unbeatable foe.


Volume-Number: Volume 24, Number 30

From [e-mail]  Sat Jun 29 04:04:08 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA25522; Sat, 29 Jun 91 04:04:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03238; Sat, 29 Jun 91 04:03:51 -0400
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: Report on 1003.12: Protocol Independent Interfaces
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]>
Date: Sat, 29 Jun 1991 03:34:15 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dan Bernstein)

People interested in protocol-independent interfaces may also be
interested in UCSPI (ooks-pie), my UNIX Client-Server Program Interface
Standard. It's not a standard, of course, until enough people decide
it's worth using, but it does have implementations for BSD TCP sockets
(with optional RFC 931 support), BSD UNIX-domain sockets (with username
security), and System V named pipes (also with username security), and
I'm working on DECnet and Kerberos v5 implementations. Programs written
for the UCSPI interface will work properly, with no changes, over all of
the above communications systems.

Note that the UCSPI interface is much simpler than what I gather POSIX
is looking at standardizing. Basically, you get two file descriptors for
reading and writing to the other side, a protocol-independent record of
who the other side is, and a variable saying what protocol you're using.
It doesn't support any sort of structured data, because that wouldn't be
portable---you can't pass structured data through named pipes. Another
benefit to this hands-off philosophy is that you can use UCSPI from
shell scripts. On the other hand, if you do want to control the
communication at a low level, you can apply protocol-dependent
operations to the descriptors.

If UCSPI gains enough momentum, it might be worth making into an
official standard in a few years. Until then, I wonder why POSIX.12 is
trying to impose ``standards'' on an area where the real world has seen
neither successes nor failures. Where are the bad protocol-independent
interfaces in the history books? What do we know about putting good ones
together? Where are all the vendors supporting a protocol-independent
interface? In other words, how does POSIX.12 know it's not going to
settle on a ``standard'' which forever stands in the way of interface
research?

If POSIX.12 merely produces a formal specification of how Berkeley and
AT&T already do sockets, then the answer is clear: the industry has come
to a consensus on sockets, people use sockets, and nothing's lost by
stating the obvious. But sockets are not truly protocol-independent, and
from the report I gather that the group aims to create a much more
comprehensive interface. What, pray tell, are they basing their work on?

Anyway, I just posted my clientserver package, including UCSPI-91, to
alt.sources. You can also get it from stealth.acf.nyu.edu in
pub/hier/clientserver/*. Please send any comments (or implementations on
top of different protocols) to me at [e-mail].

---Dan

[ I posted this because it contains not only an objection to a POSIX
document, but a codified alternative.  However, it was iffy; any followups
more concerned with the code than with standards should to go alt.sources.d.
Thanks -- mod ]

Volume-Number: Volume 24, Number 31

From [e-mail]  Tue Jul  2 18:50:44 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA15215; Tue, 2 Jul 91 18:50:44 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28222; Tue, 2 Jul 91 18:50:35 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: Report on 1003.6: Security Extensions
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Sugar Land Unix -- Houston, TX
References: <[e-mail]> <[e-mail]>
Date: Sun, 30 Jun 1991 02:09:29 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Jerry M. Carlin) writes:
> The BIG problem I see with 1003.6 is lack of I&A; identification and
> authentication. What has been lacking for a LONG time is decent login.c,
> passwd.c etc functionality including ability to develop local rules
> passwords. We've seen a number of reimplementations of these functions
> on the net precisely because the current ones are so bad & inconsistant.

Yes. We need to be able to do the following things:

    Allow or deny access on a per-port or per account basis (for example,
        disable ttyM025 and user3... we have this, but it's not
        very clean and quite inconsistent for the per-port stuff).
    Allow or deny access on a scheduled basis (only allow backup to log
        in from 2AM through 10AM, all others are kept off from 2AM
        through 6AM).
    Allow or deny access to port/account combinations (for example,
        ttyM020 only allows user1 and user2 on, all others get
        "permission denied", root and backup can only log in to
        console or ttyf01, and "telnet" can't log in on any network
        ports).
    And other combinations (allow user1 on ttyM020 from 5PM through 8AM
        and all day weekends).
--
Peter da Silva.   `-_-'   <[e-mail]>.
                   'U`    "Have you hugged your wolf today?"


Volume-Number: Volume 24, Number 32

From [e-mail]  Tue Jul  2 18:50:50 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA15233; Tue, 2 Jul 91 18:50:50 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28239; Tue, 2 Jul 91 18:50:47 -0400
Newsgroups: comp.std.unix
From: Andrew Hume <[e-mail]>
Subject: 1003.1
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
Date: Mon, 1 Jul 1991 13:14:53 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andrew Hume)

    i wanted to get the latest form/version of 1003.1.
I have the IEEE std 1003.1-1988. I know of ISO 9945-1. Is there
any other version or form or enhancement to buy?

    andrew hume
    [e-mail]


Volume-Number: Volume 24, Number 33

From [e-mail]  Wed Jul  3 15:50:49 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA22456; Wed, 3 Jul 91 15:50:49 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03852; Wed, 3 Jul 91 15:50:44 -0400
Newsgroups: comp.std.unix
From: Andrew Hume <[e-mail]>
Subject: electronically available standards (and drafts)
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
Date: Wed, 3 Jul 1991 05:32:55 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andrew Hume)

    From time to time, people have asked if posix drafts
were available online. The answer is of course no. (don't ask me why.)
    Recently I became technical editor for the working paper
for a file system standard for WORM disks (roughly), done within the
ANSI X3B11.1 committee. At the request of the committee, our working paper
is available online in two forms; compressed postscript and plaintext
(this latter would need a lot of work to format into the former but
is useful for grep'ping.) The files are available by ftp from
research.att.com (login as netlib, and cd research/memo).
    I would recommend others who can to make their working papers
similiarly available.

    andrew hume


Volume-Number: Volume 24, Number 34

From [e-mail]  Wed Jul  3 15:50:59 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA22504; Wed, 3 Jul 91 15:50:59 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03886; Wed, 3 Jul 91 15:50:52 -0400
Newsgroups: comp.std.unix
From: Jim Tomlinson <[e-mail]>
Subject: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: OSF, Unix International, Posix
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: BoGART To You Buddy, Bellevue, WA
Date: Wed, 3 Jul 1991 16:37:20 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jim Tomlinson)

My organization needs to know (RSN) what, if any, standard file systems
or directory structures have been dictated or blessed by any of the
Unix standards organizations.  Where can we find info re: what OSF,
U.I., Posix, et.al. have to say on the subject?  That is, do any of the
organizations presuppose the existence of anything beyond '/' and
'/usr' (or do they even presuppose _those_)?  We're about to have a
less-than-desirable (to say the least) structure imposed on us from
above.  We haven't concerned ourselves with this sort of thing up 'til
now, but them days are gone.  Email if possible, post otherwise.  TIA!
--
Jim Tomlinson    BoGART Project    Boeing Computer Services    Bellevue, WA
[e-mail]       ...uunet!bcstec!voodoo!jdt        [phone]
 "If you don't make mistakes, you aren't really trying." - Coleman Hawkins

[ Jim is asking about filesystem layout, something which is not really
  standardized, although there are some de facto standards.  Unfortunately,
  there are many of them -- mod ]

Volume-Number: Volume 24, Number 36

From [e-mail]  Wed Jul  3 15:51:08 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA22585; Wed, 3 Jul 91 15:51:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03894; Wed, 3 Jul 91 15:50:55 -0400
Newsgroups: comp.std.unix
From: Jeremy Epstein <[e-mail]>
Subject: Re: Report on 1003.6: Security Extensions
Message-Id: <[e-mail]>
Summary: First get 1003.1/2 to adopt I&A
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: TRW Systems Division, Fairfax VA
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Date: Wed, 3 Jul 1991 14:05:25 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jeremy Epstein)

In article <[e-mail]>, [e-mail] (Peter da Silva) writes:
> Submitted-by: [e-mail] (Peter da Silva)
>
> In article <[e-mail]> [e-mail] (Jerry M. Carlin) writes:
> > The BIG problem I see with 1003.6 is lack of I&A; identification and
> > authentication. What has been lacking for a LONG time is decent login.c,
> > passwd.c etc functionality including ability to develop local rules
> > passwords. We've seen a number of reimplementations of these functions
> > on the net precisely because the current ones are so bad & inconsistant.
>
> Yes. We need to be able to do the following things:
>
>     Allow or deny access on a per-port or per account basis (for example,
>         disable ttyM025 and user3... we have this, but it's not
>         very clean and quite inconsistent for the per-port stuff).
>     Allow or deny access on a scheduled basis (only allow backup to log
>         in from 2AM through 10AM, all others are kept off from 2AM
>         through 6AM).
>     Allow or deny access to port/account combinations (for example,
>         ttyM020 only allows user1 and user2 on, all others get
>         "permission denied", root and backup can only log in to
>         console or ttyf01, and "telnet" can't log in on any network
>         ports).
>     And other combinations (allow user1 on ttyM020 from 5PM through 8AM
>         and all day weekends).

I'm a member of the 1003.6 working group, but speaking for myself only.

All of these ideas are good ones, but they miss the point.  1003.6 is
extending 1003.1 and 1003.2 to add security relevant features.  1003.1
has no mention of either login or passwd; 1003.2 mentions passwd (although
I'm not sure that it will make it into the standard), but with many weasel-
words.  [For example, the passwd command *may* (according to 1003.2) simply
give you instructions on how to change your password, such as contacting your
security administrator, getting a brain transplant, or whatever.]

In the near future we'll see many systems which don't even use passwords
for authentication (I assume there are already some out there, but I'm
not sure).  You'll see smart cards, voiceprints, retina scans, fingerprint
analysis, etc.  It's not a good idea to specify a password-based scheme as
a standard when technology is already growing beyond that.

Even if you do accept a password-based scheme, what rules do you want to
enforce?  Should the standard use the DoD password guidelines (no words,
randomly chosen pronouncable syllables)?  Password ageing?  There are
undoubtedly other international standards which may conflict with the DoD
guidelines.

Having said all that, once there is some agreement on a meta-mechanism for
authenticating users I think it's entirely reasonable to define a mechanism
for rules.  What Peter da Silva suggests are some good ones, but there's
much more...for example, you might be allowed or denied access based on the
results of a breathalyzer (sp?) attached to the side of the system (i.e.,
if you're drunk, no playing footside with top secret information).  There's
more than simple yes/no decisions that Peter suggests: depending on the time
of day, day of the week, login terminal, etc., you may have different
privileges available to you, be audited differently, have different clearances
available (you may only be able to access "unclassified" data from ttya,
but "secret" from ttyb), etc.

Incidentally, 1003.1 has no notion of what a "user" is, which means breaking
major new ground for any such extensions.

1003.6 will be going to ballot soon (I hope!) with the current proposed
standard.  I assume that we'll then put in another request to pursue additional
areas of security standardization, possibly including some of the topics
discussed by Peter and Jerry Carlin.

Again, I speak only for myself, and not for 1003.6 or my employer.
--
Jeremy Epstein            UUCP: uunet!trwacs!epstein
Trusted X Research Group    Internet: [e-mail]
TRW Systems Division        Voice: +1 703/876-8776
Fairfax Virginia


Volume-Number: Volume 24, Number 35

From [e-mail]  Thu Jul  4 19:51:08 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA15666; Thu, 4 Jul 91 19:51:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28571; Thu, 4 Jul 91 19:51:00 -0400
Xref: kithrup comp.std.unix:253 comp.org.ieee:212
Newsgroups: comp.std.unix,comp.org.ieee
From: "Vladimir G. Ivanovic" <[e-mail]>
Subject: Re: electronically available standards (and drafts)
Message-Id: <[e-mail]>
Followup-To: comp.org.ieee
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Sun Microsystems, Inc.
References: <[e-mail]>
Date: Thu, 4 Jul 1991 04:55:45 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Vladimir G. Ivanovic)

In article <[e-mail]> [e-mail] (Andrew Hume) writes:
       From time to time, people have asked if posix drafts
   were available online. The answer is of course no. (don't ask me why.)

The reasons I've heard are (1) IEEE loses revenue and (2) how can one be sure
that the standard hasn't been altered.

My personal belief is that objection #2 can be met by using the MD4 signature
system -- witness the X-MD4-Signature header in this posting (I hope).
Obtaining the MD4 signatures for particular documents could easily be done
through an 800 (free to caller) or 900 (pay for call plus toll charges) number
without any human intervention, or by mail, or for the truely paranoid, by
registered mail.

Of course, objection #1 still remains.  I wonder how much exactly the IEEE
makes by selling standards, or more interestingly, how much they would lose if
they implemented an electronic form of transfer.

-- Vladimir
--
==============================================================================
Vladimir G. Ivanovic                            Sun Microsystems, Inc
[phone]                                  MTV12-33
[e-mail]                            2550 Garcia Ave.
{decwrl,hplabs,ucbvax}!sun!Eng!vladimir         Mountain View, CA 94043-1100
                         Disclaimer: I speak for myself.
==============================================================================

[ Please note followup -- mod ]

Volume-Number: Volume 24, Number 37

From [e-mail]  Fri Jul  5 14:01:52 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA13061; Fri, 5 Jul 91 14:01:52 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04539; Fri, 5 Jul 91 14:01:13 -0400
Newsgroups: comp.std.unix
From: Dominic Dunlop <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Summary: Yes, they are, aren't they.
Originator: [e-mail]
Keywords: OSF, UNIX International, POSIX
Nntp-Posting-Host: uunet.uu.net
Reply-To: Dominic Dunlop <[e-mail]>
X-Submissions: [e-mail]
Organization: Oxford University, GB
References: <[e-mail]>
Date: Fri, 5 Jul 1991 14:53:04 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dominic Dunlop)

In article <[e-mail]> [e-mail]
(Jim Tomlinson) writes:
>
>My organization needs to know (RSN) what, if any, standard file systems
>or directory structures have been dictated or blessed by any of the
>Unix standards organizations.

As Mr. Fagan, our moderator, says

>[ Jim is asking about filesystem layout, something which is not really
>  standardized...

The System V Interface Definition has a fair shot at nailing things
down, but almost nobody has paid any attention.  Even actual
implementations of System V Release [34] don't adhere to it that well.
Apart from that, as far as I am aware, all ``standards'' are [even
more?] proprietary.  Sun has one idea of the Right Way to do things (or
maybe more than one:  they moved stuff around in a recent SunOS
upgrade, and great was the gnashing of teeth among administrators);
Santa Cruz has another idea; IBM yet a third, and so on.  And then
outfits like the X consortium come along and do things which look weird
in any environment.  A directory in /usr/bin?  Hey, wait a minute...
(Although far more heinous crimes are perpetrated by commercial
developers.)

To compound the problem, the rules that you are supposed to follow on a
particular platform are, more often than not, undocumented or documented
only eliptically.  If you're lucky, an administration manual will
explain why things are where they are, and you can figure out that your
own files of similar function should be in the same place -- or some
relation of the same place which is set aside for non vendor-supplied
stuff.  If you're really lucky, an application developers' guide will
give you chapter and verse.  You may think it stinks, but at least it's
there in black and white.

This is all very unsatisfactory, and we all know what we do in response:
put files in what we think is the right place, independent of what might
or might not be said or implied by the system supplier.  The trouble is,
many of us are using a mental map that was drawn before networking and
file system sharing became so prevalent.  Sun's excuse for moving things
around is that it makes it easier to set up and administer shared files
using NFS -- which is medium restrictive in what it allows one to do.
AT&T's RFS is much less widely used, but allows more flexibility, making
it less important to rearrange the furniture so as to to accommodate its
whims.  And Sun's translucent file system (TFS) may do better still by
creeping up on the problem from a different direction.  (Well, it looks
useful, but I have yet to try it.)

What could one standardize?  The Version 7 layout, which ``everybody
knows''?  Hell, no.  I don't want my users under /usr.  And besides,
it's not ``network aware''.  You probably want, wearing your asbestos
underwear, to determine the common subset of current practice, and then
move out from there, causing equal pain to everybody, and bearing in
mind that POSIX standards should always cater for hosted as well as
native environments.

Would anybody care to suggest which crack in the POSIX scheme of things
this issue has slipped down and is waitng to crawl out of?  I'd say
it's somewhere beteen 1003.7, administration, and 1003.18, POSIX
environment profile.

--
Dominic Dunlop


Volume-Number: Volume 24, Number 38

From [e-mail]  Fri Jul  5 16:16:00 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA12277; Fri, 5 Jul 91 16:16:00 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22249; Fri, 5 Jul 91 16:15:42 -0400
Newsgroups: comp.std.unix
From: "Jerry M. Carlin" <[e-mail]>
Subject: Re: Report on 1003.6: Security Extensions
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Pacific * Bell
References: <[e-mail]> <[e-mail]>
Date: Fri, 5 Jul 1991 18:11:58 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jerry M. Carlin)

In article <[e-mail]> [e-mail] (Jeremy Epstein) writes:
>Submitted-by: [e-mail] (Jeremy Epstein)
>In article <[e-mail]>, [e-mail] (Peter da Silva) writes:
>> Submitted-by: [e-mail] (Peter da Silva)
>>
>> In article <[e-mail]> [e-mail] (Jerry M. Carlin) writes:
>> > The BIG problem I see with 1003.6 is lack of I&A; identification and
>> > authentication...

>I'm a member of the 1003.6 working group, but speaking for myself only...
>
>All of these ideas are good ones, but they miss the point.  1003.6 is
>extending 1003.1 and 1003.2 to add security relevant features.  1003.1
>has no mention of either login or passwd; 1003.2 mentions passwd (although
>I'm not sure that it will make it into the standard), but with many weasel-
>words...

Then 1003.6 is mostly useless and since it really does not address security
in a comprehensive way it should be called something else. This is like
saying that we won't worry about networking, windowing systems, your-favorite
topic because another part of the standard does not consider it. I guess
we can also forget about system administration. small amount of :-)  but
a larger :-(

>In the near future we'll see many systems which don't even use passwords
>for authentication (I assume there are already some out there, but I'm
>not sure).  You'll see smart cards, voiceprints, retina scans, fingerprint
>analysis, etc.  It's not a good idea to specify a password-based scheme as
>a standard when technology is already growing beyond that.

Since passwords will be what most systems use for the forseeable future,
I don't agree but if you want to extend this arguement, it might be
noted that the Orange book is obsolete so that its concepts should
not have been used either! After all, how many systems do we have that
are not networked and have dumb terminals connected to them (and that
have no databases).

>...
>Having said all that, once there is some agreement on a meta-mechanism for
>authenticating users I think it's entirely reasonable to define a mechanism
>for rules...

That is a good idea. I'd support that especially if it were coupled with
a framework whereby users could plug in authentication mechanisms (smart
cards, passwd.c with rules, etc.)

>Incidentally, 1003.1 has no notion of what a "user" is, which means breaking
>major new ground for any such extensions.

Does 1003.1 have notions of system administration, windowing systems,
networks and the like?

>1003.6 will be going to ballot soon (I hope!) with the current proposed
>standard...

And I'll vote against it as incomplete and urge others to do the same.
Without I&A the standard is not anything close to a comprehensive
"security" standard at all. I'd rather see nothing than such a standard.
--
Jerry M. Carlin    [phone] [e-mail]
To dream the impossible dream. To fight the unbeatable foe.


Volume-Number: Volume 24, Number 39

From [e-mail]  Fri Jul  5 17:31:10 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AB27996; Fri, 5 Jul 91 17:31:10 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03183; Fri, 5 Jul 91 17:31:02 -0400
Newsgroups: comp.std.unix
From: Rich Stevens <[e-mail]>
Subject: status of 1003.1a extension
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: POSIX.1
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Fri, 5 Jul 1991 21:10:20 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Rich Stevens)

Does anyone know the status of the 1003.1 extension draft?
In June 1990 it was called 1003.1b, but I see from the
October 1990 posting to this newsgroup that it's been
renamed 1003.1a.  (This is the extension that's suposed
to provide symbolic links, among other things.) In Zlotnick's
book he refers to Draft 3 of this extension, but I've seen
reference to a Draft 4 (Sept. 1990).

Anyone know what draft it's currently at, and what a reasonable
guess as to it's completion date might be?  Someone in this
newsgroup said early 1991 (which has past) but Zlotnick
mentions 1993 (which seems a little too far away).  Thanks.

    Rich Stevens  ([e-mail])


Volume-Number: Volume 24, Number 40

From [e-mail]  Fri Jul  5 21:30:55 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA29204; Fri, 5 Jul 91 21:30:55 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27116; Fri, 5 Jul 91 21:30:47 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: OSF, UNIX International, POSIX
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]>
Date: Fri, 5 Jul 1991 21:36:38 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
(Dominic Dunlop) writes:
>Submitted-by: [e-mail] (Dominic Dunlop)

>Would anybody care to suggest which crack in the POSIX scheme of things
>this issue has slipped down and is waitng to crawl out of?  I'd say
>it's somewhere beteen 1003.7, administration, and 1003.18, POSIX
>environment profile.

I'd suggest 'none of the above'.  Directory structure and the
existence of particular files with particular names won't need
to be standardized if the 1003.7 committee can define a
complete administrative interface.
--

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]

[ .2 has some interest in directory layout... where are sed, cat, etc.
  in the filesystem?  Can a portable script (or program that uses system()
  really rely on the invoker not having a different utility of the same
  name in execution path?  Just a couple of thoughts -- mod ]

Volume-Number: Volume 24, Number 41

From [e-mail]  Tue Jul  9 18:46:31 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA12712; Tue, 9 Jul 91 18:46:31 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08143; Tue, 9 Jul 91 18:46:26 -0400
Newsgroups: comp.std.unix
From: Alain Williams <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Parliament Hill Computers Ltd
Date: Mon, 8 Jul 1991 10:09:15 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Alain Williams)

> [e-mail] (Chuck Karish) writes:
> I'd suggest 'none of the above'.  Directory structure and the
> existence of particular files with particular names won't need
> to be standardized if the 1003.7 committee can define a
> complete administrative interface.
NO!! If you are an applications writer you need to know the location
of some things. Eg you you want to run a program securely (ie without
relying on $PATH to find it for you), you have to know where to find it
(to within a couple of guesses).

Also if you are writing install mechanisms, you often need to know how to
find things, where to put things (don't rely on the installing user to
tell you where they should go, they might not even understand the
question).

Alain Williams

[phone]

phLOGIN our Turnkey Security Login utility is available NOW - ask me for info.


Volume-Number: Volume 24, Number 42

From [e-mail]  Tue Jul  9 18:46:39 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA12728; Tue, 9 Jul 91 18:46:39 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08167; Tue, 9 Jul 91 18:46:34 -0400
Newsgroups: comp.std.unix
From: Rich Salz <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: OSF, UNIX International, POSIX
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: BBN Systems and Technology, Inc.
References: <[e-mail]> <[e-mail]>
Date: Tue, 9 Jul 1991 12:56:15 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Rich Salz)

In <[e-mail]> [e-mail] (Dominic Dunlop) writes:
>This is all very unsatisfactory, and we all know what we do in response:
>put files in what we think is the right place, independent of what might
>or might not be said or implied by the system supplier.

Some time ago -- either last January or June Usenix time-frame -- the
Berkeley folks called a meeting to discuss this.  At least Sun and DEC
came.  Everyone hashed things out, and CSRG came up with the definitive
prototype filesystem layout, as well as agreements from some people (DEC
is one name I recall) to follow it.  Keith Bostic had viewgraphs, and
posted them to comp.bugs.4bsd-fixes.  (No, I don't have a copy any more.)

Perhaps people can pressure vendors to pick up the BSD standard.  (A nicely
vague phraseology...)
    /r$
--
Please send comp.sources.unix-related mail to [e-mail].
Use a domain-based address or give alternate paths, or you may lose out.


Volume-Number: Volume 24, Number 43

From [e-mail]  Tue Jul  9 18:46:46 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA12815; Tue, 9 Jul 91 18:46:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08179; Tue, 9 Jul 91 18:46:40 -0400
Newsgroups: comp.std.unix
From: Fred Zlotnick <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: OSF, UNIX International, POSIX
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 9 Jul 1991 15:04:46 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Fred Zlotnick)

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
    [All ommitted except comments of the moderator]
>
>[ .2 has some interest in directory layout... where are sed, cat, etc.
>  in the filesystem?  Can a portable script (or program that uses system()
>  really rely on the invoker not having a different utility of the same
>  name in execution path?  Just a couple of thoughts -- mod ]

Dot 2 has considered this issue, and the related issue of having a shell
function of the same name as the desired utility.  The "command" utility
(which was proposed as a shell built-in in earlier drafts, but is a
stand-alone utility in 1003.2 Draft 11) solves at least part of the problem,
with no explicit knowledge of directory structure.  It relies on the
existence of a path that is known to make all system utilities (i.e.
all the utilities specified in Dot 2) accessible.  This path is not
itself specified by Dot 2.
--
Fred Zlotnick                       |    #include <std.disclaimer>
[e-mail]                  |    #include <brilliant.quote>
...!{decwrl,ames,hpda}!mindcrf!fred |


Volume-Number: Volume 24, Number 44

From [e-mail]  Tue Jul  9 22:17:50 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA08974; Tue, 9 Jul 91 22:17:50 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10456; Tue, 9 Jul 91 22:17:44 -0400
Newsgroups: comp.std.unix
From: Ran Atkinson <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: University of Virginia
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 9 Jul 1991 23:54:32 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ran Atkinson)

In article <[e-mail]> [e-mail] wrote:

>Some time ago -- either last January or June Usenix time-frame -- the
>Berkeley folks called a meeting to discuss this.  At least Sun and DEC
>came.  Everyone hashed things out, and CSRG came up with the definitive
>prototype filesystem layout, as well as agreements from some people (DEC
>is one name I recall) to follow it.  Keith Bostic had viewgraphs, and
>posted them to comp.bugs.4bsd-fixes.  (No, I don't have a copy any more.)
>
>Perhaps people can pressure vendors to pick up the BSD standard.

  What would be really nice is if CSRG could take the time and publish
the consensus information as an informational RFC.  This would make it
even more widely accessible and could help encourage vendors to follow
it.

  For one thing, it carries more weight with the vendors when several
customers ask why they aren't doing it the way RFC-HHHH describes.
For another, it makes it easier for the technical staff to persuade
managers that changes to conform are justified and worthwhile.

These are all off-the-top-of-my-head ideas, so add salt liberally.

Ran Atkinson
[e-mail]



Volume-Number: Volume 24, Number 45

From [e-mail]  Fri Jul 12 18:02:09 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA04731; Fri, 12 Jul 91 18:02:09 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17013; Fri, 12 Jul 91 18:02:05 -0400
Newsgroups: comp.std.unix
From: Dave Decot <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hewlett Packard, Cupertino
References: <[e-mail]>
Date: Thu, 11 Jul 1991 01:23:59 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dave Decot)

To be sure that you are "securely" running a standard utility, POSIX.2
provides the standard utility path via "getconf CS_PATH" that applications
can change their PATH to, and be assured of getting the standard version.

There is no need to know in advance the actual path names, since the
system tells You the right path to use.

Dave

Volume-Number: Volume 24, Number 46

From [e-mail]  Tue Jul 16 00:14:56 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA29210; Tue, 16 Jul 91 00:14:56 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17524; Tue, 16 Jul 91 00:14:37 -0400
Newsgroups: comp.std.unix
From: "James H. Moore" <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Mon, 15 Jul 1991 18:27:08 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (James H. Moore)

I just tried to post a question to comp.doc and
comp.unix.question regarding this very subject.  Although
no longer in system administration, I now answer questions
for users, and recently tried to create a .login file that
would pick up appropriate paths of executables, shared
libraries, and on-line manual pages.  I ran into some
file system structure roadblocks, and asked a similar question
regarding standards, do they exist and what can be done.

Specifically, I found in trying to create a .login file
that would localize variances of networks within our
division, while allowing for variability in architecture,
operating system level, GUI as well.  (Sooner or later
you may have to deal with natural language variables as
well.   For europe, it is probably sooner -- like now).
I dealt with various philosophies, and problems.

The most visible was how many levels of sharing are permitted,
and how vendors package software.  I know that many vendors
put packages under /usr for convenience.  Most system
administrators move these elsewhere to a partition(s) which
won't be wiped out at the next system upgrade.  [This is a
standard enough practice, from my limited visibility.  If
someone would standardize on a name for this applications
partition - local candidates include /licensed, /licensed4,
/packages or any one of the previous under the /u directory]

How authors/vendors view their "space" seems to differ.
Frequently there is "encapsulation", where a vendor puts
everything binaries, configuration files, shared libraries,
and manual pages under one heading, the package name.  That
is fine, it make individual package upgrades easy. If the
application uses an environment variable, and a shell script
which add appropriate things to access shared libraries, and
man pages, you are in good shape, you can even run multiple
versions at once (like testing a new version when it comes
out, or allowing projects near completion to finish without
using the new an improved version).

But often there are naming problems in subdirectories: sometimes
the encapsulation is by architecture, so you have .../vendor/bin
.../vendor/lib etc.  These are picked off of the distribution
tape by architecture.

Others, create the main directory, and then pick off
architectures one by one, allowing the sharing of man
pages and configuration or data files.

E.g. .../vendor/sun3/bin .../vendor/sun3/lib .../vendor/sun4/bin
.../vendor/sun4/lib .../vendor/share .../vendor/etc  [sometimes
the "etc" directory is under "share", othertimes it is not.

Some do like "." better than "/". So you find .../vendor/bin.sun3
and .../vendor/bin.sun4.  This saves no keystrokes, and usually
implies that the applications do not make use of shared libraries.

When the applications make use of a GUI, things get more
interesting.  Most append an X somewhere for X applications.
Others do things with "ow" for OpenWindows(tm) (actually OpenLook
(tm)), and "m" for Motif(tm).  The problem is that these
postfixes can be anywhere, and sometimes users have a menu
to select a windowing system in their .login.

After the "encapsulated" approach is the "installed" approach,
where binaries are added to /usr/bin, man pages to /usr/man, libraries to /usr/lib, and data to /usr/etc.  This works,
leveraging existing mechanisms to provide the user with access.

Two last issues surface, in a related way, from a users perspective,
in getting access to the applications that they want.

One is a concept of "locality" - i.e. what is "local".  What
needs to be local to the machine, working group, subnet, and
what is "global" to the organization.  This has a lot of
facets, mainly centered around how you handle overlap.

The second concept has to do with a concept that I have seen
prototyped in yellow pages, and bantered around as being part
of the file system.  Create tables for users, either tables
of paths for users (distributed via rpc program or yellow
pages), or have a part of the directories files which define
variability, and set up user's paths and variables for them
("source" files, or environment scripts).

The issue of standardizing encapsulation seems to be the easiest,
and would probably make system managers and users lives a lot
simpler.

Has anyone worked these things out?  Are there RFCs?  Is
POSIX.7 addressing these?

Thanks for listening.  Thanks for any help or suggestions.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - James H. Moore, USC, ISPD, Eastman Kodak Co, [phone]  - - -
-  [e-mail], PROFS: DDTC12(JMOORE)  VMS: DDTC12::JMOORE - -
May the Lord bless you, in Jesus's name for blessing me with your help!

Volume-Number: Volume 24, Number 47

From [e-mail]  Tue Jul 16 18:45:49 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA27378; Tue, 16 Jul 91 18:45:49 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21030; Tue, 16 Jul 91 18:45:41 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]>
Date: Mon, 15 Jul 1991 22:41:45 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Dave Decot) writes:
> To be sure that you are "securely" running a standard utility, POSIX.2
> provides the standard utility path via "getconf CS_PATH" that applications
> can change their PATH to, and be assured of getting the standard version.

Is getconf a builtin? If not, it itself can be spoofed!
--
Peter da Silva; Ferranti International Controls Corporation; [phone];
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

[ I would assume getconf is a builtin.  But we all know what happens when
  one assumes -- mod ]

Volume-Number: Volume 24, Number 48

From [e-mail]  Wed Jul 17 16:00:08 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA07620; Wed, 17 Jul 91 16:00:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26992; Wed, 17 Jul 91 16:00:01 -0400
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 17 Jul 1991 05:08:14 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dan Bernstein)

Under BSD, you can easily set up a /inst/bin directory with symlinks to
every officially ``installed'' executable. Users can then have /inst/bin
in their paths instead of all the physical directories like /bin, /etc,
/usr/bin, /usr/ucb, etc. Although the directory is large, the time for
several failing execve()s is much larger than the time for searching one
directory (especially with path caching as in BSD 4.3).

Even on System V, you can put hard links in /inst/bin, and when an
executable is on a different device you can set up a shell script which
execs the real executable. It's *still* more efficient, on the average,
than all the failing execve()s. Try it if you don't believe me.

Yes, this requires all executables to be given unique names. Any concept
of a standard path, including the POSIX.2 proposal, forces this. It's
simply not a disadvantage.

Anyway, as vendors haven't come to any agreement on this facility---the
current ``standard'' is to install most programs somewhere under
/usr/local, with new subdirectories for big programs like ingres---I
despise POSIX's attempts to name any particular solution a ``standard.''
In the interests of security, efficiency, and backwards compatibility, I
propose /inst/bin as a viable alternative to getconf. I suggest that
POSIX look---and take its time looking---before it leaps.

---Dan


Volume-Number: Volume 24, Number 49

From [e-mail]  Thu Jul 18 16:48:26 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA27725; Thu, 18 Jul 91 16:48:26 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26869; Thu, 18 Jul 91 16:48:05 -0400
Newsgroups: comp.std.unix
From: "Marc W. Mengel" <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 18 Jul 1991 15:17:10 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Marc W. Mengel)

[e-mail] (Dan Bernstein) writes:

>Submitted-by: [e-mail] (Dan Bernstein)

>Under BSD, you can easily set up a /inst/bin directory with symlinks to
>every officially ``installed'' executable. Users can then have /inst/bin
>in their paths instead of all the physical directories like /bin, /etc,
>/usr/bin, /usr/ucb, etc. Although the directory is large, the time for
>several failing execve()s is much larger than the time for searching one
>directory (especially with path caching as in BSD 4.3).

    Of course, you can't run /bin/ls there without it blowing
    up, and the directory search time is much more expensive
    than split directories.  Also none of your modern shells
    (SysV sh, csh, ksh, bash, etc.) do mulitple execve()s,
    they keep a hash table.  Most current UNIX implementations
    do not handle large (>200 files) directories well at all.
    Many standard unix utilities choke on huge directories.

    Due to the filesystem implementation, things like stat-ing
    all the files in a directory turn out to be order(n**2),
    making lots of operations slower in non-obvious ways.

>Even on System V, you can put hard links in /inst/bin, and when an
>executable is on a different device you can set up a shell script which
>execs the real executable. It's *still* more efficient, on the average,
>than all the failing execve()s. Try it if you don't believe me.

    Well, actually in general you have to write a little
    stub executable, since you can't exec() shell scripts
    on Sys. V systems previous to Release 4...
-------
Marc Mengel
[e-mail]


Volume-Number: Volume 24, Number 50

From [e-mail]  Thu Jul 18 23:45:26 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA07980; Thu, 18 Jul 91 23:45:26 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12206; Thu, 18 Jul 91 23:45:11 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 18 Jul 1991 17:14:06 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
(Dan Bernstein) writes:
>Under BSD, you can easily set up a /inst/bin directory with symlinks to
>every officially ``installed'' executable. Users can then have /inst/bin
>in their paths instead of all the physical directories like /bin, /etc,
>/usr/bin, /usr/ucb, etc. Although the directory is large, the time for
>several failing execve()s is much larger than the time for searching one
>directory (especially with path caching as in BSD 4.3).

This might be a workable optimization on some implementations.
I don't see the significance to standards of the
implementation details of your shell.  There's no reason why a
shell has to find a utility by trial and error.

>Anyway, as vendors haven't come to any agreement on this facility---the
>current ``standard'' is to install most programs somewhere under
>/usr/local, with new subdirectories for big programs like ingres---I
>despise POSIX's attempts to name any particular solution a ``standard.''
>In the interests of security, efficiency, and backwards compatibility, I
>propose /inst/bin as a viable alternative to getconf. I suggest that
>POSIX look---and take its time looking---before it leaps.

Dan, do you really understand what getconf does?  I fail to see
how its use (properly protected) can make any program less
portable.  It's a utility to return information about system
limits and options, only one of which is a path.  It's the
POSIX.2 utility-level interface to the C functionality provided
by sysconf() and pathconf().  A blanket condemnation of getconf
based on your idea of the correct default path for installing
third-party software is nonsensical.

If your complaint is that the definition of _CS_PATH will
prevent the system administrator from performing the
optimization you suggest, I don't think you've thought the
problem through. If you want programs, including
vendor-supplied shell scripts, to use /inst/bin, move the
vendor-supplied getconf aside and provide your own version that
supplies your path for _CS_PATH and calls the original getconf
for other values.

If vendors use "getconf _CS_PATH" consistently, they'll make it
easier for you to implement your scheme.  Changing getconf will
optimize PATH searching for all the system's scripts, as well
as for your interactive users.  No hacking required when you
install a new release, either.


A puzzle for the reader (maybe this is obvious to everyone but
me):  How can a shell script determine whether it's running on
a POSIX.2 system?  If it calls getconf and getconf does not
exist, the shell may exit.  It could call getconf in a
subshell, but that's ugly and expensive.
--

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]

Volume-Number: Volume 24, Number 51

From [e-mail]  Sun Jul 21 18:30:46 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA17655; Sun, 21 Jul 91 18:30:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07514; Sun, 21 Jul 91 18:30:40 -0400
Newsgroups: comp.std.unix
From: "c. dumitrache" <[e-mail]>
Subject: Unix Developments -- Help !
Message-Id: <[e-mail]>
Originator: [e-mail]
Keywords: Unix,OSF,X/open,Posix
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Caulfield Campus, Monash University, Melb., Australia.
Date: Fri, 19 Jul 1991 03:53:59 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (c. dumitrache)

I am a third year student in computer science at Monash
University in Melbourne.

I have been asked to research where Unix is at and where it
is going.

Topics include :
1) OSF developments
2) UI developments
3) X/open developments
4) Open system developments and Posix

Is there anyone willing to become my referee and guide me through
my research ?

Any help and aricles of interest are much appreciated !

Catalin Dumitrache [e-mail]

[ Reply through email, please. -- mod ]

Volume-Number: Volume 24, Number 52

From [e-mail]  Sun Jul 21 18:30:50 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA17664; Sun, 21 Jul 91 18:30:50 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07529; Sun, 21 Jul 91 18:30:46 -0400
Newsgroups: comp.std.unix
From: "Greg A. Woods" <eci386!woods>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Elegant Communications Inc.
References: <[e-mail]>
Date: Fri, 19 Jul 1991 01:36:31 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Greg A. Woods)

In article <[e-mail]> [e-mail] (James H. Moore) writes:
> Has anyone worked these things out?  Are there RFCs?  Is
> POSIX.7 addressing these?

Well, some versions of 7th Edition UNIX came with a hier.7 man page,
and thus so did some V7 derived XENIX versions.

Then there's the AT&T SVID.  Issue 1, volume 1 has a section called
filsys(ba_env).  I believe this was translated into a man page in some
releases of SysV.  There's also envvar(ba_env) and system(ba_os) which
distill down to defining the default path as ":/bin:/usr/bin".

Finally, there's filesystem.7 on SysVr4.
--
                            Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP        ECI and UniForum Canada
[phone] [h]  [phone] [w]  VE3TCP    Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL


Volume-Number: Volume 24, Number 53

From [e-mail]  Sun Jul 21 18:31:02 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA17702; Sun, 21 Jul 91 18:31:02 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07538; Sun, 21 Jul 91 18:30:54 -0400
Newsgroups: comp.std.unix
From: Geoff Clare <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UniSoft Ltd., London, England
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 19 Jul 1991 13:48:56 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Geoff Clare)

[e-mail] (Peter da Silva) writes:

>In article <[e-mail]> [e-mail] (Dave Decot) writes:
>> To be sure that you are "securely" running a standard utility, POSIX.2
>> provides the standard utility path via "getconf CS_PATH" that applications
>> can change their PATH to, and be assured of getting the standard version.

>Is getconf a builtin? If not, it itself can be spoofed!

Even if getconf is a builtin in the POSIX shell, what is there to stop
users running these "secure" scripts under a non-standard shell with a
getconf that just echoes the current PATH?

[ Requiring shell scripts to be interpreted by a specific shell or by
  a shell specified by the script, I would imagine. -- mod ]

--
Geoff Clare <[e-mail]>  (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: [phone]   Fax: [phone]

Volume-Number: Volume 24, Number 54

From [e-mail]  Sun Jul 21 18:45:57 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA19811; Sun, 21 Jul 91 18:45:57 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08724; Sun, 21 Jul 91 18:45:40 -0400
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 19 Jul 1991 19:46:32 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> Chuck Karish ([e-mail]) writes:
> >Anyway, as vendors haven't come to any agreement on this facility---the
> >current ``standard'' is to install most programs somewhere under
> >/usr/local, with new subdirectories for big programs like ingres---I
> >despise POSIX's attempts to name any particular solution a ``standard.''
> >In the interests of security, efficiency, and backwards compatibility, I
> >propose /inst/bin as a viable alternative to getconf. I suggest that
> >POSIX look---and take its time looking---before it leaps.
> Dan, do you really understand what getconf does?  I fail to see
> how its use (properly protected) can make any program less
> portable.

My objection is to the idea of standardizing something which vendors
haven't even begun to look at. I feel the same way about sysconf() and
pathconf(), POSIX sessions (oh, right, HP-UX already had something like
this---how dare I argue against such a precedent?), and most of POSIX's
other inventions.

In this particular case, existing programs can be used with /inst/bin
without even changing the source code. All you have to do is change the
default system PATH. Adding getconf to a program means that the program
will no longer work on the vast majority of systems. That's what I mean
by unportable.

> A puzzle for the reader (maybe this is obvious to everyone but
> me):  How can a shell script determine whether it's running on
> a POSIX.2 system?  If it calls getconf and getconf does not
> exist, the shell may exit.  It could call getconf in a
> subshell, but that's ugly and expensive.

Congratulations. You just hit the nail right on the head.

---Dan

Volume-Number: Volume 24, Number 55

From [e-mail]  Mon Jul 22 17:15:59 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA04365; Mon, 22 Jul 91 17:15:59 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19208; Mon, 22 Jul 91 17:15:55 -0400
Newsgroups: comp.std.unix
From: Kai Henningsen <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
References: <[e-mail]> <[e-mail]>,
Date: Mon, 22 Jul 1991 23:22:00 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Kai Henningsen)

In article <[e-mail]>, [e-mail] (Chuck
Karish) says:
>A puzzle for the reader (maybe this is obvious to everyone but
>me):  How can a shell script determine whether it's running on
>a POSIX.2 system?  If it calls getconf and getconf does not
>exist, the shell may exit.  It could call getconf in a
>subshell, but that's ugly and expensive.

I don't know what POSIX says, but I'd expect an analog to POSIX.1 -
an environment variable telling which version of POSIX we are.
POSIX.1 does the same with #define.

Volume-Number: Volume 24, Number 56

From [e-mail]  Mon Jul 22 17:16:06 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA04411; Mon, 22 Jul 91 17:16:06 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19212; Mon, 22 Jul 91 17:15:55 -0400
Newsgroups: comp.std.unix
From: "James H. Moore (726-0322" <[e-mail]>
Mmdf-Warning:  Parse error in original version of preceding line at kithrup.com
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Eastman Kodak
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 22 Jul 1991 18:55:57 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (James H. Moore (726-0322)))

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>
>Submitted-by: [e-mail] (Dan Bernstein)
>
>Under BSD, you can easily set up a /inst/bin directory with symlinks to
>every officially ``installed'' executable. Users can then have /inst/bin
>in their paths instead of all the physical directories like /bin, /etc,
>/usr/bin, /usr/ucb, etc.

This is fine, except when you have to consider shared libraries, and
man page groupings.  Also, what happens when you have multiple releases?
You bring up, and test a new release, but users which are finishing
up a project want a stable, known environment, and insist on keeping the old
familiar version around.  Most likely, you will have to rename some commands,
something.old or something equally tedious and annoying.

>Even on System V, you can put hard links in /inst/bin, ...

See above:

>Anyway, as vendors haven't come to any agreement on this facility---the
>current ``standard'' is to install most programs somewhere under
>/usr/local, with new subdirectories for big programs like ingres

We have already found that a single /usr/local, with everything dumped under
there is not optimal, as "local" can have several meanings, e.g. local
to the machine, local to the subnet, common to the division ... .

Still, with "big programs" like ingres or say frame maker, what does the
directory structure look like underneath the subdirectory?  It does make
a difference are there multiple architectures? How do you pick up your
architecture?  What if it is a window based tool, and there are different
binaries for different GUIs?

>I despise POSIX's attempts to name any particular solution a ``standard.''
>In the interests of security, efficiency, and backwards compatibility, I
>propose /inst/bin as a viable alternative to getconf. I suggest that
>POSIX look---and take its time looking---before it leaps.

We will always be stuck with rearranging directories and renaming them
unless some guidelines are laid down.  Most system administrators that I
know have better, more interesting things to do with their time than
merge man page directories, shared libraries, and rename directories,
and build links.   Sometimes things are so tied to GUI or whatever,
that "common" directories are impossible, and that the encapsulation
of the vendor needs to be retained.  Can we guide the encapsulation
process and how to recognize particular types of encpsulation?  Can we
talk about what we can mean by "local" ?  How do we handle different
types of locality?

>
>---Dan
Thanks for your input

                    Jim Moore
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - James H. Moore, USC, ISPD, Eastman Kodak Co, [phone]  - - -
- -  [e-mail], PROFS: DDTC12(JMOORE)  VMS: DDTC12::JMOORE - -
 May the Lord bless you, in Jesus's name for blessing me with your help!

Volume-Number: Volume 24, Number 57

From [e-mail]  Mon Jul 22 17:16:23 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA04498; Mon, 22 Jul 91 17:16:23 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19252; Mon, 22 Jul 91 17:16:06 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Summary: innovation considered non-harmful
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 22 Jul 1991 19:30:49 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
(Dan Bernstein) writes:
>In article <[e-mail]> Chuck Karish
>([e-mail]) writes:
[ Dan Bernstein wrote: ]
[ Secondary included text deleted for brevity's sake -- mod ]
>My objection is to the idea of standardizing something which vendors
>haven't even begun to look at. I feel the same way about sysconf() and
>pathconf(), POSIX sessions (oh, right, HP-UX already had something like
>this---how dare I argue against such a precedent?), and most of POSIX's
>other inventions.

If you've been paying attention to this newsgroup, you know
that POSIX sessions were invented because, when the working
group tried to write a specification for job control, they
discovered that the BSD behavior was underspecified and
inconsistent.  They chose invention as the lesser of two
evils rather than standardize on something that was wrong.

To elaborate on the security and efficiency issues, I fail to
see that either getconf or /inst/bin has any impact on the
administrator's ability to maintain reasonable system security.
The directories and executables in the default path, including
getconf, have to be protected no matter how many links there are
to each file.  If it's possible for a bad guy to put a Trojan
horse into the default path it doesn't matter whether its name
is 'getconf' or 'login' or 'sh' or '/.profile' or '/etc/environment'.

As others have pointed out, the efficiency of using /inst/bin
depends on the implementation.  I consider it to be a poor
candidate for standardization.  If you want to use it on
systems where it helps, go ahead.  Nothing in 1003.1 or 1003.2
will break it.

>In this particular case, existing programs can be used with /inst/bin
>without even changing the source code. All you have to do is change the
>default system PATH. Adding getconf to a program means that the program
>will no longer work on the vast majority of systems. That's what I mean
>by unportable.

There's a simple fix that makes such scripts work:  install
getconf.  It's easy to implement and no harder to install than
patch or compress, which I regularly install on new systems in
order to port other programs.  Scripts can be written to use
getconf only if it exists, which allows them to be portable to
non-POSIX.2 systems.

The issue of script portability is something of a red herring,
because it has never been possible to write really portable
scripts.  There's just too much variability in internal limits
and return codes in utilities, which are formally standardized
for the first time ("our implementation IS the standard",
as AT&T is fond of saying, doesn't cut it) in POSIX.2.

getconf, sysconf(), pathconf() and fpathconf() exist to make it
possible to allow programs to make full use of system
capabilities without being re-compiled for differently-
configured members of a binary-compatible family and without
being crippled down to a lowest common denominator.  If
you're happy to write code that works only on BSD systems,
you're free to continue to do so.  Others who try to write
portable programs can protect calls to pathconf(), sysconf(),
etc. inside "#ifdef _POSIX_SOURCE" blocks and leave the
traditional porting hackery to you, if that's what you want.

>> A puzzle for the reader (maybe this is obvious to everyone but
>> me):  How can a shell script determine whether it's running on
>> a POSIX.2 system?  If it calls getconf and getconf does not
>> exist, the shell may exit.  It could call getconf in a
>> subshell, but that's ugly and expensive.
>
>Congratulations. You just hit the nail right on the head.

There's a trivial fix for this, too: 1003.2 could require
conforming systems or shells to pre-define an environment
variable to indicate that POSIX.2 features are available.  Has
this been considered?  If so, why was it rejected?
--

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]

Volume-Number: Volume 24, Number 58

From [e-mail]  Mon Jul 22 18:31:04 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA27899; Mon, 22 Jul 91 18:31:04 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07364; Mon, 22 Jul 91 18:30:56 -0400
Newsgroups: comp.std.unix
From: Eric Gisin <mks!eric>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
References: <[e-mail]> <[e-mail]>
Date: Mon, 22 Jul 1991 22:03:57 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Eric Gisin)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
   In article <[e-mail]> Chuck Karish ([e-mail]) writes:
>   > A puzzle for the reader (maybe this is obvious to everyone but
   > me):  How can a shell script determine whether it's running on
   > a POSIX.2 system?  If it calls getconf and getconf does not
   > exist, the shell may exit.  It could call getconf in a
   > subshell, but that's ugly and expensive.

>   Congratulations. You just hit the nail right on the head.

I don't see any problem. The most obvious solution is:
    if PATH=`command -p getconf _CS_PATH`;
    then # POSIX.2
    else PATH=<default>
    fi
Or simply:
    PATH=`command -p getconf _CS_PATH` || PATH=<default>

There is a problem if you want to redirect command's error with 2>/dev/null.
Existing shells may print errors after (Korn) or before (Bourne) redirection.

Volume-Number: Volume 24, Number 59

From [e-mail]  Tue Jul 23 03:16:08 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA20224; Tue, 23 Jul 91 03:16:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29171; Tue, 23 Jul 91 03:15:56 -0400
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 23 Jul 1991 05:15:07 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dan Bernstein)

In the referenced article, Chuck points out that POSIX invented sessions
because they wanted to fix job control. I'm quite aware of this: when I
was complaining about sessions a while back Marc Teitelbaum showed me
what the discussion had been like. There's just one problem.

In POSIX, job control is an option. Sessions aren't. I defy any POSIX
supporter to defend this.

(My guess, btw, is that the committee was thinking about tty security,
and thought that by adding POSIX sessions they could solve the problems.
Indeed, published claims by Convex, Sun, and even CERT would lead most
people to believe that this is true. It's not. POSIX sessions don't help
tty security one bit.)

Even without sessions in the way, POSIX job control is not backwards
compatible. It's missing some BSD features and it added some others.
(For instance, a BSD program can be in the foreground on one terminal
and the background on another. Under POSIX a process is either in the
foreground or in the background [with respect to its controlling
terminal], and access to other ttys simply doesn't have job control.
This ``feature'' broke emacs and screen, among other programs.)

In response to my complaint that POSIX invents one thing after another,
Chuck finishes his example of job control with this:

[e-mail] (Chuck Karish) writes:
> They chose invention as the lesser of two
> evils rather than standardize on something that was wrong.

Oh, I agree that the BSD job control model was wrong. I agree that
standardizing on a model with many huge flaws is stupid. By what stretch
of the imagination does this mean that standardizing on another model,
which not only has its own flaws but is compatible with nothing and
ridiculously complex, is any less stupid?

Your unstated assumption is that POSIX had to settle on *something*.
That's crazy. You don't go making standards this way. It is far, far
better to leave something completely unstandardized than to invent a
standard out of thin air.

Readers of comp.unix.wizards will have seen my new, extremely simple job
control model, inspired by a comment from Chris Torek. The model solves
all the problems that POSIX invented sessions to solve. It doesn't need
cttys or sessions. The programming interface consists of exactly three
function calls for manipulating process groups, yet it's enough to
implement a job-control shell. It doesn't interfere with BSD or POSIX
job control, so vendors can implement it safely.

Five people responded to that article. Three liked the model. One asked
how he could do certain operations; there were solutions in each case,
but he did convince me that it would probably be easier if one of the
calls were extended or a new call were available.

The last observed acidly that I'd never get NIST to change its mind
about a FIPS. Job control will never change again.

She was right. I like to think that if POSIX hadn't tried to standardize
job control, some vendors would have implemented my model, some programs
would have been written to use it, and eventually the sheer simplicity
of the interface would win most vendors and programmers over within five
or ten years. But POSIX did standardize job control. They took BSD job
control, mangled it, patched it so that the flaws were well concealed,
and made it into a standard that won't change in the foreseeable future.
Even worse, although they sensibly decided to make job control a mere
option, they made the patches mandatory. NIST drove the last nail when
it required the option as well.

I doubt that anything will change now. Vendors climb the POSIX peak and
think their users will be happy. They don't want to experiment---who can
improve on a standard? I can rewrite job control programs to use my
model, but without a platform I won't be able to convince anyone else to
follow my lead. Even Berkeley---once the home of UNIX innovation---cares
more about POSIX compliance than about trying to make life simpler for
programmers.

And you, Chuck, tell me that this is how it should be.

> To elaborate on the security and efficiency issues, I fail to
> see that either getconf or /inst/bin has any impact on the
> administrator's ability to maintain reasonable system security.

As others have pointed out, it is rather difficult to introduce getconf
into a system so that it actually increases security. You have to change
system() so that it always uses sh. You have to make getconf---or at
least the path part of it---a shell builtin. Programs which want to use
this convention for a secure PATH then have to spawn an extra process.

In contrast, to introduce /inst/bin into a system is easy. Just make the
directory and add the links. Programs which want to use this convention
for a secure PATH can simply call /inst/bin/tee and so on. Even better,
if you do want to go to all the effort of recompiling programs and
changing libraries, you can change the default login path to /inst/bin,
and all your old programs will use the path automatically. On some
systems you don't even have to recompile---you can just add a line to
/etc/cshrc and /etc/profile.

> As others have pointed out, the efficiency of using /inst/bin
> depends on the implementation.

Ah, but at least it's getting faster, as more and more vendors adopt
symlinks. For comparison, the efficiency of getconf doesn't really
depend on the implementation. It's slow everywhere.

> I consider it to be a poor
> candidate for standardization.

Oh, I do too. I consider every solution to this problem to be a poor
candidate for standardization, because (drum roll):

    The Market Hath Not Chosen A Solution.
    The Market Hath Hardly Even Considered The Problem.

Can you name a single vendor which has a solution to the problem of a
secure path for installed utilities? I'm listening.

> >In this particular case, existing programs can be used with /inst/bin
> >without even changing the source code. All you have to do is change the
> >default system PATH. Adding getconf to a program means that the program
> >will no longer work on the vast majority of systems. That's what I mean
> >by unportable.
> There's a simple fix that makes such scripts work:  install
> getconf.

But that requires work on the part of *everyone* who wants to use the
script! Surely you admit that this is not a good thing when it can be
avoided.

> The issue of script portability is something of a red herring,
> because it has never been possible to write really portable
> scripts.

Uh, say what? People *do* write scripts all the time which work on lots
of systems; Configure is a supreme example, but nearly every script is
portable to similar machines.

> getconf, sysconf(), pathconf() and fpathconf() exist to make it
> possible to allow programs to make full use of system
> capabilities without being re-compiled for differently-
> configured members of a binary-compatible family and without
> being crippled down to a lowest common denominator.

Here's your unstated assumption again: that the standard *has* to
provide some way to do anything that systems code might want to do.
Why? Why is this sort of invention better than letting the market come
to a consensus on each feature first?

---Dan

Volume-Number: Volume 24, Number 60

From [e-mail]  Wed Jul 24 15:46:31 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA06246; Wed, 24 Jul 91 15:46:31 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20171; Wed, 24 Jul 91 15:46:17 -0400
Newsgroups: comp.std.unix
From: Alain Williams <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Parliament Hill Computers Ltd
Date: Tue, 23 Jul 1991 09:14:17 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Alain Williams)

> >A puzzle for the reader (maybe this is obvious to everyone but
> >me):  How can a shell script determine whether it's running on
> >a POSIX.2 system?  If it calls getconf and getconf does not
> >exist, the shell may exit.  It could call getconf in a
> >subshell, but that's ugly and expensive.
>
> I don't know what POSIX says, but I'd expect an analog to POSIX.1 -
> an environment variable telling which version of POSIX we are.
> POSIX.1 does the same with #define.
Yuck! There is too much in the environment already, and anyway it is far
too easily changed (accidentally or otherwise).

What is really wanted is something which can be easily put onto systems, both
new and existing. One of the problems is "OK we invent a way of doing it,
but there are still many systems out there which won't have it/do it". Have
you tried writing a portable program in ansi C ? We have to live with the
old ones for a while.

The old machines had commands like `vax' and `pdp11'. That was never really
developed/continued (sigh).

OK, use getconf, but what if it doesn't exist. Well, you could use my `path'
program to find out if it exists. It is a (Bourne) shell script, so portable
and not very long. I will post it to this list if you think that it would
be useful. I use it quite a lot for all sorts of things, eg:
    size `path emacs vi`
and it can be illuminating to try:
    path -a some_command

Alain Williams
[phone]
phLOGIN our Turnkey Security Login utility is available NOW - ask me for info.

Volume-Number: Volume 24, Number 61

From [e-mail]  Wed Jul 24 15:46:37 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA06287; Wed, 24 Jul 91 15:46:37 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20180; Wed, 24 Jul 91 15:46:21 -0400
Newsgroups: comp.std.unix
From: peter da silva <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Ferranti International Controls Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Date: Tue, 23 Jul 1991 18:10:28 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (peter da silva)

In article <[e-mail]>, [e-mail] (Chuck Karish) writes:
> POSIX sessions were invented because, when the working
> group tried to write a specification for job control, they
> discovered that the BSD behavior was underspecified and
> inconsistent.  They chose invention as the lesser of two
> evils rather than standardize on something that was wrong.

How about just leaving it out altogether?

Seriously... what is so compelling about job control that it *must* be
put into POSIX.2?

[ I think Peter means .1 -- mod ]

--
Peter da Silva; Ferranti International Controls Corporation; [phone];
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"


Volume-Number: Volume 24, Number 62

From [e-mail]  Wed Jul 24 15:46:57 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA06379; Wed, 24 Jul 91 15:46:57 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20291; Wed, 24 Jul 91 15:46:35 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mindcraft, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 23 Jul 1991 23:19:39 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
(Dan Bernstein) writes:
>[e-mail] (Chuck Karish) writes:

>I like to think that if POSIX hadn't tried to standardize
>job control, some vendors would have implemented my model, some programs
>would have been written to use it, and eventually the sheer simplicity
>of the interface would win most vendors and programmers over within five
>or ten years.
>And you, Chuck, tell me that this is how it should be.

Sorry, Dan.  No more straight lines from me.  You'll have to
provide your own soapbox.

>I consider every solution to this problem to be a poor
>candidate for standardization, because (drum roll):
>
>    The Market Hath Not Chosen A Solution.
>    The Market Hath Hardly Even Considered The Problem.
>
>Can you name a single vendor which has a solution to the problem of a
>secure path for installed utilities? I'm listening.

The 1003.2 committee doesn't even see the same problem that
Dan Bernstein does.  _CS_PATH is there for usability, not
for security.

Market forces tend to cause divergence on many technical
points, rather than agreement.  UNIX systems have been able
to stay reasonably compatible through the years because of
a lack of market forces in shaping the basic system: AT&T
owned it and sold it at reasonable rates with few restrictions.
Over the last four years competition has splintered the
market for UNIX-based workstations.

>> There's a simple fix that makes [getconf-using] scripts work:  install
>> getconf.
>
>But that requires work on the part of *everyone* who wants to use the
>script!

Not everyone; just every system administrator who wants to
run new software on an obsolete operating system.  Good
scripts will be written to work properly with or without
getconf, anyway.

>> The issue of script portability is something of a red herring,
>> because it has never been possible to write really portable
>> scripts.
>
>Uh, say what? People *do* write scripts all the time which work on lots
>of systems; Configure is a supreme example, but nearly every script is
>portable to similar machines.

If they require "similar machines", what does "portable" mean?
UNIX utilities vary quite a bit in syntax, return status, and
undocumented internal limits.  The goal of POSIX.2 is to get
rid of a lot of these pitfalls.  getconf is there to make
visible those differences that aren't to be eliminated.

"Configure" is a particularly ironic example, because it makes
inferences about the host that don't always stand up on
machines that have multiple universes or lots of compatibility
features.  It has unbounded potential (and need) for increase
in complexity as it's developed to handle new environments.
That is exactly why standards are needed.  getconf is intended
to provide definitive answers to some of the questions that
Configure has to guess about.

Configure could be used to write an implementation of getconf
for an OS that fits its preconceptions.

>> getconf, sysconf(), pathconf() and fpathconf() exist to make it
>> possible to allow programs to make full use of system
>> capabilities without being re-compiled for differently-
>> configured members of a binary-compatible family and without
>> being crippled down to a lowest common denominator.
>
>Here's your unstated assumption again: that the standard *has* to
>provide some way to do anything that systems code might want to do.
>Why?

Hyperbole aside (though I'm sure you could implement job
control from the POSIX.2 shell, Dan ;-), it's because software
developers and end users want software that doesn't have to be
hacked every time they want to run it on a new platform.

>Why is this sort of invention better than letting the market come
>to a consensus on each feature first?

There's no way to unbundle the features so that market feedback
on each individual feature can be meaningful.  "The Market"
seems to be demanding shrink-wrap software for workstations.
This sort of standardization helps make that possible.
--

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]


[ Moderator's note:  The previous message, by Peter da Silva, went out with
  the wrong number.  It should have been Volume 24, Number 62.  I apologise
  for the error -- mod ]

Volume-Number: Volume 24, Number 63

From [e-mail]  Wed Jul 24 20:02:31 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA26194; Wed, 24 Jul 91 20:02:31 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19612; Wed, 24 Jul 91 20:02:19 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: job control
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 24 Jul 1991 23:11:35 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (peter da silva) writes:
>How about just leaving it out altogether?
>Seriously... what is so compelling about job control that it *must* be
>put into POSIX.[1]?

Back in the days of the /usr/group standard, POSIX.1's predecessor, one of
the things that Ian Darwin and I were happiest about was that we'd managed
to persuade that committee that job control and all its competitors were
grotesque and inadequate botches which should not be standardized.  I still
blame myself for getting preoccupied with other things and letting it get
its slimy tentacles back into POSIX.1.

Apart from the ability to suspend processes -- in itself a trivial facility
that could be made fairly inoffensive -- what job control is about is
multiplexing your terminal among multiple processes.  Unfortunately it does
the easiest part -- deciding where keystrokes go -- and punts all the
hard parts, like saving and restoring the state of the tty and the screen,
to the user processes.  A proper implementation of such a facility would
be completely invisible to user processes:  no funny signals, no need to
save and restore tty modes, no need to redraw the screen at random times.
Just a virtual keyboard which is sometimes connected to the real one (and
blocks you if you ask for input when it isn't) and a virtual screen which
is sometimes visible on the real one (and might or might not block on output
when it's not), with the system doing the multiplexing in the same way
it multiplexes access to the disk, the processor, etc... and no impact on
user programs at all.

Ironically, job control was reasonable for POSIX.1 to consider precisely
*because* it oozes its way into every program, and hence has to be thought
about in any application-to-system interface.  Hence the canonicalization
of a wretched botch, while proper solutions were "outside the scope of .1"
and hence were not even considered.
--
Lightweight protocols?  TCP/IP *is*     | Henry Spencer @ U of Toronto Zoology
lightweight already; just look at OSI.  |  [e-mail]  utzoo!henry


Volume-Number: Volume 24, Number 64

From [e-mail]  Thu Jul 25 03:31:28 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA20549; Thu, 25 Jul 91 03:31:28 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23972; Thu, 25 Jul 91 03:31:19 -0400
Xref: kithrup comp.std.unix:281 comp.os.misc:598
Newsgroups: comp.std.unix,comp.os.misc
From: "Thomas M. Breuel" <[e-mail]>
Subject: Re: job control
Message-Id: <[e-mail]>
Followup-To: comp.os.misc
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: MIT Artificial Intelligence Lab
References: <[e-mail]>
Date: Thu, 25 Jul 1991 04:28:40 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Thomas M. Breuel)

[e-mail] writes:

   Apart from the ability to suspend processes -- in itself a trivial facility
   that could be made fairly inoffensive -- what job control is about is
   multiplexing your terminal among multiple processes.  Unfortunately it does
   the easiest part -- deciding where keystrokes go -- and punts all the
   hard parts, like saving and restoring the state of the tty and the screen,
   to the user processes.  A proper implementation of such a facility would
   be completely invisible to user processes:  no funny signals, no need to
   save and restore tty modes, no need to redraw the screen at random times.
   Just a virtual keyboard which is sometimes connected to the real one (and
   blocks you if you ask for input when it isn't) and a virtual screen which
   is sometimes visible on the real one (and might or might not block on output
   when it's not), with the system doing the multiplexing in the same way
   it multiplexes access to the disk, the processor, etc... and no impact on
   user programs at all.

It is far from obvious to me that this is the "right" thing to do.
Several systems, including ITS, have tried to keep track of the state
of the screen and keyboard at a system level, and I personally have
always disliked the result. It means that the system (either a
standardized library, or, more likely, the kernel), need to know much
more about terminals than they ought to. The result is usually that such
systems enforce suboptimal interfacing between programs and the
terminal.

I think it is not unreasonable to expect of screen oriented programs
to be able to redraw the screen when they get brought into the
foreground. This is completely analogous to window based programs having
to redraw their windows when they get exposed.

                    Thomas.

[ I, personally, would love to see this discussion continue.  But it
  is no longer relevent to this group, so I put in a Followup.
  Thank you for your support -- mod ]

Volume-Number: Volume 24, Number 65

From [e-mail]  Thu Jul 25 03:31:36 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA20562; Thu, 25 Jul 91 03:31:36 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23998; Thu, 25 Jul 91 03:31:28 -0400
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: File system/directory structure standards needed
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 25 Jul 1991 06:12:03 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dan Bernstein)

[e-mail] (Chuck Karish) writes:
> >Can you name a single vendor which has a solution to the problem of a
> >secure path for installed utilities? I'm listening.
> The 1003.2 committee doesn't even see the same problem that
> Dan Bernstein does.  _CS_PATH is there for usability, not
> for security.

My apologies. Let me rephrase the question, in a way that will no longer
let you beat around the bush: Can you name a single vendor which has a
solution to the problem of a *usable* path for installed utilities? I'm
listening. And, once again: I consider every solution to this problem to
be a poor candidate for standardization, because (drum roll):

    The Market Hath Not Chosen A Solution.
    The Market Hath Hardly Even Considered The Problem.
    The Market Apparently Doth Not Even Care.

> Market forces tend to cause divergence on many technical
> points, rather than agreement.

So you're saying that free market competition is a bad thing, and that
premature standardization is a good thing. Or did I misunderstand? Or
are you claiming that a standard which doesn't reflect reality at its
inception, and which rapidly becomes obsolete, isn't premature?

---Dan

[ A couple of requests:
  1.  Can we keep the discussion civil?  It's on its way to leaving that...
  2.  The subject is only marginally relevent; could it be changed?
  I do not wish to do either of those, since the authors of the messages
  are far more capable of doing so.  Thanks, gentle readers -- mod ]

Volume-Number: Volume 24, Number 66

From [e-mail]  Tue Jul 30 15:50:46 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA23802; Tue, 30 Jul 91 15:50:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22917; Tue, 30 Jul 91 15:50:41 -0400
Newsgroups: comp.std.unix
From: Mil Ratcliff <[e-mail]>
Subject: Portable way to get a host name?
Message-Id: <[e-mail]>
Summary: Is there a portable way to get a host name?
Originator: [e-mail]
Keywords: hostname
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 30 Jul 1991 19:46:09 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Mil Ratcliff)

SunOS provides the gethostname() call to return the host name for the current
machine.  Neither the POSIX books(D.  Lewine) nor the XPG books have a similar
call.

Is there a portable way to get a host name or must it be done on a system
by system basis?

--
Milt Ratcliff                                            [e-mail]
PE-Nelson                                                +1.408.725.1107
10040 Bubb Road
Cupertino, CA  95014

Volume-Number: Volume 24, Number 67

From [e-mail]  Tue Jul 30 16:56:47 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA17442; Tue, 30 Jul 91 16:56:47 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09362; Tue, 30 Jul 91 16:56:43 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: Portable way to get a host name?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]>
Date: Tue, 30 Jul 1991 20:22:55 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Mil Ratcliff) writes:
>SunOS provides the gethostname() call to return the host name for the current
>machine...  Is there a portable way to get a host name ...

The very concept of a host name -- a unique readable name for the host --
is not (fully) portable.  No, there is no universal way to get it.
--
Arthritic bureaucracies don't tame new  | Henry Spencer @ U of Toronto Zoology
frontiers. -Paul A. Gigot, WSJ, on NASA |  [e-mail]  utzoo!henry

[ What about POSIX and networking? -- mod ]

Volume-Number: Volume 24, Number 68

From [e-mail]  Tue Jul 30 20:23:09 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA09265; Tue, 30 Jul 91 20:23:09 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22003; Tue, 30 Jul 91 20:23:04 -0400
Newsgroups: comp.std.unix
From: Fletcher Kittredge <[e-mail]>
Subject: Re: Portable way to get a host name?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: Fletcher Kittredge <[e-mail]>
X-Submissions: [e-mail]
Organization: Bolt Beranek and Newman Inc., Cambridge MA
References: <[e-mail]> <[e-mail]>
Date: Wed, 31 Jul 1991 00:11:20 GMT
To: [e-mail]

Submitted-by: [e-mail] (Fletcher Kittredge)

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>Submitted-by: [e-mail] (Henry Spencer)
>
>In article <[e-mail]> [e-mail] (Mil Ratcliff) writes:
>>SunOS provides the gethostname() call to return the host name for the current
>>machine...  Is there a portable way to get a host name ...
>
>The very concept of a host name -- a unique readable name for the host --
>is not (fully) portable.  No, there is no universal way to get it.
>--

POSIX 1003.1 contains the uname(2) system call which returns a structure
holding information about the host.  One of the fields of the structure
is nodename, the current name of the host on a communications network.
It functions correctly on Sun O/S, DEC Ultrix and HP-UX.

regards,
fletcher
/* Fletcher Kittredge
 * BBN Software Products
 * 150 CambridgePark Dr,  Cambridge, MA. 02140
 * 617-873-3465  /  [e-mail]  /  [e-mail]
 */

Volume-Number: Volume 24, Number 69

From [e-mail]  Wed Jul 31 18:34:02 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA11323; Wed, 31 Jul 91 18:34:02 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15591; Wed, 31 Jul 91 18:33:56 -0400
Newsgroups: comp.std.unix
From: Steve March <[e-mail]>
Subject: Re: Portable way to get a host name?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 31 Jul 1991 05:37:24 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Steve March)

The best I've been able to do from the shell (ksh) is ..

export HOSTNAME=$(hostname || uname -n)

The first probably maps into the gethostname(2) and the second to uname(2).
In my experience, uname(2) is more portable.

Hope this is helpful.

-Steve

===============================================================================
Steve March                            (H) [phone]/328-5230  (W) 333-7408
Domain: [e-mail]             Path: {uunet|convex|pur-ee}!uiucdcs!march
"Time and space are modes by which we think and not conditions in which
 we live."  - Albert Einstein


Volume-Number: Volume 24, Number 70

From [e-mail]  Wed Jul 31 18:34:09 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA11352; Wed, 31 Jul 91 18:34:09 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15623; Wed, 31 Jul 91 18:34:02 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: Portable way to get a host name?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 31 Jul 1991 16:46:08 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Fletcher Kittredge) writes:
>>The very concept of a host name -- a unique readable name for the host --
>>is not (fully) portable.  No, there is no universal way to get it.
>
>POSIX 1003.1 contains the uname(2) system call which returns a structure
>holding information about the host.  One of the fields of the structure
>is nodename, the current name of the host on a communications network.

However, note the fine print a few lines further down:

"The inclusion of the *nodename* member in this structure does not imply
that it is sufficient information for interfacing to communications
networks."

In other words, it's not guaranteed to be the "host name" in the sense
of the original inquiry.  Indeed, on most current implementations that
field is too small to hold an Internet domain name of even modest length,
assuming that an Internet domain name is what you want.  On most SV-derived
implementations, *nodename* has room for only an 8-character name.  That
won't even hold "zoo.toronto.edu" or "spca.bbn.com", never mind some of
the atrocities that show up.

I stand by my original comment.  Fletcher's confusion here is an example
of the lack of any standard for what a "host name" should be and what it
should be good for.
--
Arthritic bureaucracies don't tame new  | Henry Spencer @ U of Toronto Zoology
frontiers. -Paul A. Gigot, WSJ, on NASA |  [e-mail]  utzoo!henry


Volume-Number: Volume 24, Number 71

From [e-mail]  Fri Aug  2 20:31:59 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA26495; Fri, 2 Aug 91 20:31:59 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02285; Fri, 2 Aug 91 20:31:52 -0400
Newsgroups: comp.std.unix
From: Rich Pinder <[e-mail]>
Subject: AWK - ?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: University of Southern California, Los Angeles, CA
Date: Fri, 2 Aug 1991 23:47:15 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Rich Pinder)

I have a question regarding the behavior of AWK.  The following
program successfully alters the value of one the fields as a result
of the 'if' conditional (changes the name LEROY to Snakely).
However, the output from the print statement seems to leave off the
field seperators on lines that were altered, but puts them in
correctly on others.  Is this a bug with my version (SCO's 3.2)?

Thanks for your help:

_prog:_

awk -F '|' ' {
     if ($3 == "LEROY") $3="Snakely";
         print $0  ;
        } ' $*
_input:_

00011|CARNEY|LEROY
00012|CARNEY|ROBERT
00021|MCDONALD|ALICE

_output:_

00011 CARNEY Snakely
00012|CARNEY|ROBERT
00021|MCDONALD|ALICE


        Rich Pinder
        USC School of Medicine
        [phone]

        [e-mail]

    ||||||||||||||||||||||||||||||||||||||||||||||||||


Volume-Number: Volume 24, Number 72

From [e-mail]  Sun Aug  4 05:19:28 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA11827; Sun, 4 Aug 91 05:19:28 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22910; Sun, 4 Aug 91 05:19:20 -0400
Newsgroups: comp.std.unix
From: Henry Spencer <[e-mail]>
Subject: Re: AWK - ?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]>
Date: Sat, 3 Aug 1991 23:26:40 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Rich Pinder) writes:
>However, the output from the print statement seems to leave off the
>field seperators on lines that were altered, but puts them in
>correctly on others.  Is this a bug with my version (SCO's 3.2)?

No.  The -F option sets the FS variable, but not the OFS variable,
which is what is used for reconstructing $0 when a field is modified.
The output you are getting is correct.  Adding a `BEGIN { OFS = FS }'
to the awk program will get you what you're after.
--
Arthritic bureaucracies don't tame new  | Henry Spencer @ U of Toronto Zoology
frontiers. -Paul A. Gigot, WSJ, on NASA |  [e-mail]  utzoo!henry

[ Also noted by William Lewis Jr. ([e-mail]) -- mod ]

Volume-Number: Volume 24, Number 73

From [e-mail]  Wed Aug 14 20:16:35 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA14212; Wed, 14 Aug 91 20:16:35 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07683; Wed, 14 Aug 91 20:16:16 -0400
Newsgroups: comp.std.unix
From: "Stephen R. Walli" <[e-mail]>
Subject: Report on the July IEEE POSIX Meeting for EurOpen
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Wed, 14 Aug 1991 17:51:28 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.


                                  - 1 -



       ------------------------------------------------------------------
       Report on the July IEEE POSIX Meeting for EurOpen
       POSIX is a family of standards which has grown in a hodge-
       podge fashion since its formal IEEE birth in 1985.  It
       started small with a specific goal in mind, and it can be
       argued that the need is answered by the POSIX.1 standard
       otherwise known as ISO/IEC 9945-1.  Somewhere along the way,
       the process grew dramatically.  An explosion of projects
       under the banner of POSIX has created a huge complex entity
       which everyone expects to fulfill their own diverse needs.

       Managing this complexity has been pretty informal using
       seat-of-the-pants discussions until the recent past. Long
       talked about Committees are being created and are gaining
       momentum. The management process is being put in place to
       hopefully co-ordinate this huge volunteer effort of building
       an industry standard for something as complex as a full
       function operating system. (By management, I refer to the
       process co-ordination type, not the suit-and-tie type.)

       IEEE POSIX meetings now have two very different faces.
       There is the work group face. Each individual working group
       has a chair dedicated to the task of preparing a specific
       draft document to be balloted for eventual acceptance as a
       standard. Knowledgeable volunteers work in these rooms
       discussing, editing and arguing the issues for their
       particular corner of POSIX.

       Then there's the co-ordination face. Here, also, we are
       beginning to see an explosion of committees.  There are now
       steering committees dedicated to:

          - Conformance Testing issues across all projects,

          - Distributed Services issues across the several working
            groups involved with network oriented interfaces,

          - Windowing User Interfaces issues,

          - Profiling issues within POSIX, and their relationship
            to profiles at large.

       The Project Management Committee (PMC) is a subcommittee of
       the Sponsor Executive Committee (SEC).  The SEC is the
       guiding force behind the IEEE's Technical Committee on
       Operating Systems m Standards Subcommittee (TCOS-SS).
       TCOS-SS is responsible for Operating Systems standards. The
       PMC reviews new project requests (PARs) and checks on the
       status of current working group projects.












                                  - 2 -



       A new Ad Hoc Committee began meeting in Santa Clara to
       discuss the fundamental issues of ``a POSIX architecture.''
       What does this ``thing'' look like? Will the Security
       extensions to ISO/IEC 9945-1:1990 (POSIX.1) work together
       with the Real-Time extensions?  What happens when the
       Transparent File Access extensions are added to the picture?

       Here we cover the recent IEEE POSIX working group meeting
       from the co-ordination point of view, tracking events across
       the projects instead of covering the individual projects
       from within.


       The Project Management Committee

       July's meeting was the second set of working meetings of the
       PMC.  This group is still getting used to its role as a
       project reviewer and scrutinizer of new project
       authorization requests (PAR). PARs are created for each
       draft document in the process. Once a PAR has been passed by
       the PMC, and accepted for sponsorship by the TCOS-SS SEC, it
       arrives at the IEEE's Standards Advisory Board for final and
       formal acceptance as a work item for a working group.

       The PMC suffered the same malaise the rest of POSIX projects
       suffer at times. People were extraordinarily busy with their
       ``real employment'' between the April and July meetings.
       Many of the reviews of existing projects which were
       scheduled for this meeting weren't done.

       The mentor for POSIX.0 (POSIX Guide) completed her review of
       the project. POSIX.0 has become real. It began initially as
       a working group of people with a higher level of concern for
       POSIX. It was the group holding discussions about how POSIX
       would be used in a more global sense, rather than minute
       examination of the nitty-gritty individual function calls or
       language bindings.  POSIX.0 isn't building a document for
       standardization, but rather an overall guide to Open Systems
       Environments. It was through this group's efforts that the
       Profiles Steering Committee was born.

       The POSIX.0 document is now being strongly lobbied for
       acceptance as an ISO Technical Report. Many issues which
       have been left to rest for quite some time now, are all
       rearing up again.

       It was assumed when the group was formed, that the other
       working groups would automatically provide the liaison
       people to ensure the models in the Guide were accurate. This
       did not happen. The PMC reported on this lack of involvement
       and took steps to get the SEC to ensure there is adequate











                                  - 3 -



       review of the Guide by other working groups.  The
       participation of working groups was also demanded in the
       discussion about architecture framework.  This will
       hopefully see action at the next IEEE POSIX meeting in
       October.

       The one new PAR reviewed by the PMC at this meeting was the
       request from POSIX.5 (Ada Bindings) for a project to address
       POSIX real-time extensions.  This work passed the PMC with
       some minor word-smithing, and is discussed later.

       Language Independence Specifications

       Programming language independent specifications (LIS) are a
       requirement placed on the IEEE POSIX working groups by ISO.
       The current and future C based functional interfaces will
       eventually be described semantically in an LIS and with
       various different programming language bindings associated
       with each.

       A language independent specification of POSIX.1 and its C
       binding (POSIX.16) now exist. These documents will shortly
       go out for mock ballot. A mock ballot is useful for finding
       remaining problems with a document prior to being sent for
       real ballot. For comparison reasons POSIX.1/LIS, POSIX.16
       and the ANSI C standard should be equivalent to the existing
       ISO 9945-1 standard.

       The ballot period will hopefully be 45 days, starting early
       August.  The mock will be sent to the POSIX.1, POSIX.5,
       POSIX.9 mailing lists, but it is an open ballot.

       It was suggested that the TCOS-SS Programming Language
       Independent Specification Guidelines should also be added to
       the ballot since readers may find something they consider
       incorrect, and is pervasive in the documents because it is
       due to a particular method or guideline from the Methods
       document.

       General ballot instructions include:

          - determining the equivalence of the new LIS and C
            Binding to the existing 9945-1, (remember, 9945-1
            cannot be broken);

          - determining if the LIS and C Binding clearly relate;

          - determining whether the split of material between the
            LIS and C Binding is a coherent one, and













                                  - 4 -



          - determining how easy it is to produce another language
            binding to the the LIS.

       There are still many questions to be answered with the LIS
       work. Conformance specifications for the LIS and the nature
       of test methods are much talked about issues. The validity
       of the current object model for LIS and the lack of an event
       model are problems to be addressed. Interoperability is
       still not addressed formally.  Hopefully, the mock ballot
       will contribute to all of these areas.

       The other POSIX language bindings, Ada (POSIX.5) and
       FORTRAN-77 (POSIX.9), are still proceeding with their ballot
       resolution process. ISO/IEC JTC1/SC22/WG15 has accepted the
       POSIX.5 and POSIX.9 position of finishing their current
       ballot and producing language bindings to future LIS in the
       revised ISO languages once all of those documents exist and
       are stable. Current drafts were circulated at the May WG15
       meeting for review and comment.  New Zealand has proposed
       building a Modula-2 binding to POSIX.1 as a work item to
       ISO.

       Within the POSIX working groups there is a new wrinkle with
       the LIS work.  POSIX.12 (Protocol Independent Interfaces) is
       proposing to do two bindings to an as yet undefined LIS one
       for BSD sockets, and one for X/Open's Transport Interface
       (XTI).  Two language bindings to the same LIS isn't unusual.
       They just happen to be in the same language!  A lot of this
       has to do with two established bodies of experience unable
       to compromise, and attempting to arrive at a creative
       solution.

       I don't believe that they've really thought it through.
       Harmonizing the functionality in the two existing C bindings
       to an independent specification will be non-trivial and
       possibly infeasible. If the functionality is completely
       covered by the LIS and the two bindings wholly overlap, why
       are they not harmonizing the interfaces?

       Another twist is the interoperability question between two
       language bindings.  People often use the example of one
       program running in one process context written in one
       language which writes a pipe, should be understood by a
       different program in a different process context written in
       a different language reading the pipe. I don't think the
       intent here is that a program using sockets will communicate
       directly to a program written to use XTI.















                                  - 5 -



       Profiles Steering Committee

       July was the first working meeting of the Profiles Steering
       Committee (PSC). The fledgling group is attempting to
       wrestle with a gargantuan task. They seem torn between
       trying to sort out the possibly limited and thorny problems
       of POSIX profiles, versus helping to solve the world's
       profiling and frame work problems. That is a somewhat naive
       statement, based on my narrow view of what a profile could
       be, and should understandably be taken liberally salted.

       The first meeting became somewhat mired in liaison issues
       with the rest of the world.  They were fortunately able to
       pull out of this mode and formed two small working groups to
       address two specific problems.

       One small group dealt with the harmonization of terminology
       across various different groups working both inside and
       outside of POSIX.  The second group dealt with formulating
       the rules by which POSIX profiles are built. Both of these
       groups made good progress during the rest of the week.

       Ada Real-time Study Group

       The POSIX Ada working group (POSIX.5) wants to begin
       building a binding to the POSIX.4 Real-time Extensions. They
       received permission to start a study group at the April
       meeting, and had a project request formally approved at this
       meeting. The new project, christened POSIX.5a (Ada Binding
       to POSIX.4), is under the direction of the current POSIX.5
       working group.

       The group is not extending the Ada language for real-time
       capabilities. They are binding to the currently defined
       POSIX.4 interface definitions. The ``thick'' binding versus
       ``thin'' binding issue has been put off. A language
       independent specification of POSIX.4 does not yet exist.
       The group will continue in their current process of building
       usable documents for programmers.

       The group recognizes that there is a co-ordination issue
       with ISO for both SC22/WG9 (Ada) and for the current
       proposed work item for Real Time Ada Extensions (ISO/IEC
       JTC1 N1266, dated 1991-02-22). This is the ExTRA (Extensions
       Temps Re'el a` Ada ...) work from AFNOR, the French member
       body of ISO.  As yet, ISO has not assigned sponsorship for
       this work item.















                                  - 6 -



       GUI Wars Revisited

       _W_e'_r_e _b_a_a_a_a_c_k ...

       For the second meeting running, discussion was dominated by
       the two opposing direct ballot project requests for an Open
       Toolkit Environment (Open Look) and a Modular Toolkit
       Environment (OSF/Motif). These projects had been rejected
       ``at this time'' at the April meeting in Chicago.  A letter
       from Paul Borrill (vice-president for standards in the IEEE
       Computer Society, and a member of the IEEE Standards Board)
       forced the re-opening of the issue.  The letter was seeking
       reasons for rejection and stated that two standards in the
       same project space was not sufficient reason to reject the
       requests.

       A subcommittee was formed early in the week to summarize all
       of the discussions that took place at the April meeting.
       After many meetings and much writing, the subcommittee
       delivered its report at Thursday evening's SEC meeting.

       The SEC members were asked if they agreed with any of the
       statements (pro and con) contained in the sub-committee's
       report.  The majority of the statements were against
       acceptance of the PARs.  Many SEC members had many problems
       with accepting the two PARs.  This is how the motion to
       sponsor both PARs failed.  A quick straw poll demonstrated
       that many people felt there was a fundamental problem with
       the projects.  These problems would not go away with some
       rewording or re-organization of the PAR.

       It was readily acknowledged that the documents could not
       move forward as direct ballot documents. This was a fast
       track option to be used with non-controversial documents.
       Clearly not the case here. This should have been used in
       April as the stopping point!  A real vote was then taken and
       the motion to sponsor the projects failed.

       People barely caught their breath when a motion to remove
       sponsorship from P1201 was made. (You could have heard a pin
       drop ...).  The rationale is that P1201 was supposed to be
       developing a standardized toolkit for windowing and clearly
       suffers from the same fundamental flaws as the two defeated
       project requests.

       P1201 has been moving ahead for several meetings, working to
       an unrecognized project scope.  The working group has been
       attempting to come up with a ``virtual'' toolkit for
       windowing, under which Motif or Open Look could be plugged.
       Indeed, they claim anything could be plugged into the new
       model, including a MacIntosh or Presentation Manager











                                  - 7 -



       interface.

       They have made substantial progress the past two meetings
       working with the XVT specification as a base document,
       probably because former supporters of Motif and Open Look
       have been busy with their own project requests. Now they
       face complete termination. This removal of sponsorship
       effects P1201.2 (Recommended Drivability Practise) as well.

       The motion to remove the P1201 sponsorship has been tabled
       until the October meetings. The Project Management Committee
       was due to review this project for the October meeting
       anyway, so it was felt they should be allowed to do their
       job first. What this really means is that yet another
       meeting is going to be turned on end with discussions of
       standardization of windowing interfaces.

       Institutional Representative Voting Issues

       A subcommittee of the Sponsor Executive Committee (SEC)
       recently balloted the TCOS Operating Procedures.  In general
       there is nothing too controversial in them, with one notable
       exception. The vote is being removed from TCOS SEC
       Institutional Representatives (IR). It is a sensitive enough
       issue that it is separately called out in a mini-ballot all
       by itself.

       The mini-ballot phrasing was slanted towards removing the
       vote, and has already been attacked on the net. Apparently
       history is the culprit here. It's always easy to blame
       history. It's never there to defend itself.

       The concept of IR was created within the IEEE standards
       arena with the intent of allowing other accredited standards
       organizations to have representation. TCOS extended the IR
       role to include X/Open, USENIX and Uniforum.  It looks good
       to be able to point to the greater acceptance of a standard
       by the technical community this way.

       Other groups applied for this status.  There was a small
       proliferation of IRs within the SEC. A concern was raised
       over the growing numbers of ``outside'' votes being
       generated.  With no good definition in the IEEE standards
       hierarchy as to what exactly an IR is, there's no way to
       limit the number.

       The results of the mini-ballot will be interesting. I
       personally objected on my ballot, arguing that IRs have a
       voting role and that the rules should be modified to
       adequately define IRs. All of the IRs can be reviewed in the
       light of the new definition.  There are already rules in











                                  - 8 -



       place to remove IRs. IRs often have a broader picture of
       POSIX than individual working group chairs, intent on their
       own working group progress and problems, and therefore add
       to the process.

       +---------
       --------------------------------------------------------------------+
       Stephen R. Walli                               SRW Software
       phone: [phone]                          572 Foxrun
       Court, fax:   [phone]
       Oshawa, Ontario, Canada, speaker![e-mail]   -OR-
       L1K 1N9 uunet!watmath!mks!speaker!stephe +---------
       --------------------------------------------------------------------+













































Volume-Number: Volume 24, Number 74

From [e-mail]  Thu Aug 22 15:24:08 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA21710; Thu, 22 Aug 91 15:24:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06698; Thu, 22 Aug 91 15:24:05 -0400
Newsgroups: comp.std.unix
From: Scott Johnson <[e-mail]>
Subject: POSIX Threads with UNIX
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Thu, 22 Aug 1991 17:23:06 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Scott Johnson)

Hello all,

    Does a POSIX compliant threads library for UNIX exist? I would like
to hear about any threads package, either public domain or 3rd party
offerings even if they are not POSIX compliant.

    If such a library does not exist, has anyone tried to simulate
threaded behavior using fork, exec, and shared memory?

    Please respond directly to [e-mail] as I do not normally
read this list.

Thankyou,

        -- Scott
        [e-mail]

[ I wasn't aware that a POSIX compliant threads-library for POSIX existed
yet -- mod ]

Volume-Number: Volume 24, Number 75

From [e-mail]  Thu Aug 22 16:37:50 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA14827; Thu, 22 Aug 91 16:37:50 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26955; Thu, 22 Aug 91 16:37:47 -0400
Newsgroups: comp.std.unix
From: Vladimir Ivanovic <[e-mail]>
Subject: P1003.2
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Sun Microsystems, Inc.
Date: Thu, 22 Aug 1991 20:26:10 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Vladimir Ivanovic)

I just called the IEEE Computer Society Washington office (1-202-371-0101) to
order the latest P1003.2 Shell and Utilites draft standard and was told that it
was no longer available from them because "it was being voted upon" and to
call 1-800-678-4333 (which follows banker's hours and closes at 4 PM!).

Is this draft 12 that's being voted upon?

A previous message said that Draft 12 (aka possibly 11.1) might be distributed
as a set of changes to Draft 11.  If this is so, where can one obtain the
original Draft 11 on which to base Draft 12?

Thanks for any help.

-- Vladimir
--
Vladimir G. Ivanovic                            Sun Microsystems, Inc
[phone]                                  MTV12-33
[e-mail]                            2550 Garcia Ave.
{decwrl,hplabs,ucbvax}!sun!Eng!vladimir         Mountain View, CA 94043-1100
                         Disclaimer: I speak for myself.

Volume-Number: Volume 24, Number 76

From [e-mail]  Thu Aug 22 17:00:39 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA22634; Thu, 22 Aug 91 17:00:39 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02546; Thu, 22 Aug 91 17:00:35 -0400
Newsgroups: comp.std.unix
From: Doug Ritter <[e-mail]>
Subject: System Evaluations
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mead Data Central, Dayton OH
Date: Thu, 22 Aug 1991 20:24:19 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Ritter)

Greetings all!

I have been given the task of developing a comprehensive hardware
evaluation procedure for our company.  This procedure should cover
*everything*, from CPU benchmarking to standards compliance.
I have no idea where to start with this, so I'm soliciting help
from the net.

Some specific questions I have are:

1)  Is there an existing suite of programs to test a system for
    POSIX compliance?

2)  Is it possible to get copies of the code used to do the TPC/A
    and TPC/B benchmarks?

3)  Where can I get copies of the code for other benchmarks?


And in general, could anyone offer some advice as how to approach
this task?  How do I go about developing a process generic enough
to evaluate two systems as different as say, an RS/6000 and an NCR
Enterprise 90?  *AND* come up with results that make a valid
comparison?  Are there any books on this topic?  Any organizations
where 'hardware evaluators' hang out?

Please reply by e-mail, if possible.
--
===============================================================================
Douglas N. Ritter                      Hoch und stiel leben!
[e-mail]
...!uunet!meaddata!dougr             No, I'm not speaking for MDC!

[ I think Douglas means 'system evaluations,' not 'hardware evaulations,'
  so I changed the subject to match -- mod ]

Volume-Number: Volume 24, Number 77

From [e-mail]  Thu Aug 22 19:00:46 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA04124; Thu, 22 Aug 91 19:00:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04883; Thu, 22 Aug 91 19:00:45 -0400
Newsgroups: comp.std.unix
From: Rich Stevens <[e-mail]>
Subject: XPG4 ?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Thu, 22 Aug 1991 22:18:33 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Rich Stevens)

Does anyone know anything about XPG4?  I've heard it referred to
a couple of times but haven't seen anything in print.  I've tried
sending e-mail to XPG in the UK, but you get back an automated
reply saying someone will contact you, then nothing.

    Rich Stevens  ([e-mail])


Volume-Number: Volume 24, Number 78

From [e-mail]  Thu Aug 22 21:30:25 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA07700; Thu, 22 Aug 91 21:30:25 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03461; Thu, 22 Aug 91 21:30:21 -0400
Newsgroups: comp.std.unix
From: [e-mail]
Subject: what units should df and du use?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: Project GLUE, University of Maryland
Date: Fri, 23 Aug 1991 01:20:32 GMT
To: [e-mail]

Submitted-by: [e-mail] (David J. MacKenzie)

[Reposting from gnu.announce for a wider distribution. -- djm]

[This is from rms, but please send replies to the reply-to addresses
shown in the header: [e-mail], [e-mail]]

The current draft of the POSIX user portability extensions spec says
that df and du should give sizes in units of 512 bytes.  I have found
this behavior confusing and inconvenient; I suspect others do too.

Some other people involved in the standards process have said they
prefer units of 1024; in response, the committee added the -k option,
which says to use 1024 instead of 512.

I think this is not a real solution.  The use of 512 as the unit will
make life difficult for beginning users who don't know about -k.  And
it seems silly to make 512 the default if users won't like it.

The committee chose 512, not because they think users prefer it,
but for totally unrelated reasons having to do with how BSD and
System V behave.  I think this decision should be made based on the
preferences of actual users.  If the users tell the committee what
they want, the committee may yet listen.

Aside from that, we can make the GNU system do what users prefer even
if that disagrees with POSIX.  We don't have to follow the standard.

But what do most users prefer?  To find out, here is a poll.


Which of these two alternatives would you prefer, and how much?

* df and du output is in units of 1024.

* df and du is in units of 512 unless you use -k.


[e-mail] is included in the reply-to field of this message
because he is the person to whom people not in the POSIX UPE committee
should send their comments on the spec.  It's important to send your
preference to him, because the committee must then officially
recognize that they know what you prefer.  And they have to pay at
least a little attention to your preference.  I invited him to set up
an alternative mailbox for these messages, but he said he'd rather get
them in his own mailbox.

I hope he gets a lot of mail. :-)
--
David J. MacKenzie <[e-mail]> <[e-mail]>


Volume-Number: Volume 24, Number 79

From [e-mail]  Fri Aug 23 02:03:45 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA20471; Fri, 23 Aug 91 02:03:45 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02892; Fri, 23 Aug 91 02:03:40 -0400
Newsgroups: comp.std.unix
From: "James Buster [e-mail]" <[e-mail]>
Subject: Re: POSIX Threads with UNIX
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: BTR Public Access UNIX, MtnView CA. Contact: Customer Service
    [e-mail]
References: <[e-mail]>
Date: Thu, 22 Aug 1991 23:03:10 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (James Buster [e-mail])

In article <[e-mail]> [e-mail] (Scott Johnson) writes:
>[ I wasn't aware that a POSIX compliant threads-library for POSIX existed
>yet -- mod ]

Not in general, although I have seen systems that implement Draft 9
of the Posix 1003.4a "pthreads" spec.
--
                James Buster
                   [e-mail]


Volume-Number: Volume 24, Number 80

From [e-mail]  Thu Aug 29 14:56:55 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA19686; Thu, 29 Aug 91 14:56:55 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13549; Thu, 29 Aug 91 14:56:50 -0400
Newsgroups: comp.std.unix
From: Simon Patience <[e-mail]>
Subject: Re: POSIX Threads with UNIX
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: Simon Patience <[e-mail]>
X-Submissions: [e-mail]
Organization: OSF Research Institute
References: <[e-mail]> <[e-mail]>,
Date: Mon, 26 Aug 1991 09:07:22 GMT
To: [e-mail]

Submitted-by: [e-mail] (Simon Patience)

In article <[e-mail]>, [e-mail]
(Scott Johnson) writes:
>     Does a POSIX compliant threads library for UNIX exist? I would like
> to hear about any threads package, either public domain or 3rd party
> offerings even if they are not POSIX compliant.

There is a 1003.4a Draft 4 compliant threads package in OSF/1. This will
be updated as the standard progresses. Some modification towards D5 has
been made but as D6 should be out "any day now" and will deviate
significantly from D5 in certain areas it is unlikely that any of these
will be supported until the draft is more stable and nearer adoption.

>     If such a library does not exist, has anyone tried to simulate
> threaded behavior using fork, exec, and shared memory?

I have also heard of a number of other threads packages being developed
but do not know if any are available as yet.

>     Please respond directly to [e-mail] as I do not normally
> read this list.

I suppose I will have to do this as well :-)

> [ I wasn't aware that a POSIX compliant threads-library for POSIX existed
> yet -- mod ]

So now you know!

Simon.

  Simon Patience
  Open Software Foundation            Phone: [phone]
  Research Institute                FAX:   [phone]
  2 Avenue De Vignate                Email: [e-mail]
  38610 Gieres, France                       uunet!gr.osf.org!sp


Volume-Number: Volume 24, Number 81

From [e-mail]  Thu Aug 29 14:57:00 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA19721; Thu, 29 Aug 91 14:57:00 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13555; Thu, 29 Aug 91 14:56:51 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: what units should df and du use?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Fri, 23 Aug 1991 20:52:02 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> rms writes:
>The committee chose 512, not because they think users prefer it,
>but for totally unrelated reasons having to do with how BSD and
>System V behave.  I think this decision should be made based on the
>preferences of actual users.  If the users tell the committee what
>they want, the committee may yet listen.

The real issue is whether a STANDARD should codify what existing
practice IS, or what it SHOULD HAVE BEEN.

If POSIX.2 really aims at devising new UNIX utility behavior, I
have a LOT of suggestions for improvement, and would suggest that
NEW NAMES be chosen for utilities implementing such improvements.
(Most of the common UNIX utilities have undesirable characteristics.)

If, on the other hand, POSIX.2 aims at providing a common platform
consistent with widespread practice, whenever there is a single
existing behavior then that is what the standard should specify.

A position should be adopted on this issue then adhered to.


Volume-Number: Volume 24, Number 82

From [e-mail]  Thu Aug 29 14:57:07 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA19779; Thu, 29 Aug 91 14:57:07 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13609; Thu, 29 Aug 91 14:57:03 -0400
Newsgroups: comp.std.unix
From: "Jan R. Cirpka" <[e-mail]>
Subject: Re: XPG4
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Philips Information Systems, P.O. Box 245,
References: <[e-mail]>;
Date: Tue, 27 Aug 1991 18:10:02 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jan R. Cirpka)

>
> Does anyone know anything about XPG4?  I've heard it referred to
> a couple of times but haven't seen anything in print.
>     Rich Stevens  ([e-mail])

There is currently no XPG4. X/Open and its member companies, among
them Philips are working on plans to release XPG4. It will take
some more time before it will become reality.

Regards

Jan

--
Jan R. Cirpka                        Domain: [e-mail]
                                     UUCP:   ..!mcsun!philapd!cirpka
Philips Information Systems          Tel:    [phone]
PG P9000 i V2-A07                    Telex:  36345 NLAEDCN
P.O. Box 245                         Fax:    [phone]
NL 7300 AE Apeldoorn, The Netherlands


Volume-Number: Volume 24, Number 83

From [e-mail]  Thu Aug 29 15:05:24 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA23181; Thu, 29 Aug 91 15:05:24 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15713; Thu, 29 Aug 91 15:04:43 -0400
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <[e-mail]>
Subject: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Project GLUE, University of Maryland
Date: Thu, 29 Aug 1991 17:25:35 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David J. MacKenzie)

[Reposting rms's message from gnu.announce for a wider distribution. -djm]

Last week users poured out into the streets of the network to rally to
the cause of 1024-byte blocks for measuring disk space.  When people
finally chose sides, it was amazing how few actually stood with the
POSIX Central Committee and its apparatchiks.  Only 20 out of 750
supported the 512ist coup.

In the aftermath, the GNU system has declared its independence,
throwing off the power of the POSIX party.  We are rapidly moving to
eliminate all vestage of 512ist domination.  We have already taken
direct control of df, du, and several other programs, converting them
to use 1024-byte units for measuring output, and to provide ways to
specify input quantities in units of K.

We promise to respect the rights of minorities--even tiny ones.  So
there will be options to request output in units of 512.  Even those
who cannot bear to deviate from the POSIX party line will be provided
for--they can define the environment variable POSIX_ME_HARDER.

But what we really hope is that the POSIX party will itself modernize
its hardline position, and add its support to 1024ist reform.  If the
KGB could do it, there must at least be a chance for POSIX.
--
David J. MacKenzie <[e-mail]> <[e-mail]>


Volume-Number: Volume 24, Number 84

From [e-mail]  Fri Aug 30 00:24:27 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA21524; Fri, 30 Aug 91 00:24:27 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10898; Fri, 30 Aug 91 00:24:25 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]>
Date: Thu, 29 Aug 1991 20:46:02 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (David J. MacKenzie) writes:
>Only 20 out of 750 supported the 512ist coup.

And how many supported the 1024th revisionists?
I know I expressed the opinion that the decision should not be made
until the underlying principles for making such decisions had been
established..  Did you count me on one side or the other?

>We promise to respect the rights of minorities--even tiny ones.  So
>there will be options to request output in units of 512.

There's no smaller nontrivial minority than me.  Can I specify bits or
bytes instead of artificial block sizes?


Volume-Number: Volume 24, Number 85

From [e-mail]  Fri Aug 30 13:55:45 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA16404; Fri, 30 Aug 91 13:55:45 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19846; Fri, 30 Aug 91 13:55:43 -0400
Newsgroups: comp.std.unix
From: Chris Ritson <[e-mail]>
Subject: Re: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: University of Newcastle upon Tyne, UK, NE1 7RU
References: <[e-mail]>
    <[e-mail]>
Date: Fri, 30 Aug 1991 08:52:27 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

A related issue to the units used by df/du...

On one of our  sun clusters, the computing service runs process
accounting, and find that they have to process the files on the
(dataless) clients, because if they do not do this, the figures
are wrong.

All this is because memory accounting seems somewhere to depend on
the memory page size (the server and the clients have different
memory page sizes), rather than being expressed in K-bytes. Once
again I think we need to work in K-bytes to make accounting files
portable.

Chris Ritson <[e-mail]>

EMAIL: [e-mail]       Chris Ritson,
PHONE: [phone]                  Computing Laboratory,
FAX  : [phone]                  University of Newcastle upon Tyne,
TELEX: uk+53654-UNINEW_G                UK, NE1 7RU


Volume-Number: Volume 24, Number 86

From [e-mail]  Fri Aug 30 13:55:49 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA16441; Fri, 30 Aug 91 13:55:49 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19864; Fri, 30 Aug 91 13:55:47 -0400
Newsgroups: comp.std.unix
From: Eric Gisin <[e-mail]>
Subject: POSIX.1 stream functions
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Date: Thu, 29 Aug 1991 17:25:28 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Eric Gisin)

I have POSIX 1003.1-1988 and 1990 in front of me.
Section 8.2.3 (Interaction with C stream functions) has some major changes.

Why was the requirement that fclose() set the file descriptor offset
to the stream offset removed? Note the 1990 rational is wrong.
This means applications have to do it themselves with
    fflush(fp);
    fseek(fp, 0L, SEEK_CUR);

I understand why fflush is no longer required to invalidate input buffers,
but is a 1990 implementation required to leave input buffers untouched
on non-seekable files? For example, can I write
    fgetc(stdin);        /* first byte */
    fflush(stdin);
    [fork(), child does not use stdin but does exit()]
    fgetc(stdin);        /* second byte */
without concern that stdin may be a pipe?
Or do I have to conditionalize the fflush with
    if (!seekable(fileno(stdin))
If so, how can I write seekable(), allowing for implementations
that have non-seekable devices other that ttys and pipes?

Or, when using fork(), is it required to use _exit() and explicit fflush()s?

        Eric Gisin, [e-mail]


Volume-Number: Volume 24, Number 87

From [e-mail]  Sat Aug 31 16:29:34 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA16614; Sat, 31 Aug 91 16:29:34 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26615; Sat, 31 Aug 91 16:29:32 -0400
Newsgroups: comp.std.unix
From: Chuck Karish <[e-mail]>
Subject: Re: what units should df and du use?
Message-Id: <[e-mail]>
Summary: 'democracy'
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Stanford Univ. Earth Sciences
References: <[e-mail]>
Date: Sat, 31 Aug 1991 19:11:56 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck Karish)

>The current draft of the POSIX user portability extensions spec says
>that df and du should give sizes in units of 512 bytes.  I have found
>this behavior confusing and inconvenient; I suspect others do too.

I have found this behavior confusing only because it's not
consistent.  On many systems, df and du use different units,
the utilities' output doesn't specify which units are used,
and in some cases the man pages refer only to 'blocks', leaving
the user to decide whether the block size is 512 bytes, 1024
bytes, or the file system's block size.

>Some other people involved in the standards process have said they
>prefer units of 1024; in response, the committee added the -k option,
>which says to use 1024 instead of 512.

On some systems I've used the '-k' option also changes the format
of df output.  It should always cause the utilities to display
the units used.

>I think this is not a real solution.  The use of 512 as the unit will
>make life difficult for beginning users who don't know about -k.  And
>it seems silly to make 512 the default if users won't like it.

Users are surprising adaptable when they're provided a consistent
interface.  Note also that the default block sizes for other
UNIX utilities should be considered.  dd, cpio, and tar default
to 512-byte blocks (except when the medium is tape, for tar).
It's important to keep in mind what a block is both on the command
line and in scripts.  I find it easier to do so when the utilities
all read and write data and report block counts in the same units.

>The committee chose 512, not because they think users prefer it,
>but for totally unrelated reasons having to do with how BSD and
>System V behave.

512 bytes has been a standard block size for tape and disks for
far longer than BSD and System V have existed.

>I think this decision should be made based on the
>preferences of actual users.  If the users tell the committee what
>they want, the committee may yet listen.
>
>Aside from that, we can make the GNU system do what users prefer even
>if that disagrees with POSIX.  We don't have to follow the standard.

Your system doesn't ever have to be any more than a hobbyist's
toy, either.  The more it diverges from industry standards the
more differences users will have to allow for when moving from
gnu to a commercial system.  Ask me about alloca() another time ...
--

    Chuck Karish        [e-mail]
    [phone]        [e-mail]


Volume-Number: Volume 24, Number 88

From [e-mail]  Sun Sep  1 00:25:46 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA28716; Sun, 1 Sep 91 00:25:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06357; Sun, 1 Sep 91 00:25:45 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: what units should df and du use?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]>
Date: Sun, 1 Sep 1991 00:36:47 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>512 bytes has been a standard block size for tape and disks for
>far longer than BSD and System V have existed.

Not really.  On PDP-11s, 512B was indeed a standard disk block size.
That doesn't mean it also was standard or even common on other
platforms, even from DEC, or for magtape, which has been blocked in
a variety of fixed or variable record lengths for as long as I can
remember, which is at least 20 years.

I've seen small systems recently with 256B disk block sizes.  There
are also still some systems with word sizes not an exact multiple of
8 bits, on which disk blocks are some integral number of words.

I like to express sizes in bits, since that is always feasible.

Volume-Number: Volume 24, Number 89

From [e-mail]  Sun Sep  1 00:25:50 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA28718; Sun, 1 Sep 91 00:25:50 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06363; Sun, 1 Sep 91 00:25:48 -0400
Newsgroups: comp.std.unix
From: Dan Bernstein <[e-mail]>
Subject: Re: what units should df and du use?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: IR
References: <[e-mail]> <[e-mail]>
Date: Sun, 1 Sep 1991 02:12:55 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> Chuck Karish writes:
> >Aside from that, we can make the GNU system do what users prefer even
> >if that disagrees with POSIX.  We don't have to follow the standard.
> Your system doesn't ever have to be any more than a hobbyist's
> toy, either.  The more it diverges from industry standards the
> more differences users will have to allow for when moving from
> gnu to a commercial system.

I find this incredibly funny. Chuck implies that a 1024-byte block size
for df output ``diverges from industry standards,'' when I can type
``df'' on practically any BSD machine, including a Sun, and get output
listed in kbytes. Literally millions of users work on machines which
have this behavior. That's an industry standard (albeit not the only
standard) by any reasonable definition.

POSIX committee members seem to think that they are exempt from the
moral requirements of (1) implementing their inventions before requiring
others to do the same; (2) letting the market decide what it wants
before shoving premature ``standards'' down everyone's throat. Don't
bother arguing with (1) unless you can show me someone who actually used
a complete POSIX system before POSIX.1 was standardized. Don't bother
arguing with (2) unless you can explain how a behavior preferred by 20
users out of 750 is what the market wants.

---Dan


Volume-Number: Volume 24, Number 90

From [e-mail]  Mon Sep  2 17:45:05 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA14784; Mon, 2 Sep 91 17:45:05 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08312; Mon, 2 Sep 91 17:44:56 -0400
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Article-I.D.: uunet.1991Sep2.213952.26445
References: <[e-mail]>
Sender: UseNet News <[e-mail]>
Organization: Stanford Univ. Earth Sciences
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 1 Sep 91 04:01:45 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
(David J. MacKenzie) forwards an article by Richard Stallman:
>[Reposting rms's message from gnu.announce for a wider distribution. -djm]
>
>Last week users poured out into the streets of the network to rally to
>the cause of 1024-byte blocks for measuring disk space.  When people
>finally chose sides, it was amazing how few actually stood with the
>POSIX Central Committee and its apparatchiks.  Only 20 out of 750
>supported the 512ist coup.

Am I the only one who sees this as mindless demagoguery?  This
'vote' (really a popularity contest) was held not among end
users but primarily among GNU developers and system managers.

Aside from the question of representation, consider the
procedures used:  It was conducted without advance notice or
discussion at a time that, save last week of the year, is the
time when it was least likely to reach a representative
audience.  The 'Reply-To:' header as posted on comp.std.unix
directed all replies to Hal Jesperson, so the votes reached
GNU, if they did at all, only because they were forwarded.

By the time the call for votes reached Stanford, a new version
of du reporting disk space in kilobytes had already been
distributed by GNU.

>In the aftermath, the GNU system has declared its independence,
>throwing off the power of the POSIX party.

Congratulations.  GNU can join Sun.  To paraphrase Bill Joy
(very loosely, in reference to the GUI wars:) "Standards?
We don't need no stinkin' standards.  We've got MARKET SHARE!"

-*-*-*-*-*-*-*-

It is truly sad to contemplate the false consciousness that
leads so many worthy programmers to follow Stallman's cult
of personality rather than the inexorable flow of history.
--

    Chuck Karish        [e-mail]
    [phone]        [e-mail]


Volume-Number: Volume 24, Number 91

From [e-mail]  Mon Sep  2 17:48:33 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA15450; Mon, 2 Sep 91 17:48:33 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08782; Mon, 2 Sep 91 17:48:25 -0400
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <[e-mail]>
Subject: Re: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Project GLUE, University of Maryland
References: <[e-mail]>
Date: Sun, 1 Sep 1991 06:41:17 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David J. MacKenzie)

Keep in mind that I was only reposting Richard Stallman's message; I
did not write it.  Richard does not read Usenet groups, only the GNU
mailing lists.  I forwarded Doug's posting to him in case he wants to
respond to it.

>>Only 20 out of 750 supported the 512ist coup.

> And how many supported the 1024th revisionists?
> I know I expressed the opinion that the decision should not be made
> until the underlying principles for making such decisions had been
> established..  Did you count me on one side or the other?

I was not involved in counting.  However, I personally looked at about
the first 200 responses.  All but about 4 or 5 of the ones I read had
the following approximate content (using different phrasing but the
same intent):
    I strongly prefer 1024-byte blocks.  Anything else is
    ridiculous and unintuitive.
Many of the respondants mentioned that 512-byte blocks were an
artifact of old filesystems, and are not relevant to modern systems.
Many said they had used both Unix systems that reported in 512-byte
units and Unix systems that reported in 1024-byte units; nearly all of
those said they found the 512-byte systems frustrating and confusing
and much preferred the 1024-byte systems.

>>We promise to respect the rights of minorities--even tiny ones.  So
>>there will be options to request output in units of 512.

> There's no smaller nontrivial minority than me.  Can I specify bits or
> bytes instead of artificial block sizes?

You can specify bytes in GNU du.  (I added that awhile ago because a
previous POSIX.2a draft requried it.  They removed it in the current
draft when they chose 512-bytes as the proposed standard instead.)
Not in df, but fsstat doesn't give measurements in bytes.  You can get
bits by multiplying bytes by 8, of course, but that's a silly unit of
measurement since you can't allocate individual bits in a file.
--
David J. MacKenzie <[e-mail]> <[e-mail]>


Volume-Number: Volume 24, Number 92

From [e-mail]  Mon Sep  2 17:48:36 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA15455; Mon, 2 Sep 91 17:48:36 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08788; Mon, 2 Sep 91 17:48:28 -0400
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <[e-mail]>
Subject: [[e-mail]: Re: Democracy Triumphs in Disk Units]
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Project GLUE, University of Maryland
Date: Sun, 1 Sep 1991 07:48:21 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David J. MacKenzie)

[This is Richard Stallman's reply to Doug Gwynn, which Richard asked
me to post. -djm]

735 out of 763 responses supported 1024-byte units in principle.  (A
few of these said following POSIX was more important than using the
best possible units, and another few said the opposite; but all of
them said that 1024 was better than 512.)  20 responses supported
512-byte units.  We can make the entire collection accessible if other
people want to do their own counting.

We did not receive a response from Doug Gwyn--at least, I can't find
the string `gwyn' in the archive of responses send to disk-unit-poll.
So it seems he was not counted in any fashion.  I am not the one who
did the counting, but based on what he has said, I would expect a
reply of that sort to be counted as supporting neither 512 nor 1024.
We got 8 such replies.
[Doug might have replied only to [e-mail] and not also
[e-mail].  The Reply-To: header in the
comp.std.unix reposting of the original poll mysteriously lost the
second reply address. -djm]

(An additional 154 replies have arrived since the counting was done.  I
skimmed some and they seem much like the earlier replies.)

As for deciding how to make the decision, for the GNU system, the GNU
maintainers seem to agree that we should use the disk units that we
and the users prefer.  How much weight POSIX gives this factor is out
of our hands, and not vitally important to us since it won't affect
what we do.  But this would seem like a good idea for POSIX.

    There's no smaller nontrivial minority than me.  Can I specify bits or
    bytes instead of artificial block sizes?

Yes, but you have to do a little more work and edit the source code.
GNU is famous for creeping featurism, but there are times when even I
can say no.  Sorry.
[Richard doesn't know about GNU du -b, I guess :-). -djm]
--
David J. MacKenzie <[e-mail]> <[e-mail]>

[ The second reply was lost in my effort to set header lines up
  appropriately -- sorry for getting it wrong.  Also, this discussion
  is getting perilously close to an argument -- mod ]

Volume-Number: Volume 24, Number 93

From [e-mail]  Mon Sep  2 17:48:41 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA15465; Mon, 2 Sep 91 17:48:41 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08807; Mon, 2 Sep 91 17:48:33 -0400
Newsgroups: comp.std.unix
From: [e-mail]
Subject: Re: what units should df and du use?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Sun, 1 Sep 1991 22:15:11 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

I'm new to Unix but have 'been around' for 30 years or so.
When IBM graduated from punch cards to tape and disk files, they
specified a 'unit record', analogous to a card, of 128 bytes.
The term 'block' was generally the minimum data that could be
read/written to an i/o device, usually a tape or disk.  IBM tapes
usually had a blocksize of one record (i.e. 128 bytes).  Disk
subsystems have block sizes of some power of 2 unit records,
128, 256, 512 or 1024 bytes.  It seems to me that blocksize is
implementation specific and of no real use to the user in terms
of disk usage reports.  The user thinks in terms of bytes, kilobytes,
megabytes, and now gigabytes and not in block sizes.  He doesn't care.
Simple reports should be in kilobytes (with a fractional part perhaps).
A particular file might have a 'size' of 25.5 KB.  A report for a
100 megabyte disk partition might be 102400 KB or 100 MB.  As
our disks are getting larger, GB reports might be supported.
If the reporting programs are outputting to other than stdout,
I would prefer the report to be in unit records (128 bytes).
If to stdout, reports in KB.  Command line options can override
defaults and format the report any way the user likes.

My two cents.

Joe Wright    [e-mail]

Volume-Number: Volume 24, Number 94

From [e-mail]  Mon Sep  2 19:14:00 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA00603; Mon, 2 Sep 91 19:14:00 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17719; Mon, 2 Sep 91 19:13:52 -0400
Newsgroups: comp.std.unix
From: Doug Gwyn <[e-mail]>
Subject: Re: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
References: <[e-mail]> <[e-mail]>
Date: Mon, 2 Sep 1991 22:48:07 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (David J. MacKenzie) writes:
>You can get bits by multiplying bytes by 8, of course, but that's a
>silly unit of measurement since you can't allocate individual bits
>in a file.

Your STRAW MAN argument about allocating individual bits would perhaps
be "silly", but I did not make that argument.  I did note that not all
file sizes (expressed as number of bits) are exactly divisible by 8,
which would make the 8-bit byte rather a silly unit of measure.  And
other-size bytes more appropriate for such systems aren't necessarily
any more useful.  While a 9-bit byte may be ideal for an 18-bit system,
what would you use on a 60-bit system?

I don't think there is a large advantage to using bit sizing, although
it does permit CORRECT, PRECISE information to be given in all cases.
However, the argument that 1024 8-bit bytes is somehow an optimum unit
of measurement for file sizes needs to be shot down.  It's just one of
many possible arbitrary choices.  Most users of AT&T UNIX are
accustomed to 512 8-bit bytes and most users of BSD are accustomed to
1024 8-bit bytes.  (I agree with the fellow who criticized the biased
preference poll that was conducted.)  That doesn't make either of
these "natural" or "best".  Instead of selecting one arbitrarily, it
would make more sense to allow it to fit the system characteristics
(i.e., use the system's minimum disk block size, which could be any
positive size, and typically is either 512B or 4096B), or to allow the
user to scale the units according to his own needs.

If a single size is nonetheless selected for the standard, it must
make technical sense -- since many important systems allocate files
in integral (perhaps odd) multiples of 512B, and those units can be
used to correctly and accurately express sizes of files on systems
that allocate in integral multiples of 1024B, while the reverse is
NOT TRUE, obviously 512B would be better than 1024B for a standard
that must accommodate both kinds of systems.  But flexibility would
be better yet.

I must say that attempts to force "solutions" based on popularity
polls rather than careful reasoning about the actual relevant
factors is disgusting.  Demagogues would do us all a favor by staying
out of the standardization process.

Volume-Number: Volume 24, Number 95

From [e-mail]  Tue Sep  3 12:56:47 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA07765; Tue, 3 Sep 91 12:56:47 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26684; Tue, 3 Sep 91 12:56:44 -0400
Newsgroups: comp.std.unix
From: "David J. MacKenzie" <[e-mail]>
Subject: Re: Democracy Triumphs in Disk Units
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Project GLUE, University of Maryland
References: <[e-mail]>
Date: Tue, 3 Sep 1991 02:08:35 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David J. MacKenzie)

> However, the argument that 1024 8-bit bytes is somehow an optimum unit
> of measurement for file sizes needs to be shot down.  It's just one of
> many possible arbitrary choices.  Most users of AT&T UNIX are
> accustomed to 512 8-bit bytes and most users of BSD are accustomed to
> 1024 8-bit bytes.

Users of System V may be "used" to 512-byte units, but the results of
the poll seem to indicate that most of them hate them nonetheless and
would rather have 1024-byte units.

People think and count naturally in powers of 10; since 1024 is close
to a power of 10, it has become a standard unit for measuring disk
space on most operating systems, even when selling disks (especially
floppies).  It is therefore not arbitrary; it is a de facto standard.

> I did note that not all
> file sizes (expressed as number of bits) are exactly divisible by 8,
> which would make the 8-bit byte rather a silly unit of measure.  And
> other-size bytes more appropriate for such systems aren't necessarily
> any more useful.  While a 9-bit byte may be ideal for an 18-bit system,
> what would you use on a 60-bit system?

GNU and probably POSIX.2 will never run on systems with byte sizes
other than 8 bits, so there is realistically no point in bothering to
consider them.  No filesystems allocate or measure space in units of
less than a byte, either.

> I must say that attempts to force "solutions" based on popularity
> polls rather than careful reasoning about the actual relevant
> factors is disgusting.

POSIX committees have engaged in much invention of untested schemes
because of philosophies like this one.

--
David J. MacKenzie <[e-mail]> <[e-mail]>

Volume-Number: Volume 24, Number 96

From [e-mail]  Tue Sep  3 12:56:51 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA07787; Tue, 3 Sep 91 12:56:51 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26690; Tue, 3 Sep 91 12:56:47 -0400
Newsgroups: comp.std.unix
From: Tony L Hansen <[e-mail]>
Subject: Re: what units should df and du use?
Message-Id: <[e-mail]>
Summary: 512 is better because it's consistent!
Originator: [e-mail]
Keywords: POSIX
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: AT&T Bell Laboratories
References: <[e-mail]>
Date: Tue, 3 Sep 1991 01:37:28 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Tony L Hansen)

>The committee chose 512, not because they think users prefer it, but
>for totally unrelated reasons having to do with how BSD and System V
>behave.  I think this decision should be made based on the preferences
>of actual users.  If the users tell the committee what they want, the
>committee may yet listen.

As a user, I much prefer the use of 512. Why? It's not because it's such a
better value than any other value, but because it's consistent with all the
other tools which talk in terms of "blocks". All I have to remember is that
"A block is a block is a block" and "A block consists of 512 bytes". I don't
have to remember that this command uses 1024 bytes for its blocks, and this
command uses 512 bytes for its blocks, and that one uses 2048 for its
blocks.  If EVERYTHING uses the same value, then there is LESS confusion!

I've used systems where some things were in one unit and others were in
other units, but both uses the same term, and that was much more confusing.

>Which of these two alternatives would you prefer, and how much?
>* df and du output is in units of 1024.
>* df and du is in units of 512 unless you use -k.

Definitely the latter.

                    Tony Hansen
                [e-mail], [e-mail]
                att!pegasus!hansen, attmail!tony


Volume-Number: Volume 24, Number 97

From [e-mail]  Tue Sep  3 12:56:56 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA07821; Tue, 3 Sep 91 12:56:56 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26706; Tue, 3 Sep 91 12:56:53 -0400
Newsgroups: comp.std.unix
From: "Richard A. O'Keefe" <[e-mail]>
Subject: Re: what units should df and du use?
Message-Id: <[e-mail]>
Summary: constructive suggestion
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Comp Sci, RMIT, Melbourne, Australia
References: <[e-mail]>
    <[e-mail]>
Date: Tue, 3 Sep 1991 06:16:04 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Richard A. O'Keefe)

> >The current draft of the POSIX user portability extensions spec says
> >that df and du should give sizes in units of 512 bytes.  I have found
> >this behavior confusing and inconvenient; I suspect others do too.

To be perfectly frank, it seems to _me_ that (since UNIX files are
logically sequences of bytes, not sequences of blocks, or records, or bits)
that there is precisely ONE ``natural unit'' for reporting ALL file-related
sizes, and that is bytes.

I suggest that it is possible BOTH to make things simple and consistent for
users AND to be POSIX-compliant.  Have an environment variable
    BLOCK_UNIT=1        # for me
    BLOCK_UNIT=512        # for 512ists
    BLOCK_UNIT=1024        # for 1024ists
    # no assignment        # for people who want POSIX behaviour
What about the name to be displayed for the units?  bytes/blocks/k/whatever.
Ideally, that would be ``locale''-specific.  A simple approach would just be
to display
Filesystem          size/512    used   avail capacity  Mounted on
            ^^^^^^^^
where the indicated phrase replaces "kbytes", and has the form
size/${BLOCK_UNIT-1024}.  What price a "-k" option?  You wouldn't need it.
Just use
    BLOCK_UNIT=1024 df

Doing it by making the block unit the value of an environment variable
    - clutters up the environment with another variable (I firmly believe
      that any program which uses more than one environment variable --
      the name of a file with other options -- is badly written)

    + but at least it's way better than POSIX_ME_HARDER, which is about as
      obscure as it can be

    + makes it easy for user-written utilities to follow the SAME convention
      (and the same way of over-riding it in the command line)

    - requires one more step when installing a system, setting up the
      default value (IF an installation wants non-POSIX behaviour)

    + makes it easy for an installation to configure the default in
      the default .cshrc / .profile files

    + provides a natural way of figuring out how to display the units

Of course, the Right Answer is that 'df' should be a relation, not a
program, and df itself should be a trivial AWK script on top of that.
But we can't have all our druthers, can we?
--
It really is a nice theory.  The only defect I think it has is probably
common to all philosophical theories.  It's wrong.      -- Saul Kripke.
I'm [e-mail]; all donations accepted.


Volume-Number: Volume 24, Number 98

From [e-mail]  Tue Sep  3 12:57:04 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA07887; Tue, 3 Sep 91 12:57:04 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26743; Tue, 3 Sep 91 12:57:00 -0400
Newsgroups: comp.std.unix
From: "Scott E. Preece" <[e-mail]>
Subject: Re: what units should df and du use?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Tue, 3 Sep 1991 13:26:27 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Scott E. Preece)

| Submitted-by: [e-mail] (Doug Gwyn)
|
| In article <[e-mail]> rms writes:
| >The committee chose 512, not because they think users prefer it,
| >but for totally unrelated reasons having to do with how BSD and
| >System V behave.  I think this decision should be made based on the
| >preferences of actual users.  If the users tell the committee what
| >they want, the committee may yet listen.
|
| The real issue is whether a STANDARD should codify what existing
| practice IS, or what it SHOULD HAVE BEEN.
---
Well, in truth a POSIX working group does both, as it should.  The
reason you have a working group and that you have a balloting group, is
that you want to apply as much technical expertise as possible to making
sure that you have a standard that not only embodies current practice
but also embodies *good* practice.  This often includes rationalizing
the behavior of related commands: it would be perfectly reasonable for
the working group to propose definitions so that all commands reporting
file sizes used the same units.  They then have to sell their decision
to the balloting group, because without the consent of the ablloting
group their is no standard.

Now, on this particular point I think the masses reported to have
"voted" for 1K blocks may not have thought all the considerations
through (there are a LOT more systems which can always express the space
allocated for any file as an integral multiple of 512 than of 1024, and
there are many existing shell scripts which assume that du reports as it
does today).  However, if all those people had taken the time and spent
the energy to (1) go to work group meetings, (2) read the mailings from
the work group, (3) sign up for the balloting group, (4) read the
drafts, and (5) cast thoughtful ballots pointing to what they recognized
as problems or inconsistencies, they could probably have had their way
(assuming that, when forced to consider the whole scope of the question,
they didn't come to a different conclusion than when looking at one
particular detail in isolation).

The POSIX process is about the most open process I can imagine; there is
simply no basis for complaining about "the committee" forcing things on
the poor downtrodden masses.  *Anyone* can participate in working group
meetings.  *Anyone* can participate in the balloting process (you have to
be an IEEE member to vote, but they also accept comments from any
interested party, and *anyone* can participate in the ballot resolution
process that works on turning all those ballots into a consensus.

--
scott preece
motorola/mcg urbana design center    1101 e. university, urbana, il   61801
uucp:    uunet!uiucuxc!udc!preece,     arpa:    [e-mail]
phone:    [phone]              fax:    [phone]


Volume-Number: Volume 24, Number 99