Seeking a Development Environment (Sun?)

[giebelhaus at umn-cs.arpa]

I am glad to see a discussion of this.  I think that anyone who is 
buying workstations today has some difficult issues to work through.
I still work through them often.  I hope this discussion helps other
people as much as it helps me.

I'll mostly reply to Bruce Barnett here, but I will add some comments
of other people that have posted about this subject also.  That is,
all quoted comments are Bruce Barnett's except those marked otherwise.

Barnett Bruce G <barnettb%vdsvax.uucp at BRL.ARPA> writes:

>Apollo's do have some advantage in Programming in the Large.
>Especially for Apollo-based end-user software environments.

Yep, because Apollo has a lot of nice extra tools that you don't
find in "standard" unix.

>One thing I don't like about Apollo is the intention to `lock you'
>into an Apollo domain (pun intented :-).
>Things like their pascal (which has been enhanced so much it looks like C),
>backplane, operating system, windowing and networking ...

Please tell me how Apollo locks you in more than Sun.  I hope it is not
because their are extra tools on the Apollo or that you want to mess with
/dev/kmem.

>Apollo supports standards, when they have to. It is a very different
>philosophy.

Apollo had a good thing and didn't put it up as a standard.  Maybe it
was a mistake and maybe it wasn't.  Let me quote another part of the 
article about not putting stuff up as public domain, though.
>          Maybe they are careful about the internals. But If I had a system
>          that TRULY supported diskless clients, I would not want to give away
>          the technology for free. 
I'm sure this is what Apollo must have been thinking.  I wonder how things
would have turned out if Apollo opened their Aegis stuff up as a standard
long ago.

>Disconnecting Apollo's Ring network causes a few problems, too :-)

I'm not talking about breaking the network, I am talking about when
your server goes down.  William Stallings has a book called "Local Networks"
that gives a good comparison of the ring and bus.  I think you will find
the way Apollo recommends you implements the ring more reliable, able to
take a heavier load, and certainly easier to debug than an ethernet bus.

>I have had a server supporting 17 diskless Sun 3/75's go down (power fail)
>and auto-boot several times, without serious problems.
>I did have to run fsck on the client root file system once or twice,
>but most of the time the users just waited a few minutes, and voila!
>they continued, with NO WORK LOST!

I'm afraid you have completely missed the point.  Apollo's diagnostics often
keep the machines from going down to begin with (of course not in the case
of a power outage).  Most of the time, I am warned of a failing component
before it has a chance to do any harm.

>Why did you have to edit fstab, unless to bring up a replacement
>file server? I suppose you would have to if you wanted to
>have another server provide the /usr/bin /bin and /ucb/bin directories.
>Or the swapping partitions (this is ND, not NFS by the way).

Yes, I want to boot off an alternate server.  I don't want to have to 
have 10 nodes down every time my server dies.  I know machines don't 
die that often, but they do die.

>I have heard from some Apollo people that they will NEVER support NFS.
>Also, I believe they have demonstrated some limited type of NFS remote mount,
>but this is not the same thing.
[...]
>Because it isn't a product sponsored by their competitor.
[...]
>Again, what reliability problem are you referring too?
>A stateless implementation is a lot more reliable than a statefull
>implementation.
And also from Guy Harris
>(I was a bit confused by his comment here; if Apollo hasn't released this
>alleged NFS implementation, how can you get it?)

I don't know if there is anything official yet, but I'll bet anyone 
who wants to take me up on it a beer that Apollo will offer NFS as a 
product before the end of the year.  As I hear the rumor, there is a 
royalty problem with Sun in providing NFS.  I seem to remember another
vendor (possibly Piramid) having much the same problem.  

As for the already available stuff, perhaps this is the one that Bruce
said he saw but was unimpressed with.  I heard of it but did not pursue
it as I don't want the administrative headaches of no file locking and
keeping up NFS (fstab files and such).

I guess NFS is one of those things that I may not think much of, but am
going to have to get used to.  I'm glad to see that Sun is putting
some file locking in it.  This makes it so it isn't stateless anymore, 
doesn't it?  Perhaps NFS will look like what RFS will look like (some
people have accused me of being an optimist at times).

Nathaniel Mishkin explained some about file locking so I won't go
into it again.  Sun must think it is important or they wouldn't have
added it to NFS, though.

>Not nearly as different as Domain/IX is from ANY Unix machine.
>I keep hearing people say that Apollo has Unix.
>
>They don't. It is an emulation.

