Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!teklds!zeus!bobr From: bobr@zeus.UUCP Newsgroups: comp.sys.apollo Subject: Re: AEGIS/UN*X Message-ID: <1828@zeus.TEK.COM> Date: Wed, 10-Jun-87 17:45:41 EDT Article-I.D.: zeus.1828 Posted: Wed Jun 10 17:45:41 1987 Date-Received: Sat, 13-Jun-87 07:02:53 EDT References: <870609150939.860039@HI-MULTICS.ARPA> Reply-To: bobr@zeus.UUCP (Robert Reed) Organization: CAE Systems Division, Tektronix Inc., Beaverton OR Lines: 113 In article <870609150939.860039@HI-MULTICS.ARPA> Giebelhaus@HI-MULTICS.ARPA writes: For things like electric-C and such, you do need something like emacs. I wish the DM editor were easier to expand, but that is a fault of the DM. For doing things like editing troff input, though, I will always [use] the DM unless I am on a terminal. It doesn't bother you that the DM editor does not have word wrap, that basic of text processing services? When I write troff input (usually using -me), I take advantage of a -me Emacs package which does things like automatically match displays, generates footnote displays when a "\**" footnote indicator is entered, and allows me to fill paragraphs to make it easier to read unformatted documents. Of course, none of this is possible with the DM editor. >I can do things with an Emacs package driving the UNIX dbx debugger that >would make users of debug drool with envy. Have you posted these additions to emacs? Can you? If you can get more fuctionallity than debug, I want the tool. 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. Having written it, I know where its weak points are and can demonstrate the functionality I described without suffering the pitfalls. It does require dbx (Not debug, but I understand that dbx is now available with 9.5. Can anyone confirm this?) plus some changes to process.ml and a current-line function to return the line number of dot. Given these conditions, if you think you might like to try it, I would have no reservations about mailing it to you. what is [strictly] aegis? I can run Emacs under aegis if I have the unix libraries. I find that it is not so much UNIX that I like, but all the [tools] that come out under it. If I could have all the UNIX tools, I would rather work under Aegis. I won't buy any [arguments] stating that the tools could not be developed under Aegis. Aegis is a better base to build upon than is UNIX (I mean the UNIX without the tools). 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. If those non-UNIX tools are not sufficient a development environment for you, we begin to understand more clearly where the dividing line lies: the choice falls between a pure UNIX environment (pick BSD4.2 to avoid quibbling) and a MODIFIED UNIX/AEGIS environment. That is, AEGIS doesn't have enough poop on its own to survive as a reasonable development environment, which was what my contention was in the first place. The unix equivalent to tb is addressed, what of the rest? One has to get their core dumped first. What if it does not? tb always works. 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. It seems to me that your are calling emacs part of unix. This does not seem quite fair. It is a tool that runs on top of UNIX. It can run on top of Aegis also. So are awk, sed, vi, yacc, lex, wc, grep and csh. Are these any less part of the UNIX environment because they are tools which run on top of UNIX? My use of Emacs in my examples was not so much to tout the properties of Emacs, but to show an alternative to the privitive bogusity inherent in the DM. I could have taken other examples, but the ones found in Emacs are the most familiar to me, so I arrived at them first. This is not to say that I have not already stated other examples, such as the ksh or K-shell. 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. It seems to me that it is more that some people are very used to the UNIX way of doing things. Learning a new way, would take a very long time. In some cases one can't do in Aegis what one can do in unix. In other cases one cannot do in any unix what one can do in aegis. Learning a new way implies that there is an alternative. As we've demonstrated above, your "alternative" relies on UNIX tools (i.e., tools which are licensed to Apollo under an AT&T UNIX license agreement). There are a few features under Aegis which expand upon the basic capabilities of UNIX, such as the ACL protection scheme, so there are a few things Aegis offers which are not possible under any version of UNIX, but very few. The balance is much more in the other direction. 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? In the mean time, it is very important that one can run unix tools on aegis so that aegis can take advantage of work done on unix. It is mostly the tools which unix has which make it loved by many. 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. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK