Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helps!bigtex!james
From: james@bigtex.cactus.org (James Van Artsdalen)
Newsgroups: comp.unix.sysv386
Subject: Re: '386 Unix Wars
Keywords: sco unix interactive wars
Message-ID: <51537@bigtex.cactus.org>
Date: 21 Dec 90 09:51:17 GMT
References: <276d312d-8aecomp.unix.i386@point.UUCP> <33791527@bfmny0.BFM.COM> <2812@cirrusl.UUCP> <350@metran.UUCP>
Reply-To: james@bigtex.cactus.org (James Van Artsdalen)
Organization: Institute of Applied Cosmology, Austin TX
Lines: 29

In <350@metran.UUCP>, jay@metran.UUCP (Jay Ts) wrote:

> I am *scared* of SVR4!!  When/if my clients have to upgrade, they
> will have to add at least 4 Mb of memory and probably suffer a
> performance degradation as well.  (Someone please tell me this isn't
> really true!)

I recently used some of our test hardware on SysVr4 and discovered
that the interrupt handler latency (time from interrupt acknowledge to
reading from device) is better than the handler latency in SysVr3.
This isn't the whole story by any means, but it's a good sign.

Another feature is that the "sticky" bit doesn't appear to be needed
any more to avoid excess disk activity when a binary is started.  If
you run emacs twice in a row, there isn't any disk activity the second
time (if you have that much RAM).

The SysVr4 compiler isn't real bright (worse than SysVr3 I think), but
you can use gcc for production code.

> And it won't markedly improve the functioning of their existing
> software, either.

Well, what about job control, BSD-style line editing (I'm not sure
what BSD calls this), long file names, etc?  Something in there seems
useful.
-- 
James R. Van Artsdalen          james@bigtex.cactus.org   "Live Free or Die"
Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789