Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!apollo!mishkin From: mishkin@apollo.uucp (Nathaniel Mishkin) Newsgroups: comp.unix.wizards Subject: Re: How good is Apollo UNIX? (was: O'pain Software Foundation: (2)) Message-ID: <3ce957a3.13422@apollo.uucp> Date: 27 Jun 88 14:20:00 GMT References: <610@quintro.UUCP> <2038@ssc-vax.UUCP> Reply-To: mishkin@apollo.com (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Lines: 83 In article <2038@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >in article <610@quintro.UUCP>, kts@quintro.UUCP (Kenneth T. Smelcer) says: >> Despite their reputation, Apollo has been doing a fairly good job >> in the past few years of integrating Unix into their environment. >I tend to agree that things have been better...however that doesn't make >them good or even marginal. >I tend to dislike the offering of two Unix systems on one machine. You >end up with three operating systems (including Aegis) and YOU HAVE TO >USE AEGIS whether you want to or not (SR 9.7). The simplest example of >this is with tar (to quote their man page) : [to rewind or retension]"use >the command /com/rbak with -reten or -rewind" Another simple example >is ANY sort of system administration command, they all live >on the Aegis side and bear no resemblance to Unix. I don't like multiple operating environments either, but we didn't exactly get to pick. We could have "merged" the functionality, but before you suggest that, please do a close analysis and tell me how many program will break if not modified. (I don't really want much to hear about how close System V and BSD really are. They're not. Sure, they can be merged if you don't care about breaking some unspecified set of programs.) Also, let's not exaggerate here -- we didn't "end up with three operating systems". I don't care what the marketing brochures say -- we have ONE operating system that supports the sum total of the BSD services, the System V services, and the services that Apollo has defined. All these services are available from all programs. There are some services both BSD and System V give the same name, yet the services behave slightly differently. To cope with this, every process has a flag that determines whether the services in question get BSD behavior or System V behavior. It's gross, but it's just not that big a deal and there's not a lot of duplication of code. As far as the fact that you have to use /com/rbak to retension a tape, I can't tell whether the "/com" offends you, or the "rbak" offends you or whether you really want to be able to use "mt retension" or what, but it hardly seems like a big deal. At the forthcoming software release, we have restructured the software distribution to be more Unix culturally compatible. All the tools that don't come with BSD or System V but that are needed to maintain an Apollo system are in /etc or /usr/apollo/... As far as system administation goes, I'm sorry if you think the way to maintain a network of 1000s of users is by editing and distributing /etc/passwd. I happen to think that tools that do similar operations in a control, robust, and distributed fashion are the way to go. Apollo is in the business of creating such tools. Again, I can't tell whether the fact that some tools happened to live in /com is the problem, or whether you just object to the idea of doing certain system administration function via tools (or whether just Apollo is not allowed to make new tools and call them extensions to Unix.) >one more aegis note : >when Apollo went to SR9.5 they introduced an ingenious bug in there >ACL command ... Since their current Unix (SR9.7) depends on >access control lists (ACLS) this command is frequently used >for system administration ... >Interestingly enough some people could also get the ACLS of the root >directory easily by giving ACL a wildcard option...at 9.5 Apollo reacted >to some Usenet people that trashed their systems using ACL...now they >put the disclaimer "DO NOT, HOWEVER, DO $ acl /... (anything) AS THIS >MAY RENDER YOUR NODE UNUSABLE." Thanks for making this bug in our software more widely known so that people will know to avoid it. Give me a break -- nobody else has ever had a similarly serious bug in their software? What does it have to do with how well Apollo's do Unix? >We find the mapping between Aegis and Unix is less than perfect and on occasion >we wind up living in a permissions no-mans land...where a user account >may be myseriously owned by lpr or some such nonsense...Apollo has two >kludges to repair this ...flush_cache and fix_cache. Fixed in the forthcoming software release in which ACLs and Unix-style protection have been more sensibly integrated. We continue to believe that the flexibility offered by ACLs is a good thing. The changes we've made were to make it the case that if you never wanted or used the flexibility, you'd get *exactly* the Unix protection model without the kludginess to which you refer. -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com