As was said by paul at umix.uucp and Nathaniel Mishkin, Apollo's UNIX is
not an emulation.  Apollo has a non standard kernel and so does Sun.
I hold that if DOMAIN/IX is an emulation, SunOS is an emulation.

>You cannot buy a board that comes with a Unix device driver and install it
>in an Apollo. The internals of Domain/AEGIS are different.

As Guy Harris put it, you can't really do this on Sun either.  I
think that Sun is closer to running on a VAX in this way, but this 
does not necessarily make it better or easier.  I personally don't 
believe in having to recompile the kernel in order to add a device.

>Apollo provides a package that
>allows users to interface to their hardware, but this is a rigidly
>controlled interface. It may be easier to use, but is slower than a
>real device driver (the interrupt latency time is very high), and non-portable.

Yes, I like rigidly controlled interfaces.  Then again, I like strongly
typed languages like Ada.  If unix were completely rewritten in Ada using
"modern" software engineering techniques, I would be thrilled.

>Sun's have a standard architecture. Any Sun can have a TTY or a graphics
>device as a master console. Most graphics software is layered
>over a TTY tool. Examples are MAILTOOL and DBXTOOL, along with the
>chess and backgammon demo's.

I'm afraid I don't understand the above.  What do you mean by "standard
architecture" and how is it different than what Apollo has?  The way I
see it, Apollo meets this better.  On the Apollos, you don't have to 
worry about what CPU you are running; there are not separate directories
and programs for 68010 and 68020 cpus.  Any Apollo object will run on
any Apollo (unless it was specifically optimized for a particular CPU).

>And the system administration on Aegix is not UNIX.
>As I recall, scripts that add a user to the password file
>don't work the same way (or at all).

The password files are there.  They are standard bsd.  There is an
easier way to use them than to edit them, but they are certainly there.

>I admit that there are differences between SYS V, 4.2 bsd and 4.3 bsd.
>But there are a LOT of books available for people who need help.
>And you can go to seminars on system administration.
>But Apollos's administration is nothing like the others.
>In some cases is it probably easier. But different.

And SunOS system administration is different, also.  The non standard
parts of the Sun system administration are a lot more difficult for
me than the non standard parts of the Apollo system administration.

>You can take courses on Unix. From several people besides AT&T.
>And you can get books on the internals (like Bach's DESIGN ON THE UNIX
>OPERATING SYSTEM).

Funny, I never had to take a class on how to sys admin an Apollo.  I 
believe I am considered pretty good at sys administrating Apollos, too.
I did buy Bach's book.  When I get a chance, I'll read it.  I have
also taken some UNIX classes.

>Are you saying that Sun's need a server, while Apollo's don't?
>I don't understand.
[...]
>It makes a bigger difference when you have 12-15 diskless nodes per server.
>Sun has invested in diskless node technology. It works.
>I am not convinced that Apollo has done the same. Maybe they can demonstrate
>a diskless node or two, but I have heard of diskless benchmarks that
>show ~7 diskless Sun's having a performance degradation equivalent
>to 1 or 2 diskless Apollo's. And it seems to me that Sun's are usually
>faster for the same price as an Apollo, so the price/performace makes
>a BIG difference.  I would think that when you compare a 10-15 station
>cluster, Sun's would give you much faster machines at a much cheaper price.

I believe the Apollo topology can be much more reliable and fast for about
the same price.  Guy Harris is right in what I was recommending for a 
topology.  Every other node is a file server.  That is, half the nodes
are disked and half are diskless.  These are not SCSI bus disks either.
Especially with the new disks Apollo has just started using, the disked
nodes have much faster disk access than Suns or Apollos accessing files 
over DOMAIN or ethernet.  This is especially important in AI.  This is 
about the same cost of buying an equal amount of Suns with servers.

I would like to know where you got your benchmarks for diskless performance.

> Maybe you get what you pay for? :-)

If I thought I had to pay more money for quality, perhaps I would be 
looking at IBM RTs with some mainframes.  :-)

>The prices are similar to the sources for other versions of Unix.

Not Apollo or bsd source.  They are free and $400 respectively.

>          This is a very strange comment. Don't you know about the Sys V/bsd
>          merging? Also, see my previous comments.
I must not have been clear here.  I'll include Guy Harris's comments here
too, and answer them both at the same time.  Of course, Guy was not able
to see my all of my original text first; maybe it wouldn't have made a
difference anyway.
>It is not only strange, but uninformed.  There are several people from Sun's
>system software group working with the IEEE committee.  We have made joint
>proposals with HP on terminal driver and reliable signals issues.  We might
>not let them look at our source code, but some of them may work for
>vendors that don't have UNIX source licenses, and AT&T wouldn't *let* us let
>them look at it.  Does the person who makes this claim have examples of
>cases where we *didn't* let the 1003.1 committee look at our stuff?

