Xref: utzoo alt.sources.d:633 comp.sources.d:5576
Path: utzoo!attcan!uunet!shelby!bu.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth!galaxia!dave
From: dave@galaxia.Newport.RI.US (David H. Brierley)
Newsgroups: alt.sources.d,comp.sources.d
Subject: Re: Unnecessary tar-compress-uuencodes
Message-ID: <987@galaxia.Newport.RI.US>
Date: 11 Jul 90 14:57:34 GMT
References: <15652@bfmny0.BFM.COM> <1990Jul10.182546.26487@diku.dk>
Organization: Dave's Very Own Personal System
Lines: 58

In article <1990Jul10.182546.26487@diku.dk> thorinn@skinfaxe.diku.dk (Lars Henrik Mathiesen) writes:
>	name	       size		crummy ASCII graphics
>	----------  -------		---------------------
>	tar	    4718592	tar	 ------- -60.3% ------>	tar.Z
>	tar.Z	    1874378	+37.8%				 +37.8%
>	tar.Z.uu.Z  2229065	tar.uu.Z -------  -6.8% ------>	tar.Z.uu.Z

Several points I would like to make.

1) The compressed-uuencoded-compressed file is almost 20% larger than the
compressed file, therefore you have *increased* my phone bills by 20%.  I
do not exactly appreciate this.

2) You have increased both the amount of disk space and the time required
for me to determine if this program is useful to me.  First I have to
uudecode it, then I have to uncompress it, and then I have to un-tar it.
Each of these steps require disk space and time.  With a shar posting I can
read the entire source before I even save it into my directory.  I can also
unpack a multi-part shar file one piece at a time and then remove the piece
that I just un-shar'ed thus greatly reducing the disk space requirements.

3) "tar" format is a lot less portable than "shar" format.  With a shar file
I can edit the file names if they are too long for my system V based machine.
Try doing that with a tar file.  "shar" format can be unpacked on a lot of
different systems other than just UNIX.  People these days are using your
programs in ways you never envisioned and on systems you never envisioned.
Even if a program is not really applicable to a particular environment,
there are often portions of the program that can be borrowed and used in
other applications.

4) With a "shar" format posting I can decide if something is useful before
I have all of the pieces.  If I then miss one or more pieces I can request
them from somewhere knowing that they are useful to me.  With a uuencoded
tar file I need to have all of the pieces before I can decide if it is
really useful to me.  I know some people will say "but I precede the posting
with a description of what it is" but this is not good enough.  Unless the
description you post exactly matches the description I have been thinking
of for something that I want then I cant really tell if this will be useful
to me.  There is no substitute for reading through all of the documentation
supplied and reading through a good portion of the source code.  Besides
that, what if the one piece of your posting that I miss is the first one and
therefore I never see your description of what it is.

In my opinion there are just too many arguments against posting uuencoded
tar files to even consider it as a viable alternative to shar files.  The
only reason I can see for uuencoding something is if it is a binary or if
it contains binary data.  Even then you should just uuencode that one item
and include it in a shar file with the plain text documentation.

Please do not post uuencoded tar files!  If you are concerned about your
program being modified as it is transmitted through BITNET then make sure
your source code is portable enough to withstand this.  You could also
try including checksums in your postings using the "snefru" package that
was posted recently.
-- 
David H. Brierley
Home: dave@galaxia.Newport.RI.US    {rayssd,xanth,att} !galaxia!dave
Work: dhb@quahog.ssd.ray.com        {uunet,sun,att,uiucdcs} !rayssd!dhb