Splinter Unix?

[Roger B.A. Klorese]

Let me preface this with the mandatory disclaimer: this *definitely* does
not reflect the views of MIPS Computer Systems, Inc.

In article <7922 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <556 at n8emr.UUCP> lwv at n8emr.UUCP (Larry W. Virden) writes:
>>What do you folks think of this "grand" idea of the creation of a third 
>>standard?
>It should be obvious what their real motives are.  It must grate to
>have to pay AT&T royalties.

I don't think this has *anything* to do with their real motives.  If this
were the case, this would have kicked off long ago.

>Notice that all the vendors in this ploy are ones who were pushing
>their own proprietary operating systems and were reluctantly forced
>to have a UNIX-based offering because customers demanded it.  Old
>mindsets sure die hard.

All of the *American* vendors in this movement *so far* are ones who
were pushing their own proprietary operating systems.  There are no
computer systems vendors of long standing *at all* who have been on
a UNIX platform for any significant length of time (i.e., close to
10 years).  AT&T was not a systems vendor, and Sun is an upstart as
well, albeit a very successful one.

Why is it if you're DEC, when you merge features of System V and BSD
and add some of your own, you're evil violators of a standard, but if
you're Sun and do exactly the same thing, you're the masters of an
emerging standard?  This Joy-o-centric view of the universe is a
travesty.

>We sure don't need a DIFFERENT system interface.  A true UNIX clone
>would be okay (although it would lag in picking up new developments),
>except I doubt they will produce one.

What *is* a UNIX clone?  Something that will keep in sync with
whatever geegaw AT&T and Sun dream up *this* year?  Why should they be
allowed a position of control?  If a portable operating system is to
be a standard, it must be *built* by a body committed to a standard,
not by a profit-making entity whose motives are suspect.  When AT&T was
essentially a research body in the world of operating systems, this
role was appropriate for it.  Now that it is a competitor, it is
unacceptable.

And as for the subject of the lag:  this may be trivial off in hacker-land,
where people will incorporate code from alpha releases into their local
versions, then re-fit, then re-fit, ad nauseum.  In the real world of
operating system porting, it is inappropriate to ship a port until the
released version of the base product.  If we receive a frozen Sun/AT&T
operating system in July, it may take a vendor anywhere from six to eighteen 
months to ship its version, due to product management cycles, QA, etc.
This "lag" which you trivialize would give a definite sales advantage
not to *all* vendors of a "standard" UNIX, but to Sun and AT&T alone.

An illustration of this is NETdisk, or Diskless NFS, or whatever Sun's
calling it these days.  Many of us have been showing code based on a
pre-release of SunOS 3.2 for a year and a half now.  Sun has, in my
opinion, (a) procrastinated the release of this product they were
allegedly offering in the name of "non-competition" until they had
a server product based on SPARC which, while still no great shakes, 
would at least stay the defection of the server business to their NFS 
licensees, and (b) changed the product, disk layouts, etc. "on the fly"
without freezing the specification until code ship on the 386i, which
will prevent conscientious vendors from shipping a fully-QA'd product
based on a frozen specification until 6 to 18 months from Sun's FCS.

And as for "lagging in picking up new developments": since my thesis is
that AT&T has no business in the standards game at all, its new developments
are no more important or useful than anyone else's, and should not need to
be "picked up".

>>What impact will this have on the Posix effort?  On development of portable
>>code?
>
>It has no impact at all on 1003.1 or the NBS FIPS, which are quite close
>to being officially approved.  There could be a small effect on other
>1003 subgroups eventually, although 1003.2 is probably far enough along
>to be relatively unperturbed.
>
>The effect on portable code is this:
>
>	The AT&T/Sun and AT&T MicroSoft agreements to merge the only
>	commercially significant UNIX variants into a single system
>	would have made it possible for applications to rely on
>	several important features of the merged system that go well
>	beyond any official (e.g. POSIX) standards, just as the SVID
>	specifies far more than does POSIX at this point.

...And POSIX and its follow-ons are the *only* standards that matter at
all, because they are developed as standards should be.  We cannot have
our competitors ramming their ad hoc "standards" down our throats.

>	It is a rare application that does not need more support from
>	the system environment than is covered by (almost-)existing
>	POSIX standards.  If the AIX system ends up looking entirely
>	unlike AT&T's UNIX system outside the domain specified by
>	POSIX, then portable applications will be forced to deal with
>	logically unnecessary variations among systems, largely
>	defeating the purpose of standards and imposing an economic
>	burden on software development.  (Note that this can also be
>	construed as a complaint about what is actually accomplished
>	by POSIX as it turned out.)
>
>	The emergence of POSIX and in particular the NBS POSIX-based
>	FIPS has handed the lawyer types a tool for challenging any
>	Federal specification for a SVID-compliant system rather
>	than just a minimally FIPS-compliant one.  If RFP writers get
>	the help of someone who really understands the practical
>	effects of the differences between these two system interface
>	specifications, it is possible to accommodate them both and
>	ensure that the actual customer needs are satisfactorily met.
>	Otherwise, there is considerable risk that the silly rules
>	constraining Federal procurement will force acceptance of a
>	system that does not satisfy the needs that prompted the
>	procurement.  (Yes, many of the rules ARE silly.  They appear
>	to have been based on an entirely bogus notion of what
>	competition is all about, as well as misguided attempts to
>	enforce legitimate concerns for impartiality.)

The point is that SVID-compliant programs cannot at the moment *be* 
FIPS-compliant.  This is not a problem with the FIPS, but with SVID.
Pure and simple, System V is a work of prior art which should now be
adjusted to adhere to FIPS, as a superset.
 
>I get pissed off at companies that prefer to resort to marketing and
>legal strategies rather than responding technically.  If they're
>really going to develop an alternative operating system instead of
>adding value to an established standard one, it should be SIGNIFICANTLY
>BETTER than UNIX, not just a small incompatible tweak, or else they're
>wasting everyone's time.

They are *incapable* of adding value to an established standard operating
system, because there is no such thing.  System V is a widely used but
proprietary system whose development and marketing constraints cannot
help but leave other system vendors behind AT&T and Sun chronologically
in the release of versions.  This is wholly inappropriate for a "standard".

The realization that UNIX is a two-headed beast, the world's only
"proprietary" "standard" with people who actually like it that way
(unlike the IBM PC, etc., which many accept but only grudgingly), has
finally reached critical mass.  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.

AT&T could have headed this off long ago, by opening all future development
efforts to a consortium approach, instead of blessing Sun as their saviour
in the marketplace, then trying to convince the world that Sun's having access
to signed-off code a year before the rest of the world will either (a) have
no effect on their business, or (b) be a good thing.

-- 
Roger B.A. Klorese                           MIPS Computer Systems, Inc.
{ames,decwrl,prls,pyramid}!mips!rogerk  25 Burlington Mall Rd, Suite 300
rogerk at mips.COM                                     Burlington, MA 01803
I don't think we're in toto any more, Kansas...          +1 617 270-0613