🚀 go-pugleaf

In article <VIXIE.89Jan14123901@bacchus.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes:
>
>Well, waitaminute.  There is no ABI for MIPSCO as yet; binaries from an Ardent
>are not going to run on a MIPSCO M1000.  Heck, binaries from a SysV MIPSCO box
>don't run on a UMIPS 4.3 MIPSCO box.
>
>So while this point is valid for binary data files, if by "binaries" you mean
>binary code files, either a.out or *.o, then this point is etherial since there
>is nothing to be binary-compatible WITH.

There is no excuse for this.  Vendors of large application programs (like the
Oracle RDBMS) are getting very tired of vendors of hardware who can't get their
act together to standardize on ABI's.  We have had to expand our computer room
3 times in the last 3 years to fit in all the machines from various vendors
running different flavors of the UNIX operating system.  Because UNIX vendors
have not standardized the operating system call interfaces for each hardware
type, Oracle's UNIX development staff now has more people than any other
development department.  We have dozens of people who do nothing but take
many megabytes of source code, compile it on yet another UNIX box and spend
weeks figuring out what that manufacturer did not manage to get right in his
port of UNIX.

Sequent and Pyramid have demonstrated that you *can* provide a single
environment which supports both BSD and SV system calls.  The 88000
group is wisely starting out up front by standardizing on an ABI.
The reason UNIX has taken so long to succeed in the market place
is because there was no application software.  The reason that there
was no application software is because application vendors cannot
afford the machines, development time, support staff, etc. to support
14 different flavors of UNIX for each hardware platform out there.
(Quick test: how many vendors are there of UNIX 68000 boxes?)

MIPS & DEC are shooting themselves in the foot by not providing a standard
ABI's for the large software vendors.  We will not port software for a
machine unless it is clear that there is sufficient demand out there to
justify our investment.  By subdividing the MIPSCO marketplace MIPS & DEC
are that much less likely to be able to generate sufficient sales for vendors
to justify supporting those os/hardware combinations.  And of course the lack
of application vendor support on those platforms increases the probability that
customers will chose to go with other machines (like 88000 based boxes) where
there is a standard ABI and software vendors know months or years in advance
that they will be able to justify porting their software to that environment.

>As Mike Khaw pointed out, Ultrix is no more or less proprietary than SunOS or
>UMIPS.

As a software vendor we do not care what flavor of UNIX you are running
(provided you support the System V IPC primitives).  We do not care
what you call your version of UNIX nor what fancy extras you add to
make your box unique (csh, more, NFS, RFS, X windows, etc.). where
we start to get really frustrated is when you release different versions
of UNIX for the *SAME BOX* which cannot run the same binary programs.
(Are you listening DEC?  MIPSCO?)

>Ultrix is not that much of a change, really.  It's enough like SysV that most
>SVID code compiles, and it's enough like BSD that most BSD code compiles.  And
>it's enough like SunOS that most SunOS users would feel quite at home.  Note
>that I don't particularly _like_ Ultrix (or SunOS), I'm a BSD purist.  But as
>of 3.0, Ultrix is enough like BSD that I no longer pine and whine for 4.3.

That's funny last time I looked at our code there were a fair number of #ifdef's
to work around bugs and/or idiosyncrasies for Ultrix, BSD and the SunOS.
(You aren't there yet folks.  Ask the software vendors if you want to know
for sure! :-)).


>(I'm in research, not product; I get to say things like "I don't like Ultrix"
>and they don't fire me.  Neat, huh?)
>
Yes, research people would like BSD 4.3.  A great environment for research,
but not one that can support a high performance RDBMS due to its lack of
robust IPC primitives.  I'll take a real O.S. that conforms to the SVID
any day of the week.

>What you said.  The above (non-quoted) opinions are clearly mine; I have no
>idea what I'd say if I were speaking officially for DEC.  If anyone quotes
>any of the above, please include this paragraph.
>--
>Paul Vixie
>Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
>Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

I'm not in management at Oracle, but I suspect my opinions are close to
management's given the amount of money we have to spend to support products
for vendors who can't get it organized to standardize binary interfaces.

Robert Bradbury
Oracle Corporation
(206) 782-9474                            hplabs!oracle!rbradbur