[TUHS] Other POSIX Candidates?

[TUHS] Other POSIX Candidates?

[segaloco via TUHS]

I'm paraphrasing here but I've read in a few places something to the effect that UNIX was "selected" as the basis on which to build a portable operating system standard, which of course we all know as POSIX.  However, I got thinking on the implications of that phrasing, and have to ask, was there actually a "selection" made picking UNIX over some other candidate, or was it pretty much established from the outset of pursuing a standard that UNIX was going to get standardized?

Another way to put it would be as a chicken and egg, which came first, desire for a portable base system definition that UNIX happened to fit nicely, or the ongoing need for UNIX standardization finding sponsorship by the working groups, IEEE, etc.?  Did any other OS contend for this coveted honor?

- Matt G.

[TUHS] Re: Other POSIX Candidates?

[George Michaelson]

its weak thinking on my part, but I always understood the POSIX
branding to be a very explicit nod to this being a stamp of approval
on a burgeoning UNIX-varieties ecology.

I do not think VMS, or a DOS derivitive, or PICK was a serious
consideration except perhaps in a post-fact rationalisation.

1 let's invent our own
2 let's not thats too stupid
3 so all the mainframe OS targetting IBM are not really much more than
JCL or what MIT and Stanford do and anyway
4 nobody buys anything but minicomputers now and they all run versions
of unix but
5 porting is a royal pain.
6 ok so lets pick a subset of required behaviour to make C and shell work
7 and for good measure is there anyone here who seriously wants VMS? No
8 ok done. Now, for the next 15 committee meetings, lets have many
fine luncheons
9 <time traveller> Richard Stallman is smelly and people don't like him
10 noted. Thank goodness we came up with POSIX independently as a backronym

On Tue, Aug 6, 2024 at 1:27 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
> I'm paraphrasing here but I've read in a few places something to the effect that UNIX was "selected" as the basis on which to build a portable operating system standard, which of course we all know as POSIX.  However, I got thinking on the implications of that phrasing, and have to ask, was there actually a "selection" made picking UNIX over some other candidate, or was it pretty much established from the outset of pursuing a standard that UNIX was going to get standardized?
>
> Another way to put it would be as a chicken and egg, which came first, desire for a portable base system definition that UNIX happened to fit nicely, or the ongoing need for UNIX standardization finding sponsorship by the working groups, IEEE, etc.?  Did any other OS contend for this coveted honor?
>
> - Matt G.

[TUHS] Re: Other POSIX Candidates?

[arnold]

segaloco via TUHS <tuhs@tuhs.org> wrote:

> Another way to put it would be as a chicken and egg, which came first, ...
> ..., or the ongoing need for UNIX standardization finding sponsorship
> by the working groups, IEEE, etc.?

This.

Try to understand what things were like at the time. There were
a ton of competing Unix systems, all different:

- IBM: AIX on the mainframe and PS/2, which were different from
  AIX on the RT/PC and later RS/6000 (workstations).

- DEC: Ultrix on minicomputers and microvaxen, and later on MIPS
  based workstations

- Data General: DG/UX on their minicomputers.

- Pyramid: A BSD/System V hybrid RISC minicomputer

- Sun: Workstations, 680x0 based and later SPARC based, and servers.
  Initially BSD based, later SVR4 based.

- Workstations from HP, Tektronix, NBI, others I've probably forgotten,
  3B2 and 3B1/Unix PC from AT&T... The list goes on and on and on.

Things split roughly along BSD/System V lines, but code wasn't portable.
Did you use bcopy() or memcpy()? index() or strchr()? There was lots
of mixing and matching happening, too.

There was a crying need for a standard. The mess is what begot GNU
Autoconf, which made a difference at the time. Having the ANSI C standard
also helped.

HTH,

Arnold

[TUHS] Re: Other POSIX Candidates?

[Peter Weinberger (温博格) via TUHS]

and the folks from PARC wanted a more RPC-based open OS, according to
my not-yet-fully-retrieved memories.

On Tue, Aug 6, 2024 at 2:40 AM <arnold@skeeve.com> wrote:
>
> segaloco via TUHS <tuhs@tuhs.org> wrote:
>
> > Another way to put it would be as a chicken and egg, which came first, ...
> > ..., or the ongoing need for UNIX standardization finding sponsorship
> > by the working groups, IEEE, etc.?
>
> This.
>
> Try to understand what things were like at the time. There were
> a ton of competing Unix systems, all different:
>
> - IBM: AIX on the mainframe and PS/2, which were different from
>   AIX on the RT/PC and later RS/6000 (workstations).
>
> - DEC: Ultrix on minicomputers and microvaxen, and later on MIPS
>   based workstations
>
> - Data General: DG/UX on their minicomputers.
>
> - Pyramid: A BSD/System V hybrid RISC minicomputer
>
> - Sun: Workstations, 680x0 based and later SPARC based, and servers.
>   Initially BSD based, later SVR4 based.
>
> - Workstations from HP, Tektronix, NBI, others I've probably forgotten,
>   3B2 and 3B1/Unix PC from AT&T... The list goes on and on and on.
>
> Things split roughly along BSD/System V lines, but code wasn't portable.
> Did you use bcopy() or memcpy()? index() or strchr()? There was lots
> of mixing and matching happening, too.
>
> There was a crying need for a standard. The mess is what begot GNU
> Autoconf, which made a difference at the time. Having the ANSI C standard
> also helped.
>
> HTH,
>
> Arnold

[TUHS] Re: Other POSIX Candidates?

[Rik Farrow]

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

I recall something different than what others had suggested. When the US
government issued requests for proposals, they weren't permitted to specify
products by name. In particular, if you wanted something that wasn't
Microsoft, you couldn't actually specify that it be Unix.

So POSIX was born partially as a way of letting it be known you wanted a
Unix variant rather than something else.

Certainly porting was an issue. I did work for a software shop in the late
80s and early 90s that produced graphics software, and porting between Unix
systems was relatively easy, compared to, say, moving the software to
Apollo's DomainIX, a sort of Unix-like version of Apollo Domain. With Unix
systems and this software, the biggest issue was fonts, as the software
needed to be able to calculate the extent, that is, the bounding box, for
text that was to be displayed.

Strangely enough, the other big issue was time.

Rik


On Tue, Aug 6, 2024 at 6:29 AM Peter Weinberger (温博格) via TUHS <
tuhs@tuhs.org> wrote:

> and the folks from PARC wanted a more RPC-based open OS, according to
> my not-yet-fully-retrieved memories.
>
> On Tue, Aug 6, 2024 at 2:40 AM <arnold@skeeve.com> wrote:
> >
> > segaloco via TUHS <tuhs@tuhs.org> wrote:
> >
> > > Another way to put it would be as a chicken and egg, which came first,
> ...
> > > ..., or the ongoing need for UNIX standardization finding sponsorship
> > > by the working groups, IEEE, etc.?
> >
> > This.
> >
> > Try to understand what things were like at the time. There were
> > a ton of competing Unix systems, all different:
> >
> > - IBM: AIX on the mainframe and PS/2, which were different from
> >   AIX on the RT/PC and later RS/6000 (workstations).
> >
> > - DEC: Ultrix on minicomputers and microvaxen, and later on MIPS
> >   based workstations
> >
> > - Data General: DG/UX on their minicomputers.
> >
> > - Pyramid: A BSD/System V hybrid RISC minicomputer
> >
> > - Sun: Workstations, 680x0 based and later SPARC based, and servers.
> >   Initially BSD based, later SVR4 based.
> >
> > - Workstations from HP, Tektronix, NBI, others I've probably forgotten,
> >   3B2 and 3B1/Unix PC from AT&T... The list goes on and on and on.
> >
> > Things split roughly along BSD/System V lines, but code wasn't portable.
> > Did you use bcopy() or memcpy()? index() or strchr()? There was lots
> > of mixing and matching happening, too.
> >
> > There was a crying need for a standard. The mess is what begot GNU
> > Autoconf, which made a difference at the time. Having the ANSI C standard
> > also helped.
> >
> > HTH,
> >
> > Arnold
>

