Seeking a Development Environment (Sun?)

[barnettb at vdsvax.uucp]

In article <4254 at brl-smoke.ARPA> giebelhaus at umn-cs.arpa writes:
>My experience is that Apollo is much better for professional software
>development and Sun is better for hacking.  

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

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 ...

Apollo seems very interested in providing software that keeps you on Apollo
machines, while Sun is always pushing for, and supporting, new standards.

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

>Other things such as much of the network hanging
>when a server node goes down until you edit fstab and reboot really bothers
>me.  

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

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!

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).

>You can get NFS for the Apollo

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.

> but I don't believe that Apollo wants
>to release it because of some reliability problems like the one just
>mentioned and the lack of file locking.  Apollo is putting their resources
>in RFS instead.

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.

Re: File locking. I would suppose that NFS file locking will be added 
eventually. But I have a dumb question. Unix didn't have file locking
for years, yet people got around it by either creating another `lock'
file and testing for the existance of it, or by using a specialized 
device driver to provide synchronization of different processes.
Why is file locking the BIG DEAL? It seems to me that all of the vendors
who have their own proprietary scheme knock NFS because of this, yet
Unix has been lacking in the `niceties' of file locking for years.
Is this just Sour grapes?

>I have a hard time getting software support from Sun.  I am not a great
>UNIX wizard, yet, and I surly don't understand the internals of UNIX.
>If I really got into the guts of the stuff, Sun might be easier since
>the lower layers of SunOS are closer to bsd than DOMAIN/IX.  Still, every
>modual of the SunOS has been modified.  From Sunwindows to Yellow pages,
>the operating system is different than bsd.  
>
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.

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.
The data structures (as normally documented in /usr/include) are not the same.
This is useful, not only with device drivers, but with programs like
ps(1) that read the internals of the system memory (using /dev/kmem) to find out
what is going on inside. I have taken courses on the internals of Unix,
and programs that examine the file system, user areas, etc.
ARE useful. I would guess that the public domain program `top' won't
run on an Apollo very easily.

I was under the impression that Apollo is still hiding the internals from
everyone. Do they even have a "/dev/kmem" ? It also seemed to me that
programs making use of the object image (nm, size, strip, dbx)
are not the same. Sun provides documentation on adding device drivers
(or pseudo-device drivers) to the kernel. They even provide programs that
make it easier to debug (like adbgen). 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.

Also, the Apollo's are very workstation based. The debugger won't run
on a TTY. Other programs are also workstation-only based, when they shouldn't
be. How do you debug a program over a phone line?
In fact, I don't KNOW for sure what standard Unix programs are missing
on an Apollo, or can't be used over a phone line/TTY. Wouldn't
it be a bummer if man(1) doesn't work? It probably does. But I
wouldn't assume that Aegis has every utility that you are used to.
Or that it has the same output. 

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.

This strikes me as following the `Unix Philosophy'.
Tools that use tools, you know.

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).
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.

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).

I would much rather have a system that is well known and available
on several machines than one that is only on one vendor's product.
Unix is tough enough to learn when there is a stardard.

>Prices of the two systems are about the same.  With Apollo, you don't
>need the server (I run every other node diskless with very good results).

Are you saying that Sun's need a server, while Apollo's don't?
I don't understand.

>When you take the cost of the server into account, it really makes a 
>difference.  

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.

>Another thing that makes me worry about buying Sun is that they don't
>seem interested in "Open Systems" like they used to be.  The UNIX source
>was free and relatively easy to get from Apollo.  

 Maybe you get what you pay for? :-)

>I understand the SunOS
>source costs a bundle and even then they don't like to give it out 
>(havn't checked it out, though).  

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

>Much of the SunOS is getting propietary
>so I don't know about it becoming a standard.  Also, they haven't let
>the IEEE committee for UNIX look at their stuff.  To me, Apollo looks
>much more open.
>

	This is a very strange comment. Don't you know about the Sys V/bsd
	merging? Also, see my previous comments.
	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. And besides, there is a BIG difference in the
	interface to a system and the internal implementation.
	The interface is documented in the manuals you can purchase.
	In fact, more of the internals of SunOS is documented that that of
	Aegis/Domain.

>We find it a hard and somewhat religous choice between the two.  If you
>have any questions, I would be happy to help.  I wouldn't want anyone
>to go through the problems I did.

	Maybe I tend to get religious too. I have been burned badly by
	being locked on to a single vendor's platform. Apollo is just
	like all of the others. Sun is a breath of fresh air. They
	are balanced on a two-edged sword of standards. It is as easy to
	jump onto a Sun bandwagon as jump off. 
	Also, it is harder to be burned by a Sun (standard) platform 
	than an Apollo platform. I might hazard a guess that some of
	Apollo's OEM's are finding out how difficult it is to move to other
	workstations.

	Also, I have followed Sun and Apollo's direction for years,
	and it seems to me that Sun has a definite goal, and is going
	towards their goal with a very efficient team of people.
	Apollo seems to be lacking in direction. How many different
	architectures are they supporting? Which options are available with
	which machines? Which bus is used? Which Windowing standards?
	Which networking scheme?

	It has been a year since I have last used an Apollo, and they have been
	improving the product, so my memory may be faulty in a few spots.
	But I feel that the difference in the companies
	is primarily in attitude. And I don't like Apollo's attitude.
	
	Bruce Barnett 
	chinet!steinmetz!vdsvax!barnettb

{These are my own opinions, guesses, hunches, and mistakes. Please excuse}