Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!ut-sally!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (terry)
Newsgroups: comp.misc
Subject: Re: Doom and Gloom, as they say, revisited (computer market failures)
Message-ID: <219@wsccs.UUCP>
Date: 28 Feb 88 07:36:55 GMT
References: <1903@saturn.ucsc.edu> <1568@uhccux.UUCP> <19908@bu-cs.BU.EDU> <735@ddsw1.UUCP>
Lines: 63
Summary: asdf

In article <735@ddsw1.UUCP>, karl@ddsw1.UUCP (Karl Denninger) writes:
> In article <19908@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes:
> >This brings up an interesting point that most people miss.  The cost
> >of an 80386 machine is very comparable to the cost of a similarly
> >configured Sun 3/50.  Performance wise they're pretty close, too, but
> >in terms of software reliability the Sun UNIX is somewhat better than
> >Xenix or Microport.
> 
> Software reliability > Xenix/386?
> 
> This would be difficult... Since receiving our copy of Xenix/386, I have not
> had a single crash or other anomoly that could not be directly traced to
> hardware (we had a bad memory board, that doesn't count).  We've been
> running it full-bore now for about 3 months (Xenix V/386).

	You have Xenix/386?  While the tty drivers are better (the console
driver is *MUCH* better) than comparable "standard" systems, do _not_ argue
about software reliability in my presence.  All systems have bugs.  Try
typing

	vi -x

on an SCO system sometime.  I've told a number of people in their tech
support about it and they were very prompt in ignoring me.  If you have
a 386 system with a "smart" card, then you may have had some experience
with their "provisional" 286 release for 386 users.  If you updated from
2.1.3 to 2.2.x, you may have noticed that the size of the clist structs
went from 32 to 24.  You may also have noticed your "smart" board blowing
chunks all over /dev/kmem as a result of nobody being told (DMA boards tend
to do DMS in fixed sizes... one might even hazard to say sizeof(struct clist).

> As for compiler compatibility/reliability, well, I tell the software that 
> I'm a VAX and that we run System V and 95% of the time it works first shot.
> All the useful utilities and tools from the net (ie: ELM 1.7, uemacs, Jove, 
> pathalias, etc) worked right out of the kit.

[ A commercial for 386 boxes from Macro Computer Solutions, Inc. deleted]

And it doesn't do serial I/O the same and unless you dump you buffer to one
char, it blocks normal raw I/O differently and it handles the init process
"funny" when it comes to device permissions.  As for Jove (Johnathan's Own
Version of Emacs), if I'm not mistaken, it has a #define for Xenix.  Bad
example, guy, unless you are running old code, in which case it's a worse
example.  Xenix is based on System III, not V.  Yes, Paul, I know we argued
this at Uniform, but tell me, why then does it use /etc/ttys?  It may meet
SVID, but it isn't SysV.3 derived.


	I am not flaming SCO; the point is that all systems have problems.
and that one is not intrinsicly better than another because of "less bugs"
...as far as I'm concerned, there is no such thing as "less bugs".  I think
Jim's point was simply to point out that alternatives are available and to
plug his favorite machine.  I know I plug mine whenever I can, simply because
it is easier to manage techinal support if everyone is running my machine :-).
Lord knows that Jim's report came about as a result of someone plugging SCO...
I personally plug SCO.


| Terry Lambert           UUCP: ...!decvax!utah-cs!century!terry              |
| @ Century Software       or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'There are monkey boys in the facility.  Do not be alarmed; you are secure' |