Xref: utzoo comp.sources.d:2100 comp.binaries.ibm.pc.d:231
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!necntc!encore!loverso
From: loverso@encore.UUCP (John Robert LoVerso)
Newsgroups: comp.sources.d,comp.binaries.ibm.pc.d
Subject: Re: Standard for file transmission
Message-ID: <3055@encore.UUCP>
Date: 13 May 88 16:03:51 GMT
References: <292@cullsj.UUCP> <696@fig.bbn.com> <2932@cognos.UUCP>
Reply-To: loverso@encore.UUCP (John Robert LoVerso)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 27

In article <2932@cognos.UUCP> brianc@cognos.UUCP (Brian Campbell) writes:
> In article <696@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes:
> > If you are (sigh) going to post binaries on Usenet, DO NOT compress
> > them first.  Many Usenet sites use compress to pack up their news
> > batches.  Compressing a compressed file makes it larger.
> 
> Maybe those Usenet sites should not use the -f (force) flag with compress.

Thats not how (typical) news batching works.  Compress is used as a stage
of a pipe:
	batch | compress | uux
and because compress doesn't know the size of its input when it starts
up, it will *always* produce compressed output.

The point is that an article which contains binary thats compressed and then
uuencode/btoa/your_favorite'd will lower the compression ration for the batch
that contains it.  The overall size of the batch will be smaller if the
included binary was just uuencoded, etc.

I no longer carry comp.binaries.* as I am using its disk space to store
more *useful* news.  It would be nice to see such things split out
into bin.*.

As gnu says: "Use the Source, Luke..."

John Robert LoVerso, Encore Computer Corp
encore!loverso, loverso@multimax.arpa