kent@xanth.UUCP (04/10/87)
[no sense quoting all that old stuff, you've all read it]
Here at ODU, we Amigans are building up a fair public domain library for our
own use. We find that arc, shar, uuencode, and compress all have their place.
We use arc for local storage, becuase it is compatible with a whole range of
microcomputers. It is as close to a standard as exists in the microcomputer
field. We upload and download arced files with kermit image (binary) mode,
and have no troubles at all. This has become especially pleasant since some
kind soul (bless you) ported arc to BSD 4.3 UNIX(tm). The advantages of using
arc: it allows files of multiple types to be packaged in a single compressed
file (sources, executables, makefiles, etc.), with its own index and checksum
protection. This saves us a directory level and the associated storage block
for the directory, on our UNIX system (xanth.cs.odu.edu). This is a very
convenient format for a group of related files, since the "optimum"
compression technique is used on each of the files. There is some overhead
for the associated index, however.
Which brings up compress. We use this a lot in the same library, for IFF
pictures, because it generally doesn't make sense to pack them up in groups;
the user tends to want to pick and choose them to download one at a time, and
we save about 5 percent in storage space over arcing the same files. (That's
byte count. Since the disk files are by big or little blocks, it really
doesn't work out that way on an individual file basis, but occassionally you
will save a block, so it probably works out about the same.) This has
gotten a lot nicer since another kind soul ported compress to the Amiga.
(Bless you, too.)
Now, when we transport micro-floppy disks to our fellow Amiga users, the
software/data is usually arc'ed, because we know they have arc. But, when
we transport code across USENet, we compress and uuencode the binary's, and
shar them together with the source, documentation, makefiles, etc., because
that is the standard way to communicate code across the UNIX networks.
This is less convenient than using arc, because it requires multiple steps
to get back to the original files. Still, it is what works here. If USENet
eventually goes to a protocol (I'm way over my head here) that allows image
(raw binary) transfer, like kermet does, I would expect arc, modified to
accept the longer file names on UNIX (versus MS-DOS, which, I think, is the
origin of arc), to replace the clumsier uuencode and shar methods. Not too
quickly, because of institutional and personal inertia, but someday.
The moral of all this is that there is a necessity for all of these
compression and data sharing methods right now for anyone who is reading
comp.sys.amiga on the network, and using >>>The Fabulous Amiga<<< at home or
work, so it is not really much use arguing that one is "better" than the
other; right now, when I see a nail, I grab my hammer, and when I see a
plank that's too long, I grab my saw. Tools are appropriate where they are;
who wants to argue that a hammer is "better than" a saw? Use what fits.
Kent.
--
The Contradictor Member HUP (Happily Unemployed Programmers) // Also
// A
Back at ODU to learn how to program better (after 25 years!) \\ // Happy
\// Amigan!
UUCP : kent@xanth.UUCP or ...{sun,cbosgd,harvard}!xanth!kent
CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu
Voice : (804) 587-7760 USnail: P.O. Box 1559, Norfolk, Va 23501-1559
Copyright 1987 Kent Paul Dolan. How about if we keep the human
All Rights Reserved. Author grants race around long enough to see
retransmission rights recursively only. a bit more of the universe?