Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!ssc-vax!benoni From: benoni@ssc-vax.UUCP (Charles L Ditzel) Newsgroups: comp.unix.wizards Subject: Re: How good is Apollo UNIX? (was: O'pain Software Foundation: (2)) Message-ID: <2038@ssc-vax.UUCP> Date: 24 Jun 88 06:05:14 GMT References: <610@quintro.UUCP> Organization: Boeing Aerospace Corp., Seattle WA Lines: 64 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. > The older Apollo releases (pre-9.0) had real problems, but the current > release (9.7) is quite Unix compatible (for both SysVR2 and BSD 4.2). > I don't know about IBM and DEC, but Apollo has definitely demonstrated > their commitment to Unix, and to the unification of the various flavors > of Unix into a common platform. 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. Incidentally the "r" and "u" options of tar are not supported by the Apollo tape drivers. Tar on Apollo winds up only being able to create new archives to tape, the block length is fixed at 10240 bytes for /dev/rmt8 (and /dev/rmt12)and 512 bytes for /dev/rct8(and /dev/rct12). As a result if you want to change the block length you wind up having to use an Aegis command (edmtdesc). on a aegis sidelight... The Aegis side of tar is a command called "rbak". Apollo sells their system with these 5 1/4 floppies and you can use the rbak command to write to the floppy however they have a wonderful disclaimer in their docs cautioning you that error detection (during reads and writes) with rbak and floppies is "poor". They tell you not to place any critical or unrecoverable data on the floppy. (I suppose you can use their mtvol command but it winds up having a different disclaimer about dmtvol being necessary...and i have always guessed that they might have forgot to put in the above. Still I have always wondered why they charge for their floppy systems?) 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 ... anyway ACL has dual purposes 1) ACL gives you the access control list for a file/directory 2) ACL also allows you to give a target file/directory a sources ACLS. 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." 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. Actually Apollo still has a ways to go ... there are lots of differences (look at chmod on Apollo they've mucked with that too...something about enhancing Unix permissions by dis-allowing x only...) maybe SR10.0??? ----------------- Naturally My Opinions Are My Own and not my employers...