Unix optimized for SPARC?

Robert C. White Jr. rwhite at nusdhub.UUCP
Sat Jul 2 09:36:56 AEST 1988


in article <2482 at winchester.mips.COM>, mash at mips.COM (John Mashey) says:
> 
> In article <253 at iconsys.UUCP> ron at iconsys.UUCP (Ron Holt) writes:
>>
>>Recently, there has been fear expressed that evil AT&T and Sun will
>>some how optimize future versions of Unix for SPARC.
> 
> From outside, there are two issues:
> a) The marketing one: some of the Sun sales/marketing materials we've
> seen have explicitly said "standard UNIX would be optimized for SPARC",

As I understood iti, durring the University UNIX Users Group ("U3G")
meetings a couple months back, the following was going to happen:

SVR3.2, the Unix/Xenix merge, would be released and then an ABI would
	be set for the 386 family.

SVR4, the Unix/Xenix/Sun merge, would be released with an ABI set
	for SPARC and the 386 family.

SVR5, a re-write of SVR4 entirely in C++

SVR4 may be the C++ version, I don't remember for shure, but Cassoni
explained it thus:

AT&T has a vested intrest in keeping the "basis" for all UNIX System
products as universally useable as possible.  The aledged universality
of UNIX being the only thing that makes it different from "all those
other operating systems" (refering to VMS, DISOS, and a few others by
name.)   Aparently the truley optomiseable <real word?< portions would
be seperated from the main text in a much more tangable way, useing
modules and assemblies.  AT&T's current marketing stratagey (provided
with many glossy color brochures) involves maintaining a very-available
source code base, "as many exclusive ABI's as possible" <my paraphrase.<
by which it was menat that where processor arcitecture differed
greatly, and agreements could be reached I assume, an ABI would bes set;
the guiding rule being, _NO OVERLAP_ in arcitectures/ABIs.

Centroid to this was that sources (including the available assemblies)
would be "at least as easy to obtain as is currently the practice" <as
close as I can come to an exact quote.<

Whe asked "why?" Cassoni explained that the real purpose of the 
merging of products was twofold:
	1) people were demanding (common) BSD features like jobcontrol,
		better signal handeling, and (uncommon) aditional
		features like "real time" functioning (whatever you
		take that to mean.)
	2) The secucess of the small computer industry was largely
		due to the availability of "off the shelf" "shrink
		wrapped" products.

Number two seems to be the big issue.  AT&T wants to sell product, that
should be obvious.  If they can manufacture a compleetly uniform
product that _everybody_ wants and uses regularly they win twice.
One, they can open a competitive market of applications software
which needs only to be re-compiled every time someone invents/produces
a new computer. And Two, if they can make _everybody_ want their
product ( c.f. UNIX ) then they can sell it to everybody.

By opening up the standard compleetly, listening to every word spoken
by the standards commities, and setting a fair/just/honorable/uniform
ABI for every arcitecture they possibly can, they encourage everybody
to buy thir product.

Because of their licence agreements issued to date (esp version 2
licences) they can't come out and _make_ everybody buy some new and
hardware spesific monster, their only choice it to try and make
_everybody_ want the new and improved versions.  By being nice to
everybody, and catering to every possible public whim, AT&T could
win very big.

This is all common sense, but nobody has tried this aproach before,
so everyone is suspicous.  Just think, if you held a always and
forever patent on the internal combustion engine (from day one),
and you put a licencing and usage fee of $1 each, payable after
construction with no further usage fees or anything, you would
be rich and nobody would have really minded at all (if it had
started out that way.)  This is what AT&T seems to be trying to do.

Disclaimer:  These are opinions based on presentations made by AT&T,
	nothing more and nothing less.

Rob White
National University.



More information about the Comp.unix.wizards mailing list