Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!van-bc!jtc
From: jtc@van-bc.wimsey.bc.ca (J.T. Conklin)
Newsgroups: comp.unix.sysv386
Subject: Re: GNU compress/uncompress/zcat for ESIX Rev.D
Keywords: FSF, GNU, ESIX Rev.D, compress/uncompress/zcat. mtools.
Message-ID: <1293@van-bc.wimsey.bc.ca>
Date: 10 Jan 91 23:14:12 GMT
References: <1991Jan10.195147.6635@portia.Stanford.EDU>
Distribution: comp.unix.sysv386
Organization: SEAC Software Engineering, Vancouver, B.C., Canada
Lines: 36

In article <1991Jan10.195147.6635@portia.Stanford.EDU> fangchin@portia.Stanford.EDU (Chin Fang) writes:
>GNU compress/uncompress/zcat also allows you to configure the 
>buffer size as you deem fit (for ex. large buffer size for machines
>with lots physical memory).  That alone motivated me to switch to
>GNU utility. It improves performance for processing large files.  

That feature has been present since compress version 3.0.  The only
changes that the FSF has done is to fix a bug which caused it to
delete the compressed (.Z) file when it received a SIGINT and to 
document more of its flags in the usage message.

>One more question to the netland, does anyone know whether the 
>ramdisk utility (/etc/ramdisk* as for ESIX rev.D) has a solid
>public domain counterpart or not?

In general, a ramdisk is a bad idea, as it reduces the amount of
core memory the system has to play with and thus causes a lot of
paging.

>Poor documentations seem to be the only bad thing about ESIX so far to
>me. 

Its TCP/IP suite is awful as wll.

>ps. maybe someone has tried FSF's GNU file utilities in ESIX.  I built the 
>    entire set and tested them all. ls behaved very strangely (ie.
>    outputs garbage).  I didn't have time to figure out why. So that
>    time, I junked GNU file utility suite and retained ESIX faithfuls.

I have ported fileutils, find, diff, sed, gawk, etc. to ESIX with no
problems whatsoever.

	--jtc

-- 
J.T. Conklin	jtc@wimsey.bc.ca, ...!{uunet,ubc-cs}!van-bc!jtc