Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!mips!daver!tscs!tct!chip
From: chip@tct.uucp (Chip Salzenberg)
Newsgroups: comp.unix.sysv386
Subject: Re: Why DEC chose SCO UNIX
Message-ID: <277916E3.2042@tct.uucp>
Date: 26 Dec 90 21:32:19 GMT
References: <2777E87B.6392@tct.uucp> <29027@usc> <29029@usc>
Organization: Teltronics/TCT, Sarasota, FL
Lines: 89

According to annala@neuro.usc.edu (A J Annala):
>In article <2777E87B.6392@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>>Well, of course it won't run VMS.  VMS is coded in VAX assembler.
>
>My friends tell me most of VMS is coded in a DEC proprietary language
>called BLISS.  BLISS exists for PDP-11's, PDP-10's, and VAXen -- DEC
>could have chosen to write a new BLISS compiler for the 80386 -- but
>that is not what happened -- instead, DEC adopted SCO UNIX for their
>new machine.

Um, okay.  I've also been informed by Thomas Breuel that significant
portions of VMS are written in FORTRAN.  So to port VMS to the 386,
you'd have to translate all the assembler code, the BLISS language
support and the FORTRAN language support to the 386.  No small job,
even for DEC.

>Moreover, in the process, DEC abandoned it's own ULTRIX 
>(DEC proprietary version of UNIX) in order to adopt SCO UNIX.

SCO UNIX has ready support for *multiprocessing* (SCO MPX).  ULTRIX
doesn't.  I'll bet that this consideration was probably the most
important one.  This advantage is utterly unrelated to any security
issues.  (Also, ULTRIX hasn't yet been ported to the 386; such a port
would likewise be no small job, though infinitely easier than VMS.)

>Living within C2 guidelines is causing us no real grief.

Congratulations.  You're one of the few and fortunate.

>What more do you want from SCO UNIX?

I've enumerated the problems with C2 before.  To repeat some of them:

1.  User info is spread out.  Besides /etc/passwd, you must have a file
    /tcb/files/auth/<first letter of user>/<user>.  Some of the fields
    in the auth file duplicate fields in /etc/passwd.  So forget using
    vi on /etc/passwd.

2.  User and group identities determine privilege at the kernel level.
    For example, user "chip" may be able to run a setuid-root program,
    while user "steve" cannot.  This is a maintenance nightmare.

3.  The C2 security (as described in #2) can be "relaxed", but not
    disabled.  That is, the default kernel permissions can be broadened
    from their fascist defaults, but the kernel is still a C2 kernel.
    So the administrative headaches are still there.

4.  There are lots of "databases" in /etc/auth that figure in system
    security -- i.e. they get in the way.  For example, to add a new
    shell type in /usr/lib/mkuser, it's necessary to edit the secure
    files database /etc/auth/system/files.  When you add a new terminal,
    including a pty, it must be in /etc/auth/system/ttys.  Etc.

4b. C2 breaks automated system administration scripts.

    Our application had a program to create a new user.  That program
    doesn't work any more.  Now users have to run the sysadmsh to
    create new users.  We took great pains to have a consistent user
    interface in our system; the use of sysadmsh blows that strategy
    out of the water.

    Yes, we could write a new program using the new library routines.
    But why should we have to?  Whatever happened to that watchword
    of Unix System V, "portability"?

    The addition of new ttys is another example.  Each tty must be in
    the tty database before it can be used for logins.  This "feature"
    breaks the installation scripts we used for our application.  Yes,
    we know about /tcb/bin/ttys_update.  But we object to the fact that
    we need to know about it and we need to change our code to use it.

To quote Ronald Khoo:
================================================================
> Here is another place where SCO have made a serious mis-assumption.
> They seem to have assumed that "tradition" is the only concern of Unix users.
> It's not simply for a veneer of "traditional" behaviour that we want to
> be able to do /bin/rm -f /tcb, remember that whole Unix way of
> doing things is by tying programs together in an ENVRONMENT.
> 
> If you break this environment, people who only use integrated applications
> like MS-DOS users will be fine, but the rest of us will suffer (read: find
> another vendor) because OUR SYSTEMS WON'T WORK ANYMORE.
================================================================

Clear now?
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
"Please don't send me any more of yer scandalous email, Mr. Salzenberg..."
		-- Bruce Becker