Giebelhaus@HI-MULTICS.ARPA (05/21/87)
I'm also interested in peoples opinions about whether Apollos are UNIX boxes. My presonal opinion is that they are just about as UNIX as any other vendor except Berkley or Bell depending on which version of UNIX you mean. I know of a number of places where the Apollo is different. Perhapse the amost annoying is the file descriptors (although they are close enough to mostly be an annoyance only). Other vendors have their own problems. Everyone has been into the kernals hacking for windows, networks, and other fun features. The worst problem the Apollo has is marketing. When you think of a UNIX workstation, is the Apollo the first thing that comes to mind? For many people it does not come to mind at all. Why? Has anyone ever put together a list of difference between Apollo's IX and bsd at the interface level? For example, the /dev/kmem does not have what you might expect in it. I would love to see such a list. If people want to send me the incompatibilities they know of, I would be happy to compile such a list.
dennis@PEANUTS.NOSC.MIL (Dennis Cottel) (05/21/87)
Seems to me you're asking for Apollo to provide both Unix enhancements (longer than 8-character ids) and very close compatibility tolerances (same format for /dev/kmem). I'm not a Unix guru, but this sounds tough to do. --Dennis Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 225-2406 dennis@nosc.ARPA sdcsvax!noscvax!dennis
Giebelhaus@HI-MULTICS.ARPA (05/21/87)
I did not mean to say I wanted Apollo to support /dev/kmem. I think it is very bad programming practice to use kmem. Not only that, I think Apollo has advanced beyond the point where they can use kmem. I just want to KNOW what the differences are, not have ALL of them "fixed". I do still think talk is "broke" if it will not work with all the users on the Apollo, though. Yes, I'm greedy. Where I can have compatibility without giving up enhancements, I want it. In some cases, it may be best to give up the enhancements to get the compatibility. I don't mind where IX & Aegis is a superset of UNIX, but I am at least intereasted in the places IX is lacking compatibility to UNIX.
ray3rd@ssc-vax.UUCP (Ray E Saddler III) (05/21/87)
In article <870520222712.854845@HI-MULTICS.ARPA>, Giebelhaus@HI-MULTICS.ARPA writes: > I'm also interested in peoples opinions about whether Apollos are UNIX > boxes. My presonal opinion is that they are just about as UNIX as any > other vendor except Berkley or Bell depending on which version of UNIX > you mean. > > The worst problem the Apollo has is marketing. When you think of a UNIX > workstation, is the Apollo the first thing that comes to mind? For many > people it does not come to mind at all. Why? > I'm not a real heavy Apollo user, but I do not think of it as a UNIX box, rather, an AEGIS box. I have run UNIX on an APOLLO workstation, but it was on a system called MENTOR (a system installed on Apollo h/w to do electronic design/test). It (the UNIX shell) seemed real wierd, and was made to fit/run from AEGIS, which caused a lot of ~standard UNIX files and utilities to be quite out of the norm. That's about all I have, what about the rest of y'all? -- Ray E. Saddler III CAD Support and Administration | __ __ __ __ Boeing Aerospace Company Ballistic Systems Division | / / / // //| // P.O. Box 3999 M.S. 3R-05 Kent Space Center East | /-< / //- // |// _ Seattle, Wa. 98124 U.S.A. - North America - Earth | /__//_//__ // //__/
bobr@zeus.TEK.COM (Robert Reed) (05/21/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. The file system, protection strategies, interprocess support, I/O drivers, administrative support and networking are substantially different from those of any flavor of UNIX. Rumors abound that SR-10 of the Apollo system will be a "true" UNIX, implemented at the kernel level. We wait to see. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
benoni@ssc-vax.UUCP (Charles L Ditzel) (05/22/87)
> In article <870520222712.854845@HI-MULTICS.ARPA>, Giebelhaus@HI-MULTICS.ARPA writes: > I'm also interested in peoples opinions about whether Apollos are UNIX > boxes. My presonal opinion is that they are just about as UNIX as any > other vendor except Berkley or Bell depending on which version of UNIX > you mean. > > The worst problem the Apollo has is marketing. When you think of a UNIX > workstation, is the Apollo the first thing that comes to mind? For many > people it does not come to mind at all. Why? > No Apollo is not a Unix box - *for starters look at the kludges with /etc/passwd... *second - what starts up your Unix shells... *funny within GMR3D & GMR2D your Unix system calls die... *Acl? Why don't they map *correctly* into Unix protections. Fix_cache and flush_cache exist to fix mappings between acls and unix permissions remember. *why do certain Unix ports take literally forever. Go ask alis (sic ... i really meant Alice). *i am sure that i will believe that Apollo is a Unix box when i see the required amount of Apollo ads (telling me 'i am so a Unix box')
peterson@utah-cs.UUCP (John W Peterson) (05/22/87)
I have ported a fair amount of Unix code (50K+ lines of C, shell scripts, makefiles, etc.) to the Apollo, and in general (speaking post SR9.2) I would say it's relativly painless. The major differences usually crop up in programs that want to know lots about /dev/kmem, a.out.h, or the guts of stdio.h. I would say it's much easier to port code to Domain/IX than to try and port it across different versions of Unix (say, from 4.2 BSD to ATT Sys5). Cheers, jp
bandy@amdcad.AMD.COM (Andy Beals) (05/23/87)
In article <1734@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes: >Apollo currently is NOT a UNIX box. Agreed. >Rumors abound >that SR-10 of the Apollo system will be a "true" UNIX, implemented at the >kernel level. We wait to see. Our Apollo salesdroid was out today with his dog and pony show about "Native Ethernet, Unix Update and Network Computer System". The "native ethernet" is a 3-com(?) card that goes into the "at slot". They claim that while it's still a hair slower at getting data between Domain-Ring members, their engineering folks can't really tell the difference between Domain-Over-Ethernet and Domain-on-a-Ring. That's right, they're saying that if they run Domain-Over-Ethernet, it not only runs at the same speed, they encapsulate the Domain packets within IP packets so you can squirt them across gateways - but only T1 links, 56kbps is too slow. They were also claiming that TCP/IP throughput is 63% better with the "native ethernet". He also said that with SR-10, Aegis will exist for backwards compatability reasons and that Unix will be the base of their system. I'll believe that when I see it. The "Network Computing System" seems to be mostly vaporware right now, but they do seem to have some good ideas. Basically they're willing to hand out standard interfaces to subroutines that could be on remote machines. They have servers for deciding what machines to poll for certain subroutines and also a couple other functions. They didn't say anything about compiler improvements. They also made a face when I asked when they were going to start supporting NeWS. andy -- Andrew Scott Beals, {lll-crg,decwrl,allegra}!amdcad!bandy +1 408 749 3683
kjb@zeke.UUCP (Kevin Buchs) (05/24/87)
in article <1242@ssc-vax.UUCP>, ray3rd@ssc-vax.UUCP (Ray E Saddler III) says: > > I have run UNIX on an APOLLO workstation, but it was on a system > called MENTOR (a system installed on Apollo h/w to do electronic > design/test). It (the UNIX shell) seemed real wierd, and was made > to fit/run from AEGIS, which caused a lot of ~standard UNIX files > and utilities to be quite out of the norm. Mentor does not modify the Apollo operating system. The Domain/IX unix variant is ok, but not nearly as fast as other systems I have used. I hope Aegis 10.0 will improve this. -- Kevin Buchs 3500 Zycad Dr. Oakdale, MN 55109 (612)779-5548 Zycad Corp. {rutgers,ihnp4,amdahl,umn-cs}!meccts!zeke!kjb
Erstad@HI-MULTICS.ARPA (05/26/87)
Minor correction. Mentor does not FOR THE MOST PART modify the Apollo operating system. They do use a non-standard /lib/gprlib file which includes routines not normally distributed by Apollo.
mishkin@apollo.UUCP.UUCP (05/27/87)
In-Reply-To: amdcad!bandy@ucbvax.Berkeley.EDU (Andy Beals), fri, 22 may 87 20:52:56
[[Sorry for those of you who are receiving this twice. The Yale mailer bounced
a bunch of targets.]]
The "native ethernet" is a 3-com(?) card that goes into the "at slot".
They claim that while it's still a hair slower at getting data between
Domain-Ring members, their engineering folks can't really tell the
difference between Domain-Over-Ethernet and Domain-on-a-Ring. That's
right, they're saying that if they run Domain-Over-Ethernet, it not
only runs at the same speed, they encapsulate the Domain packets
within IP packets so you can squirt them across gateways - but only
T1 links, 56kbps is too slow. They were also claiming that TCP/IP
throughput is 63% better with the "native ethernet".
This is a little garbled. There is no IP encapsulation. Routing through
an internetwork (note that little "i") is handled the way it's been handled
for the last year or so: using Apollo routers. The only thing that's
new is we support Ethernet as one of the possible data link types that
can be a network in an Apollo internetwork. As far as Domain performance,
it is indeed just fine. As far as TCP/IP goes, one should note that
the most likely reason it's better is that you generally have a route
that's one hop shorter than before (when your node was on the ring and
had an extra hop through a node that was on an ether and a ring). This
isn't saying that "63%" is wrong, I just think people should understand
the details.
The "Network Computing System" seems to be mostly vaporware right
now, but they do seem to have some good ideas.
NCS is NOT vaporware. (I speak as an engineer working on the project.)
It is fully functioning and in beta test. I personally have run it on
Apollo, a VAX running 4.3, a Sun running SunOS 3.0, and an Alliant (running
Concentrix [aka 4.2 Unix for Alliants]). BTW, we have a paper on
NCS at Usenix next month.
-- Nat Mishkin
Apollo Computer Inc.
-------rees@apollo.UUCP (Jim Rees) (05/28/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.
-------bobr@zeus.UUCP (05/29/87)
Jim Rees replied to my statement:
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.
with:
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.
I appreciate his review of changes for Domain/IX. It is the first time I
have seen such a concise description of the modifications made to BSD UNIX
utilities for Domain/IX. I have a few comments on the material presented.
'ar', 'cc', 'ld', 'nm', and 'size' are different because we don't use
a.out. Neither does sys V, ...
I don't know about the SV comment, but I do know that the standard way for
generating nroff terminal descriptions (as found in /usr/lib/term) is to
compile a C source file and strip it. I believe this works both under BSD
and under SV, but it doesn't on an Apollo, because the object format bears
no resemblence. I'm not claiming that it should--just that this is one of
the loose ends in Apollo's emulation of UNIX. There may be other
dependencies here, but nroff driver tables is one I know about.
'ps' uses well-defined interfaces rather than muck about in /dev/kmem.
I appreciate the fact that Apollo is trying to clean up some of the
dangerous coding practices employed in the implementation of UNIX. I would
like to see the well-defined interface used for implementing 'ps'. I would
like to port 'sps', which has in my opinion a superior user interface.
However, since I can get neither the source for the Apollo version of ps nor
documentation or code for this interface (as far as I know), I'm stuck.
'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.
Some of it has to do with a lot of other things, like process forking/job
control. Because of the underlying differences in process support, Apollo
workstations do very poorly in forking processes. They work much better
when the process address space is reused (controlled via the INPROCESS
environment variable). /com/sh provides some nice error reporting features,
which do not work under the modified /bin/sh or /bin/csh, and the usual UNIX
tools (e.g. adb) are not available to do the corresponding sorts of probes
under the UNIX shells.
'login' and 'passwd' are pretty hacked up. This has to do with our
distributed registry, which I think is better than /etc/passwd.
I won't comment here. Please note a recent posting on the difficulties this
system has introduced in reconfiguring nets operating under Domain/IX.
Anyway, I don't think I would want to work for a 'pure' unix box
company. It's obsolete technology.
Is that why sr10 is going to have a kernel level implementation of UNIX
system calls? Or why IEEE is formulating operating system standards that
look very much like UNIX? Or why superficially AEGIS itself looks very much
like UNIX, with names changed to protect the guilty? Give me a break.
Not mentioned in Jim's summary are changed to the support libraries. I'm
not sure how much difference exists, but I've seen mentioned on the net that
UNIX system calls fail when using DMR3D, and I have personal experience with
TERMCAP.
The Termcap library implemented on Apollo systems is something of a kludge.
Under conventional UNIX systems is the notion that control information can
be sent to the "screen" via the same stream that transmits data. This is a
reasonable conclusion for a system first implemented on "terminals."
Implicit in this notion is the ability to divine a set of character strings
which control the screen in certain ways, and a library which can contain
the particular character strings to service a great number of terminals.
Unfortunately, control or special data access to the Apollo screen is
available only through a functional interface. So in order to support
termcap, some magic had to be employed. A call to tgetent() to establish a
particular terminal type automatically spawns a vt100 terminal emulator
task, which subsequently acts as a filter with predefined and unchangable
characteristics. These characteristics include the creation of a new pad
which covers the existing input and output pad, remaining in place until the
program which called tgetent() terminates. In 4.2BSD the easiest way to
find the width of the screen was via termcap (this information has been
moved to the terminal driver in 4.3). Thus the simple act of trying to
determine the width of the window prior to formatting output places an
obscuring pad which captures all output for the duration of the program, and
on exit any program output issued afte the tgetent() call similarly
disappears. MH mail is an example of programs which use this technique and
so require nontrivial changes to work on Apollo systems. Another example is
more(1).
I would class myself as a novice Apollo user, yet I was able to find these
and many more differences between the BSD system I use and the Apollo system
I am trying to learn in my free time. I thank Jim for confirming my
contention about Domain/IX. Nothing in my claim was contradicted by his
posting.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK