Splinter Unix?

[Doug Gwyn]

In article <342 at mipseast.mips.COM> rogerk at mipseast.mips.COM (Roger B.A. Klorese) writes:
>If a portable operating system product
>can be developed by OSF that will support AIX and Ultrix applications,
>be available at the same time to all of its members, and conform to
>POSIX and its follow-ons, it will be a far more appropriate product
>for the marketplace than your alleged "standard", the AT&T-Sun proprietary
>operating system.

I've been developing applications for this standard environment for
years, and as you put it I "like it that way".  It was even worth the
trouble of implementing a SVID-compatible environment for BSD-based
systems when vendors failed to provide one.

POSIX, on the other hand, was so weakened in an attempt to accommodate
vendors' existing implementations (including AT&T's and DEC's) that it
failed, in my opinion, to provide a sufficiently specific portable
application platform.  I will STILL have major porting problems going
between POSIX-conforming systems that I do NOT have when moving code
among SVID-based systems (not that the SVID is perfect, but it's a
more USEFUL standard than POSIX).  Note that I am NOT saying that
POSIX should have rubber-stamped the SVID, but it should have been at
least as "crisp".

If POSIX had been more radical, for example fixing obvious problems
in existing UNIX implementations (including AT&T's), it could have
been a useful "neutral" standard that I could support as a total
replacement for the SVID (at least in those areas that are covered
by both standards), insofar as application needs are concerned.  As
it stands, I think I'll have to continue to use the SVID as my working
UNIX-environment specification.  The only likely impact POSIX will
have for my applications will be the few small changes to the SVID
that AT&T has committed to in order to accommodate POSIX, and the
addition of a handful of new routines such as sigaction().

Vendors who supply just POSIX, or just POSIX plus non-SVID compatible
vendor-specific extensions, will find me not recommending their
systems for local acquisition.  I cannot afford the added application
software development overhead.

The above is, as always, not necessarily an official DOD position.