nazgul@apollo.uucp (Kee Hinckley) (06/09/87)
---
I've been watching the Aegis/Unix debate with some interest, and figured
that I might as well toss my 2 cents in. I should note however that these
are MY 2 cents and should NOT be taken as representing the views of Apollo.
o Where did Aegis come from?
As someone mentioned, many of the tools came from the Software Tools
Library. When I started about 4 years ago I had the job of enhancing
the Aegis Shell (that's right, I'm responsible for the mess, I apologize).
I took one look at the Ratfor and started over again from scratch in C.
o Why not /dev/kmem?
Apollo's philosophy has always been to use procedural interfaces rather
than data structures. The underlying hardware in different Apollo
machines can very greatly. I'm sitting here in my office at a DN3000
with a 68020, next to it is my old DN400 that crawls along using two
68000s, since if you couldn't implement VM with just one. Yet I can
run the same programs on both machines, even if those programs are doing
graphics, or examining processes. Much of this hardware independence
comes from the procedural abstraction - you don't have to recompile or
relink, because the global libraries are different on the two machines,
and they are dynamically loaded. The complaint was made however, that
in some cases we don't even ship the *procedural* interfaces. This
stems from the knowledge that once we ship something, we can't change it.
Some companies don't have this restriction, but we fight VERY hard to
maintain compatibility - sometimes perhaps too hard. Those of you who
have used the Aegis shell probably know about the 'eon' command to allow
variable evaluation. That was added at the last minute simply because
someone's scripts broke because they were constructing pascal source
in a shell script, and the file contained pascal pointers (e.g. ^foo)
which the shell mistook for variables. In retrospect, with all the
complaints I got ("Variables don't work!", "Did you use eon?", "What?")
I wish I had just gone ahead and broken things, but...
o Is NCS vaporware?
If NCS is vaporware I've been spending a lot of time imagining a whole
bunch of multi-user battlezone games.
o Is it real Unix?
As Jim Rees pointed out, most of our utilities differ from System V/
BSD4.2 less than they differ from each other. I've occasionally had
cause to dive into the libraries, and my impression is that most of
them are fairly clean as well. There have been comments to the effect
that our Unix system calls aren't in the kernel, but are just layered.
I'm not entirely sure just what and where this is considered to be a
problem, but for the most part these calls are no more "layered" than
any of the standard Aegis calls we support. My impression is that Aegis
tends to do more things at the library/user level than Unix systems do.
(I say "my impression" because I'm really not that familiar with the
underlying implementation of either Aegis or "Unix-box" kernels - I do
most all of my programming at the library interface level.)
Another important consideration is the question "When is it real Unix?".
Was AUX real Unix? Absolutely not. Is SR9.2 real Unix? Is 9.5? How
about SR10? I've been porting programs off the net since I started at
Apollo. In the beginning there were very few large programs that I could
compile and run without modification, some couldn't be run at all.
At SR9.[56] I regularly bring large programs off and compile them with
little or no problems. (The "little" is mainly due to programmers who
seem to think that automatic variables will always be set to NULL, and
Apollo is not the only system on which those will fail.) Are there
still problems? Of course. Some of you have pointed some of them out -
mapping ACLs to Unix protections, doing terminal-like things in a pad,
the interaction/lack-of-integration between the VT100 emulator and the
rest of the system, obscure DM keydef hacks, bad interactions between
/etc/passwd and the registry, case insensitivity.... But a large number
of these problems are due to interactions between the limitations of
Unix and our not integrating our changes into Unix from the start.
So we have to integrate after the fact, and that's a slow process.
A few additional notes. This discussion has proved to be an good microcosm of
the debates that have gone on within Apollo. For every person who claims that
"it isn't Unix", there is another saying "thank God!". And yet of course the
market pressure is there. The goal of course is to try and please both sets
of people, by providing Unix and more. Obviously it isn't that easy, even at
the seemingly simple level of command line options. Several "pro-aegis" people
mentioned how they liked the consistency of Aegis command line options. Several
"pro-unix" people mentioned how they disliked having to go off to /com in order
to do system administration or other "unix-plus" things. To address the latter
complaint it seems like we should make a set of unix-like commands (or command
extensions) to deal with things. Fine. But what kind of options should they
take? Part of the consistency praised by Aegis users is due to multi-character
options, but multi-character options violate SVID specs and are not "unix-like".
So the battle goes on.
So, for those of you who may think that we don't care about Unix or your Unix
problems. I can assure you that a *large* number of people at Apollo use Unix
to the exclusion of Aegis wherever possible, and we experience exactly the same
problems and advantages that you do. For those of you who are afraid that we
are diving into becoming just another unix-box, I can assure you that we have
no desire to take any steps backward in areas where Aegis is clearly superior.
And for both groups of people. If you have complaints, bugs, suggestions...
Send in ucrs! It doesn't help anyone if you simply sit in front of your node
and quietly fume.
Again the disclaimers. These are my opinions alone, and should not be taken
as expressing the opinions or intentions of Apollo Computer Inc..
Kee Hinckley
User Environment
--
UUCP: {mit-erl,yale,uw-beaver}!apollo!nazgul ARPA: apollo!nazgul@eddie.mit.edu
I'm not sure which upsets me more; that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.