🚀 go-pugleaf

I recently posted this message to Sun-Spots (the Sun mailing list),
and I thought people on this list might be interested.  Note that it
is definitely biased towards people who are deciding between Apollo
and Sun as Unix-based workstations - there is almost nothing here
about the merits of Aegis in its own right.  Nor does this take
many shots at the Sun - it's more intended for people who understand
the 4.2 environment already and want to know whether to buy one or
the other workstation.

(Before I get flamed too badly, it has been described by one of my
co-workers as "remarkably even-handed" :-)

----------

I used Suns at Rice for several years, since the original Sun-1 and Unisoft
V7 Unix.  (In fact, I used to moderate this list.)  I've been using Apollos
for about 6 months here at Bellcore.  These are a few comments about the
merits and problems of the Apollo relative to the Sun.  (Note that my Sun
experience goes up to Sun 1.3, not 2.0, and my Apollo experience goes to
SR9.)

First, I have to confess that even on the Apollos, we use Unix exclusively.
(For those who don't know, the Apollo runs a kernel operating system called
Aegis.  Libraries and server processes sit on top of that kernel.  The
"Domain/IX" product is a Unix emulator for both 4.2 and System V,
simultaneously if you like, and provides most of the Unix system utilities,
libraries, and system calls.)

We use Unix mostly for reasons of portability and familiarity.  Regardless
of the merits of the native Apollo operating system, there's no way a
program written with it will run on another machine, while with Unix,
there's at least a fighting chance of writing portable code.

APOLLO MINUSES:

Because the native operating system is not Unix, there are an entirely new
set of system management problems.  You have to learn a whole new set of
commands, remember where different configuration files are, and so forth, to
be an effective system manager.  This took me about a month or so.  The
problem was greatly complicated because most of the Aegis commands have
almost exact Unix equivalents, but the names have been changed.  For
example, "list directory" is "ld", not "ls".  "Move file" is "mvf", not
"mv".  It's an annoyance.  Once Domain/IX is in place, these problems
almost, but not quite, go away.

All of 4.2 BSD is not supported.  For example, the syscall interface to the
kernel is missing, as is the SIGIO signal.  The 4.2 print spooler (lpr, lpd)
and the Unix graph(1) command are not present.  I'm sure there are other
things that I haven't missed yet.  I am not too familiar with System V and
we aren't using it, so I don't know what's missing there.

Because the C compiler is a native Apollo compiler and not the Portable C
compiler, there are subtle C language incompatibilities.  Also, there is no
assembler in the standard distribution, the compiler produces error messages
in a different format, and the code quality is different between Apollo C
and PCC.  (It's not clear which is better.  Under SR8, Apollo C was clearly
inferior to PCC, but the situation has improved under SR9.)

Apollo uses a TCP/IP derived from the old BBN sys.10 process-based TCP,
which means there are a different set of management commands from the ones a
4.2 user would be used to (ie, different host tables, no netstat, route,
arp).  Most of the same functionality is present, it's just different.  (The
network libraries, sockets and so forth, are identical to 4.2 BSD's.)

The object and executable formats are unlike Unix's, so programs that dump
memory state don't work.  In addition, the symbols etext, edata, and end are
not provided.

To make a sweeping comparison, the Apollo (with a 68010) is slower than the
equivalent Sun.  Using the Dhrystone benchmark, an Apollo DN320 with an FPA
comes in at 793, while a Sun 2/120 without FPA runs at between 1100 and
1200.  I don't know the relative clock speeds of the two machines, or the
memory wait-state situation on the Apollo, or whether the 68020 versions
will be different.

In addition, an Apollo with 3 meg, diskless, "feels" slower than a diskless
Sun (running ND, not NFS) with 2 meg.  One should take into account that
this includes the (presumably) extra overhead of running Domain/IX programs
as opposed to native Aegis commands, which we don't use much.  Some
commands, particularly those that deal with directory reading or writing
(like "find") are painfully slow.

The standard Unix debuggers (adb, dbx) are not supported on the Apollo.  The
standard editor is nicer in some ways, worse in most, to the Sun dbxtool.
It's certainly different - another training problem.

The Apollo's performance is not "predictable" to me.  There are sometimes
long pauses for no good reason.  This may well be an artifact of my
unfamiliarity with the internals of Aegis, and strange interactions with the
Apollo virtual memory and single level store.

