Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!alberta!calgary!freedman From: freedman@calgary.UUCP Newsgroups: comp.sys.apollo Subject: Re: AEGIS Vs UNIX Message-ID: <941@vaxb.calgary.UUCP> Date: Thu, 4-Jun-87 13:24:02 EDT Article-I.D.: vaxb.941 Posted: Thu Jun 4 13:24:02 1987 Date-Received: Sat, 6-Jun-87 10:09:05 EDT References: <870603192007.915098@HI-MULTICS.ARPA> Organization: U. of Calgary, Calgary, Ab. Lines: 230 Summary: best and worst of Apollos 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.