Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!rphroy!caen!uwm.edu!ogicse!milton!uw-beaver!stowe.cs.washington.edu!pauld From: pauld@stowe.cs.washington.edu (Paul Barton-Davis) Newsgroups: comp.unix.sysv386 Subject: Re: Summary: What's wrong with SCO (long) Message-ID: <1991Apr17.210627.4517@beaver.cs.washington.edu> Date: 17 Apr 91 21:06:27 GMT References: <1991Apr14.022153.2099@emisle.uucp> <1991Apr16.183342.10185@compu.com> Sender: news@beaver.cs.washington.edu (USENET News System) Reply-To: pauld@cs.washington.edu (Paul Barton-Davis) Organization: Computer Science & Engineering, U. of Washington, Seattle Lines: 88 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- combinations, and Ctrl- is not the same as - 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 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 UW Computer Science Lab ``to shatter tradition makes us feel free''