I am not convinced that 4.2 and Sys V are merging.  I see no
commitment from AT&T to merge 4.2 into V resulting in something
looking much like what Sun has.  I hope that V picks up a lot
of what is in 4.2, but I don't expect the new V to look like SunOS.
To begin with, Sun has said that they will always be 4.2 based.  While it
may be possible to have a V looking interface with 4.2, I question Sun's
committment to standards in saying that they will stay with 4.2 no
matter what (by 4.2, I'm sure they meant what ever the latest bsd release is).

Last I checked Sun was not licensing or distributing their SunOS system
to anyone.  The merge that Sun has made looks to me that it will be
incompatible with all other versions of UNIX.  I could go on for a while
with this, but I'll just sum it up with this:
SunOS is a version of UNIX that is unique to Sun.
SunOS is privately developed.
SunOS is does not have it's technology sublicensed.
SunOS is not publicly documented.
SunOS has no firm commitment from AT&T.
SunOS is not reviewed by the IEEE P1003.
If anything, SunOS looks more questionable to me than DOMAIN/IX.

I am glad to see that Sun has some people on the IEEE committee.
My verbiage could have been better when I said that Sun "haven't let
the IEEE committee for UNIX look at their stuff."  I didn't mean to say
that Sun had denied the IEEE.  I don't know for a fact whether Sun has
denied the IEEE.  Maybe it is the case that the IEEE hasn't asked to
see it.

By proprietary I mean that Sun is not making parts of it's operating
system available.

Along the same line, Guy Harris writes:
>AMEN.  The IEEE committee is *not* developing an implementation
>specification, it is developing an interface specification. 

I hope I did not imply otherwise.  I don't think an implementation
specification standard could work. 

>          But I feel that the difference in the companies
>          is primarily in attitude. And I don't like Apollo's attitude.

I feel they have pretty different attitudes, also.  Sun seems to tell me
to do it myself.  I could get almost the same level of software support
if I bought bsd from Berkley.  That is, close to none.  Hardware support
is the same.  I had their 24 hour mail in service and it took over a week.
I consider service 7 times worse than promised pretty bad.  After a few
bad experiences like that, I stopped using Sun's service.

Apollo is the other way around.  Out of Vaxes, Symbolics, Honeywell, 
Bridge, and a few others, I find one gets the best software and hardware 
service on the Apollos.  

Sales support is the same story.  Sun gives nice little shows and does a
wonderful job with their image, but just try to get them to follow a 
delivery schedule.  Apollo has only failed to me the delivery schedule
once, but that was on a special order the salesman rushed for me.  Even
then, it was only a few days late instead of months late like I have 
from Sun.  Sun really got under my skin when our last set of machines
were late.  The delivery date passed without word from the salesman.
When we called the salesman, he either was not willing to or could not
find a new date.

For a university full of cheap labor, one may not need quite so much
support, but I don't have time for this kind of stuff.  I get people 
quoting dollar losses to me when these problems happen.  And then they
wonder why I would rather buy Apollos than Suns.

Robert Reed writes:
>It is also a standard file system, which has a structure and file formats
>that are known in advance.  It does not have extra fields in /etc/passwd and
>/etc/group, [...] or a C compiler which generates error messages
>incompatible with standard error postprocessing techniques.  

What is this stuff on extra fields in /etc/passwd and such.  It is not on
my machine.  The C compiler is different.  I find it much better than the
cc on the Suns except for the one thing that Robert pointed out.  I'm
not sure about the rest of the things he has mentioned.  I have not 
noticed anyone having a problem with malloc on any of our Apollos yet.

Robert Reed also writes:
>To some extent the issue is whether /dev/kmem exists, when it restricts the
>portability of standard UNIX tools.  Obviously, the folks at Apollo have
>some way to get around it, since they have an implementation of ps which
>appear standard.  However, I have not yet seen any documentation about how
>to get at such information as required by ps.  This means I have no
>mechanism for building tools that look like "top", or "sps", or other publicly
>distributed tools that I might want to have on an Apollo.

I don't think it is very structured to have to go into /dev/kmem.  I have
not look for the routines Apollo uses for getting the process names and
such, but if it is not available, it should be.  Instead of reading
memory directly, I believe an operating system should provide functions
and procedures.  

Giebelhaus at hi-multics.arpa
ihnp4!umn-cs!hi-csc!giebelhaus