How good is Apollo UNIX? (was: O'pain Software Foundation: (2))

[Nathaniel Mishkin]

In article <2038 at ssc-vax.UUCP> benoni at ssc-vax.UUCP (Charles L Ditzel) writes:
>in article <610 at quintro.UUCP>, kts at 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 at apollo.com