The Apollo documentation for Domain/IX is almost a straight printout of the
Berkeley VAX documentation.  Usually the differences and limitations of
Domain/IX are not mentioned.  As documentation for someone unfamiliar with
Unix, it suffers from the typical Unix problem - you have to know a lot
about Unix already before the documentation makes sense.  Apollo should make
an effort to try to expand on the conventional documentation.  They have a
short guide for new users, but nothing really for systems programming.  (Sun
has more or less the same problem, but since they've had Unix longer, their
documentation is somewhat further along.  It still suffers from emphasis on
novice users, though.  I don't know if the 2.0 documentation is better.)

I like the Sun keyboard and optical mouse much better than the Apollo
keyboard and mechanical ball mouse.  The Sun window interface has somewhat
better mechanics; Apollo window placement, cursor treatment, and general
user interface have some problems.

APOLLO PLUSES:

Aegis is a much "cleaner" operating system than Unix in a number of ways.
For example, the single level store allows very nice shared libraries to be
implemented.  Rather than including the object code for all of the C library
with every program, as Unix does, Aegis does dynamic binding at run time.
The executables are much smaller, and the system can be changed without
rebinding anything.  I have executables from 4 major releases of Aegis ago
that still run with no changes.  One could claim that from a design
standpoint, Aegis is more consistent than Unix.  It has more support for
record-oriented files, which might be important for some applications, like
databases.  (You can't use this and remain Unix-compatible).

Apollo has had transparent access to files for much longer than Sun has.
Therefore, the performance seems to be much better (I have only limited
experience with NFS, but long waits for file opens don't occur on the
Apollo.)  The performance of Sun ND seems superior to Apollo's distributed
access, but remember that ND didn't allow read/write file sharing among
machines.

In order to run a single ring of machines, much less system administration
per processor is needed on the Apollos.  It is almost as simple as plugging
a new machine into the ring, turning it on, and using it.  The Sun requires
a much more complicated procedure to configure a new machine.  A diskless
Sun has to be administered like a separate machine, while a diskless Apollo
doesn't have any separate administration problems.

The Apollo user interface has some nice features that the Sun lacks, like
scrollable back histories, and command resubmission and editing.  There is a
simple (almost too simple) pervasive editor that is always available on the
Apollo to do input editing.  The Sun is much more oriented towards multiple
ASCII terminal windows.

The Apollo graphics package is considerably easier to use than the Sun
package, although of course neither is the least bit portable to other kinds
of machines or each other.

The Apollo error messages, both from system routines and the compilers, are
much better than the standard Unix messages found on the Sun.

We experienced a large number of CRT failures at Rice, and other groups at
Bellcore continue to lose Sun CRTs commonly.  We have never had an Apollo
CRT go out on us (in two years with four to seven nodes).  In general
hardware reliability seems higher on the Apollo.

Apollo seems to have a much higher commitment to software compatibility and
support across releases and different Apollo hardware than Sun does.  With
Sun, we went through a large number of completely incompatible software
upgrades (Unisoft to Sun 0.1 to 0.3 to 1.0 to 2.0) across which most
graphics software broke completely.  Apollo guarantees compatibility from
release N to release N+1, and in practice, across many more release levels.

The documentation for Aegis has a rich set of examples in several languages
for how to use most of the system interface.

As a company, Apollo has exhibited somewhat different tactics than Sun.  In
the early days, Sun made a lot of promises and then failed to deliver.
Apollo delivered a product with full function but bad performance, then
concentrated on making it fast.  Now that Sun can deliver, the difference is
less pronounced - but I still remember a year of not being able to do much
with Suns because the graphics and network software wasn't there yet.

THE BOTTOM LINE

We are getting our work done with the Apollo, working around the problems
caused by lack of full Unix support.  In general we're happy, but we're also
scared that the CS research community is moving to Suns exclusively.  It
seems clear that Sun's commitment to full native Unix is stronger than
Apollo's.  We have already had some problems porting programs from Sun or
VAX to Apollo.  While this can be chalked up in large part to sleazy
programming practices, that doesn't make the problem any more manageable.

In brief:  For applications involving exclusive use of Unix, and contact
with the general research community, the clear choice for now seems to be
Sun.  If you don't have the constraints of Unix and Unix portability, you
should give Apollo a look.

	Mike Caplinger
	mike@bellcore.arpa
	ihnp4!bambi!mike

ps.  I'm still looking for the perfect workstation.  It's beginning to look
as though I'll have to build it. :-)