cpr%Shasta@.ARPA (05/02/85)
From: imagen!cpr@Shasta
It is high time someone spoke out on this august forum on the topic of
Apollo workstations. At Imagen, we have a few dozen diskless DN300's
(a basic black and white workstation with 1.5MB--don't buy them with
anything less), and one DFS-500 (a 1MB RAM, 500 MB high-speed disk file
server) for each 5 DN300's. We decided in their favor for two
fundamental reasons: they have a true single-level file store--that is,
any file on the entire ring is accessible to any machine, modulo
protection--and they promised to have what appeared to be an excellent
set of integrated software maintenance tools (DSEE, for Domain Software
Engineering Environment). (I can't usefully comment on DSEE, since we
are just starting to use it, but I will summarize our experience in a
few months.) We use these workstations mostly for software
development, and are also just starting to use Mentor Graphics software
for hardware development.
First the bad news. We had a rummy experience with cabling--if you
don't use the Belden cable they so lightly recommend, their network
will not work. Period. For some reason, Belden makes much better
cable than any of their competitors, and the Apollos need this quality
to work. We made the mistake, since our Belden cable was 6 months
back-ordered, of using some other "equivalent" cable, and ended up
replacing all 8,000 feet of it. Apollo's only fault here is not
absolutely requiring its use. Further, you really have to know how to
make those BNC connectors, or, again, the network will not work. (I
guess the same can be said of making N-type connectors on Ethernet, but
if you use the stinger taps, you can usually avoid problems.)
As far as hardware reliability goes, the Apollos are quite good,
EXCEPT, from our experience, for their ring interface boards.
Unfortunately, this is their Achilles heel, since if a ring board goes
bonkers, it will just as likely take out the entire ring as not (unlike
the passive networks). And, when you're entirely diskless, even if
your ring board goes bad in a way which doesn't bring down the net, you
are personally down. (Same as your Ethernet card going south in a
diskless Sun, of course.)
On the whole, however, now that we have the proper cable installed, and
Apollo has been able to track down the marginal transceivers and ring
boards, network reliability has been good.
The DFS-500 file servers have been rock solid. I believe we've had one
failure amoung all 8 servers since they were installed about 6 months
ago. This is with a machine room air conditioning system that is most
politically described as recalcitrant. I'm impressed.
Apollo is a truly professional company, and it shows in their field
service: they have competent people, and they are quite responsive.
(This is their Mountain View office supporting us.) One reason we
didn't buy Suns was because they didn't have a field maintenance
organization at that point (and didn't for quite a while after, if they
do now--I haven't kept up). I also have to put in a good word for our
sales rep (Ed McGinnis), who is really one of the better people in this
business.
One picky point about mice: I happen to like the Kirsch, er, Mouse
Systems, mice above all others (the one that Sun uses). Apollo uses
the clumsiest of the Logitech mice, and if I were given the chance to
order over again, I would buy the keyboards without a mouse (I think
you can do that), and use the Mouse Systems Logitech-emulation
plug-compatible optical mouse.
Now on to Software. I couldn't stomach the thought of managing 50
different file systems, even with the public file system hack that Sun
has. Apollo's single-level file system is truly wonderful, both in
concept and in implementation. Any file is completely accessible to
any process on the ring, a Multics-like sophisticated protection scheme
permitting. I can't see how anything less would ever be acceptable.
I'm not impressed with the Sun NFS proposal as an operational tool,
since it would still have "private virtual disks" for efficiency's sake
(someone correct me if I'm wrong).
The arbitrarily-precise protection scheme that Apollo gives you for
file system objects--you can allow or disallow a variety of access
modes to any given object from any given
user/project/organization/node, in any combination, wildcards
included--is important for some environments, especially if you have
randoms from all over a company on the network.
The Apollo Display Manager is truly useful, and makes the Sun default
"virtual dumb tty" windows looks anemic by comparison. The Display
Manager provides the concept of arbitrarily scrollable windows on
transcript pads containing both text and graphics. The ability to
scroll back in any process transcript arbitrarily far, and to scroll
right and left when the line length or graphics output exceeds the
window width is amazingly useful, and is something I wouldn't give up
now that I've used it. The Display Manager also has a soft interface
that is user-customizable, and I've used that customizability to its
fullest extent, by providing our users with a set of key definitions
that provides a simple Emacs emulation. We still run Gosling Emacs in
a window, of course, when we need the "real thing", but having an
Emacs-like interface to ALL system interaction is addictive.
The Apollo Display Manager provides a very powerful set of graphics
primitives, both in pad and direct screen access modes. The direct
screen access within a window means, for example, that software
packages like Interleaf can easily work within a window, when they
can't on the Sun because the Sun lowest-level access (pixrect?) is too
inefficient. The same is true of our Gosling (Unipress) Emacs port--it
works in direct screen mode for speed, but within an ordinary window
which can be resized, moved, etc., at any time. My feeling about the
Sun window system, based soley on reading the manual and watching the
Sun-Spots digest, is that it more of a mechanism for OEMs and others
wanting to write their own window systems, than a user-level window
system.
The Display Manager supports user-definable icons, representing windows
or groups of windows. It has the basic set of screen fonts available
per-window, so you can customize a given window for readability or
capacity.
The Apollo has a Multics-like dynamic binding scheme whereby libraries
aren't normally linked with an image until it is executed. This has
all the good effects you'd expect (see the Organick book on Multics for
details), such as avoiding duplication of many libraries in all images,
both on disk and in memory. It also means that executable images don't
become obsolete with system updates--as long as the library interfaces
are upwards compatible (something that Apollo guarantees for a
transition from version n to n+1, and which normally is true for many
version changes), then you don't have to relink anything.
The Apollo operating system, Aegis, provides a user-accessible
extensible streams package. This means, for example, that the DSEE
package, which stores differences between n versions of a source file
as an n-way branch inside the file itself, can present a ordinary
stream file to the outside world at high efficiency. It also means
that adding access to foreign file systems can be done at user level
with a new stream type.
Another feature of Aegis is user-level dynamically-loaded device
drivers--you can build your own Multibus device driver and install it
at any time, without rebuilding anything.
The fundamental, low-level Apollo file system access primitive is
mapping file pages, which leads to great efficiencies. For example,
the stdio package in Unix maps files directly, avoiding the multiple
copies that occur in every Unix implementation I've ever seen.
One of Apollo's goals for Aegis was to keep the kernel itself VERY
small and simple. They seem to have achieved that, with user-level
libraries doing most of what you would normally associate with an
"operating system:" display, stream, network, etc., management. This is
great for keeping the fundamental kernel small and maintainable, but
it does open up one problem area: some libraries' global data are
present and unprotected in every processes' address space. Thus, an
errant process can clobber other processes' stream or display manager
data bases, which of course doesn't formally "crash" the workstation, as
the kernel is incorrupt, but it does make it unusable! This could be
fixed, I suppose, if they would add one more domain of protection to
their system so that the libraries could run at a higher right than user
mode.
They have an excellent TCP/IP implementation, running as a user process
either on each node or on a gateway node, using IP gateways running on
any node that has a Multibus and an Ethernet interface. We have been
heavily using a beta test version of their 4.2 TCP/IP socket support
for a couple of months now with no problems. From a disked node to an
unloaded 750, they get almost 500Kbits/second. From my diskless DN300,
I have consistently seen 250Kbits/second to an unloaded 750. Not bad
for a user-level implementation!
We are just about to start beta-testing their 4.2 implementation. From
my playing with it, it looks excellent (as does their System V
implementation--they use a Ridge-like scheme of selecting the version
of Unix to emulate based on an environment variable). They no longer
consider their 4.2 and System V Unix environments as an add-on,
though--market pressures have made them realize that they'd better have
real Unix to a "t" or they won't survive in some segments of the
market. I know they made substantial changes to Aegis to support their
new Unix products (called Domain/IX). I'll report back after a few
months of experience.
I might also recommend the Interleaf software here, which we use on the
Apollos--it's probably the world's best WYSIWYG text and graphics
editor to date. It's a little pricey--about $3K per node, after the
first node, which is $8K. (Disclaimer: Interleaf resells Imagen
printers as part of their bundled systems, so I'm not a totally
disinterested party.)
I don't have any experience with their color systems (DN550 and DN660),
but I have played with them a little, and they both exhibit impressive
display speed.
Of course, I have a lot of nit-picky complaints about the Apollos, but
that's inevitable when you use a system daily. I do wish they would
get over their religious committment to ring networks, and support an
Ethernet network interface--there's apparently no technical reason they
couldn't, other than internal adherence to the ring religion, and lack
of market pressure. For smaller sites such as ours (we'll never have
more than ~100 nodes, I hope), I have strong reasons to believe the
performance using Ethernet would match their current ring net, and
since we already have Ethernet everywhere, it would have been nice not
to have to also cable the world for the ringnet.
Oh, of course--I forgot the most important feature of the Apollo system
(tongue fairly firmly inserted in cheek): they have, for my tastes, the
most wonderful keyboards in the world. The Sun-1 keyboards were
unspeakably bad, and the Sun-2 keyboards are very much like the Apollo
keyboard (Microswitch, I believe), but they have an amazingly
brain-damaged mechanical keyclick. The one thing wrong with the Apollo
keyboard is that only some of the keys are up/down encoded, so there is
no obvious left-hand "meta" key, something near and dear to the heart
of an ex-ITS Emacs freak.
--Chris Ryland
{decwrl,shasta,ucbvax}!imagen!cpr