ram@nucsrl.UUCP (06/02/87)
I can't stand this anymore. All you guys claim AEGIS is far superior
to any UNIX implementation, but fail to state explicitly as to what
makes it superior.
Stating popularity as reasons for superiority is like comparing
IBMs with non-IBMs. Just 5 years back, anybody mouthing UNIX would
have been frowned upon. Based on technical merits alone, what is
it that makes AEGIS superior/inferior?
I am no UNIX guru and so would like to know what's wrong in using
/dev/kmem(Perhaps if I am a guru,I would be die-hard fan of /dev/kmem:-)).
How would AEGIS compare with MACH?
-------------------
Renu Raman UUCP:...ihnp4!nucsrl!ram
1410 Chicago Ave., #505 ARPA:ram@eecs.nwu.edu
Evanston IL 60201 AT&T:(312)-869-4276
P.S: Could anybody mail me pointers to papers/articles on the
implementation of AEGISkrowitz@mit-kermit.UUCP (David Krowitz) (06/03/87)
Ok, here's why I myself think that AEGIS is better than Unix ...
1) The distributed file system is an integral part of the OS, not layered
on top as an afterthought. All file systems on all machines in the network
are co-equal in AEGIS. In NFS the foreign file systems are mounted
beneath your local file system and your file system, in turn, is mounted
beneath their file system. With AEGIS their is no concept of a 'foreign'
file system -- all disks on all machines are equally accessable.
2) Better file protection. Unix gives you only group, owner, and world (everyone)
protections. Even the old Decsystem-10 operating system (TOPS-10) gave you
the ability to specify exceptions to these three classes (and TOPS-10 predates
Unix by about 10 years). Their are people in my 'group' who are complete
idiots -- I don't want to have to trust them with my files, but I have to
let other people in my group have access to them. I can't do this with Unix
style file protections. It is quite easy to do with ACLs (regardless of the
operating system, AEGIS, TOPS-10, etc). Claims that ACLs are 'too hard to
understand' are heard frequently from the Unix camp. I've never had a problem
with them. I can make my ACL for a file as simple or as complicated as I
wish, and I usually leave them pretty simple. The way most ACL systems work
is that the OS scans down the list of entries for the file in question and
finds the first entry that matches the user-id (either directly, or via a
wild card match) and applies the protection corresponding to that entry.
Here's an ACL list which would correspond to the Unix-style protection :
me.%.%.% matches 'me' for all groups, projects, and nodes
%.my_group.%.% matches other people in my group next
%.%.%.% matches everyone else last.
3) A better file system. Apollo calls it and 'object oriented' file system.
Basically, files have types. The system can tell you whether a file contains
ascii text, fixed-length binary records, variable-length binary records,
bitmaps, whatever. The Unix file system has no concept of this. Files are
simply strings of bytes and your program has no way of telling what kind
of bytes are in a particular file. Under Unix program may write a special
code are the beginning of a file (called a magic number) so they can
recognize their own output, but other programs may not check this code and
can easily read it as part of the data. Programs must rely upon the user
always feeding them the correct input files -- otherwise you get the old
garbage in, garbage out. Unix enthusiasts consider this feature a blessing.
They can write programs which can do anything they want with a file\
(including screwing it up completely). The AEGIS file system knows what
kind of data is in a file ands reads it accordingly. Your program can
check that it's reading the correct kind of file without depending on
someone else having put the correct magic number in the file. It can also
handle multiple types of input file very easily because the operating system,
not the user program, handles the job of getting the data extracted from
the file in the proper format. If you *really* want to play with the raw
bytes in the file you can do that with AEGIS also. There is a seperate set
of system calls for doing this.
3) Memory mapped I/O. It's simply faster than the byte oriented I/O found in
the standard Unix kernal. Many performance-oriented vendors who use Unix
are rewriting their kernals to use memory mapped I/O, AEGIS already has it
as the underlying basis of the file system. As a user you see no differnce
in you programming ... the system is simply faster.
4) Better organized system librarys and manuals. All AEGIS system calls for
a particular set of operations have similar names. For instance, all of
the input/output calls have names like IOS_$READ, IOS_$WRITE, IOS_$DELETE
(you get the picture). It simply makes it easier for the non system hacker
types to remember what call they are looking for and where to find it in
the manual. If you are a system guru and know all of the OS manuals by
heart this doesn't make any difference, but most of us can't remember what
the name of the particular call we wanted. At least if I know that it had
something to do with process control I can look for calls beginning with
PROC_$. This also makes it easier to find sections of my programs which
are doing particular operations. If I'm having trouble with a bug in the
formatting of my I/O I can simply have the editor search for the string
'VFMT_$' and I can find *all* of the places where I'm formatting my I/O.
5) An extensible file system. Not only does AEGIS have file types, but you
can create your own new types and instruct the file system how to deal
with them. We can create a new kind of object which implements a
'backup copy' concept quite easily (ie. a special kind of link which
first tries a directory on node_1, and if it is not available (the
node is down or whatever), then tries a backup directory on node_2) Unix
has no provision for this. If the node containing your library is
unavailable, then you're just out of luck (well, you can re-link your
directories by hand, or redefine an environment variable, but you've
got to recognize the problem by your self and correct it on your own.
The Unix file system won't do it for you, and you can't write your own
extension to the file system to do it, either).
6) Better system management utilies. WBAK/RBAK combine the best features
of 'tar' and 'dump'. 'tar' can backup individual files and trees, but
it can't handle a multi-tape backup. 'dump' can handle multi-tape
backups, but you have to dump an entire file system (read 'disk partition')
you can't backup just the files/directories you want. WBAK/RBAK can do
both (and uses industry standard (ie. OS independent, not just Unix
standard) ANSI labelled tapes to do it). INVOL and SALVOL are much easier
to use and the Unix 'fsck' and 'diskf' utilities. I suppose that some
people really want to deal with the number of cylinders, tracks, and
sectors per track of their disks; but I'd rather just specify how many
partitions I want on the disk and their sizes. I'll let the program
figure out what that means in terms of tracks/sectors and block sizes.
Yes, the Unix utilities will let me do anything I want (as long as I know
how to do it), including destroying the file system with a single mistyped
command. What I really want to do is to manage my twenty machines with
as little work as possible and save the complicated disk utilities for
an emergency when I'm working with a system service rep. who knows what
he/she's doing.
7) A more consistant and better shell. If I want to create a file/link/directory
the command is crf/crl/crd, not 'cp /dev/null'/ln/mkdir. The file-name
wild cards are more powerfull and can be used in both the input and
output file names. (ie. you can copy the portion of the name which matched
the wild card in the input name to the same (or different) location in
the output name). It is easier to teach novice, no computer science major,
users to use the AEGIS shell than it is to teach them the C shell. The
commands are simply easier to remember.
I could go on like this for awhile. The major point I'm trying to make is that
AEGIS is a newer operating system than Unix and was designed to take the best
features of Unix and combine them with the advances in OS designs that had been
made since Unix was developed in the 1970's. It's capabilities are a superset
of those of Unix, and while Unix can be made to run on top of the AEGIS
kernal, the reverse is not true. I think that Apollo has taken the correct
approach, which is to make both the BSD4.2, SYS V, and AEGIS shells and libraries
run as co-equals on top of a single, technically advanced kernal rather than
forcing a choice between a SYS V or a BSD4.2 kernal, both of which would
represent a step backwards. There are quite a few people who *insist* that
it isn't *real* Unix unless the kernal is so similar to the Vax implementation
of BSD4.2 that they can muck around in /dev/kmem. They are WRONG! Many Unix
vendors, Sun included, are rewriting major portions of the kernal simply to
improve performance, not to mention adding new features. Writing code which
depends on poking around directly into the guts of the OS rather than going
through a well defined user interface (ie. a system call) is writing non-portable
code -- non-portable from one version of the OS to another version on the same
machine. User communities which insist that they can't live without this style
of programming wind up locking themselves into obsolete architectures and
operating systems. Look at the IBM mainframe people, still saddled with the
IBM 360 architeture 25 years after it was developed.
-- David Krowitz
mit-erl!mit-kermit!krowitz@eddie.mit.edu
mit-erl!mit-kermit!krowitz@mit-eddie.arpa
krowitz@mit-mc.arpa
(in order of decreasing preference)Erstad@HI-MULTICS.ARPA (06/03/87)
Add to David Krowitz's list 8) An extremly consistent set of command line switches. If I use a command referencing a node, I know the option is '-n', and I know the different specifications I can use in identifying the node - they're the same for all commands. If I want to list directories, I use a -ld; it doesn't matter if I'm doing a directory command, a tape archive command, a copy command, or whatever. And so on. Regardin7 - Consistent and better shell. I agree for the most part. The one big place Apollo goofed here which consistently messes up new users is crd vs dlt. Why not crt or dld? Most of it is much better, though.
scottj@cae780.UUCP (06/04/87)
In article <870603192007.915098@HI-MULTICS.ARPA> Erstad@HI-MULTICS.ARPA writes: > >Add to David Krowitz's list > > 8) An extremly consistent set of command line switches. If I use a >command referencing a node, I know the option is '-n', and I know the ^^^^^ >different specifications I can use in identifying the node - they're the >same for all commands. > Except for the 'crp' command where you use '-on'. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FROM: Scott A. Jordahl, Tektronix/CAE Systems Division UUCP: tektronix!teklds!cae780!scottj {ihnp4, decvax!decwrl}!amdcad!cae780!scottj {nsc, hplabs, resonex, qubix, leadsv}!cae780!scottj ADDR: 5302 Betsy Ross Drive, Santa Clara, CA 95054 AT&T: [408] 748-4727 [direct] +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Erstad@HI-MULTICS.ARPA.UUCP (06/04/87)
> Except for the 'crp' command where you use '-on'.
True. The problem is that -N is the "standard" switch for two things -
a node identification and a process name. Since the CRP command has
both switches, something has to give.
One could either argue that such doubling up on switch meanings is
either poor implementation or unavoidable (i.e. one wants a set of
switches describing every possible option which are unique, meaningful
and short - which may be an overconstrained problem). Not having a
crystal ball, I won't guess at which reason applies.freedman@calgary.UUCP (06/04/87)
Having had our Apollos (6 3000s and a DSP90) for about 8 months now, I thought I'd post a list of our users' likes and dislikes to add to the UNIX vs. Aegis discussion. Our users are typically Computer science faculty, grad students, and research assistants working on a wide variety of problems such as A.I., user interfaces, and data-compression. The Downside ============ Filenames don't work the same between Unix and Aegis due to Aegis's case insensitivity and intolerence of certain characters. This means that novice users have to be told "you can use the right-hand mouse button to edit your file, but it doesn't work on your .login or .cshrc". Aegis programs also have problems with UNIX filenames (try typing in "acl .login" for example). Some bsd4.2 programs are missing. It is a hassle to not have convenience programs such as "talk" on the system (we are running 9.2.5 since 9.5 has STILL not arrived). Some bsd4.2 programs just plain old don't work, such as strip. Strangely, some UNIX programs can do things that corresponding Aegis programs can't. For example, with "rm", you can remove a sysboot file, but with "dlf" you can't. Some programs have serious bugs in them, such as who (which doesn't tell you who is logged in to your node unless they are logged in to the display manager). While some parts of the system are well thought out, others are not. This results in some things being trivial to implement, and some other similar things being close to impossible. For example, creating a remote process that runs a shell script is simple, but creating one that runs remotely in the background after you log out is hard. Writing graphics programs is simple, but writing a text only terminal emulator is hard (the DM will let you do *nearly* everything that you need to do under program control but not quite, and GPR requires you to re-implement by hand all of the stuff that DM lets you do before you can add the one or two extra functions that you need. Have you ever tried to get program control of an editable text area, for example? It turns out that you can either give up the ability to have control of input, or you can give up the ability to make changes to text on the screen. This is fairly frustrating. The dynamic linking really only goes half-way. Multics, for example, has a full implementation of dynamic linking, where links are made (and can be broken and remade) on-the-fly as needed. Both programs and external data are treated similarly with regard to linking. Aegis on the other hand only allows dynamic linking to happen in the form of pre-loading of libraries into your address space. For multics types, the difference is quite major. The files-as-memory/memory-as-files single level store Aegis concept also only goes half way. True, you can map a file into your address space, but you have to worry about how big its going to get, unmapping it, etc. Again, looking at multics, if you have a pointer to a segment (a multics file), thats all there is to it. No worrying about how big it is or anything. The logout process is painful for unix users. If you have background processes running, or if you have foreground processes such as emacs running, then logging out becomes a real chore. Once you have typed "lo", Aegis tries to kill off all of your processes, and it seems to take it up to one minute to realize that it can't (God knows why) kill off your emacs or rlogin. During this time, you wait. You cant do anything. Once the minute is up, you are asked if you want to blast all of your processes, which you do, since you dont know any better. This gets you logged out, but leaves a mess on the disk, which is only salvaged the next time you do a salvol, which involves taking own the system. Painful. The DM editor does not understand about su's or new logins. If you su to gain access to a file, the DM will still refuse you access. The use of the cursor is a bit painful. The area in which the cursor must be in order for you to type is far too small. Having the cursor in the non-writeable portion of the window should still allow one to type in the window's writeable portion. This is a fundamental flaw due to the same cursor being used for both pointing and text insertion. One of our users said that "It's not real UNIX unless I don't have to know Aegis to use it". This condition is not sufficient, but it is necessary. You can't administer the system without using Aegis. You can just about barely use the system as a user without knowing Aegis (until your processess need blasting ;-< ). Although UNIX and Aegis programs work together, there are some inconveniences involved. For example, the Aegis help program will not access UNIX man pages, and vice versa. Some Aegis programs respond very badly to being STOPped (ie with a SIGTSTP signal). They go off into never never land. Also, the magic incantation for signalling a SIGTSTP from the DM is dq -c 120028. However this number is never explained in any of the documentation. Why 120028 and not 120027? The vt100 program and server is really awful. Any time any of our users have used it, they have had trouble. For example, the vt100 server is started each time the termcap tgetent routine is called. Not only does this take forever to start up, but it doesnt respond to SIGTSTP's correctly. Thus emacs is not easily paused. Having non-newline-terminated strings sent to stdout is a real trick. No amount of flushing seems to be able to reliably get the strings to the screen. This is using printf and flush with the 9.2.5 C compiler. Some administrative tasks are quite painful, such as moving a master registry or renaming a node that is a registry 'site'. The DM's lack of control functions (such as if, while) is quite limiting. FOr example, if you want backspace to wrap around when it reaches the beginning of a line in the DM editor, tough luck. The process scheduling and/or paging is not good. It is frustrating to type a character into a window that is just running a shell, and have it take 3 seconds to echo back just because you have been recently using another process which needed a lot of memory. (of course, once your 1st character has come back, your 2nd and subsequent characters are echoed quickly, its just the initial context switch that takes a long time.) Some users would like ALL keys on the keyboard to be self-repeating. At the very least this should be a DM option. Currently, certain keys are self- repeating (such as backspace) and certain ones arent. Serial ports do not seem to be accessable from any node except the ones that they are connected to. Users can trash files that they shouldn't be able to trash by using the DM. Eg: Bring up a help window on some help file (type help acl, for example) and then use the pn command to write the window to a file in your current directory. Hint: Make a copy of the file first. The help file will be trashed, and you may well not have access to the pn'd file in your current directory! I'm not convinced that the security works on the system. This is not to say that I have evidence that it doesn't (although the above example casts large doubts), but rather to say that Apollo seems to have gone for security through obscurity. I just plain don't know what's going on down there in the kernel, and without source code, I have no way of finding out. There don't seem to be any technical manuals available (at least the local Apollo office doesn't seem to be able to come up with any for us). There is no apparant support for grey-scaling on the monochrome displays. The Aegis shell is yet another example of half of an excellent program. The language features are in general good, unless you want to do something really outragous like find the number of arguments to a shell script! Shell scripts do execute quite fast, though. There are no history or alias features, which means that people won't use it! THe Display manager hates tabs, which is a pain under UNIX, because certain program need tabs, such as make. The Upside ========== The transparency of the network enrironment is really excellent. There is really no need to worry about where one is working or where ones files reside. The reliability of both the system software and the hardware is excellent. Our fileserver has never ever crashed, and has only gone down when we wanted to install new software or salvage the disk space lost due to blasted processes). The system is fairly easy to administer (with the odd exception). It is really nice to be able to install new software by just typing install and then typing in the name of the piece of software to install. Its also nice not to have to worry about the hardware too much when salvaging disks, etc. The DM provides some very good features, such as a completely reprogrammable keyboard, a transcript of your whole session, cut-and-paste, an acceptable editor, etc. The compilers give mostly intelligable error messages. The UNIX is fairly close to vax bsd4.2 -- the differences are highly annoying, mind you, but not usually a problem to get around. Differences include different constant values, some different constant names in include files, lack of /dev/kmem, etc. The DIALOGUE user interface package is quite easy to use, and is fairly powerful, although it is not very flexible if you want to do something in a way different from the way it thinks things should be done. The DSEE source code manager is quite powerful, although like the rest of the system, there are fairly obvious features missing that make doing certain "simple" things difficult (like moving a library from one system to another). The dynamic linking, although limited, is still immensly useful. It means that program development goes quicker, and programs end up being smaller. The object-oriented filesystem is great. For example, one of the demo programs that comes with the system is a sort of NFS-only-better. It allows programs running on apollos to access remote filesystems over ethernet with the appropriate driver on the remote system. To the local programs, the files are just normal files accessed in the normal way. No kernel mods needed, all user-level stuff, no risk of crashing the system. The graphics stuff is good, fast, powerful, and easy to use. Aegis programs generally have a consistant set of command line options. The interprocess communication is good and fast. The debugger is excellent, allowing debugging of forking processes, graphic processes. etc. -- and it works, too. Philosophical ============= There are some puzzling things about the Apollo system. In many ways it is a half-finished very good product trapped by evolving hardware. For example, for a system with extensive graphics capability, there are very few graphically-oriented tools. -- edfont, prfd, netmain and maybe a couple of others. But at the same time, support for serial terminals which are textually oriented is lacking. The tools that are there tend to have some excellent features that work very well, but they tend to be side-by- side with wished-for features that are missing. I hope that Apollo keeps improving its products in order to bring the whole system up to the level of some parts of its tools. In the mean time, I like using the Apollos because they give me the power of UNIX plus half the power of Multics, plus the things that neither UNIX or Multics have built in, such as graphics. But at the same time, each time I use them, I get frustrated by the lack of orthoganality of the quality of the system's features. Dan Freedman The University of Calgary Computer Science Department.
thompson@calgary.UUCP (06/04/87)
Dan and I came up with a number of the comments which he posted. After he
posted it, we came up with a few others:
====================
PRO
====================
The protected subsystem idea is both powerful and convienent. The ease with
which a group of programs and files can be isolated and controlled using the
protected subsystem tools is impressive
====================
CON
====================
It is not apparently possible, without borrowing the entire display, to
obtain information regarding the user's activities (i.e. mouse movement,
button and key events, etc.) outside of the windows associated with a
process.
There appears to be no way to add system global error codes which will be
recognized by the error_$ system calls, or 'stcode'. While this is not really
a problem on UNIX systems, the ability to have defined codes for errors
occuring in site created systems would promote consistancy with the provided
error reporting characteristics of the system.
{ insert silly comment/standard disclaimer (there's a difference?) here }
--
-------------------------------------------------------
Bruce Thompson
University of Calgary , Computer Science Department
(403)220-3538 (office)peterson@utah-cs.UUCP (John W Peterson) (06/05/87)
Re: Dynamic linking: Apollo actually has had the ability to load (and reload) new libraries on the fly. They just never documented it (grumble grumble..) Re: Tab characters and the DM not reading '.login' - try fixing your key definitions (hint: look at /sys/dm/bsd4.2_keys2, "stab" and "r3"). Speaking of cryptic key defs, many of the flames about the Apollo posted here are really flames about the DM (and it's illegitimate child, vt100_server). And they're not unjustified - the DM was hot stuff in 1982, but relative to the rest of the world it hasn't gotten much warmer. If you are running a B&W DN3000 with 4 meg or more of memory, and you want "a unix box", you should very seriously consider running the X window system instead of the DM. All those obnoxious misfeatures of vt100 and pads you can't control go away, and your machine looks just like your Suns, HP's, uVaxen, etc (assuming you run X on those too). For a large part of the user community at Utah, their Apollo specific knowledge is simply "log in and type 'X'". (Actually, they generally also know how to unwedge the TCP server...) Now, I did say a B&W DN3000 with 4 meg or more of memory. X runs nowhere near as fast as the DM, and we've found that on older Apollos the performance isn't quite acceptable; but on DN3000's it's OK. This really isn't X's fault, the Apollo port has been around less than a year, vs. half a decade of careful tweaking for the DM. Perhaps this will even out when Apollo offically releases their X implementation. Cheers, jp
srt@CS.UCLA.EDU (06/09/87)
Robert Reed writes:
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 can do things with an Emacs package driving the UNIX dbx debugger that
would make users of debug drool with envy...
It seems to me that many of the people who are dissatisfied with the Apollos
are people who come from a one-window, command-line oriented operating
system like Unix. In that kind of environment, Emacs running sub-processes
is a dream come true, because it gives you a kind of multi-window
functionality. That comes for free on the Apollos - you can liberate
yourself from this kind of one-window thinking.
You can't simply look at the Aegis command-line interpreter independent of
the environment it operates in. Sure, if you want to fire up your Apollo
with one window and treat it like an extremely expensive workstation, you
are going to be dissatisfied with the environment. That's the wrong way to
use it. You don't need to run your editor and your debugger in the same
window. Run them in different windows and move between them however and
whenever you want. Share information, cut and paste, etc.
Much of the functionality of the C-shell isn't needed on the Apollos. I
rarely use the history functions (!!, etc.) on the Apollos because "Again"
and C&P are so much handier, and I'm sure there are other examples.
This argument has degenerated from a discussion of the command-line
interpreters on the Apollo to a comparison of Aegis commands to other
operating systems on other machines. I personally don't feel there is much
to be gained from this discussion, since these things tend to be a matter
of religion and personal biases.
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...
I don't think the DM editor is a joke, though it obviously is not nearly as
flexible as a powerful Emacs. Many of the most common editor functions are
supplied in the DM, and the most important customizations can be handled
(key binding, macros). It is annoying not to be able to write
paren-balancing or "electric-C" mode, but I think Apollo made the right
choice in providing a simple, extensible and blindingly fast text editor
rather than trying to implement some kind of mega-editor in an attempt to
please everyone.ram-ashwin@YALE.ARPA (Ashwin Ram) (06/09/87)
> Date: Mon, 08 Jun 87 23:28:17 PDT > From: srt@CS.UCLA.EDU > > Robert Reed writes: > > 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... > > I don't think the DM editor is a joke, though it obviously is not nearly as > flexible as a powerful Emacs. Many of the most common editor functions are > supplied in the DM, and the most important customizations can be handled > (key binding, macros). It is annoying not to be able to write > paren-balancing or "electric-C" mode, but I think Apollo made the right > choice in providing a simple, extensible and blindingly fast text editor > rather than trying to implement some kind of mega-editor in an attempt to > please everyone. I totally disagree. You're thinking of Emacs as a "single window terminal editor", for which case your arguments hold. Imagine, however, that the DM was one unified Emacs, each DM window being like an Emacs window but without the dumb terminal restrictions, the DM command window being the minibuffer, and so on. You still get cut and paste between windows, you still get independent shells running in independent windows, you still get input pads to those shells, and the rest of the things you and I both love. But you also get different Emacs-like modes in those windows, customizable keys *and* keymaps, local/mode-specific key bindings, extensibility (the DM command language is surely a joke), electric modes, and so on. You get an Emacs running directly on the graphics of the Apollos, utilizing the full capabilities of these slick machines, not one you have to laboriously start up in a vt100 window. I think this can be blindingly fast without sacrificing *real* editing facilities. I don't think the DM editor even satisfies novice text entry. It doesn't even have word wrap at the end of the line, let alone a decent undo function. -- Ashwin Ram -- ARPA: Ram-Ashwin@yale UUCP: {decvax,linus,seismo}!yale!Ram-Ashwin BITNET: Ram@yalecs
ram-ashwin@YALE.ARPA (Ashwin Ram) (06/09/87)
A point I'd like to clarify about my message -- I wasn't making a Unix vs. Aegis argument, but a DM vs. Emacs one. I was only claiming that it would be real nice if the DM editor *was* Emacs, suitably enhanced to take advantage of the Apollo workstation. As far as Unix vs. Aegis goes, there are some features of Unix that I like (and use), but if I were forced to use one or the other exclusively, I'd go for Aegis. I think it would be a pity if Apollo abandoned Aegis completely. The current setup -- primarily Aegis, but allowing me to use some Unix stuff where it's better or more familiar -- suits me (as a user, not a system programmer) just fine. Of course, it would be nice if some of the Unix stuff that people liked could be integrated into Aegis (like TEST(1) vs. EXISTF, APROPOS, upper/lower-case filenames, etc., at the user level, or like cleaning up PGM_$ARGs at the system programmer level). -- Ashwin.
bobr@zeus.UUCP (06/10/87)
In article <8706090628.AA29741@zeus.CS.UCLA.EDU> srt@CS.UCLA.EDU writes:
It seems to me that many of the people who are dissatisfied with the
Apollos are people who come from a one-window, command-line oriented
operating system like Unix. In that kind of environment, Emacs running
sub-processes is a dream come true, because it gives you a kind of
multi-window functionality. That comes for free on the Apollos - you
can liberate yourself from this kind of one-window thinking.
Give me a break! I am quite familiar with windowing systems, their
strengths, and their weaknesses. One common failing of windowing systems is
that there is no choice but to treat each window as a separate virtual
terminal with a completely different environment. With no context,
everything must be specified in a fully qualified form. While running Emacs
with multiple windows, a context is established and shared among the
subwindows managed by Emacs. Functionally, this is no less a windowing
environment than the "true windows" provided by the DM, but in some
respects, it is more. This shared context can provide a level of
cooperation among windows that is not easily obtained in the DM windows
model.
You can't simply look at the Aegis command-line interpreter independent
of the environment it operates in. Sure, if you want to fire up your
Apollo with one window and treat it like an extremely expensive
workstation, you are going to be dissatisfied with the environment.
I normally have a minimum of four windows running. One contains an emacs
process with up to five or six separate panes. One is used for compiling
and running programs (I still haven't been able to solve the AEGIS bug which
causes some Emacs subprocess support to hang). These first two tile the
entire screen (excluding the DM command line). I also have a window for the
debugger, though I would rather run this as one or more panes in the Emacs
window. A forth window runs /com/sh, because /bin/csh still has some bugs
in it that prevent some programs from running properly. Running them under
/com/sh seems to alleviate the problems. As I said in my previous post, I
generally will work a system to its limits. I have not ignored the
capabilities of multiple windows, but I have discovered their weaknesses.
You don't need to run your editor and your debugger in the same window.
Run them in different windows and move between them however and whenever
you want. Share information, cut and paste, etc.
Consider the advantage of running the debugger as a subprocess of your
editor. The most obvious advantage is simple navigation about a multi-file
program. I don't need to type "env MCHAN_C\create_process\" to get to that
context for debugging. I just "^X^Gcreate_process^J" which takes me right
there. I can brouse the file easily without concern for line numbers. I
don't need to guess at line numbers and have "env" tell me that such and
such a number doesn't exist. When I find the line I want to breakpoint, I
have a function key mapped to "ESC-Xdbx-break^J" which computes the line
number and feeds a command to dbx to actually place the breakpoint. Other
function keys have been similarly mapped to functions for single stepping,
printing values and continuing to the next breakpoint. When I discover a
bug, I'm generally right at the place I need to be to fix it
Multiple DM windows offer no advantages over this method of debugging. It
goes without saying that I do have another window which is actually running
the program I am debugging.
Much of the functionality of the C-shell isn't needed on the Apollos. I
rarely use the history functions (!!, etc.) on the Apollos because
"Again" and C&P are so much handier, and I'm sure there are other
examples.
"again" and "cut and paste" are a bearly adequate replacement for csh
history functions. The problem is interposed program output, which causes
command lines to be scrolled off the page, requiring a lot of keystrokes to
find an reexecute commands. A better solution than either of these is the
technique used in the ksh where simple key sequences pan back through the
history file, selecting those lines which were specifically entered as
commands. I'd rank the csh second in usability of this function and the DM
last.
I don't think the DM editor is a joke, though it obviously is not nearly
as flexible as a powerful Emacs. Many of the most common editor
functions are supplied in the DM, and the most important customizations
can be handled (key binding, macros).
I disagree that the DM provides facilities for performing the most important
customizations. It provides facilities for supporting the most easy to
implement customizations, i.e. simple string replacements. There are some
important things that can be done, such as binding SHELL to /etc/start_csh,
but the lack of conditionals and parameters means that lots of simple
functions which are easy to produce in other macroprocessors are impossible
to do in the DM.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKslade-stephen@YALE.ARPA (Stephen Slade) (06/10/87)
Much of the functionality of the C-shell isn't needed on the Apollos. I
rarely use the history functions (!!, etc.) on the Apollos because
"Again" and C&P are so much handier, and I'm sure there are other
examples.
"again" and "cut and paste" are a bearly adequate replacement for csh
history functions. The problem is interposed program output, which causes
command lines to be scrolled off the page, requiring a lot of keystrokes to
find an reexecute commands. A better solution than either of these is the
technique used in the ksh where simple key sequences pan back through the
history file, selecting those lines which were specifically entered as
commands. I'd rank the csh second in usability of this function and the DM
last.
Note: the DM's "undo" command serves exactly this function when typed to
an input pad. This is usually much more convenient than history hacking
or "again" with cut and paste. In a departure from accepted practice, I
shall refrain from expressing any deep sentiments about adherents of the
UNIX user interface beyond those implicit in the following verse.
"Eunuchs, abortive Platonists and priests
Speak always very wisely about love."
- Theodore Spencer, An Act of Life (1944)
--Stephen Slade
-------benoni@ssc-vax.UUCP (06/11/87)
In article <8706090628.AA29741@zeus.CS.UCLA.EDU>, srt@CS.UCLA.EDU writes: > Much of the functionality of the C-shell isn't needed on the Apollos. I > rarely use the history functions (!!, etc.) on the Apollos because "Again" > and C&P are so much handier, and I'm sure there are other examples. Totally false!!!!! Alot of our users started that way and hated it. It requires *mousing* and *window scrolling* that is tedious and time consuming. The c-shell is not only faster but contains many more practical benefits. > I don't think the DM editor is a joke, though it obviously is not nearly as > flexible as a powerful Emacs. The DM editor is a joke. It was built for non-computing types that ocassionally log on and won't have to learn or remember anything. Amazingly, within one group, four people started out using the DM. They all gave it up in favor of VI. Reasons : * documentation(!!!) * the DM deals terribly with CONTROL characters * balancing symmetrical characters * macros * ab * ability to set modes * VI is everywhere, DM editor is only on Apollo Even some of the Apollo developers seem to distance themselves from the DM editor. A couple of us once got into a discussion about the merits of the DM editor and VI and they had to admit VI was the more powerful editor. Emacs provides even nicer features and am looking foreward to using it. Speaking of Aegis consistency - ACL name1 => gives the acls for the named file or directory ACL name1 name2 => clones the acls of name2 on name1 Why didn't they write a CPACL for copy acl. People munge their files and directories by thinking they are going to get the acls for two objects.
hwarkentyne@watdragon.UUCP (06/12/87)
In article <1290@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >In article <8706090628.AA29741@zeus.CS.UCLA.EDU>, srt@CS.UCLA.EDU writes: >> Much of the functionality of the C-shell isn't needed on the Apollos. I >> rarely use the history functions (!!, etc.) on the Apollos because "Again" >> and C&P are so much handier, and I'm sure there are other examples. > >Totally false!!!!! Alot of our users started that way and hated it. >It requires *mousing* and *window scrolling* that is tedious and >time consuming. The c-shell is not only faster but contains many more >practical benefits. I wrote software on an Apollo for two years and never had a problem retrieving previous commands using Aegis. By putting a "hold" on the input window and pressing the "undo" button, I could easily recover whole sequences of commands and inputs for editing and/or repetition. No mousing and only minimal window scrolling is needed. I found this method much easier than using the history capability of the c-shell. Anyway, whether or not Mr. Ditzel finds Aegis deficient with respect to retrieving previous commands, I found it extremely useful and would jump at the chance to work again on an Apollo in an Aegis environment. Ken Warkentyne
nazgul@apollo.uucp (Kee Hinckley) (06/13/87)
In article <1819@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes: > "again" and "cut and paste" are a bearly adequate replacement for csh > history functions. The problem is interposed program output, which causes > command lines to be scrolled off the page, requiring a lot of keystrokes to .... One of these days I will get around to posting all of my keydefs (this sounds simple, but actually they are split up so different ones get loaded on different machines). Anyway. In the meantime here is my again key. I still use ! in the csh for recent commands, but this is in some ways more powerful. kd R2 twb -t;au;twb -b;twb -r;\%[%@#>=-$D:B][0-9 -=S$]?*@&'Key: '\; / /;ar;dr;tr;xc AGAIN_BUF;pb;tb;tl;ti;tb;tr;xp AGAIN_BUF; twb -b;pb;tb;tr ke kd R2U ke kd R2S twb -t;au;twb -b;twb -r;\%[%@#>=-$D:B][0-9 -=S$]?*@&'Key: '\; / /;/ /;dr;tr;xc AGAIN_BUF;pb;tb;tl;ti;tr;xp AGAIN_BUF;tr ke The first version gets the command, the second gets the arguments. In both cases it prompts for a wildcard to match on the command line. Just pressing return will result in the last command. They key thing to change here is the contents of the regular expression in []s. These indicate the first 2 characters of your prompt. If you only ever have one prompt then you could just say \%ab?*...\ or some such, but usually I have multiple environments and this is set up to work in all my shells, DSEE, the debugger, and a number of other environments. For instance, let's say you wanted to take care of the Aegis shell (sigh) and DSEE. Then you would say '[$D][ S]' Enjoy. Oh well, while I'm at it. Here are my window setup keydefs for a BW DN3000. (000,000)dr;(000,063)idf (065,000)dr;(671,496) wdf 1 (673,000)dr;(1279,496) wdf 2 (065,498)dr;(671,994) wdf 3 (673,498)dr;(1279,994) wdf 4 (065,000)dr;(671,496) wdf 5 (673,000)dr;(1279,496) wdf 6 (065,498)dr;(671,994) wdf 7 (673,498)dr;(1279,994) wdf 8 kd NP7 twb -l;dr;(065,000)wg;twb -r;twb -b;dr;(671,496)wg;tl ke kd NP4 twb -l;dr;(065,000)wg;twb -r;twb -b;dr;(671,994)wg;tl ke kd NP1 twb -l;dr;(065,000)wg;twb -r;twb -b;dr;(671,496)wg;twb -l;twb -b;dr;(065,994)wm;tl ke kd NP8 twb -l;dr;(065,000)wg;twb -r;twb -b;dr;(1279,496)wg;tl ke kd NP5 twb -l;dr;(065,000)wg;twb -r;twb -b;dr;(1279,994)wg;tl ke kd NP2 twb -l;dr;(065,000)wg;twb -r;twb -b;dr;(1279,496)wg;twb -l;twb -b;dr;(065,994)wm;tl ke kd NP9 dr;(1279,000)wm;twb -l;twb -b;dr;(673,496)wg;tl ke kd NP6 dr;(1279,000)wm;twb -l;twb -b;dr;(673,994)wg;tl ke kd NP3 dr;(1279,000)wm;twb -l;twb -b;dr;(673,496)wg;twb -r;twb -b;dr;(1279,994);wm;tl ke This will set up your screen psuedo-tiled (which in my mind is better than tiled, but...) +-----+-----+ I| | | C| | | O+-----+-----+ N| | | S| | | +-----+-----+ With the number keys used to put windows in their places according to which keypad key you press. Note that the movement commands don't *always* work, in particular DSEE can only be placed with them on the right hand side. And use these to get things in and out of Icons (or invisible windows) without using the mouse. You either type the name of the window or a group (created with ^G). kd ^G wgra @&'Group: ' ke; # Add to group #kd ^E wi -w @&'Group: ' ke; # Make visible #kd ^W wi -i @&'Group: ' ke; # Make invisible kd ^W icon -i @&'Group: ' ke kd ^E icon -w @&'Group: ' ke Enough for now. -kee -- UUCP: {mit-erl,yale,uw-beaver}!apollo!nazgul ARPA: apollo!nazgul@eddie.mit.edu I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
benoni@ssc-vax.UUCP (06/15/87)
In article <2915@watdragon.UUCP>, hwarkentyne@watdragon.UUCP writes: > By putting a "hold" on the input window and pressing the "undo" > button, I could easily recover whole sequences of commands and > inputs for editing and/or repetition. > No mousing and only minimal window scrolling is needed. > I found this method much easier than using the history capability > of the c-shell. True. You can backtrack and *that* is useful but by no means an adequate replacement for the csh history and command line editing features. Somehow '!v' (= vi anyfile.c) seems relatively easier than searching "whole sequences of commands". The previous example given however was extolling the virtues of "again" something i find of limited use because of the scrolling and mousing. A particularly nice feature available in csh is upon logging in to be able to see what your last 25 or so commands were the last time you were logged on - i am sure with some hacking Apollo's DM might be able to replicate this - but you will never catch me trading in csh for the weaker DM. The point being the csh already has these type of things built in and i would prefer to write scripts that extend csh to my needs AND THE SCRIPTS ARE *PORTABLE* TO OTHER *NON-APOLLO* MACHINES.
krowitz@mit-kermit.UUCP.UUCP (06/15/87)
I *would* be nice to be able to have portable display manager scripts,
but let's face it, there are no two vendors which use the same display
manager today. X-windows will be available from many vendors in a year
or so, but it is currently not a product.
I'm not certain what all the debate about the DM vs. csh history feature
is about ... The DM operates just as well in a BSD4.2 window as in an
AEGIS window. I use whichever feature (DM vs. !!) is more convenient at
the particular moment. I think we have to make the distinction between
what features a display manager needs to have and what features the command
processor (the shell) should have.
-- David Krowitz
mit-erl!mit-kermit!krowitz@eddie.mit.edu
mit-erl!mit-kermit!krowitz@mit-eddie.arpa
krowitz@mit-mc.arpa
(in order of decreasing preference)