kts@quintro.UUCP (Kenneth T. Smelcer) (06/14/88)
In article <697@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: >Ron Natalie @ Rutgers notes: >> The Apollo systems I've been forced to use do such a poor imitation >> of UNIX that I have no wonder that you have problems with SVVS. > >A friend of mine who uses Apollo says the same thing as well. > > >In Apollo's defense, Nathanial Mishkin (mishkin@apollo.uucp) says: >> In at least some ways, SVVS as it is currently constituted >> thus stifles innovation. I think stifling innovation is something >> none of us want. > >Isn't it *wonderful* how people can make sunshine out of sh*t? :-) > This isn't the place for a "How good is Apollo Unix" war, but I just had to put my $0.02 in defense of Domain/IX. 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 have very few problems with programs from comp.sources.* (most run without any modifications), and I think they've done a decent job integrating SysV, BSD, and Aegis into a usable, coherent package. 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. As far as the SVVS is concerned, I'd be interested in hearing any details about the problems Domain/OS (also known as SR10) had passing the verification suite. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corporation - Quincy, Il. UUCP: att-ih!spl1!quintro!kts or {att-ih,uunet}!wucs1!wuibc!quintro!kts
benoni@ssc-vax.UUCP (Charles L Ditzel) (06/24/88)
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...
benoni@ssc-vax.UUCP (Charles L Ditzel) (06/24/88)
in article <2038@ssc-vax.UUCP>, benoni@ssc-vax.UUCP (Charles L Ditzel) says: > 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 meant wbak (i was thinking about another feature of rbak ...i was also reading the rbak man page at the time of writing) when I was writing the description the brain mis-fired :-). do a mental substitution of wbak for every ocurrance of rbak in the above. thanks. another Apollo Unix sidelight : in chmod - Apollo calls it a feature of Domain memory management, you need read permission to execute a file...okay...however if you type chmod 111 foo you wind up getting : -r-xr-xr-x owner Basically giving execute to the owner and anyone else you give read permissions. If you give it chmod 222 foo you will not get -w--w--w- rather you get : -rw-rw-rw So they also give read rights to the owner also. ------ Naturally my opinions are my own.
mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (06/25/88)
We have a DN3000 running DomainOS SR10 (4bsd flavor). Some things are still
unlike Unix (e.g., you create accounts through Apollos registries), but
there's no longer a /com directory of Aegis programs (yay!), but there is
a new /usr/apollo directory (boo!) where programs like rbak live, but it's
got a lot less than the SR9.x /com directory contained.
SR10 feels more like real Unix, but apollos are still apollos, and do certain
things differently, some better than Unix, some not.
Mike Khaw
--
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303mishkin@apollo.uucp (Nathaniel Mishkin) (06/27/88)
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
ronc@cerebus.UUCP (Ronald O. Christian) (06/30/88)
In article <3ce957a3.13422@apollo.uucp> mishkin@apollo.com (Nathaniel Mishkin) writes: >In article <2038@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >>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). > >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.) Seems to me the real problem is that Unix sits on top of AEGIS, not that two flavors of Unix were supported. Hell, the machine on which I am composing this, a Sequent Balance 21000, has BSD and SYSV modes, but the native OS is (mostly) BSD. Having the native OS being Unix rather than some proprietary operating system makes a *big* difference when you have a development environment with a couple dozen kinds of Unix boxes, a gaggle of Unix gurus, and no (0) AEGIS (for instance) gurus. The fact that you *must* learn and use AEGIS to use the Domains is one of the primary reasons we decided to purchase our workstations from one of Apollo's competitors instead. Never mind that AEGIS is better than Unix, that's not the issue. It's *not* Unix. BTW, anyone want a couple of Domain 3000's? We've been trying to unload them for some time now, but still no takers. Ron -- Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) {amdahl, pyramid, sun, unisoft, uunet}!cerebus!ronc Calling all Fujitsu Usenet sites! Contact cerebus!ronc or ronc@fai.com to establish uucp connection. -- Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) {amdahl, pyramid, sun, unisoft, uunet}!cerebus!ronc Calling all Fujitsu Usenet sites! Contact cerebus!ronc or ronc@fai.com to establish uucp connection.
benoni@ssc-vax.UUCP (Charles L Ditzel) (06/30/88)
in article <3ce957a3.13422@apollo.uucp>, mishkin@apollo.uucp (Nathaniel Mishkin) says: > > In article <2038@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: # 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/... The question was how good was Apollo Unix. Not how good was Aegis? A number of Unix functions do not perform well without Aegis...tar needs Aegis' rbak... > 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 Correct me if I am wrong but doesn't EVERY Apollo have a local registry (the functional equivalent of /etc/passwd) and yes I know that typical networks use master registry...but as far as I can tell you handout the same basic information .... I have no gripes against the tools used as long as their is a high degree of compatibility for Unix programs to function...unfortunately the /etc/passwd I am familar with on Apollos does not contain the encrypted password information...so if you had a Unix script that told you who had passwords by looking at /etc/passwd , it won't work.(Again I am talking SR9.7 and before... I don't know what the soon to be released SR10 looks like) >>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 ... .... > Thanks for making this bug in our software more widely known so that people > will know to avoid it. Give me a break -- WHOA! I didn't learn about the ACL bug from Apollo. Are you kidding? I have yet to see monthly bug reporting let alone any bug information... I learned about this from the 'net. A couple of burned users reported it back at 9.5 on Usenet. At SR9.7 and it still exists. > similarly serious bug in their software? What does it have to do with > how well Apollo's do Unix? Pre-SR10 Unix LIVES on ACLS. This IS the primary tool for finding out what your Access Control Lists are. Further followups should be posted to comp.sys.apollo .... ------------------------ Naturally, my opinions are my own.