[-- Attachment #2: Type: text/html, Size: 3370 bytes --]

[TUHS] Re: Other POSIX Candidates?

[Marc Rochkind]

[-- Attachment #1: Type: text/plain, Size: 3273 bytes --]

As I remember, part of the rationale was that DEC wanted something that
could be specified in an RFP that was defined in terms of an interface,
rather than an implementation. In theory this would allow them to propose
VMS with an appropriate interface layer. I don't know if anything like this
was ever created. But the interface standard sure was, of course.

On Tue, Aug 6, 2024 at 11:32 AM Rik Farrow <rik@rikfarrow.com> wrote:

> I recall something different than what others had suggested. When the US
> government issued requests for proposals, they weren't permitted to specify
> products by name. In particular, if you wanted something that wasn't
> Microsoft, you couldn't actually specify that it be Unix.
>
> So POSIX was born partially as a way of letting it be known you wanted a
> Unix variant rather than something else.
>
> Certainly porting was an issue. I did work for a software shop in the late
> 80s and early 90s that produced graphics software, and porting between Unix
> systems was relatively easy, compared to, say, moving the software to
> Apollo's DomainIX, a sort of Unix-like version of Apollo Domain. With Unix
> systems and this software, the biggest issue was fonts, as the software
> needed to be able to calculate the extent, that is, the bounding box, for
> text that was to be displayed.
>
> Strangely enough, the other big issue was time.
>
> Rik
>
>
> On Tue, Aug 6, 2024 at 6:29 AM Peter Weinberger (温博格) via TUHS <
> tuhs@tuhs.org> wrote:
>
>> and the folks from PARC wanted a more RPC-based open OS, according to
>> my not-yet-fully-retrieved memories.
>>
>> On Tue, Aug 6, 2024 at 2:40 AM <arnold@skeeve.com> wrote:
>> >
>> > segaloco via TUHS <tuhs@tuhs.org> wrote:
>> >
>> > > Another way to put it would be as a chicken and egg, which came
>> first, ...
>> > > ..., or the ongoing need for UNIX standardization finding sponsorship
>> > > by the working groups, IEEE, etc.?
>> >
>> > This.
>> >
>> > Try to understand what things were like at the time. There were
>> > a ton of competing Unix systems, all different:
>> >
>> > - IBM: AIX on the mainframe and PS/2, which were different from
>> >   AIX on the RT/PC and later RS/6000 (workstations).
>> >
>> > - DEC: Ultrix on minicomputers and microvaxen, and later on MIPS
>> >   based workstations
>> >
>> > - Data General: DG/UX on their minicomputers.
>> >
>> > - Pyramid: A BSD/System V hybrid RISC minicomputer
>> >
>> > - Sun: Workstations, 680x0 based and later SPARC based, and servers.
>> >   Initially BSD based, later SVR4 based.
>> >
>> > - Workstations from HP, Tektronix, NBI, others I've probably forgotten,
>> >   3B2 and 3B1/Unix PC from AT&T... The list goes on and on and on.
>> >
>> > Things split roughly along BSD/System V lines, but code wasn't portable.
>> > Did you use bcopy() or memcpy()? index() or strchr()? There was lots
>> > of mixing and matching happening, too.
>> >
>> > There was a crying need for a standard. The mess is what begot GNU
>> > Autoconf, which made a difference at the time. Having the ANSI C
>> standard
>> > also helped.
>> >
>> > HTH,
>> >
>> > Arnold
>>
>

-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

[-- Attachment #2: Type: text/html, Size: 4367 bytes --]

[TUHS] Re: Other POSIX Candidates?

[arnold]

For a long time DEC had "VMS POSIX" product.  I don't know much
more about it, other than that it existed and was what you
describe, more or less.

Marc Rochkind <mrochkind@gmail.com> wrote:

> As I remember, part of the rationale was that DEC wanted something that
> could be specified in an RFP that was defined in terms of an interface,
> rather than an implementation. In theory this would allow them to propose
> VMS with an appropriate interface layer. I don't know if anything like this
> was ever created. But the interface standard sure was, of course.
>
> On Tue, Aug 6, 2024 at 11:32 AM Rik Farrow <rik@rikfarrow.com> wrote:
>
> > I recall something different than what others had suggested. When the US
> > government issued requests for proposals, they weren't permitted to specify
> > products by name. In particular, if you wanted something that wasn't
> > Microsoft, you couldn't actually specify that it be Unix.
> >
> > So POSIX was born partially as a way of letting it be known you wanted a
> > Unix variant rather than something else.
> >
> > Certainly porting was an issue. I did work for a software shop in the late
> > 80s and early 90s that produced graphics software, and porting between Unix
> > systems was relatively easy, compared to, say, moving the software to
> > Apollo's DomainIX, a sort of Unix-like version of Apollo Domain. With Unix
> > systems and this software, the biggest issue was fonts, as the software
> > needed to be able to calculate the extent, that is, the bounding box, for
> > text that was to be displayed.
> >
> > Strangely enough, the other big issue was time.
> >
> > Rik
> >
> >
> > On Tue, Aug 6, 2024 at 6:29 AM Peter Weinberger (温博格) via TUHS <
> > tuhs@tuhs.org> wrote:
> >
> >> and the folks from PARC wanted a more RPC-based open OS, according to
> >> my not-yet-fully-retrieved memories.
> >>
> >> On Tue, Aug 6, 2024 at 2:40 AM <arnold@skeeve.com> wrote:
> >> >
> >> > segaloco via TUHS <tuhs@tuhs.org> wrote:
> >> >
> >> > > Another way to put it would be as a chicken and egg, which came
> >> first, ...
> >> > > ..., or the ongoing need for UNIX standardization finding sponsorship
> >> > > by the working groups, IEEE, etc.?
> >> >
> >> > This.
> >> >
> >> > Try to understand what things were like at the time. There were
> >> > a ton of competing Unix systems, all different:
> >> >
> >> > - IBM: AIX on the mainframe and PS/2, which were different from
> >> >   AIX on the RT/PC and later RS/6000 (workstations).
> >> >
> >> > - DEC: Ultrix on minicomputers and microvaxen, and later on MIPS
> >> >   based workstations
> >> >
> >> > - Data General: DG/UX on their minicomputers.
> >> >
> >> > - Pyramid: A BSD/System V hybrid RISC minicomputer
> >> >
> >> > - Sun: Workstations, 680x0 based and later SPARC based, and servers.
> >> >   Initially BSD based, later SVR4 based.
> >> >
> >> > - Workstations from HP, Tektronix, NBI, others I've probably forgotten,
> >> >   3B2 and 3B1/Unix PC from AT&T... The list goes on and on and on.
> >> >
> >> > Things split roughly along BSD/System V lines, but code wasn't portable.
> >> > Did you use bcopy() or memcpy()? index() or strchr()? There was lots
> >> > of mixing and matching happening, too.
> >> >
> >> > There was a crying need for a standard. The mess is what begot GNU
> >> > Autoconf, which made a difference at the time. Having the ANSI C
> >> standard
> >> > also helped.
> >> >
> >> > HTH,
> >> >
> >> > Arnold
> >>
> >
>
> -- 
> *My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

[TUHS] Re: Other POSIX Candidates?

[Rik Farrow]

[-- Attachment #1: Type: text/plain, Size: 3755 bytes --]

A little digging turned up FIPS 151-2:

https://web.archive.org/web/20140220130516/http://www.itl.nist.gov/fipspubs/fip151-2.htm

This website also explains Microsoft's desire to support several APIs:

https://brianreiter.org/2010/08/24/the-sad-history-of-the-microsoft-posix-subsystem/

Rik


On Tue, Aug 6, 2024 at 11:04 AM Marc Rochkind <mrochkind@gmail.com> wrote:

> As I remember, part of the rationale was that DEC wanted something that
> could be specified in an RFP that was defined in terms of an interface,
> rather than an implementation. In theory this would allow them to propose
> VMS with an appropriate interface layer. I don't know if anything like this
> was ever created. But the interface standard sure was, of course.
>
> On Tue, Aug 6, 2024 at 11:32 AM Rik Farrow <rik@rikfarrow.com> wrote:
>
>> I recall something different than what others had suggested. When the US
>> government issued requests for proposals, they weren't permitted to specify
>> products by name. In particular, if you wanted something that wasn't
>> Microsoft, you couldn't actually specify that it be Unix.
>>
>> So POSIX was born partially as a way of letting it be known you wanted a
>> Unix variant rather than something else.
>>
>> Certainly porting was an issue. I did work for a software shop in the
>> late 80s and early 90s that produced graphics software, and porting between
>> Unix systems was relatively easy, compared to, say, moving the software to
>> Apollo's DomainIX, a sort of Unix-like version of Apollo Domain. With Unix
>> systems and this software, the biggest issue was fonts, as the software
>> needed to be able to calculate the extent, that is, the bounding box, for
>> text that was to be displayed.
>>
>> Strangely enough, the other big issue was time.
>>
>> Rik
>>
>>
>> On Tue, Aug 6, 2024 at 6:29 AM Peter Weinberger (温博格) via TUHS <
>> tuhs@tuhs.org> wrote:
>>
>>> and the folks from PARC wanted a more RPC-based open OS, according to
>>> my not-yet-fully-retrieved memories.
>>>
>>> On Tue, Aug 6, 2024 at 2:40 AM <arnold@skeeve.com> wrote:
>>> >
>>> > segaloco via TUHS <tuhs@tuhs.org> wrote:
>>> >
>>> > > Another way to put it would be as a chicken and egg, which came
>>> first, ...
>>> > > ..., or the ongoing need for UNIX standardization finding sponsorship
>>> > > by the working groups, IEEE, etc.?
>>> >
>>> > This.
>>> >
>>> > Try to understand what things were like at the time. There were
>>> > a ton of competing Unix systems, all different:
>>> >
>>> > - IBM: AIX on the mainframe and PS/2, which were different from
>>> >   AIX on the RT/PC and later RS/6000 (workstations).
>>> >
>>> > - DEC: Ultrix on minicomputers and microvaxen, and later on MIPS
>>> >   based workstations
>>> >
>>> > - Data General: DG/UX on their minicomputers.
>>> >
>>> > - Pyramid: A BSD/System V hybrid RISC minicomputer
>>> >
>>> > - Sun: Workstations, 680x0 based and later SPARC based, and servers.
>>> >   Initially BSD based, later SVR4 based.
>>> >
>>> > - Workstations from HP, Tektronix, NBI, others I've probably forgotten,
>>> >   3B2 and 3B1/Unix PC from AT&T... The list goes on and on and on.
>>> >
>>> > Things split roughly along BSD/System V lines, but code wasn't
>>> portable.
>>> > Did you use bcopy() or memcpy()? index() or strchr()? There was lots
>>> > of mixing and matching happening, too.
>>> >
>>> > There was a crying need for a standard. The mess is what begot GNU
>>> > Autoconf, which made a difference at the time. Having the ANSI C
>>> standard
>>> > also helped.
>>> >
>>> > HTH,
>>> >
>>> > Arnold
>>>
>>
>
> --
> *My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*
>

[-- Attachment #2: Type: text/html, Size: 5358 bytes --]

[TUHS] Re: Other POSIX Candidates?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 7753 bytes --]

On Mon, Aug 5, 2024 at 11:27 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> I'm paraphrasing here but I've read in a few places something to the
> effect that UNIX was "selected" as the basis on which to build a portable
> operating system standard, which of course we all know as POSIX.

I hate history rewrites and marketing  spin.  *No other OS API or ABI was
ever considered!!!*

However, I got thinking on the implications of that phrasing, and have to
> ask, was there actually a "selection" made picking UNIX over some other
> candidate, or was it pretty much established from the outset of pursuing a
> standard that UNIX was going to get standardized?
>
Yes -- see below.

>
> Another way to put it would be as a chicken and egg, which came first,
> desire for a portable base system definition that UNIX happened to fit
> nicely, or the ongoing need for UNIX standardization finding sponsorship by
> the working groups, IEEE, etc.?

UNIX needed IEEE -- see below.



> Did any other OS contend for this coveted honor?
>
No.

Ok, the history.  The commercial ISVs, particularly in the Minicomputer and
Mainframe works, were tired of customizing applications for VMS, AOS, NOS,
VM, or the like, and UNIX, as a "portable" operating system, offered them a
potential solution, but the problem was that the HW vendors had an
instilled concept of "value add" (embrace and extend) that would take UNIX
and customize it.   Note there were two primary schools of thought in those
days,  the idea of an ABI (application binary interface) definition, which
was popular for systems that were being cloned (*i.e*., the IBM Mainframes
and the new PCs with CP/M and DOS), and the API (application programming
interface) folks that wanted to use something more like what was proving to
be successful in the programming language world - which was that the
minicomputer vendors favored.

So, the "Open Systems" community of the early 1980s had a problem. People
already knew that the availability of application SW that solves people's
problems drove HW sales, so the question was: How to make more applications
available for UNIX and do it in a manner that the ISVs would support.

There were two organizations at the time, USENIX and /usr/group (later
renamed "uniform"), that were the primary place where that could be
solved.  USENIX was the Academic Research Community, and everyone had
sources, so helping commercial ISVs was not really on their plate.  But
/usr/group were the folks that were trying to build a new commercial market
for UNIX.   They sponsored a group led by TUHS's Heinz Lycklama to try to
create an* API standard* that the ISVs could accept.

The members of that committee were: *J. Bass, R. Bott, J. Boykin, B. Boyle,
J. Brodie, E. Brunner, D. Buck, H. Burgess, P. Caruthers, F. Christiansen,
D. Clark, C. Cole, A. Cornish, W. Corwin, B. Cox, D. Cragun, I. Darwin, L.
Ford, C. Forney, M. Gien, S. Glaser, A. Godino, J. Goldberg, T. Green, J.
Guist, M. Hakam, R. Hammons, G. Harris, S. Head, T. Hoffman, T. Houghton,
J. Isaak, B. Joy, M. Katz, D. Kretsch, D. Ladermann, G. Laney, M.
Laschkewitsch, B. Laws, Jr., H. Lycklama, J. McGinness, R. Michael, J.
Moskow, M. O’Dell, D. Peachey, E. Petersen, P. Plauger, T. Plum, C.
Prosser, R. Ptak, J. Schriebman, S. Sherman, H. Stenn, R. Swartz, T.
Tabloski, M. Teller, J. Thomas, M. Tilson, D. Weisman, M. Wilens, R. Wirt,
D. Wollner.*

In November 1984, the original /usr/group standard was published.  BTW: a
residual effect of this work can be seen today, as this is the document
where the <unistd.h> was defined.

As a side note, this document is "perfect bound" and I have been reluctant
to break the back on my copy of it.  At some point, I may have to do that
so it can be properly scanned.

As soon as it was published, it was known to be incomplete and, of course,
lacked the user (command) level standard and an ABI standard.  It also has
had one huge issue, in that /usr/group was not recognized by any of the
American Standards or ISO to create a document that could be brought
forward for International standardization.   Furthermore, without a formal
proposal from an American Standard a Federal Information
Processing Standard (FIPS) couldn't be proposed, so a document needed to
created from one of the blessed organizations that could be.

Maurice Graubie had recently been the chair of IEEE 802.  Jim Issak, then
of Charles RIver Data System with Maurice's sponsorship was able to get
IEEE to open a committee under their guidance to create a portable OS.
 The scope and purpose are cut/pasted from the charge:


A.003.2
15JAN85


           Scope and Purpose of the IEEE P1003 Working Group

"To define a standard operating system interface and environment based
on the  UNIX Operating System documentation to support application
portability at the source level. (UNIX is a trademark of Bell Labs)"

This effort entails three major components:

1.  Definitions - Terminology and objects referred to in the document.
    In the case of objects, the structure, operations that modify these,
    and the effects of these operations need to be documented as well.
    (Sample Term:  Pipe, Sample Object:  File Descriptor)

2.  Systems Interface and Subroutines (C-Language Binding)
This area includes:

    A.  The range of interface & subroutines in the /usr/group document
    B.  IOCTL/TermIO
    C.  IFDEF Specifications
    D.  Real Time (Contiguous files, synchronization, shared data, priority
        scheduling, etc.)
    E.  Device interface, including Termcaps/TermIO
    F.  Job Control, Windowing
    G.  Network Interface (but not Protocol)
    H.  Distributed Systems
    I.  Device Drivers
    J.  Error Handling & Recovery

3.  User interface issues, including:

    A.  Shell, Command Set, Syntax
    B.  Portability - Media/Formats
    C.  Error Handling & Recovery

In all of these areas, consideration will be given to defining the impact on
security, international usage (language and character sets, etc.), and
application needs such as transaction processing.

The following areas may require review and commentary, perhaps even
revisions
and updates, but are outside of the scope of the current effort:  Network
Protocols, Graphics, DBMS, Record I/O.

Two areas are explicitly outside of the scope of the group:  Binary compati-
bility/exchange of software in executable form, and the end-user interface
(where ease-of-use is a critical issue).

Target "consumers" of the documents are:  Systems implementations (including
AT&T Licensees, those developing compatible systems, and those implementing
"hosted" systems), and application implementors - for areas 1 and 2.  With
Area 3, multivendor systems integrators and shell users are also identified
as document consumers.

All of these efforts will not occur at once.  The initial document for
balloting will be based on Section 1 and 2-A and B above.  As this goes
through the balloting process, additional areas in 2 and 3 will be readied
for balloting.  At this point, it is not clear if this will represent
separate
revisions of a common document, separate "chapters" or "modules" of a
common
document, or separate standards documents.

At the first meeting of the /usr/group committee in 1985, Jim presented
this document from IEEE.  We voted to disband and reconvene the meeting
under IEEE's rules, with Heinz graciously stepping back and Jim becoming
the new chair of the new committee.

The first IEEE version was published in 1988, and the first ISO version in
1990.  Somewhere in between FIPS-151 was published.




ᐧ

[-- Attachment #2: Type: text/html, Size: 14218 bytes --]

[TUHS] Re: Other POSIX Candidates?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 8157 bytes --]

typo:  Jim Isaak
ᐧ

On Tue, Aug 6, 2024 at 2:19 PM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Mon, Aug 5, 2024 at 11:27 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
>> I'm paraphrasing here but I've read in a few places something to the
>> effect that UNIX was "selected" as the basis on which to build a portable
>> operating system standard, which of course we all know as POSIX.
>
> I hate history rewrites and marketing  spin.  *No other OS API or ABI was
> ever considered!!!*
>
> However, I got thinking on the implications of that phrasing, and have to
>> ask, was there actually a "selection" made picking UNIX over some other
>> candidate, or was it pretty much established from the outset of pursuing a
>> standard that UNIX was going to get standardized?
>>
> Yes -- see below.
>
>>
>> Another way to put it would be as a chicken and egg, which came first,
>> desire for a portable base system definition that UNIX happened to fit
>> nicely, or the ongoing need for UNIX standardization finding sponsorship by
>> the working groups, IEEE, etc.?
>
> UNIX needed IEEE -- see below.
>
>
>
>> Did any other OS contend for this coveted honor?
>>
> No.
>
> Ok, the history.  The commercial ISVs, particularly in the Minicomputer
> and Mainframe works, were tired of customizing applications for VMS, AOS,
> NOS, VM, or the like, and UNIX, as a "portable" operating system, offered
> them a potential solution, but the problem was that the HW vendors had an
> instilled concept of "value add" (embrace and extend) that would take UNIX
> and customize it.   Note there were two primary schools of thought in those
> days,  the idea of an ABI (application binary interface) definition, which
> was popular for systems that were being cloned (*i.e*., the IBM
> Mainframes and the new PCs with CP/M and DOS), and the API (application
> programming interface) folks that wanted to use something more like what
> was proving to be successful in the programming language world - which was
> that the minicomputer vendors favored.
>
> So, the "Open Systems" community of the early 1980s had a problem. People
> already knew that the availability of application SW that solves people's
> problems drove HW sales, so the question was: How to make more applications
> available for UNIX and do it in a manner that the ISVs would support.
>
> There were two organizations at the time, USENIX and /usr/group (later
> renamed "uniform"), that were the primary place where that could be
> solved.  USENIX was the Academic Research Community, and everyone had
> sources, so helping commercial ISVs was not really on their plate.  But
> /usr/group were the folks that were trying to build a new commercial market
> for UNIX.   They sponsored a group led by TUHS's Heinz Lycklama to try to
> create an* API standard* that the ISVs could accept.
>
> The members of that committee were: *J. Bass, R. Bott, J. Boykin, B.
> Boyle, J. Brodie, E. Brunner, D. Buck, H. Burgess, P. Caruthers, F.
> Christiansen, D. Clark, C. Cole, A. Cornish, W. Corwin, B. Cox, D. Cragun,
> I. Darwin, L. Ford, C. Forney, M. Gien, S. Glaser, A. Godino, J. Goldberg,
> T. Green, J. Guist, M. Hakam, R. Hammons, G. Harris, S. Head, T. Hoffman,
> T. Houghton, J. Isaak, B. Joy, M. Katz, D. Kretsch, D. Ladermann, G. Laney,
> M. Laschkewitsch, B. Laws, Jr., H. Lycklama, J. McGinness, R. Michael, J.
> Moskow, M. O’Dell, D. Peachey, E. Petersen, P. Plauger, T. Plum, C.
> Prosser, R. Ptak, J. Schriebman, S. Sherman, H. Stenn, R. Swartz, T.
> Tabloski, M. Teller, J. Thomas, M. Tilson, D. Weisman, M. Wilens, R. Wirt,
> D. Wollner.*
>
> In November 1984, the original /usr/group standard was published.  BTW: a
> residual effect of this work can be seen today, as this is the document
> where the <unistd.h> was defined.
>
> As a side note, this document is "perfect bound" and I have been reluctant
> to break the back on my copy of it.  At some point, I may have to do that
> so it can be properly scanned.
>
> As soon as it was published, it was known to be incomplete and, of course,
> lacked the user (command) level standard and an ABI standard.  It also has
> had one huge issue, in that /usr/group was not recognized by any of the
> American Standards or ISO to create a document that could be brought
> forward for International standardization.   Furthermore, without a formal
> proposal from an American Standard a Federal Information
> Processing Standard (FIPS) couldn't be proposed, so a document needed to
> created from one of the blessed organizations that could be.
>
> Maurice Graubie had recently been the chair of IEEE 802.  Jim Issak, then
> of Charles RIver Data System with Maurice's sponsorship was able to get
> IEEE to open a committee under their guidance to create a portable OS.
>  The scope and purpose are cut/pasted from the charge:
>
>
> A.003.2
> 15JAN85
>
>
>            Scope and Purpose of the IEEE P1003 Working Group
>
> "To define a standard operating system interface and environment based
> on the  UNIX Operating System documentation to support application
> portability at the source level. (UNIX is a trademark of Bell Labs)"
>
> This effort entails three major components:
>
> 1.  Definitions - Terminology and objects referred to in the document.
>     In the case of objects, the structure, operations that modify these,
>     and the effects of these operations need to be documented as well.
>     (Sample Term:  Pipe, Sample Object:  File Descriptor)
>
> 2.  Systems Interface and Subroutines (C-Language Binding)
> This area includes:
>
>     A.  The range of interface & subroutines in the /usr/group document
>     B.  IOCTL/TermIO
>     C.  IFDEF Specifications
>     D.  Real Time (Contiguous files, synchronization, shared data, priority
>         scheduling, etc.)
>     E.  Device interface, including Termcaps/TermIO
>     F.  Job Control, Windowing
>     G.  Network Interface (but not Protocol)
>     H.  Distributed Systems
>     I.  Device Drivers
>     J.  Error Handling & Recovery
>
> 3.  User interface issues, including:
>
>     A.  Shell, Command Set, Syntax
>     B.  Portability - Media/Formats
>     C.  Error Handling & Recovery
>
> In all of these areas, consideration will be given to defining the impact
> on
> security, international usage (language and character sets, etc.), and
> application needs such as transaction processing.
>
> The following areas may require review and commentary, perhaps even
> revisions
> and updates, but are outside of the scope of the current effort:  Network
> Protocols, Graphics, DBMS, Record I/O.
>
> Two areas are explicitly outside of the scope of the group:  Binary
> compati-
> bility/exchange of software in executable form, and the end-user interface
> (where ease-of-use is a critical issue).
>
> Target "consumers" of the documents are:  Systems implementations
> (including
> AT&T Licensees, those developing compatible systems, and those
> implementing
> "hosted" systems), and application implementors - for areas 1 and 2.  With
> Area 3, multivendor systems integrators and shell users are also
> identified
> as document consumers.
>
> All of these efforts will not occur at once.  The initial document for
> balloting will be based on Section 1 and 2-A and B above.  As this goes
> through the balloting process, additional areas in 2 and 3 will be readied
> for balloting.  At this point, it is not clear if this will represent
> separate
> revisions of a common document, separate "chapters" or "modules" of a
> common
> document, or separate standards documents.
>
> At the first meeting of the /usr/group committee in 1985, Jim presented
> this document from IEEE.  We voted to disband and reconvene the meeting
> under IEEE's rules, with Heinz graciously stepping back and Jim becoming
> the new chair of the new committee.
>
> The first IEEE version was published in 1988, and the first ISO version in
> 1990.  Somewhere in between FIPS-151 was published.
>
>
>
>
> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 15026 bytes --]

[TUHS] Re: Other POSIX Candidates?

[Heinz Lycklama]

The POSIX standard is based on the /usr/group standard
which we started in 1981 under /usr/group, and turned
into the standard in 1984, which was then turned over
to the IEEE under the leadership of Jim Isaac. As the
chair of the /usr/group standards effort, we made every
attempt to include as many UNIX vendors as possible,
systems vendors as well as application vendors. The
work of the /usr/group standard was joined by all major
computer manufacturers - mainframe, mini-computer,
and micro-computer - plus applications vendors who
were interested in having their apps run on as many
platforms as possible. The members of the /usr/group
standard committee also included the vendors of
UNIX-like systems who did not have access to the source
code for the UNIX System.

ISC  (my employer at the time) also developed a UNIX
emulation product that ran on the VAX VMS system in 1979.
We had an interest in providing a platform for as many
applications as possible on the VAX UNIX emulation platform.
I do not recall that Govt contracts were a big concern at
the time that we started the UNIX standards effort, but it
did become a concern over the years.

My recall of the UNIX standards beginnings.

Heinz

On 8/6/2024 11:09 AM, arnold@skeeve.com wrote:
> For a long time DEC had "VMS POSIX" product.  I don't know much
> more about it, other than that it existed and was what you
> describe, more or less.
>
> Marc Rochkind <mrochkind@gmail.com> wrote:
>
>> As I remember, part of the rationale was that DEC wanted something that
>> could be specified in an RFP that was defined in terms of an interface,
>> rather than an implementation. In theory this would allow them to propose
>> VMS with an appropriate interface layer. I don't know if anything like this
>> was ever created. But the interface standard sure was, of course.
>>
>> On Tue, Aug 6, 2024 at 11:32 AM Rik Farrow <rik@rikfarrow.com> wrote:
>>
>>> I recall something different than what others had suggested. When the US
>>> government issued requests for proposals, they weren't permitted to specify
>>> products by name. In particular, if you wanted something that wasn't
>>> Microsoft, you couldn't actually specify that it be Unix.
>>>
>>> So POSIX was born partially as a way of letting it be known you wanted a
>>> Unix variant rather than something else.
>>>
>>> Certainly porting was an issue. I did work for a software shop in the late
>>> 80s and early 90s that produced graphics software, and porting between Unix
>>> systems was relatively easy, compared to, say, moving the software to
>>> Apollo's DomainIX, a sort of Unix-like version of Apollo Domain. With Unix
>>> systems and this software, the biggest issue was fonts, as the software
>>> needed to be able to calculate the extent, that is, the bounding box, for
>>> text that was to be displayed.
>>>
>>> Strangely enough, the other big issue was time.
>>>
>>> Rik
>>>
>>>
>>> On Tue, Aug 6, 2024 at 6:29 AM Peter Weinberger (温博格) via TUHS <
>>> tuhs@tuhs.org> wrote:
>>>
>>>> and the folks from PARC wanted a more RPC-based open OS, according to
>>>> my not-yet-fully-retrieved memories.
>>>>
>>>> On Tue, Aug 6, 2024 at 2:40 AM <arnold@skeeve.com> wrote:
>>>>> segaloco via TUHS <tuhs@tuhs.org> wrote:
>>>>>
>>>>>> Another way to put it would be as a chicken and egg, which came
>>>> first, ...
>>>>>> ..., or the ongoing need for UNIX standardization finding sponsorship
>>>>>> by the working groups, IEEE, etc.?
>>>>> This.
>>>>>
>>>>> Try to understand what things were like at the time. There were
>>>>> a ton of competing Unix systems, all different:
>>>>>
>>>>> - IBM: AIX on the mainframe and PS/2, which were different from
>>>>>    AIX on the RT/PC and later RS/6000 (workstations).
>>>>>
>>>>> - DEC: Ultrix on minicomputers and microvaxen, and later on MIPS
>>>>>    based workstations
>>>>>
>>>>> - Data General: DG/UX on their minicomputers.
>>>>>
>>>>> - Pyramid: A BSD/System V hybrid RISC minicomputer
>>>>>
>>>>> - Sun: Workstations, 680x0 based and later SPARC based, and servers.
>>>>>    Initially BSD based, later SVR4 based.
>>>>>
>>>>> - Workstations from HP, Tektronix, NBI, others I've probably forgotten,
>>>>>    3B2 and 3B1/Unix PC from AT&T... The list goes on and on and on.
>>>>>
>>>>> Things split roughly along BSD/System V lines, but code wasn't portable.
>>>>> Did you use bcopy() or memcpy()? index() or strchr()? There was lots
>>>>> of mixing and matching happening, too.
>>>>>
>>>>> There was a crying need for a standard. The mess is what begot GNU
>>>>> Autoconf, which made a difference at the time. Having the ANSI C
>>>> standard
>>>>> also helped.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Arnold
>> -- 
>> *My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

[TUHS] Re: Other POSIX Candidates?

[segaloco via TUHS]

On Tuesday, August 6th, 2024 at 11:36 AM, Heinz Lycklama <heinz@osta.com> wrote:

> The POSIX standard is based on the /usr/group standard
> which we started in 1981 under /usr/group, and turned
> into the standard in 1984, which was then turned over
> to the IEEE under the leadership of Jim Isaac. As the
> chair of the /usr/group standards effort, we made every
> attempt to include as many UNIX vendors as possible,
> systems vendors as well as application vendors. The
> work of the /usr/group standard was joined by all major
> computer manufacturers - mainframe, mini-computer,
> and micro-computer - plus applications vendors who
> were interested in having their apps run on as many
> platforms as possible. The members of the /usr/group
> standard committee also included the vendors of
> UNIX-like systems who did not have access to the source
> code for the UNIX System.
> 
> ISC (my employer at the time) also developed a UNIX
> emulation product that ran on the VAX VMS system in 1979.
> We had an interest in providing a platform for as many
> applications as possible on the VAX UNIX emulation platform.
> I do not recall that Govt contracts were a big concern at
> the time that we started the UNIX standards effort, but it
> did become a concern over the years.
> 
> My recall of the UNIX standards beginnings.
> 
> Heinz
> 
> On 8/6/2024 11:09 AM, arnold@skeeve.com wrote:
> 
> > For a long time DEC had "VMS POSIX" product. I don't know much
> > more about it, other than that it existed and was what you
> > describe, more or less.
> > 
> > Marc Rochkind mrochkind@gmail.com wrote:
> > 
> > > As I remember, part of the rationale was that DEC wanted something that
> > > could be specified in an RFP that was defined in terms of an interface,
> > > rather than an implementation. In theory this would allow them to propose
> > > VMS with an appropriate interface layer. I don't know if anything like this
> > > was ever created. But the interface standard sure was, of course.
> > > 
> > > On Tue, Aug 6, 2024 at 11:32 AM Rik Farrow rik@rikfarrow.com wrote:
> > > 
> > > > I recall something different than what others had suggested. When the US
> > > > government issued requests for proposals, they weren't permitted to specify
> > > > products by name. In particular, if you wanted something that wasn't
> > > > Microsoft, you couldn't actually specify that it be Unix.
> > > > 
> > > > So POSIX was born partially as a way of letting it be known you wanted a
> > > > Unix variant rather than something else.
> > > > 
> > > > Certainly porting was an issue. I did work for a software shop in the late
> > > > 80s and early 90s that produced graphics software, and porting between Unix
> > > > systems was relatively easy, compared to, say, moving the software to
> > > > Apollo's DomainIX, a sort of Unix-like version of Apollo Domain. With Unix
> > > > systems and this software, the biggest issue was fonts, as the software
> > > > needed to be able to calculate the extent, that is, the bounding box, for
> > > > text that was to be displayed.
> > > > 
> > > > Strangely enough, the other big issue was time.
> > > > 
> > > > Rik
> > > > 
> > > > On Tue, Aug 6, 2024 at 6:29 AM Peter Weinberger (温博格) via TUHS <
> > > > tuhs@tuhs.org> wrote:
> > > > 
> > > > > and the folks from PARC wanted a more RPC-based open OS, according to
> > > > > my not-yet-fully-retrieved memories.
> > > > > 
> > > > > On Tue, Aug 6, 2024 at 2:40 AM arnold@skeeve.com wrote:
> > > > > 
> > > > > > segaloco via TUHS tuhs@tuhs.org wrote:
> > > > > > 
> > > > > > > Another way to put it would be as a chicken and egg, which came
> > > > > > > first, ...
> > > > > > > ..., or the ongoing need for UNIX standardization finding sponsorship
> > > > > > > by the working groups, IEEE, etc.?
> > > > > > > This.
> > > > > > 
> > > > > > Try to understand what things were like at the time. There were
> > > > > > a ton of competing Unix systems, all different:
> > > > > > 
> > > > > > - IBM: AIX on the mainframe and PS/2, which were different from
> > > > > > AIX on the RT/PC and later RS/6000 (workstations).
> > > > > > 
> > > > > > - DEC: Ultrix on minicomputers and microvaxen, and later on MIPS
> > > > > > based workstations
> > > > > > 
> > > > > > - Data General: DG/UX on their minicomputers.
> > > > > > 
> > > > > > - Pyramid: A BSD/System V hybrid RISC minicomputer
> > > > > > 
> > > > > > - Sun: Workstations, 680x0 based and later SPARC based, and servers.
> > > > > > Initially BSD based, later SVR4 based.
> > > > > > 
> > > > > > - Workstations from HP, Tektronix, NBI, others I've probably forgotten,
> > > > > > 3B2 and 3B1/Unix PC from AT&T... The list goes on and on and on.
> > > > > > 
> > > > > > Things split roughly along BSD/System V lines, but code wasn't portable.
> > > > > > Did you use bcopy() or memcpy()? index() or strchr()? There was lots
> > > > > > of mixing and matching happening, too.
> > > > > > 
> > > > > > There was a crying need for a standard. The mess is what begot GNU
> > > > > > Autoconf, which made a difference at the time. Having the ANSI C
> > > > > > standard
> > > > > > also helped.
> > > > > > 
> > > > > > HTH,
> > > > > > 
> > > > > > Arnold
> > > > > > --
> > > > > > My new email address is mrochkind@gmail.com mrochkind@gmail.com

Thank you so much everyone for the thorough clarifications!  I think this little "selected" nugget may originate with verbiage on Wikipedia although I feel like I've seen at least one other source attempt to posit there was a selection to be made. From the Wikipedia overview:

"Unix was selected as the basis for a standard system interface partly because it was "manufacturer-neutral"."

My understanding aligns with what others have stated, that this was always a UNIX standardization effort, not some "which OS is it gonna be" that landed on UNIX for convenience. I figured this was the case but worth asking about anyhow.  Maybe it's time to dig out the old Wikipedia account and clarify that verbiage...

- Matt G.

[TUHS] Re: Other POSIX Candidates?

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

At 2024-08-06T14:19:19-0400, Clem Cole wrote:
> There were two organizations at the time, USENIX and /usr/group (later
> renamed "uniform"),

Should that be "Uniforum"?

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Other POSIX Candidates?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Tue, Aug 6, 2024 at 2:49 PM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> At 2024-08-06T14:19:19-0400, Clem Cole wrote:
> > There were two organizations at the time, USENIX and /usr/group (later
> > renamed "uniform"),
>
> Should that be "Uniforum"?
>
Officially it should be capitalized and as you point out correctly, spelled
with a U, so thank you.   Dyslexia-r-me.

BTW: Rik Farrow says, *"**Wow, they have a web page from the mid-1990s:*
http://www.uniforum.org/"
ᐧ
ᐧ

[-- Attachment #2: Type: text/html, Size: 2153 bytes --]

[TUHS] Re: Other POSIX Candidates?

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

On Tue, Aug 6, 2024 at 2:10 PM <arnold@skeeve.com> wrote:

> For a long time DEC had "VMS POSIX" product.  I don't know much
> more about it, other than that it existed and was what you
> describe, more or less.
>
> IIRC VMS POSIX was what motivated the product name change from VMS to
OpenVMS.  I thought the name change was an expensive and stupid idea at the
time.  I still do.

-Paul W.

[-- Attachment #2: Type: text/html, Size: 710 bytes --]

[TUHS] Re: Other POSIX Candidates?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On Tue, Aug 6, 2024 at 3:05 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

>
> "Unix was selected as the basis for a standard system interface partly
> because it was "manufacturer-neutral"."
>
BS ... the cart is before the horse here.

The minicomputer and workstation manufacturers had already picked "UNIX'
and we had a term for it already: "Open Systems" - because the sources for
the interfaces were open and the core UNIX technology (*i.e.*, the AT&T and
BSD sources) were >>freely available<< to vendors, ISVs and even users (but
they might have to >>pay<< for a license -- *i.e.*, it was "open" (free as
in "libre" but not "free" as in beer).

It was not neutral at all. What seems to be forgotten/misunderstood in
today's world, the core problem being solved was getting >>ISV<< codes to
your system.

Thus, the ABI *vs.* API argument.  In many ways, the ISVs like the ABIs
over the API as it cuts down their tests/number of versions needed -- but
if we could create an API that everyone could agree to, that would be
neutral - as then the difference for an ISV would be packaging and
testing.  The concept was "just recompile."  ISTR Heinz was one of the
people who reminded us on the committee early on that without a real ABI,
we would never have as many applications as either the mainframes or the
PCs. But no vendor would give up control.  AT&T tried to create an ABI and
did define one for their System V (I think R2 originally), but as they were
so backward /behind in the OS features due to NIH and frankly heavy-handed
in licenses and business issues, few vendors trusted them.   By the time of
SVR4, that was a lost cause.

Funny, even Linux never got there, contrary to what it says.  This is why
Intel has to develop the Cluster Ready Program.   I know of one HPC ISV
that had a test matrix of 144 different Linux cluster configurations they
had tested their code - when you counted, N versions of Red Hat, Ubuntu,
SUSE, and then manufacturers: IBM vs HP vs Cray, and everyone had different
interconnects.  What a nightmare!!!


ᐧ

[-- Attachment #2: Type: text/html, Size: 4184 bytes --]

[TUHS] Re: Other POSIX Candidates?

[Theodore Ts'o]

On Tue, Aug 06, 2024 at 10:31:42AM -0700, Rik Farrow wrote:
> I recall something different than what others had suggested. When the US
> government issued requests for proposals, they weren't permitted to specify
> products by name. In particular, if you wanted something that wasn't
> Microsoft, you couldn't actually specify that it be Unix.

That might have been *a* consideration, and that might have been a
reason to take a pre-existing standard work and turn it into something
official such as IEEE.

There was a similar dynamic at work with the Linux Standard Base,
which was originally an effort (which I was involved in), to create a
ABI standard for Linux.  The hope at the time was that this might make
it easier for application vendors to make comercial software available
that would work across multiple Linux distributions --- and in
particular SuSE and Red Hat.

This work went on for awhile, and we had developed an ABI standard
that worked aross multiple architectures, including (but not limited
to) x86/64, PowerPC, and S/390.  At one point, in order to sell into
certain government market (both the US and some European countries),
there was a desire by certain major companies that we take the LSB to
some Official Standards Body (the Free Standards Group, and which
merged with OSDL to form the Linux Foundation wasn't good enough for
government bureaucrats).  So I was involved with various corporate
strategists about which standards body would be easy enough to
control; we considered IEEE, ECMA, and ISO.  Ultimately the choice was
ISO, and various big companies (including IBM and HP) sent their
employees to various national standards bodies, and I got bunch of
international trips to Europe and Asia, and after a year or two, the
Linux Standard Base became ISO/IEC 23360.

Of course, keeping an ISO standard up to date took a huge amount of
effort and money, and over time, the requirement from government
buyers that an OS came with an Internaional Standard went away --- and
then my employer at the time, as well as the other major Linux
companies, abandoned the effort completely.

So while it may have been the case that at one point the US Government
may have had a requirement, and the US Government may have looked down
on plebian standards bodies like Uniforum and the Free Standards Body,
and this might have inspired the $$$$ and effort to get an officially
blessed International Standard, this was very likely *not* the reason
why the stndard was written in the first place.

						- Ted

P.S.  For those of you who heard the controversy of how Microsoft
manipulated the ISO process by stacking the deck with the employees at
multiple countries' national bodies to influence the Office Open XML
File Format (ISO/IEC 29500, previously known as ECMA-376), I can say
quite authoratively that IBM and HP, as multinational, were not above
doing something very similar with ISO/IEC 23360.  The only difference
was that it wasn't quite a high stakes, and it didn't result in
appeals up to ISO/IEC JTC like what happened with ISO/IEC 29500.

But as a result, I'm quite cynical about standards bodies which do
voting by countries' national standards bodies, since I've seen how
easy it is for multinationals to put fairly major thumbs on the scales
to get a desired business outcome...

[TUHS] Re: Other POSIX Candidates?

[Steffen Nurpmeso]

Theodore Ts'o wrote in
 <20240807040644.GA4511@mit.edu>:
 |On Tue, Aug 06, 2024 at 10:31:42AM -0700, Rik Farrow wrote:
 |> I recall something different than what others had suggested. When the US
 |> government issued requests for proposals, they weren't permitted \
 |> to specify
 |> products by name. In particular, if you wanted something that wasn't
 |> Microsoft, you couldn't actually specify that it be Unix.
 |
 |That might have been *a* consideration, and that might have been a
 |reason to take a pre-existing standard work and turn it into something
 |official such as IEEE.
 |
 |There was a similar dynamic at work with the Linux Standard Base,
 |which was originally an effort (which I was involved in), to create a
 |ABI standard for Linux.  The hope at the time was that this might make
 |it easier for application vendors to make comercial software available
 |that would work across multiple Linux distributions --- and in
 |particular SuSE and Red Hat.
 |
 |This work went on for awhile, and we had developed an ABI standard
 |that worked aross multiple architectures, including (but not limited
 |to) x86/64, PowerPC, and S/390.  At one point, in order to sell into
 |certain government market (both the US and some European countries),
 |there was a desire by certain major companies that we take the LSB to
 |some Official Standards Body (the Free Standards Group, and which
 |merged with OSDL to form the Linux Foundation wasn't good enough for
 |government bureaucrats).  So I was involved with various corporate
 |strategists about which standards body would be easy enough to
 |control; we considered IEEE, ECMA, and ISO.  Ultimately the choice was
 |ISO, and various big companies (including IBM and HP) sent their
 |employees to various national standards bodies, and I got bunch of
 |international trips to Europe and Asia, and after a year or two, the
 |Linux Standard Base became ISO/IEC 23360.
 |
 |Of course, keeping an ISO standard up to date took a huge amount of
 |effort and money, and over time, the requirement from government
 |buyers that an OS came with an Internaional Standard went away --- and
 |then my employer at the time, as well as the other major Linux
 |companies, abandoned the effort completely.
 |
 |So while it may have been the case that at one point the US Government
 |may have had a requirement, and the US Government may have looked down
 |on plebian standards bodies like Uniforum and the Free Standards Body,
 |and this might have inspired the $$$$ and effort to get an officially
 |blessed International Standard, this was very likely *not* the reason
 |why the stndard was written in the first place.
 |
 |      - Ted
 |
 |P.S.  For those of you who heard the controversy of how Microsoft
 |manipulated the ISO process by stacking the deck with the employees at
 |multiple countries' national bodies to influence the Office Open XML
 |File Format (ISO/IEC 29500, previously known as ECMA-376), I can say
 |quite authoratively that IBM and HP, as multinational, were not above
 |doing something very similar with ISO/IEC 23360.  The only difference
 |was that it wasn't quite a high stakes, and it didn't result in
 |appeals up to ISO/IEC JTC like what happened with ISO/IEC 29500.
 |
 |But as a result, I'm quite cynical about standards bodies which do
 |voting by countries' national standards bodies, since I've seen how
 |easy it is for multinationals to put fairly major thumbs on the scales
 |to get a desired business outcome...
 --End of <20240807040644.GA4511@mit.edu>

Btw how ridiculous is the view onto those Chinese Linux
Distributions which put effort in making Linux POSIX compatible,
and even pay money for making that official?
I personally was *tremendously*, well, pissed, once one of those
distributions was (just recently, ie, years later) not allowed to
join the encrypted part of oss-security.
Too much politics in a non-free world.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|
| Only during dog days:
| On the 81st anniversary of the Goebbel's Sportpalast speech
| von der Leyen gave an overlong hypocritical inauguration one.
| The brew's essence of our civilizing advancement seems o be:
|   Total war - shortest war -> Permanent war - everlasting war

[TUHS] Re: Other POSIX Candidates?

[Theodore Ts'o]

On Wed, Aug 07, 2024 at 10:56:14PM +0200, Steffen Nurpmeso wrote:
> Btw how ridiculous is the view onto those Chinese Linux
> Distributions which put effort in making Linux POSIX compatible,
> and even pay money for making that official?

Well, that's their choice.  No US companies that I know of care about
POSIX compliance, so I don't know if any US-based distributions that
are paying money (or more importantly) engineer time, to make it
official.  If Chinese distributions are investing resources in that
way, well.... that's there stupidity or maybe, a very good business
choice.  :-)

> I personally was *tremendously*, well, pissed, once one of those
> distributions was (just recently, ie, years later) not allowed to
> join the encrypted part of oss-security.
> Too much politics in a non-free world.

In the real wrld things get complicated.  In 2019 the US put export
restrictions for Huawei, which was interpreted at the time that public
discussions on open mailing lists relating to Linux was totally fine.
But there was some legal interpreations that direct
engineer-to-engineer e-mail might be considered lending assistance
that could potentially run afoul some of the export restrictions.  I'm
not a lawyer, but an encrypted distribution to certain chinese
entities might be... complex from a legal perspective.  Talk to your
corporate legal counsel for specific legal advice.

Things are even worse with Russian companies, since the OFAC (Office
of Foreign Assets Controls, at https://ofac.trasury.gov) sanctions are
even more strict.  Even if the exchange happens on an open source
mailing list, if the patches come from a sanctioned entity, or an
entity controlled by a sanctioned entity, and the patches say, contain
device drivers used by a Russian SOC that is known to be used in
Russin missiles used against Ukraine (completely hypothetically, of
course...)  --- if a US based engineer accepts those patches, that's
considered rendering assistance to a sanctioned entity, and you and
your company have to file paperwork acknowledging that it was done
unknowingly, and the patches need to be reverted.  Again, talk to your
friendly neighborhood legal counsel before you do anything with an
entity that may be from Russia, because the OFAC database of
sanctioned entities is constantly changing, and its search functions
are terribly primitive.

The joys of being an open source maintainer in the 21st century....
Not only do you have to worry about trojan horse constributions from
agents of the Chinese Ministry of State Security (ala xz), you also
have to worry about the US government and OFAC-administered sanctions.

						- Ted

[TUHS] Re: Other POSIX Candidates?

[Kevin Bowling]

[-- Attachment #1: Type: text/plain, Size: 3115 bytes --]

On Tue, Aug 6, 2024 at 12:31 PM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Tue, Aug 6, 2024 at 3:05 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
>>
>> "Unix was selected as the basis for a standard system interface partly
>> because it was "manufacturer-neutral"."
>>
> BS ... the cart is before the horse here.
>
> The minicomputer and workstation manufacturers had already picked "UNIX'
> and we had a term for it already: "Open Systems" - because the sources for
> the interfaces were open and the core UNIX technology (*i.e.*, the AT&T
> and BSD sources) were >>freely available<< to vendors, ISVs and even users
> (but they might have to >>pay<< for a license -- *i.e.*, it was "open"
> (free as in "libre" but not "free" as in beer).
>
> It was not neutral at all. What seems to be forgotten/misunderstood in
> today's world, the core problem being solved was getting >>ISV<< codes to
> your system.
>
> Thus, the ABI *vs.* API argument.  In many ways, the ISVs like the ABIs
> over the API as it cuts down their tests/number of versions needed -- but
> if we could create an API that everyone could agree to, that would be
> neutral - as then the difference for an ISV would be packaging and
> testing.  The concept was "just recompile."  ISTR Heinz was one of the
> people who reminded us on the committee early on that without a real ABI,
> we would never have as many applications as either the mainframes or the
> PCs. But no vendor would give up control.  AT&T tried to create an ABI and
> did define one for their System V (I think R2 originally), but as they were
> so backward /behind in the OS features due to NIH and frankly heavy-handed
> in licenses and business issues, few vendors trusted them.   By the time of
> SVR4, that was a lost cause.
>

I often wonder about SCO when these kinds of discussions come up.  Speaking
about SCO is always a sticky wicket because the name became disgraced with
the late form.

My understanding is the SCO Xenix -> {SCO UNIX v3, OpenDesktop, OpenServer}
lineage was the largest volume UNIX for most of the 1980s and 1990s.

Relevant to Clem's point, it seems like the iBCS
https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard served to
try and provide some uniformity for ISVs providing binary software on a
variety of x86 UNIX.  The bit it says about Linux having support is true
too, I have some old boxed Linux distros and that is one of the features
they advertise.

Of course this all started to collapse by the mid to late 1990s.. but once
upon a time it seems like SCO was a big deal.. although I guess it appealed
to a different crowd.


> Funny, even Linux never got there, contrary to what it says.  This is why
> Intel has to develop the Cluster Ready Program.   I know of one HPC ISV
> that had a test matrix of 144 different Linux cluster configurations they
> had tested their code - when you counted, N versions of Red Hat, Ubuntu,
> SUSE, and then manufacturers: IBM vs HP vs Cray, and everyone had different
> interconnects.  What a nightmare!!!
>
>
> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 5652 bytes --]

[TUHS] Re: Other POSIX Candidates?

[Theodore Ts'o]

On Wed, Aug 07, 2024 at 06:25:12PM -0700, Kevin Bowling wrote:
> 
> Relevant to Clem's point, it seems like the iBCS
> https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard served to
> try and provide some uniformity for ISVs providing binary software on a
> variety of x86 UNIX.  The bit it says about Linux having support is true
> too, I have some old boxed Linux distros and that is one of the features
> they advertise.

Around 1994, MIT purchased a site license for a proprietary
spreadsheet program for SCO because we knew it would work on Linux
(and we had a lot of Linux usage on campus; we had ported a good chunk
of the Project Athena infrastruture, including the Andrew File System
to Linux).

An amusing anecdote; I worked with one of their primary software
developers so we could get a custom build of the software that would
only work if the IP address of the machine was 18.X.Y.Z, since MIT had
class A network.  This person would eventually become one of the
founders of Red Hat, and I told him that we were purchasing it
intended to run it on Linux.  He told me that this would be perfectly
fine, because he had compiled the iBCS binary on Linux.  Turns out the
development environment on Linux was far more developer friendly (at
least in his eyes) than SCO, so he was building a SCO/iBCS binary on
Linux.  Since he had done his basic automated regression testing on
Linux with iBCS emulation, and only later sent the binary to do QA on
the SCO client, he was quite confident that it work just _fine_ on our
student's Linux desktops.

       	   	      	    	   - Ted

[TUHS] Re: Other POSIX Candidates?

[Marc Donner]

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

To summarize this discussion, if I may, the unifying driver was developer
friendliness, with all of its deeper implications, that drove the process.

Reflecting on this theme, I note that MSFT focused on developers in the
golden age of Windows.  Some of it was investment in powerful IDEs but an
awful lot of it was stuff like their MVP program that created community as
well as offering participants some differentiation in their competition for
customers.

Looking back, the community-building aspects attracted me in the early days.

Marc
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


On Wed, Aug 7, 2024 at 11:57 PM Theodore Ts'o <tytso@mit.edu> wrote:

> On Wed, Aug 07, 2024 at 06:25:12PM -0700, Kevin Bowling wrote:
> >
> > Relevant to Clem's point, it seems like the iBCS
> > https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard
> served to
> > try and provide some uniformity for ISVs providing binary software on a
> > variety of x86 UNIX.  The bit it says about Linux having support is true
> > too, I have some old boxed Linux distros and that is one of the features
> > they advertise.
>
> Around 1994, MIT purchased a site license for a proprietary
> spreadsheet program for SCO because we knew it would work on Linux
> (and we had a lot of Linux usage on campus; we had ported a good chunk
> of the Project Athena infrastruture, including the Andrew File System
> to Linux).
>
> An amusing anecdote; I worked with one of their primary software
> developers so we could get a custom build of the software that would
> only work if the IP address of the machine was 18.X.Y.Z, since MIT had
> class A network.  This person would eventually become one of the
> founders of Red Hat, and I told him that we were purchasing it
> intended to run it on Linux.  He told me that this would be perfectly
> fine, because he had compiled the iBCS binary on Linux.  Turns out the
> development environment on Linux was far more developer friendly (at
> least in his eyes) than SCO, so he was building a SCO/iBCS binary on
> Linux.  Since he had done his basic automated regression testing on
> Linux with iBCS emulation, and only later sent the binary to do QA on
> the SCO client, he was quite confident that it work just _fine_ on our
> student's Linux desktops.
>
>                                    - Ted
>

[-- Attachment #2: Type: text/html, Size: 3319 bytes --]

[TUHS] Re: Other POSIX Candidates?

[Charles H Sauer (he/him)]

Yes, MSFT and their 
https://microsoft.fandom.com/wiki/Professional_Developers_Conference 
were important, especially the 1993 Anaheim one that gave many of us our 
first real taste of "Chicago." That Brad Silverberg and Steve Ballmer 
paid special attention to people  like me didn't hurt. I suspect Brad 
deserves even more credit than he gets regarding supporting developers.

To keep things vaguely Unix related, that Anaheim conference was after 
Rick Rashid had moved to MSFT Research. He and I bumped into each other 
in a gift shop in Fantasyland, and discussed our career changes (I had 
just left Dell for VTEL).

Charlie

On 8/8/2024 3:46 AM, Marc Donner wrote:
> To summarize this discussion, if I may, the unifying driver was 
> developer friendliness, with all of its deeper implications, that drove 
> the process.
> 
> Reflecting on this theme, I note that MSFT focused on developers in the 
> golden age of Windows.  Some of it was investment in powerful IDEs but 
> an awful lot of it was stuff like their MVP program that created 
> community as well as offering participants some differentiation in their 
> competition for customers.
> 
> Looking back, the community-building aspects attracted me in the early days.
> 
> Marc
> =====
> nygeek.net <http://nygeek.net>
> mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/Twitter: CharlesHSauer

[TUHS] Re: Other POSIX Candidates?

[Steffen Nurpmeso]

Theodore Ts'o wrote in
 <20240807234755.GB4511@mit.edu>:
 |On Wed, Aug 07, 2024 at 10:56:14PM +0200, Steffen Nurpmeso wrote:
 |> Btw how ridiculous is the view onto those Chinese Linux
 |> Distributions which put effort in making Linux POSIX compatible,
 |> and even pay money for making that official?
 |
 |Well, that's their choice.  No US companies that I know of care about
 |POSIX compliance, so I don't know if any US-based distributions that
 |are paying money (or more importantly) engineer time, to make it
 |official.  If Chinese distributions are investing resources in that
 |way, well.... that's there stupidity or maybe, a very good business
 |choice.  :-)
 |
 |> I personally was *tremendously*, well, pissed, once one of those
 |> distributions was (just recently, ie, years later) not allowed to
 |> join the encrypted part of oss-security.
 |> Too much politics in a non-free world.
 |
 |In the real wrld things get complicated.  In 2019 the US put export
 |restrictions for Huawei, which was interpreted at the time that public
 |discussions on open mailing lists relating to Linux was totally fine.
 |But there was some legal interpreations that direct
 |engineer-to-engineer e-mail might be considered lending assistance
 |that could potentially run afoul some of the export restrictions.  I'm
 |not a lawyer, but an encrypted distribution to certain chinese
 |entities might be... complex from a legal perspective.  Talk to your
 |corporate legal counsel for specific legal advice.
 |
 |Things are even worse with Russian companies, since the OFAC (Office
 |of Foreign Assets Controls, at https://ofac.trasury.gov) sanctions are
 |even more strict.  Even if the exchange happens on an open source
 |mailing list, if the patches come from a sanctioned entity, or an
 |entity controlled by a sanctioned entity, and the patches say, contain
 |device drivers used by a Russian SOC that is known to be used in
 |Russin missiles used against Ukraine (completely hypothetically, of
 |course...)  --- if a US based engineer accepts those patches, that's
 |considered rendering assistance to a sanctioned entity, and you and
 |your company have to file paperwork acknowledging that it was done
 |unknowingly, and the patches need to be reverted.  Again, talk to your
 |friendly neighborhood legal counsel before you do anything with an
 |entity that may be from Russia, because the OFAC database of
 |sanctioned entities is constantly changing, and its search functions
 |are terribly primitive.

Thanks for the answer.
(I try to be strong and just hope *that* is over soon.)

 |The joys of being an open source maintainer in the 21st century....
 |Not only do you have to worry about trojan horse constributions from
 |agents of the Chinese Ministry of State Security (ala xz), you also

Aaaah!  Not north korean, .. they are only out for the money.
(And are blocked at github, like i think cuba, iran, whoever.)
I see.  I did not know that rock-solid argumentation (except for
the lengthy commit time sleuthing posts).

 |have to worry about the US government and OFAC-administered sanctions.

Yes i have read "small lip notices" by Kroah-Hartman on
oss-security (before Linux "started emitting own CVEs").
That is no fun.  Let's just hope we can somehow overcome all that.


Good bye, ciao, and good night from Germany.
Thanks.



Now unfortunately i cannot keep my mouth shut, and it is likely
that most people do not want to read this further.  But it is all
about (the remains of) Unix (aka free software world, mostly, with
lots of people spending free time for the very famous
https://xkcd.com/2347/), from a red flag waving NetBSD
mailing-list, aka tech-pkg AT netbsd.org, from the 4th of April
this year, while responding to an (american) email ending "I think
we should really discuss this...", and pointing to
https://joeyh.name/blog/entry/reflections_on_distrusting_xz, all
of which i have forgotten.  I apologise in advance.  Sorry!!!

Short:

I am so disappointed that all the opportunities for bashing
people have been omitted, like that you do not win wars.

  [.] jiat75 reads like dschiha:d, and 5.6.0 was shortly before
  ramadan

Isn't it a shame that muslims are not valued enough for being real
hacking threats, are they only good enough for kamikaze?
(I love what Rainer Maria Rilke said about the Koran btw.  In my
bad bad translation it reads like "Islam is a 'religion of the
undisguised space', of pure creature feeling: earth can be
perceived as a 'pure star': 'creatureliness of the earth can
appear pure and undisguised'".)

And then (i apologize for quoting this, i did not know the
maintainer was hm dissed over months)

  He publically mentioned his mental health issues multiple times,
  and -- sorry if i got that thread starter wrong even -- that may
  make people think of Jekyl and Hyde who then gets himself what he
  is actually worth, with schizophrenically (i am not an expert as
  you see) raising alert signs to others, like explicitly mentioning
  mental health issues.

That reminds me that the Helter Skelter murders drive 55 today.

Longer:

  I reverted to 5.4.0 locally.  I looked at the ~half a dozen
  commits of jiat75 by then, and they looked good.
  But AlpineLinux stayed at 5.6.1, they simply autoreconf -vis or
  what, instead of using anything provided.  There are a few hundred
  commits of jiat, and the poor original developer has to crawl
  through them.  Then again i personally have my doubts and said so
  in public already.

[Does not smell Chinese style imho, they have lots of autonomous
regions with a whole lotta different "tribes" aka cultures.
Granted the Han are the by far largest sort.  But still.  I mean,
there *are* muslims, ok.]

[now it cums.  I mean, not that Iran shoots its own ships no more
at the moment, as it did under Trump, but the Palestinians are
where his son-in-law wanted them .. etc etc etc etc]

  And jiat75 reads like dschiha:d, and 5.6.0 was
  shortly before Ramadan, so i think it surely is a small-minded not
  even christian educated western-style desired-to-be-criminal.
  ...

[*That* still *could* be Chinese nonetheless, of course.]  And

   |One thing we need to discuss for sure is the blame game currently
   |being played by quite a few parties. "You merged a Jia Tan commit,

[btw "jia tan" reads in german like "dschiha:d on", which is
a particularly smart name for a chinese secret service guy]

   |you must be a plant as well!" Personally, I find the danger of that kind of

[A German talking.  I .. think .. with born-eastern experience, ..]

   |attitude turning away a lot of volunteers a lot more harmful.

Here we are back at the famous https://xkcd.com/2347/.

Technically .. well.  Well, technically, i think much more
sophisticated miracles were already seen in the past, in the end
all the software and hardware designs are US controlled.
Not that i would have been able to invent it, or even, do it.

Now -- I must and wholeheartly do admit that i adore political
Chinese cartoons, they still have the black wit that i miss so much
in Germany, but which was still present when i was a younger man,
say, thirty years ago, snappy cabaret artists like the "forever"
unforgotten Dieter Hildebrandt etc etc.

  https://www.globaltimes.cn/cartoon/
  curl --insecure -O https://www.globaltimes.cn/Portals/0/attachment/2024/2024-02-08/d4010c2b-f01f-4370-8424-0f3e84950662_s.jpeg
  curl --insecure -O https://www.globaltimes.cn/Portals/0/attachment/2024/2024-02-19/fcb05453-2619-4932-9888-bcd471c5252c_s.jpeg
  curl --insecure -O https://www.globaltimes.cn/Portals/0/attachment/2023/2023-04-13/a3d522d5-2a81-4569-b325-7e0ed5bc0bad_s.jpeg

300 KB, and i do admit they are very one-sided.

 |      - Ted
 --End of <20240807234755.GB4511@mit.edu>

I am sorry, dear Warren.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|
| Only during dog days:
| On the 81st anniversary of the Goebbel's Sportpalast speech
| von der Leyen gave an overlong hypocritical inauguration one.
| The brew's essence of our civilizing advancement seems o be:
|   Total war - shortest war -> Permanent war - everlasting war