Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!HI-MULTICS.ARPA!Giebelhaus
From: Giebelhaus@HI-MULTICS.ARPA.UUCP
Newsgroups: comp.sys.apollo
Subject: Re: AEGIS/UN*X
Message-ID: <870611182822.521109@HI-MULTICS.ARPA>
Date: Thu, 11-Jun-87 14:28:00 EDT
Article-I.D.: HI-MULTI.870611182822.521109
Posted: Thu Jun 11 14:28:00 1987
Date-Received: Sat, 13-Jun-87 09:46:07 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 83

Robert Reed writes:

  It doesn't bother you that the DM editor does not have word wrap, that
  basic of text processing services?

Nope, doesn't bother me a bit.  That is what troff is for.  Once again,
I can use emacs under Aegis also.  I don't think you can call emacs part
of standard unix.  I believe that it was first developed on Multics; I
think Stallman first put it on Multics, it slips my mind for sure now.
In any case, Emacs is no more unix than it is aegis.

  I have never posted the package because I've never taken the time to
  bulletproof it to a point where I would consider inflicting it upon
  others.

The problem with most unix tools.  They are not even close to
bulletproof.  Thanks, I'll keep using something which is pretty bullet
proof: debug.  dbx does run on the Apollo.  

  But UNIX is the sum of its tools and the environment within which they
  operate.  What is strictly Aegis?  I give as a first approximation the
  display manager, kernel services plus the contents of /com.  There's
  probably other pieces floating around, but anything in /bsd4.1 /bsd4.2
  /sys3 or /sys5 are definitely not native Aegis.

I see: anything that runs on unix is unix, but not even the things
apollo ships which run under aegis are aegis.  Maybe we should call unix
just the things that AT&T puts out... and be sure to take out the things
which were developed under other operating systems first.  With the
definitions you are using, it is no wonder you don't like aegis.

  I thought I did comment on the rest.  What they were now escapes me.
  Regarding tb, how do you get to a point where you can issue tb?  Since
  /com/sh does not have a suspend function (as far as I know), the
  program has either completed (in which case the stack should be
  empty), or crashed (which under UNIX would automatically cause the
  generation of a core file).  Therefore, adb would always work.

The /com/sh is meant for multi-windows.  Thus, I would go to another
window and do the tb.  Core dumps are a pretty stupid idea.  It is data
structure based instead of procedural based.   It would be ok to dump
core, but the user should not see it or have access to it in any way
other than through procedures.  Otherwise the data structures of the
core are frozen.  This means you can't update the data sturctures which
is not a position I would like to be in.  No matter how good they were
when I buildt them, I am going to want to change them in 20 years.

I have had programs crash where I have not gotten core dumps.  I do not
know why not.  This has happened on Suns and on a Microvax.

    All one has to do us look back through about the last 25 messages of
    this news group to see the difference in conventions.  The UNIX kernel
    is great.  As soon as you leave the kernel, you are on real shaky
    ground.

  What?  I don't understand what you're trying to say here.  Most of
  what I have been defending are facets lying outside the kernel, though
  they require support and underlying philosophy provided ultimately by
  the kernel in order to work.
  
There are some nice conventions inside the kernel.  Once you leave the
kernel, though, life get miserable (when it comes to conventions,
programming practices, and the such).

    I believe that unix is moving towards aegis in most ways.

  Oh, you mean because network services are finally getting integrated
  into the kernel?  This is a process that started before Apollo existed
  (dating back to the point at which Berkeley got the DARPA contract).
  In what other ways is UNIX moving towards AEGIS?

I also mean in that /dev/kmem going away, core dumps going away, etc.
In general, it will have to get more consistant and procedural based as
it enter the business market.  Most vendors and standards are moving in
this direction.  It is a whole 'nother discussion.

  And it is mostly the petals and aroma of a flower that makes it loved
  by many.  Are they any less part of the flower because they can be
  desribed separately, or pulled off and pasted into a book?  These
  tools are as much a part of UNIX as the kernel. 

Ah, but if I can have the same petals and more on a better flower, would
I not rather have that better flower?