Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!apollo.UUCP!rees
From: rees@apollo.UUCP (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Is an Apollo a UNIX box?
Message-ID: <8705271752.AA06674@apollo.UUCP>
Date: Wed, 27-May-87 22:42:30 EDT
Article-I.D.: apollo.8705271752.AA06674
Posted: Wed May 27 22:42:30 1987
Date-Received: Sat, 30-May-87 02:26:46 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 87


    Apollo currently is NOT a UNIX box.  It runs an operating system called
    AEGIS, and provides libraries to simulate SV and BSD system calls, plus a
    lot of hacked up versions of standard programs which attempt to give the
    APPEARANCE of a unix system.

I decided to try to verify this claim, and took a look at the source code
to some of our unix commands.  I just looked at the Berkeley commands, because
that's what I use.  Didn't check out the system V commands.

Just going alphabetically through /usr/src/bin, here's what I found.

Apparently unchanged from the Berkeley source tape, or with bug fixes having
nothing to do with Domain/IX:

    awk, cat, chgrp, chmod, cmp, date, dd, diff,
    du, echo, ed, expr, false, grep, hostid, hostname, kill, ln, mail, make,
    mkdir, nice, od, pagesize, pr, pwd, rm, rmail, rmdir, sed, strip, stty, tee,
    test, time, true.

'ar', 'cc', 'ld', 'nm', and 'size' are different because we don't use a.out.
Neither does sys V, so I don't think you can claim we're deficient here.

'cp', 'mv', and 'tar' have some modifications to make them work better with
our typed file system.  If you only ever used unix commands on our system,
you would only ever have ascii typed files, and you could get by with the
regular unix versions of these commands.  We felt it was important that
unix users be able to co-exist with aegis users on the same ring, so that's
why they've been modified.  The user interface to these commands looks
just like 4.2 bsd as far as I can tell.

'df' has been changed to use an abstract interface to the file system
instead of opening the raw device and reading the superblock.  I guess we
could have fixed it to understand our superblock, which is different from
the bsd4.2 superblock, but it seemed better to put in the abstraction.
Similarly, 'ps' uses well-defined interfaces rather than muck about in
/dev/kmem.  This seems like a better implementation to me, and the user
interface (which is what's important here, I think) looks a lot like
unix to me.

'write' has been fixed to work with windows rather than dumb terminals.

'csh' and 'sh' have quite a few hacks in them.  These are hard to
characterize.  Some of it has to do with better error reporting.  For
example, if I run some program on my Sun (oops) that calls foo(), but
foo() isn't defined, it says " (core dumped)".  But if I run that same
program on my Apollo, it says
"reference to undefined global (process manager/loader)".  I guess this
is a matter of taste, but I prefer the Apollo way.

'login' and 'passwd' are pretty hacked up.  This has to do with our
distributed registry, which I think is better than /etc/passwd.  I
hear that part of the sr10 work is to make this more unix-like without
losing the benefits of a distributed registry.

'mt' is completely different because we never implemented the tape ioctls.
Guilty as charged on this one.  We tried to set priorities and I guess
this one lost.  On the other hand, the user interface to the command seems
to be just like 4.2 bsd.

To be fair, you would have to also check out /usr/src/usr.bin and ucb.
My guess is that you would find even fewer changes in these commands,
because they tend to muck with things like /dev/mem less then the /bin
commands do.  The only thing I could find different in a quick spot check
was ranlib, again because of the difference in a.out/archive formats.

I can just about guarantee that a diff between the Berkeley source tape
and our bsd 4.2 sources would be smaller than a diff between the Berkeley
source tape and the sys V source tape.  In other words, we're more nearly
'real' unix than AT&T is.  Assuming you're from the Berkeley school.
If you're from the AT&T school, just s/Berkeley/Sys V/.  We're more nearly
'real' unix than Berkeley is.

Anyway, I don't think I would want to work for a 'pure' unix box company.
It's obsolete technology.  What Apollo is trying to do, and I think it's
a pretty good strategy, is provide enough unix to make you feel at home,
and enough state-of-the-art computer science muck (object-oriented,
uid-addressed, distributed file system, etc.) to entice the folks who
like to live on the leading (ragged?) edge.  It's sometimes hard to know
where to draw the line.

Note that this is all my opinion.  I don't work for the OS group here at
Apollo, have little to do with Domain/IX (any more), and can't tell you
with any authority what's in sr10.

Sorry this got so long.  I'll shut up now.
-------