Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-unix!sri-spam!ames!ucbcad!ucbvax!mit-kermit.UUCP!krowitz From: krowitz@mit-kermit.UUCP (David Krowitz) Newsgroups: comp.sys.apollo Subject: Re: AEGIS Vs UNIX Message-ID: <8706031707.AA21038@EDDIE.MIT.EDU> Date: Wed, 3-Jun-87 12:25:08 EDT Article-I.D.: EDDIE.8706031707.AA21038 Posted: Wed Jun 3 12:25:08 1987 Date-Received: Sun, 7-Jun-87 01:34:11 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 142 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)