Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!rutgers!husc6!mit-eddie!apollo!mishkin
From: mishkin@apollo.uucp (Nathaniel Mishkin)
Newsgroups: net.unix-wizards
Subject: Re: Seeking a Development Environment (Sun?)
Message-ID: <30ceeabf.809c@apollo.uucp>
Date: Mon, 20-Oct-86 08:05:21 EDT
Article-I.D.: apollo.30ceeabf.809c
Posted: Mon Oct 20 08:05:21 1986
Date-Received: Tue, 21-Oct-86 06:57:47 EDT
References: <4254@brl-smoke.ARPA> <935@kbsvax.steinmetz.UUCP>
Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 86


I'll spare the feint of heart by saying up-front that (a) this is yet another
in the string of Apollo vs. Sun messages, (b) I work for Apollo Computer,
(c) this is not a sales pitch, (d) this is not an official message from
Apollo Computer Inc.  It you just can't stand it any more, please feel free
to go to the next article.

In article <935@kbsvax.steinmetz.UUCP> barnettb@steinmetz.UUCP (Barnett Bruce G) writes:

    Also, I believe they have demonstrated some limited type of NFS remote
    mount, but this is not the same thing.

I can't comment on what Apollo will or won't do, but I'll just take this
opportunity to point out that what we HAVE done is build a framework
so that you can build client-side support for any remote file access
scheme of your own choosing or creation.  This framework is a product
and we even ship an example (demonstrative, not complete and efficient)
of how to use it to allow transparent remote file access to remote 4.2bsd
systems.

The framework is, I would claim, a better (dare I say "more open") thing
to have than simply NFS.  One could build NFS support using the framework.
One could build ISO/FTAM support with the framework.  One could build
something that FTP'd a whole file over to your machine on open and back
on close, if that's the best you could squeeze out of an uncooperative
remote system.  Better that then nothing.

As far as server-side support goes, writing servers (especially stateless
ones) that do the things that remote clients ask it to do just isn't
that hard.

    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?

Well, I suppose this could be religious territory.  I suspect that one's
attitude about the necessity of MANDATORY file locking changes when one
considers an environment of, say 1000 workstations.  (Say, like us.  Say,
like I expect more and more sites to have eventually.)  I'm just not
willing to take my chances that either (a) I have no competitors for
access to the same file as I'm accessing, or (b) that every program
actually bothers to do the lock file hack or "lock call" (correctly) 
when appropriate.

    I keep hearing people say that Apollo has Unix.  They don't. It is
    an emulation.

I object to the term "emulation".  What is Unix?  It's commands (programs),
subroutine libraries, and system calls.  No, our kernel is not derived
from any standard Unix kernel.  But all our commands and much of our
library code is simply the straight Unix source code.  Is our "read"
an "emulation" because it calls some lower level interface other than
the lower level interface called by the Berkeley Unix kernel?

There is no question that if you spend your time making changes to the
Unix kernel, that you will be disappointed at the extent to which those
skills can not be transferred to the Apollo kernel.  However, I would
guess that the fraction of Unix users who change the kernel is much,
much smaller than it was 5 years ago.  Yes, this is because most Unix
users these days are doing application work, NOT kernel work.  The argument
is valid, nonetheless.

    I was under the impression that Apollo is still hiding the internals
    from everyone. Do they even have a "/dev/kmem" ?

I guess all I can say is that if you think that programs that read
"/dev/kmem" are the wave of the future, I hope you're wrong.  I believe
in procedural abstraction.

    Also, the Apollo's are very workstation based.

I'll take this criticism as a complement.

    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?

If this is true, it's a bug.  We certainly intend that all programs which
are critical and/or likely to be used over TTY lines should work passably
well in that environment.  Certainly, I can't imagine any reason (other
than bugs) that standard Unix programs wouldn't work over TTY lines.

                    -- Nat Mishkin
                       apollo!mishkin