PKARC

bob, mon bobmon at iuvax.cs.indiana.edu
Fri Feb 26 13:22:20 AEST 1988


...but I can't resist this topic :-)

<4638 at teddy.UUCP> jpn at teddy.UUCP (John P. Nelson) writes (among other things):
>>If you are using PKARC, you might give some serious
>>consideration to going back to the Standard ARC.
>
>I would NEVER go back to ARC.
>
>Why would I bother?  Because PKARC is 10 TIMES FASTER than arc.
>I don't know about anyone else, but that means a LOT to me!
>
>>PKARC is in violation of S E A's copywrite.
>
>This would be AWFULLY hard to prove.  I believe that pkarc is a
>complete rewrite.  It's not a look-and-feel issue either.  The
>only thing in common between the two programs is the compression
>algorithm (Lempel-Ziv), and that is public domain!

I measured a 7:1 speed ratio on my test suite.  I have occasional can't-
write-the-dam'-file problems with pkarc, but not v1.2 -- which I keep around
as a backup for this reason :-(  The speed improvement (8-9 minutes versus
AN HOUR on biggish archives) makes the hassle worth it.  The superior
compression is nice too, but I'd pay a slight size penalty for that speed.

Pkarc and ARC have something fairly valuable in common, namely their whole
approach to the task.  I like being able to group files together (like UNIX
shar does).  I like being able to compress the files (like UNIX compress
does (usually better than pk/arc does)).  I like having a CRC available, not
to mention the "test validity" option.  They make for a more robust archive.
By the way, I've seen "arc t badarc" report an error where "pkxarc /t badarc"
hung the whole machine...when I suspect trouble I use arc first now.

These abilities aren't really available to me on Unix right now.  I can
compress some stuff, and I can uuencode and shar it, and I can run CRC's on
everything, but if I send it to someone I can't be sure that their unshar
can handle my shar (okay, it probably will), and I can't be sure that they
can generate the same CRC or checksum or whatever that I used -- there are
variations on the algorithms that produce different values; there are
additional characters that mailers sometimes add to files that can change
those values.  I can't be sure that the recipient will in fact do all the
right things to get files out intact.  The ARC format makes much of that
easier and more automatic.

While I'm at it, the ZOO format yields most of these same benefits, and I like
the extract-and-run-from-memory feature a lot for infrequently used programs.
It's biggest problem is that it isn't used much.  Both zoo and arc have been
ported to UNIX systems so files can be exchanged quite conveniently (although
the machine I'm on right now has neither).

p.s.  Henderson and Katz:  you're on my list of people to register with,
right along with Buerg.  Pray for me to get out of school and get a job :-)

RAMontante				bobmon at iuvax.cs.indiana.edu
Computer Science Department			If you listen to Tools...
Indiana University					the Slide Rules!



More information about the Comp.unix.xenix mailing list