* [TUHS] Other POSIX Candidates? @ 2024-08-06 3:26 segaloco via TUHS 2024-08-06 3:38 ` [TUHS] " George Michaelson ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: segaloco via TUHS @ 2024-08-06 3:26 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 3:26 [TUHS] Other POSIX Candidates? segaloco via TUHS @ 2024-08-06 3:38 ` George Michaelson 2024-08-06 6:39 ` arnold 2024-08-06 18:19 ` Clem Cole 2 siblings, 0 replies; 24+ messages in thread From: George Michaelson @ 2024-08-06 3:38 UTC (permalink / raw) To: segaloco; +Cc: The Eunuchs Hysterical Society 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 3:26 [TUHS] Other POSIX Candidates? segaloco via TUHS 2024-08-06 3:38 ` [TUHS] " George Michaelson @ 2024-08-06 6:39 ` arnold 2024-08-06 13:29 ` Peter Weinberger (温博格) via TUHS 2024-08-06 18:19 ` Clem Cole 2 siblings, 1 reply; 24+ messages in thread From: arnold @ 2024-08-06 6:39 UTC (permalink / raw) To: tuhs, segaloco 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 6:39 ` arnold @ 2024-08-06 13:29 ` Peter Weinberger (温博格) via TUHS 2024-08-06 17:31 ` Rik Farrow 0 siblings, 1 reply; 24+ messages in thread From: Peter Weinberger (温博格) via TUHS @ 2024-08-06 13:29 UTC (permalink / raw) To: arnold; +Cc: tuhs, segaloco 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 13:29 ` Peter Weinberger (温博格) via TUHS @ 2024-08-06 17:31 ` Rik Farrow 2024-08-06 18:04 ` Marc Rochkind 2024-08-07 4:06 ` Theodore Ts'o 0 siblings, 2 replies; 24+ messages in thread From: Rik Farrow @ 2024-08-06 17:31 UTC (permalink / raw) To: Peter Weinberger (温博格); +Cc: tuhs, segaloco [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 17:31 ` Rik Farrow @ 2024-08-06 18:04 ` Marc Rochkind 2024-08-06 18:09 ` arnold 2024-08-06 18:18 ` Rik Farrow 2024-08-07 4:06 ` Theodore Ts'o 1 sibling, 2 replies; 24+ messages in thread From: Marc Rochkind @ 2024-08-06 18:04 UTC (permalink / raw) Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 18:04 ` Marc Rochkind @ 2024-08-06 18:09 ` arnold 2024-08-06 18:36 ` Heinz Lycklama 2024-08-06 19:07 ` Paul Winalski 2024-08-06 18:18 ` Rik Farrow 1 sibling, 2 replies; 24+ messages in thread From: arnold @ 2024-08-06 18:09 UTC (permalink / raw) To: mrochkind; +Cc: tuhs 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>* ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 18:09 ` arnold @ 2024-08-06 18:36 ` Heinz Lycklama 2024-08-06 18:45 ` segaloco via TUHS 2024-08-06 19:07 ` Paul Winalski 1 sibling, 1 reply; 24+ messages in thread From: Heinz Lycklama @ 2024-08-06 18:36 UTC (permalink / raw) To: tuhs 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>* ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 18:36 ` Heinz Lycklama @ 2024-08-06 18:45 ` segaloco via TUHS 2024-08-06 19:31 ` Clem Cole 0 siblings, 1 reply; 24+ messages in thread From: segaloco via TUHS @ 2024-08-06 18:45 UTC (permalink / raw) To: heinz; +Cc: 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 18:45 ` segaloco via TUHS @ 2024-08-06 19:31 ` Clem Cole 2024-08-08 1:25 ` Kevin Bowling 0 siblings, 1 reply; 24+ messages in thread From: Clem Cole @ 2024-08-06 19:31 UTC (permalink / raw) To: segaloco; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 19:31 ` Clem Cole @ 2024-08-08 1:25 ` Kevin Bowling 2024-08-08 3:56 ` Theodore Ts'o 0 siblings, 1 reply; 24+ messages in thread From: Kevin Bowling @ 2024-08-08 1:25 UTC (permalink / raw) To: Clem Cole; +Cc: segaloco, tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-08 1:25 ` Kevin Bowling @ 2024-08-08 3:56 ` Theodore Ts'o 2024-08-08 8:46 ` Marc Donner 0 siblings, 1 reply; 24+ messages in thread From: Theodore Ts'o @ 2024-08-08 3:56 UTC (permalink / raw) To: Kevin Bowling; +Cc: segaloco, tuhs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-08 3:56 ` Theodore Ts'o @ 2024-08-08 8:46 ` Marc Donner 2024-08-08 16:09 ` Charles H Sauer (he/him) 0 siblings, 1 reply; 24+ messages in thread From: Marc Donner @ 2024-08-08 8:46 UTC (permalink / raw) To: Theodore Ts'o; +Cc: segaloco, tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-08 8:46 ` Marc Donner @ 2024-08-08 16:09 ` Charles H Sauer (he/him) 0 siblings, 0 replies; 24+ messages in thread From: Charles H Sauer (he/him) @ 2024-08-08 16:09 UTC (permalink / raw) To: tuhs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 18:09 ` arnold 2024-08-06 18:36 ` Heinz Lycklama @ 2024-08-06 19:07 ` Paul Winalski 1 sibling, 0 replies; 24+ messages in thread From: Paul Winalski @ 2024-08-06 19:07 UTC (permalink / raw) To: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 18:04 ` Marc Rochkind 2024-08-06 18:09 ` arnold @ 2024-08-06 18:18 ` Rik Farrow 1 sibling, 0 replies; 24+ messages in thread From: Rik Farrow @ 2024-08-06 18:18 UTC (permalink / raw) To: Marc Rochkind; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 17:31 ` Rik Farrow 2024-08-06 18:04 ` Marc Rochkind @ 2024-08-07 4:06 ` Theodore Ts'o 2024-08-07 20:56 ` Steffen Nurpmeso 1 sibling, 1 reply; 24+ messages in thread From: Theodore Ts'o @ 2024-08-07 4:06 UTC (permalink / raw) To: Rik Farrow; +Cc: Peter Weinberger (温博格), tuhs, segaloco 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... ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-07 4:06 ` Theodore Ts'o @ 2024-08-07 20:56 ` Steffen Nurpmeso 2024-08-07 23:47 ` Theodore Ts'o 0 siblings, 1 reply; 24+ messages in thread From: Steffen Nurpmeso @ 2024-08-07 20:56 UTC (permalink / raw) To: Theodore Ts'o Cc: Rik Farrow, Peter Weinberger (=E6=B8=A9=E5=8D=9A=E6=A0=BC), tuhs, segaloco 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-07 20:56 ` Steffen Nurpmeso @ 2024-08-07 23:47 ` Theodore Ts'o 2024-08-09 0:53 ` Steffen Nurpmeso 0 siblings, 1 reply; 24+ messages in thread From: Theodore Ts'o @ 2024-08-07 23:47 UTC (permalink / raw) To: Rik Farrow, Peter Weinberger, tuhs, segaloco 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-07 23:47 ` Theodore Ts'o @ 2024-08-09 0:53 ` Steffen Nurpmeso 0 siblings, 0 replies; 24+ messages in thread From: Steffen Nurpmeso @ 2024-08-09 0:53 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Rik Farrow, Peter Weinberger, tuhs, segaloco 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 3:26 [TUHS] Other POSIX Candidates? segaloco via TUHS 2024-08-06 3:38 ` [TUHS] " George Michaelson 2024-08-06 6:39 ` arnold @ 2024-08-06 18:19 ` Clem Cole 2024-08-06 18:23 ` Clem Cole 2024-08-06 18:49 ` G. Branden Robinson 2 siblings, 2 replies; 24+ messages in thread From: Clem Cole @ 2024-08-06 18:19 UTC (permalink / raw) To: segaloco, The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 18:19 ` Clem Cole @ 2024-08-06 18:23 ` Clem Cole 2024-08-06 18:49 ` G. Branden Robinson 1 sibling, 0 replies; 24+ messages in thread From: Clem Cole @ 2024-08-06 18:23 UTC (permalink / raw) To: segaloco, The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 18:19 ` Clem Cole 2024-08-06 18:23 ` Clem Cole @ 2024-08-06 18:49 ` G. Branden Robinson 2024-08-06 18:55 ` Clem Cole 1 sibling, 1 reply; 24+ messages in thread From: G. Branden Robinson @ 2024-08-06 18:49 UTC (permalink / raw) To: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Re: Other POSIX Candidates? 2024-08-06 18:49 ` G. Branden Robinson @ 2024-08-06 18:55 ` Clem Cole 0 siblings, 0 replies; 24+ messages in thread From: Clem Cole @ 2024-08-06 18:55 UTC (permalink / raw) To: G. Branden Robinson; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2024-08-09 0:54 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-08-06 3:26 [TUHS] Other POSIX Candidates? segaloco via TUHS 2024-08-06 3:38 ` [TUHS] " George Michaelson 2024-08-06 6:39 ` arnold 2024-08-06 13:29 ` Peter Weinberger (温博格) via TUHS 2024-08-06 17:31 ` Rik Farrow 2024-08-06 18:04 ` Marc Rochkind 2024-08-06 18:09 ` arnold 2024-08-06 18:36 ` Heinz Lycklama 2024-08-06 18:45 ` segaloco via TUHS 2024-08-06 19:31 ` Clem Cole 2024-08-08 1:25 ` Kevin Bowling 2024-08-08 3:56 ` Theodore Ts'o 2024-08-08 8:46 ` Marc Donner 2024-08-08 16:09 ` Charles H Sauer (he/him) 2024-08-06 19:07 ` Paul Winalski 2024-08-06 18:18 ` Rik Farrow 2024-08-07 4:06 ` Theodore Ts'o 2024-08-07 20:56 ` Steffen Nurpmeso 2024-08-07 23:47 ` Theodore Ts'o 2024-08-09 0:53 ` Steffen Nurpmeso 2024-08-06 18:19 ` Clem Cole 2024-08-06 18:23 ` Clem Cole 2024-08-06 18:49 ` G. Branden Robinson 2024-08-06 18:55 ` Clem Cole
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).