Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!husc6!spdcc!tauxersvilli!alphalpha!nazgul From: nazgul@alphalpha.com (Kee Hinckley) Newsgroups: comp.sys.apollo Subject: Re: How to modify the "kernel'? Message-ID: <1990Sep13.155043.16104@alphalpha.com> Date: 13 Sep 90 15:50:43 GMT References: <6881.26e59640@jetson.uh.edu> <25786@boulder.Colorado.EDU> <1802@tuvie> <1215@fang.dsto.oz> Organization: asi Lines: 89 In article <1215@fang.dsto.oz> agq@itd1.dsto.oz (Ashley Quick) writes: > >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!!!. Agreed. However the DM is dead in the long term, the market has decided. There is one and only one correct solution - take the best of the DM and migrate it to X/Motif. And furthermore, make those fixes available to OSF, the X Consortium, etc.. Any other path relegates Apollo to the dustbins of forgotten operating systems. >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: J. Random User doesn't compile source code - they want working binaries, and they'll pay for them (if they have to). Any other solution won't fly. (Note that if you read this group you aren't J.R. User by definition.) >3. The first coding job I did was to write a device driver interface ... > From this point of view, DOMAIN/OS is GOOD!!!!!! > Why the UNIX crowd have not taken this approach bemuses me. Yep. So Apollo should move this technology to OSF/1, not just to their veresion, but to all versions. Port it and export it. That's the only way to win the system software game. >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. Debateable, but it doesn't really matter if it doesn't run on other machines. However if you really prefer "rws_$open" to "open" I would suggest using #define. :-) > 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!) Port it... >6. Type managers (and typed files) are a great idea! Once again, you ... >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. This one the Unix people have actually learned. However they see it as a way of saving disk space and memory, they haven't learned yet that if you use procedural abstraction instead of data abstraction you don't have to recompile. That will come, but it'll take time. >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. Documenting that things work doesn't really do anything to please the programmer who is trying to do something that ought to be simple (try hooking up a Telebit to an Apollo sometime. RTS/CTS?! 19.2?!). It's not that Apollo doesn't know about the problems, it's just that Apollo consistantly made the mistake of doing the advanced stuff without first covering the simple things. Now someone else's simple thing has one the war. If Apollo moves fast (and it encourages me to see the number of Apollo people working with OSF) they can get that advanced stuff onto OSF/1 and make it a standard there and then we won't see 10 years of work go down the tubes. > If the problems with the UNIX environments could be fixed, that > might cure some gripes. Apollo is the one company that really knows what those things are. Hopefully that expertise can be put to use. > Why is UNIX the way it is? Because MOST people (especially in > Universities) have NOT idea about writing GOOD STRUCTURED code. Debatable. I'd take BSD code over Bell Labs any day. >10.What is so good about SUN machines anyway? They run BSD or SUNOS, They sell. No one can beat them alone, but OSF offers a chance to beat them together. -kee -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 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.