Summary: What's wrong with SCO (long)

[Paul Barton-Davis]

I worked on ISC 2.0.2 and 2.2.[01] for about a year, doing device
driver work (well, actually adding a complete kernel subsystem to
support a 25MIPS RISC coprocessor with 16MB of RAM and its own
SCSI interface) as well as developing 10MB of custom software
including a "graphical" shell (as graphical as curses(3) gets) with
limited job control, oddles of shell scripts, and lots of
code that uses read-write optical drives. I wouldn't even try to
defend ISC - V/386, like all system V's, is not even close to the
most basic BSD offering, and ISC's support was awful. There are
serious bugs in the TCP/IP implementation (which despite claims to the
contrary, were still not fixed at the last release), and you should see
what they used to do in NFS when a client tries to do a mvdir (:-(((((

However, generally, it was a workable, fast-ish system that worked
reliably once you got used to a few significant problems.  As for SCO:

\begin{flame} I've been working on SCO for about 2 months (now
part-time and fading) The only good thing I have to say about SCO is
that they ship the device driver manual with the development system. I
don't know what Fred has been trying to do with his SCO system, but my
experience has been TERRIBLE. The whole V/386 thing is ridiculous -
the manual is full of Xenix references, and even the libs keep saying
"must be linked with the -lx option" (which links the xenix
libraries).  comp.unix.wizards has been talking a lot about bloated
code: SCO has *two* shared memory systems, and two semaphore systems
!!! The security stuff is a joke - who ever heard of an "expire"
option for users that can't be undone ? If it was called "lockout" -
OK. Then you find that root can just edit the relevant tcb file, and
you can get back in - the only way if you were setting up an account
and mistakenly expired the user ... The boot sequence sucks, although
at least they let you choose single user as it comes up, which ISC
does not. I have to sit in front of the system as it boots, which
might be normal for many systems, but if you're writing a driver and
reboot 30 times a day, its awful ... The csh is broken, the default
keyboard mapping is brain-damaged (by default they eliminate Alt-<key>
combinations, and Ctrl-<arrow key> is not the same as <arrow-key> -
try using emacs with that :-() and only root can reset the key mapping
for a multiscreen (surely the default file should apply to ALL
multiscreens, not just the console). The startup file problem ("xxx:
cannot execute") is ridiculous, and the documentation on kernel
rebuilds is awful (they supply all of AT&T's IDD tools, but fail to
mention their use, and providing a hack-and-a-half called "configure",
surely a candidate for the Unix program with the most confusing set of
option flags in existence). Looking through the "value-added
extensions", almost all fall into the "code bloat" category. They
changed fdisk from its DOS-style interface, even though its existence
is owed soley to DOS via the BIOS boot nightmare.

I want to add a general comment on V/386 systems: I'm getting REALLY
REALLY tired of the profusion of <some-company's-acronym>ix varieties.
I don't know quite how much work ISC, SCO, Esix, or anyone else has
done on the kernel, but its about time for these companies to sell
their stuff as additions to System V/386, not as my-xxx-ix/386. I know
that there's no obligation to be kernel-compatible, but one of the
attractions of V/386 systems is the plethora of cheap hardware that
can be hooked up them. I've been making a comfortable living out of
writing device drivers and other system software to use these things,
and I'm getting really tired of worrying about the day when

	SCO Unix/386 != Interactive Unix != ....

Most clients and other folk I know have one central question, as
evidenced on this list: what's the difference ? My responses to date
have been to stress that they all stem from the same AT&T System V/386
port, but have had a lot of stuff added, mostly as user processes and
commands, but a few kernel enhancements (and mindwarps) have been
added too. One day soon, they won't all be kernel-equivalent either,
as one company decides to go beyond replacing the disk driver (as ISC
did) or adding C2-Security (as SCO tried to do). Someone will decide to
change something more fundamental, and suddenly, there will be even
more significant differences than there are now.

I don't know how to fix this - the same thing has happended with BSD,
but maybe if it was stopped before it started ... wait, its already
started.

Enough ..
\end{flame}
\begin{summary}
I support the notion that for word-processing it might work, but for
systems programming and serious Unix users, its a joke.
\end{summary}



-- 
Paul Barton-Davis			<pauld at cs.washington.edu>
UW Computer Science Lab		``to shatter tradition makes us feel free''