richard@gryphon.CTS.COM (Richard Sexton) (06/05/87)
Re: David Krowitz AEGIS vs. UN*X dissertation
Geez, David, couldn't have said it better myself (really!). You
missed my favorite advantage of AEGIS over UN*X - the display manager.
Those transcript pads and the ability to edit text/commands whatever
is blinding progress compared to the UN*X interface that only needs
an ascii terminal and remins me of old time share systems.
Do these people who prefer UN*X actually use AEGIS ?
I used to think UN*X was the greates thing in the world, till
I used AEGIS. Now poor old UN*X seems like a relic. An important
evolutionary step, but so was Australopithicus.
--
Richard Sexton
INTERNET: richard@gryphon.CTS.COM
UUCP: {akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richardbobr@zeus.UUCP (06/07/87)
In article <607@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes:
Those transcript pads and the ability to edit text/commands whatever is
blinding progress compared to the UN*X interface that only needs an
ascii terminal and remins me of old time share systems.
Here's someone who's obviously never heard of "ksh" or used an Emacs shell
buffer to interact with the shell. These are not characteristics of UNIX, per
se, just as the DM (what a horrible hack) is not a characteristic of AEGIS.
Do these people who prefer UN*X actually use AEGIS ?
Speaking as one who does prefer UNIX, yes, I do use AEGIS whenever I am
forced to by the incomplete coverage by Domain/IX of the engineering
environment I require.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKGiebelhaus@HI-MULTICS.ARPA.UUCP (06/08/87)
Robert Reed writes:
Here's someone who's obviously never heard of "ksh" or used an Emacs
shell buffer to interact with the shell. These are not
characteristics of UNIX, per se, just as the DM (what a horrible hack)
is not a characteristic of AEGIS.
I am using Multics Emacs now and I use GNUemacs on the Apollo and Sun.
I don't think the DM is a hack. I'll usually use the DM when possible.
It is easier to do some things in Emacs and it is easier to do other in
the DM. You really should spend as much time in the DM as with Emacs
before trying to pass judgement.
Speaking as one who does prefer UNIX, yes, I do use AEGIS whenever I
am forced to by the incomplete coverage by Domain/IX of the
engineering environment I require.
This does not sound to me that you use the Aegis part of the operating
system very much (-:. Either you have not given Aegis much of a chance
or your requirements are very different from mine. Actually, I find
that for hacking, UNIX is better. The thought of doing a major software
project under standard BSD just makes me cringe, though.
It is true that I have spent time around some of the people who helped
develop Ada and some people who are pretty close to the state of the art
in software engineering. Some people might say that I spend too much
time on the method and not enough time on software it's self. Of
course, I don't think I do.
I'd also rather have a slower robust machine than a fast piece of trash.
I really have troubles believing that someone would like UNIX better
when Aegis has DSEE, tb, compilers with real error messages, an
operating system designed with some conventions, ts, dmpf, debug, and
many more 1st and 3rd party products. I absolutely detest "segmentation
error" and "memory fault".
Further, I don't look at as Aegis or UNIX. I look at is as one
operating system. The aegis commands are at the end of my search path
for my csh and the unix commands are at the end of my search paths for
my /com/sh. I always have both shells up on my dm and will switch
between them constantly. Even from a terminal I usually start up a
/com/sh from the csh which a suspend and unsuspend as I need it. It is
not because I find the Apollo csh incomplete, but because I find the
unix csh does not contain all the functionallity of /com/sh. Also, I
find that /com/sh does not contain all the functionallity of csh.
I look at it as UNIX++.percy@amdcad.UUCP (06/08/87)
So much talk about AEGIS/UNIX! What is Apollo's strategic direction? I have heard (rumour mill?) that Apollo is trying to get rid of Aegis and go to stand alone Unix (ala Domain i.e. your choice of System 5 or UCB 4.2bsd) a Domain that runs native and does not make use of AEGIS (drivers or set up utilities)! Is that true? May be someone from Apollo can confirm or deny that!! *IF* Apollo's direction is to go to Unix, would'nt that settle the issue of AEGIS/UNIX *OR* is Apollo an Unix box :-) !! What are Apollo's plans to go to 4.3? All flames to /dev/null please!
bobr@zeus.TEK.COM (Robert Reed) (06/09/87)
In article <870608041836.190078@HI-MULTICS.ARPA> Giebelhaus@HI-MULTICS.ARPA writes:
You really should spend as much time in the DM as with Emacs before
trying to pass judgement.
Well, that's just not the way I operate. I find as a matter of course that
I start pushing the limits of whatever tool I'm using rather quickly,
whether or not I am able to use the full breadth of its capability. I am
therefore willing to dig in order to make use of the facilities as they
exist. I was therefore able in fairly short order (albeit cursing and
swearing the whole time) to come up with a macro in debug to print ascii-z
strings (i.e., strings terminated by NUL) which debug, amazingly enough,
knew nothing about. The point of all this is that despite my willingness to
hack in order to develop sufficient tools in a given environment, I come
very quickly to conclusions about the effectiveness of those tools in
providing a reasonable environment. Some tools rarely get in my way (e.g.
Gosling Emacs). Some tools constantly get in my way (e.g. AEGIS, DM, debug,
etc.) I don't have to suffer through complete emersion before having a good
gut feeling about DM.
Either you have not given Aegis much of a chance or your requirements
are very different from mine.
One very quickly runs out of gas strictly within the DM. Its editing
facilities are a joke. I'm sure the DM editor satisfies novice text entry
needs OK, but I mostly edit documents and code. I require things like
electric-C mode, tags, background compilation and error walkthrough, and
other things which the DM editor does not support. I can do things with an
Emacs package driving the UNIX dbx debugger that would make users of debug
drool with envy.
The thought of doing a major software project under standard BSD just
makes me cringe, though.
Funny, I have the same reaction to doing it under a strictly AEGIS
environment.
It is true that I have spent time around some of the people who helped
develop Ada ...
Well, there's part of your problem right there :-)
I'd also rather have a slower robust machine than a fast piece of trash.
Me, too. That's why I put up with firing up Emacs to do text editing rather
than using the infinitely faster to start DM editor.
I really have troubles believing that someone would like UNIX better
when Aegis has DSEE, tb, compilers with real error messages, an
operating system designed with some conventions, ts, dmpf, debug, and
many more 1st and 3rd party products. I absolutely detest "segmentation
error" and "memory fault".
Whoa, what a mouthful! I know people who refer to it as "dizzy." It sure
promises a lot, but I've heard nothing but complaints from people who've
tried to use it (I, fortunately, haven't had to). Other implementations of
UNIX have a perfectly reasonable analog to tb, called core files and one of
a number of debuggers, including adb, sdb and dbx. Of course, these don't
work under SR9.2.3. I can't fault the compiler error messages other than
for their parsing difficulty (remember, I prefer to use the Emacs next-error
function to automatically open and position at the errors). The slur about
conventions is just that. There are many conventions within the UNIX
domain, from the definition of regular expressions to the "small is
beautiful" philosophy of UNIX tools.
Further, I don't look at as Aegis or UNIX. I look at is as one
operating system.
I wish I could. However, the "glue" between the two is so spotty in some
places that I'm constantly getting stuck in the cracks. Besides, claiming
to prefer AEGIS but defining that to be AEGIS with DOMAIN/IX is in some
sense cheating. If AEGIS is so good, would you prefer it if none of the
UNIX tools were available? If not, is it simply the tools you find
valuable? Or is it the philosophy that belies the tools and makes them play
well together that you desire? I personally view AEGIS as a step to the
side, founded on a few good ideas (like the networking scheme), but
ultimately a dead end that is currently being backtracked into a more
mainstream approach, so that those good ideas can be preserved in a more
flexible environment.
I always have both shells up on my dm and will switch between them
constantly. Even from a terminal I usually start up a /com/sh from the
csh which [I] suspend and unsuspend as I need it. It is not because I
find the Apollo csh incomplete, but because I find the unix csh does not
contain all the functionallity of /com/sh.
What's missing? Is it tb (whose equivalent functionality Apollo defeated by
not initially providing core files and adb)? The unspoken comment here is
that you run csh by default. Why not /com/sh? Others have suggested that
UNIX is obsolete by AEGIS standards, but here we have an AEGIS advocate who
requires UNIX tools, down to the default command processor.
Apollo has done a few things right, and they stand out like bright shining
jewels amongst a sea of crud.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKErstad@HI-MULTICS.ARPA (06/09/87)
With regard to Robert Reed's comments on "dizzy" (DSEE, or Domain Software Engineering Environment). As a relatively experienced DSEE user (1.5 years of intense use) I would contend that DSEE does indeed deliver what it promises. The primary complaint I would have is that the documentation is not up to snuff, although it did improve significantly with 9.0. On the other hand, it provides powerful, yet easy to use, procedures for code control, history management, and parallel/semi-interelated development efforts. We had one summer student in last year from Stanford (a junior) and had here dizzying away after about 3 days total training on the Apollos and DSEE combined. We've had half a dozen people working in the same general areas; frequently even had two people working on the same tool at the same time for different purposes; DSEE provides the ability to control interactions between these people to allow maximum sharing of commonality while preventing destructive interference. It also allows alternate "branches" of development to proceed, so we may have an obsoleted version of a tool which we continue to bugfix, while developing the next generation of that tool. In short, DSEE doesn't do a lot that couldn't be done manually (except for enforcing proper revision control/history), but I sure as heck wouldn't want to do it. Dave Erstad, Honeywell Solid State Electronics Division
Giebelhaus@HI-MULTICS.ARPA (06/09/87)
Robert Reed writes:
I don't have to suffer through complete emersion before having a good
gut feeling about DM.
That is just what I am saying. You need more than a gut feeling to pass
judgement. 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 used the DM unless I am on a terminal.
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.
The thought of doing a major software project under standard BSD just
makes me cringe, though.
Funny, I have the same reaction to doing it under a strictly AEGIS
environment.
Can you tell me why? And what is stricly 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 tool that come out under it. If I could have
all the UNIX tools, I would rather work under Aegis. I won't buy any
arguements 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).
Whoa, what a mouthful! I know people who refer to it as "dizzy." It
sure promises a lot, but I've heard nothing but complaints from people
who've tried to use it (I, fortunately, haven't had to). Other
implementations of UNIX have a perfectly reasonable analog to tb,
called core files and one of a number of debuggers, including adb, sdb
and dbx. Of course, these don't work under SR9.2.3. I can't fault
the compiler error messages other than for their parsing difficulty
(remember, I prefer to use the Emacs next-error function to
automatically open and position at the errors). The slur about
conventions is just that. There are many conventions within the UNIX
domain, from the definition of regular expressions to the "small is
beautiful" philosophy of UNIX tools.
I have barely used DSEE. I know a number of people who swear by it. I
know a number of managers who swear they have save man months by using
DSEE. There is even a case of a programmer who refused to use DSEE and
lost a month of time merging his code into the project code. For a
small project DSEE is not very useful; it is more work than it is worth.
For large projects, though, it is quite valuable.
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.
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.
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's missing? Is it tb (whose equivalent functionality Apollo
defeated by not initially providing core files and adb)? The unspoken
comment here is that you run csh by default. Why not /com/sh? Others
have suggested that UNIX is obsolete by AEGIS standards, but here we
have an AEGIS advocate who requires UNIX tools, down to the default
command processor.
From a terminal, I use mostly csh. From the DM, I use mostly /com/sh.
The /com/sh was not made to work from a terminal; csh was.
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.
I believe that unix is moving towards aegis in most ways. 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.thompson@calgary.UUCP (06/09/87)
In article <1809@zeus.TEK.COM>, bobr@zeus.TEK.COM (Robert Reed) writes: > In article <870608041836.190078@HI-MULTICS.ARPA> Giebelhaus@HI-MULTICS.ARPA writes: > > when Aegis has DSEE, tb, compilers with real error messages, an > > Whoa, what a mouthful! I know people who refer to it as "dizzy." It sure > promises a lot, but I've heard nothing but complaints from people who've > tried to use it (I, fortunately, haven't had to). Other implementations of (Much editting and cutting done above) I just thought that I'd put my two cents worth into this with regards to DSEE (or Dee-Cee as we call it). I'm working on a large software development project at the moment. The functionality that DSEE gives me, I find impressive. The system models used in DSEE are sufficiently powerful to let me do various strange things which 'make' couldn't handle. (Or at least I couldn't get make to handle :-)) While I do admit that for editting I prefer EMACS, I typically have three windows up, one with EMACS, one with DSEE and the final one with an AEGIS shell in it. This configuration allows me do to literally anything to or with the system. ------------------------------------------------------------------------------ Bruce Thompson | Disclaimer? But...but... I didn't University of Calgary, | say anything....really! Well, Computer Science Department | nothing of any interest anyways. (403)220-3538 or (403)220-5109 (office) |
bobr@zeus.UUCP (06/10/87)
Dave Erstad (Erstad@HI-MULTICS.ARPA) writes:
We've had half a dozen people working in the same general areas;
frequently even had two people working on the same tool at the same time
for different purposes; DSEE provides the ability to control
interactions between these people to allow maximum sharing of
commonality while preventing destructive interference. It also allows
alternate "branches" of development to proceed, so we may have an
obsoleted version of a tool which we continue to bugfix, while
developing the next generation of that tool.
So? We have a shell script which uses RCS to do all that stuff. So what's
the big deal? My friends content that DSEE requires a server which eats up
node cycles and VM space, is bulky and slow, and isolates the user in a
subsystem that must be entered and exited. Admittedly, this is all hearsay,
since I've never used it myself. But having used enough of the rest of the
system to get a flavor of the things that Apollo provides, I would not be
surprised.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKbobr@zeus.UUCP (06/11/87)
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
benoni@ssc-vax.UUCP (06/11/87)
In article <960@vaxb.calgary.UUCP>, thompson@calgary.UUCP (Bruce Thompson) writes: > In article <870608041836.190078@HI-MULTICS.ARPA> Giebelhaus@HI-MULTICS.ARPA writes: > > when Aegis has DSEE, tb, compilers with real error messages, an > I have heard that DSEE seems to be a pretty good product from people that use it daily. The Debugger is a letdown.
Giebelhaus@HI-MULTICS.ARPA.UUCP (06/11/87)
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?donp@CAEN.ENGIN.UMICH.EDU (Don Peacock) (06/15/87)
In regard to :
Dave Erstad (Erstad@HI-MULTICS.ARPA) writes:
We've had half a dozen people working in the same general areas;
frequently even had two people working on the same tool at the same time
for different purposes; DSEE provides the ability to control
interactions between these people to allow maximum sharing of
commonality while preventing destructive interference. It also allows
alternate "branches" of development to proceed, so we may have an
obsoleted version of a tool which we continue to bugfix, while
developing the next generation of that tool.
So? We have a shell script which uses RCS to do all that stuff. So what's
the big deal? My friends content that DSEE requires a server which eats up
node cycles and VM space, is bulky and slow, and isolates the user in a
subsystem that must be entered and exited. Admittedly, this is all hearsay,
since I've never used it myself. But having used enough of the rest of the
system to get a flavor of the things that Apollo provides, I would not be
surprised.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
The next time you have several people working on thousands of lines of code
each at a different location and intend on turning your finished product
over to a support group try using DSEE. With its history functions it allows
you to rebuild a system the way it was built 1,2 or 3 months ago or mix and
match different versions of the same overall system. A support person can
trace the development of a module from 0 lines to n lines and open up
the comments for each change which is a great help when fixing someone elses
code. I used this while working at General Motors and it is a GREAT HELP when
you have something complex to code.
I have used APOLLO products which could have been easier to use or had bugs in them
but I've yet to see this OS everyone is comparing AEGIS to. You know the
one, no bugs, great user interface, great development facilities, networking,
compatibility among differing machines... OH you must be talking about
UN*X. Thats right the perfect OS the one that is its own standard. The one overriding
+ that UN*X has that no other OS has is its ability to make programmers portable
other than that there is not a single thing that you can do with UN*x that some
other GURU in another OS can't do. That is the reason that business is going to UN*X
not because its the greatest thing since sliced bread but because programmers and code
are portable to some extent. Lets forget about the tools that are out there all the
don't run on the SUN either.
I use the C shell only!!! I am forced to use /com commands at times when
nothing else is available ie. edacct edppo ... and we have close to 250 APOLLOs.
Mr. Reed
Please next time you are listening to some hearsay sit down at your APOLLO
take a week and learn for yourself what is useful and what isn't. Don't
believe everything you hear and please don't spread it around before
you find things out for yourself.
sincerely:
Don Peacock (University of Michigan)
When I'm right nobody remembers,
When I'm wrong nobody fogets.mishkin@apollo.UUCP (Nathaniel Mishkin) (06/15/87)
People have been doing a find job hashing this topic about. It's been
great fun plowing through it all at once. (I was at Usenix all last
week.) I think most of the points have been fairly well hashed out. I
just have three comments (and a meta-comment):
First, no one that I know of thinks that the DM by itself is God's gift
to editing and window management. However, I've used a number of "real"
editors (Emacs, etc.) in my life, and even so, I find the DM editing
functions quite effective. I miss word wrap too. I miss a lot of other
things. But I use it all the time. It's amazing what you can do with
key definitions. The question is not simply whether an editor has some
feature, but how often one uses that feature and how much that feature's
absence affects one's productivity. For me, I haven't found the missing
features all that crippling to my productivity. Just remember, most
Emacs devotees are appalled by VI, despite the fact that a number of
people swear by VI. Finally, one would be naive to think that we aren't
addressing the deficiencies in all our products and are bound to the
interaction style currently imposed by the DM.
Second, before anyone says how bad DSEE it, I think they should really (a)
read the documentation closely, and (b) use it. Anyone who thinks that
RCS or SCCS in combination with "make" has anything like the functionality
of DSEE is sadly mistaken. There's no comparison. Sure it's big and
complicated -- so are the problems it's trying to address. (Further,
I've used it quite effectively on essentially one-person projects with
sources only in the few thousands of lines.)
Third, "cmcmanis@sun.uucp" stated that "UNIX is an O/S, and as such can
only reasonably be implemented as part of the kernel". Now THERE'S a
strong point. I'd also like some evidence for it. Hopefully it's a
false statement because otherwise, we're ALL in for a lot of headaches
in the future if we ever want to see Unix evolve.
A final meta-point: We know our system has bugs and deficiencies and
we want to hear about them. We're working on a number of them right
now. However, a lot of the messages seem to imply that what people should
do is just buy some other piece of equipment, as if that equipment wouldn't
have it's own set of bugs and deficiencies. Having a "native Unix" kernel
doesn't guarantee a few number of problems. Sadly enough, we all carry
around ratty baggage. People should open there eyes wide no matter what
vendor they buy from.
-- Nat Mishkin
Apollo Computer Inc.
-------bobr@zeus.TEK.COM (Robert Reed) (06/18/87)
In article <8706151345.AA03689@caen.engin.umich.edu> donp@CAEN.ENGIN.UMICH.EDU (Don Peacock) writes:
The next time you have several people working on thousands of lines of
code each at a different location and intend on turning your finished
product over to a support group try using DSEE. With its history
functions it allows you to rebuild a system the way it was built 1,2 or
3 months ago or mix and match different versions of the same overall
system. A support person can trace the development of a module from 0
lines to n lines and open up the comments for each change which is a
great help when fixing someone elses code. I used this while working at
General Motors and it is a GREAT HELP when you have something complex to
code.
My point was not that DSEE ineffective, just overkill. Nothing you've
described here is outside the capabilities of RCS and Make. Plus, this
combination probably uses a lot fewer system resources to accomplish the
same ends (this is speculation based on what little I know of DSEE).
I have used APOLLO products which could have been easier to use or had
bugs in them but I've yet to see this OS everyone is comparing AEGIS to.
You know the one, no bugs, great user interface, great development
facilities, networking, compatibility among differing machines... OH
you must be talking about UN*X.
I don't know how many more times I'll have to say this, but, my
participation in this discussion began when several people began making the
statement that AEGIS obsoletes UNIX. I have plenty of problems with UNIX.
I have more problems with AEGIS. On the spectrum from clucker to cadilac,
there are individual lines where AEGIS lies above UNIX, but over all, I
would rank UNIX closer to the ultimate in program development environments.
Please next time you are listening to some hearsay sit down at your
APOLLO take a week and learn for yourself what is useful and what isn't.
Don't believe everything you hear and please don't spread it around
before you find things out for yourself.
Actually, I am reasonably conscientious at this sort of thing.
Unfortunately, DSEE has never been installed at our site, so I must rely on
the input of friends whose technical judgement I trust. They are in a
slightly different situation, not having began the project under DSEE. They
are trying to convert a large software system over to DSEE, and have nothing
but ill feelings about it.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKrichard@gryphon.CTS.COM (Richard Sexton) (06/23/87)
Well, now that the AEGIS/UNIX discusion has petered out into DM/EMACS
and DSEE/MAKE, it seems to me that I guess I'm not really sure what
AEGIS really is. Is it the OS ? Or is it the integrated envirnment (mouse
bitmapped-display, keyboard with 'read' keys etc).
If the answer is the latter, then comparing it with UN*X seems about as
relevent as comparing the Apple Mac environment with UN*X.
I enjoyed this discussion quite a bit, and although I use and very much
enjoy the DM editor, I'm going to check out GNU EMACS.
To R. Reed at zuess/tek. Could you explain your reply to my posting about
mice pointers and multple windows ? I did't understand what you said, and cant
find the article or your address now. E-Mail unless you feel it is of cosmic significance.
Cheers,
--
Richard Sexton
INTERNET: richard@gryphon.CTS.COM
UUCP: {akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard