Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!fang!itd1!agq From: agq@itd1.dsto.oz (Ashley Quick) Newsgroups: comp.sys.apollo Subject: Re: How to modify the "kernel'? Message-ID: <1215@fang.dsto.oz> Date: 13 Sep 90 01:46:20 GMT References: <6881.26e59640@jetson.uh.edu> <25786@boulder.Colorado.EDU> <1802@tuvie> Sender: news@fang.dsto.oz Lines: 151 I have seen all the discussion about "modifying the kernel", etc, and wish to comment: 1. As a new comer to Apollos about 8 months ago, I have found the environment (DM) nice! Killing it for the sake of standards would be silly. *** HP/APOLLO PLEASE TAKE NOTE! *** Allowing interoperability with things like X is desirable, but I have found X to be YUK to use!!!. 2. We run PCNFSD here. It compiles without any problems, IF YOU GET HOLD OF THE SUN RPC SOURCE CODE. Something to note about PC NFS: PC NFS is plain ordinary NFS for a PC. So you need to run NFSD on your host (whatever flavour, SUN, VAX/VMS, etc). As the PC is a crummy little beast and does not know about user ID's, you need a special piece of software called the AUTHENTICATION SERVER, known as PCNFSD to do this special function. This is the thing that is supplied in source form ON THE PC disks when you by PC NFS from SUN. If we can compile and run it, anybody can. Dont bring up silly issues like this if you dont try very hard. (BTW: there is a bug in the SUN Supplied source code for PCNFSD which I posted a fix for a week or so back). I have found in testing that an Apollo DN3000 running SR10.2 performs as well as a SUN 3/280 for PC NFS file transfer. (Someday I will post about 10 pages of benchmarks of various NFS implementations.) PC NFS is NOT a big deal! 3. The first coding job I did was to write a device driver interface on a brand new DN4500. This machine was to be a divisional server and I found one day that all the files had been shifted on! I expected this to be a problem as the machine would not be "stable". On the contrary, the PBU_$ system calls allow a device driver to be loaded and unloaded under user controll. You really have to try very hard to crash a machine using this approach. Further, you dont need to reboot the machine every time you make a change, and (by trying a bit harder) you can debug a device driver (call side). [The interrupt side can be done by placing trace info into shared storage]. I was therefore able to develop device handling software without killing the node and affecting others. From this point of view, DOMAIN/OS is GOOD!!!!!! Why the UNIX crowd have not taken this approach bemuses me. 4. System software using the DOMAIN calls is easy to write. The calls also stand out in the code, making debugging / understanding a program easy. You really need to be a UNIX guru to follow some C programs. Example: Domain Mailbox calls WORK WELL!!!! Try using UNIX sockets! YUK YUK YUK YUK YUK!!!! DOMAIN/OS supports several different types of interprocess communication, and they work and they are simple to understand. If you want a brain-dead approach, you can still uses SYSV or BSD IPC as well. (Or all at once if you are a real masochist!) The whole approach to DOMAIN/OS system calls, by breaking them up into "manager" function makes it easy to write software. The whole O/S has had a lot of thought put into it. Writing it off as a crummy implemenation is being far too simplistic. Yes there are faults. EVERYTHING has faults. At least they can be either worked around or get fixed (eventually: SR10.1 print servers look like a good idea without enough development time). 6. Type managers (and typed files) are a great idea! Once again, you can set up special handling without putting user-specific handling into the OS (how do you debug it it its in the OS? Must be pretty hard!) Type managers allow the user to develop and debug (LINE BY LINE with DDE) special file handling systems without disturbing other users on the node or the network. Pretty clever, Eh? 7. Dynamically loaded libraries allow programs to be written with a dependance on a "balck box" module. That module can be changed without requiring a recompilation of anything which depends upon it. (Unless the interface changes, obviously). The use written libraries can then be set up (WITHOUT MODIFICATION) to be loaded at boot time and become available to everybody. Effectively, it is possible to EXTEND the OS. 8. There are some things where UNIX inter-operation does not work. There are not really too many, and lots of limitations are documented in the manuals. Take an objective look at UNIX some time. It has grown over the years and reeks of lots of undergraduate computing projects! What I am getting at is that the system calls and the utilities and the directory structure are all a big mixed up mess! It all seems to have had more bits tacked on without much thought, and definitely without a total SYSTEM approach. It is a lazy persons O/S from the ground up. The best thing that could happen to UNIX is to scrap it and start again. Unfortunately that will not happen, as UNIX seems to have become trendy. It is JUST LIKE THE IBM PC. A case of mediocrity wins by MIGHT not RIGHT. Sigh! (Apologies to IBM if that upsets them!) I also get the feeling that OSF/1 will end up some kind of horrible monster. Reminds me of the joke about the Elephant: a mouse designed by a committee. To ME, the best HP/Apollo could do is to add another compatibility type: SYSV, BSD and OSF/1. I suspect it wont happen, though. If the problems with the UNIX environments could be fixed, that might cure some gripes. Why is UNIX the way it is? Because MOST people (especially in Universities) have NOT idea about writing GOOD STRUCTURED code. [If you are in a university and take exception, so be it - but look at your undergrads... how good are they? Most would be OK but NOT GOOD]. I really dont think people are taught to take a black box [information hiding] approach to writing software, and that has shown up in UNIX due to its evolution. DOMAIN/OS reeks of being written by a group to a set of standards, and being designed from the ground up. Writing code in C is also part of the problem - it is just TOO easy to get away with TOO much in C. Sorry C hackers (yes, I have become one too, but at least I can be objective and say I do not like it a lot!), but C programmers tend to get lazy and that leads to crypography. I heard a guy from a military software contracting company say that you do not write programs in C, you cipher in it! Finally: remember: every UNIX is NOT standard. How many BSD 4.2's have YOU used and found that the MORE command behaves differently!!!!! Not to mention SYS5!!!!! PLEASE PLEASE PLEASE dont trot out the tired old line about UNIX being some kind of standard! It IS NOT. (It may become one by default [ie pressure of users]. That does not make it NICE to USE or PROGRAM under!). 9. It was the story that Apollo would not have continued if they were not taken over by HP. If that is so, we should give thanks for small mercies! 10.What is so good about SUN machines anyway? They run BSD or SUNOS, they have umpteen incompatible hardware platforms, their networking is NFS (sort of client / server rather than peers). They win by selling lots at good prices, not by any kind of O/S superiority! Yours in anticipation of a balanced viewpoint, Ashleigh Quick AGQ@dstos3.dsto.oz.au Defence Science and Technology Organisation, Salisbury, South Australia 5108.