Unnecessary tar-compress-uuencodes

[Greg A. Woods]

In article <sean.647630062 at s.ms.uky.edu> sean at ms.uky.edu (Sean Casey) writes:
> doug at letni.UUCP (Doug Davis) writes:
> 
> |Actually this is a very incorrect assumption, very few newsfeeds any
> |more are not compressed in some way.  Compressing/uuencodeing/etc 
> |a posting neatly circumvents any compression.  The minimal savings
> 
> Compressing an article reduces phone time. If compress finds a file
> is bigger after compression, it doesn't compress it. So the phone
> costs really aren't increased by users doing their own compression.
> 
> Plus, Lempel-Ziv is not the ultimate compressor for certain kinds
> of data.  There's ways of compressing bitmaps, for instance, that
> are a lot more effective.
> 
> I don't see what the problem is. Compress is smart enough to not
> expand files, and it *does* save disk space on the remote site, so
> why complain?

Because, if you are batching with a more reasonable size like
200-400Kb, a couple of gundged up, uuencoded files may mess up the
compression of the remainder of the articles in the batch.  I've not
actually measured this carefully, but the occasional time I've made a
tar of a directory with a few such files, or worse yet a few already
compressed files, I get 20-50% larger archives than if I unpack those
few files first, then archive and compress the whole works.  Remember
LZ compression uses a dictionary....

As we've been saying over and over, shar's are simple and easily dealt
with in any number of environments.  They don't intrude on the causal
reader's ability to browse, and they don't make your head hurt as it
mine certainly does when I see the even lines of absolute garbage that
uuencode creates.

It's not only the cost of phone lines alone we're worrying about, but
also the manpower involved!

As for more efficient compression algorithms for special forms of
data, please do use them where appropriate, IFF the decoders are
readily available to the target audience.  HOWEVER, PLEASE post them
ONLY to an appropriate binaries group, unless they are part of a
*shar*ed source posting.

As for saving disk space, please don't bother!  The volume involved
amongst the zillions of un-compressed postings is insignificant.
Besides I *do* like to grep through files in the spool directories,
and I *do* like to be able to do regex searches in rn.

Just what is the average end savings in converting an arbitrary binary
to an approx. 35% compressed binary stream, then converting it back to
the 96 printable characters in record format?  The few times I've done
it, the savings have not been appreciable, but were necessary to mail
an otherwise impossible to mail binary.
-- 
						Greg A. Woods

woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP
+1 416 443-1734 [h]   +1 416 595-5425 [w]   VE3-TCP   Toronto, Ontario; CANADA