Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-spam!sri-unix!hplabs!hp-sdd!ncr-sd!ncrcae!ece-csc!uvacs!edison!steinmetz!barnettb From: barnettb@vdsvax.uucp (Barnett Bruce G) Newsgroups: net.unix-wizards Subject: Re: Seeking a Development Environment (Sun?) Message-ID: <959@kbsvax.steinmetz.UUCP> Date: Tue, 28-Oct-86 17:36:47 EST Article-I.D.: kbsvax.959 Posted: Tue Oct 28 17:36:47 1986 Date-Received: Thu, 30-Oct-86 22:35:32 EST References: <4254@brl-smoke.ARPA> <935@kbsvax.steinmetz.UUCP> <173@umix.UUCP> Sender: root@steinmetz.UUCP Reply-To: barnettb@steinmetz.UUCP (Barnett Bruce G) Organization: General Electric CRD, Schenectady, NY Lines: 107 In article <173@umix.UUCP> paul@umix.UUCP ('da Kingfish) writes: >The idea that Apollo's Unix is an "emulation" or a "layered product" >(like Eunice, for example) is really getting to be tiresome, and is a >canard. I sorry you feel that I am spreading false and malicious reports. But I have tried to be as accurate as I can be, especially since I haven't had an Apollo machine in front of me for since the beta release of Domain IX. Because of this, if I have erred, I have tried to err in favor of Apollo. (But I can always count on the Net to correct my errors :-). But I cannot think of a better word than emulation to describe a software product that: 1. Is optional. (or was at the time) 2. Is layered on top of the native operating system (AEGIS). 3. Is missing functionality that every version of Unix has. (Functionality in an area I consider essential) 4. That does not behave EXACTLY the same way as Unix does. (I realize that unixes differ, but see below). 5. That handles system administration information in a form unlike any other version of Unix. 6. That is derived from a proprietary operating system instead of a standard AT&T release. I know it's tiresome, but I am tired of people who tell me Aegis/AUX IS REAL Unix. How can it be? Now emulations have good and bad points. Some functions are faster, some are slower. Some system administration tasks become easier, some harder. Apollo's is most likely the best emulation around. But then, they have the ability to change the underlying operating system, when necessary. My main point is that I do know KNOW where the areas of incompatibility exist. I know they are there. If I believed people who told me that Aegis WAS Unix, I could get myself into trouble. One of the most impressive features of Unix is the ability to monitor, tune, and extend the operating system, EVEN IF YOU DON'T HAVE THE SOURCE CODE! For instance, if I wanted to write a program that would tell me what files were currently being accessed, and what disk they were on, whether they were locked, being waited for, been modified, is shared by more than one process, the inode number, size, etc. etc. then it would be a trivial task. I wrote such a program when I went to AT&T's course on Unix Internals (Excellent course! I KNEW all those strange files is /usr/include/sys were good for something! :-) I would open file `/vmunix' (or `unix' or ...), use nlist(3) to locate the whereabouts of the system data structures, then open and seek `/dev/kmem' and using the data structures in /usr/include/sys/..., get the information I need. But AUX doesn't support nlist(3) or `/dev/kmem', so this can't be done. --> AND I WOULDN'T KNOW THIS UNTIL I TRIED. <-- The point is, if someone is using a particular technique on a UNIX system, than I KNOW it can be done on a Sun or Vax. Also, if someone develops some clever technique (like device drivers that can be re-loaded dynamically, i.e. without rebuilding the operating system), it will most likely be developed on a Sun or Vax. I LIKE this feeling of confidence. I LIKE being able to use programs like William LeFebvre's top(1). I know UNIX and know that I can write some very powerful programs if the need comes up. I don't feel comfortable that a unix-look-alike will behave the same way as a UNIX operating system. I would never know when a program off of USENET would work, and when it wouldn't. I like being able to use the latest techniques discussed at UNIX conventions. Please don't tell me DOMAIN/AEGIS/AUX is REAL unix. I'm tired too. >As I mentioned above, they do >have a different kernel, with their own OS interface. That can be >risky to do, when other vendors trade on the safety of adherence to the >beliefs of the past, and other signs of orthodoxy, like /dev/kmem. > >Apollo does "hide" some internals, in that you can't grope through kmem. >Sometimes information hiding is OK, and in some contexts that is considered >to be desirable. . . >And there is no /dev/kmem. (Although I think that is >definitely a step in the right direction ... i.e., the 1980s.) Like 1984? (Sorry, couldn't resist. :-) But seriously, how can it be desirable to not have /dev/kmem? You could always prevent access from everyone except root. You could even delete the file, I guess, and change/delete all programs that access it. Or you could fix the location of every data structure, and never change the size/location of the structures in the operating system. But *IF* they change, you have no method of verifying the *real* locations. Now, I'm not disagreeing that there are times when hiding information is desirable. But I can't see your point that eliminating it for EVERYBODY is a step in the right direction. It seems to me to be a step backwards. >paul@umix.cc.umich.edu - Bruce Barnett -someone who never believes managers who say: `We will never port this product'