Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!uwvax!uwmacc!anderson
From: anderson@uwmacc.UUCP
Newsgroups: comp.sys.ibm.pc,comp.sys.att
Subject: Re: Perf./Comp. Tests ARC/PKARC was: Numerous requests ...
Message-ID: <1364@uwmacc.UUCP>
Date: Sat, 11-Apr-87 20:28:43 EST
Article-I.D.: uwmacc.1364
Posted: Sat Apr 11 20:28:43 1987
Date-Received: Sun, 12-Apr-87 06:04:22 EST
References: <274@cup.portal.com>, <58200031@gorgo.UUCP> <433@csm9a.UUCP> <1743@whuts.UUCP>
Organization: UWisconsin-Madison Academic Comp Center
Lines: 57
Xref: utgpu comp.sys.ibm.pc:2872 comp.sys.att:298

In article <1743@whuts.UUCP>, tes@whuts.UUCP (STERKEL) writes:

Thank you for your valuable comparison runs. That's a real service
to a large community.

> 1. This "incompatibility" issue is silly.  As pkarc is the 
> "follower" package, it should maintain compatibility in
> BOTH directions.  As the originator, SEA sets the standard,
> not PKware.

While *I* agree with you, and surely SEA would, Phil Katz (I assume
he's the PK of PKARC) probably would not. This is marketing, folks,
and you have to make consumer choices, like it or not. On compatibility
itself, see below.

> 2. I personally do not upload to BBS (have nothing of interest)
> but anyone who does should consider it a matter of PROFESSIONALISM
> to upload ONLY SEA-compatible files.

At least one should tell the sysop clearly what one has done. The
issue is a hot one (again!), because we have a BBS at work that is
right now considering making PK its standard ARC utility. Both
programs are readily available here, as most places. 

> 3. The difference in sizes is trivial, less than 2.5%.  If that
> makes a difference to you, I suspect that the real problem is
> that you have outgrown your hard disk.

No cultural snobbism, please :-) -- thousands of people do not
have hard disks, though I agree that 2.5% is unlikely to be a
decisive factor.

> Recommendation:
> Use PKARC/PKXARC in the "/oc" mode to save time while remaining
> truly compatible.

This *seems* reasonable. I have many megabytes of ARCed files, and
although I have plenty of hard disk space, that's true because I
offload anything that has a low probability of being used. Over the
past year, the ARCed archive of text files has kept on growing, and
if anything the growth rate will itself increase. My point is, I have
a big interest in compatibility with SEA ARC. But speed factors of
5+ become more and more significant as time goes along, and unless
SEA can achieve an improvement of something like an order of
magnitude, it's doomed.

Now it's unfortunately a harsh world out there, but it's looking
increasingly like market forces will push SEA out, PK will reign
supreme, and SEA will go the way of CP/M -- lots of people invested,
but no future. Then what? I suspect nothing can be done. Part of
the life of being a consumer is to get a certain number of whacks
on the back of the neck with a not very sharp ax. Ah yes ...
-- 
==ARPA:==============anderson@unix.macc.wisc.edu===Jess Anderson======
| UUCP: {harvard,seismo,rutgers,  (avoid ihnp4!)   1210 W. Dayton    | 
|    akgua,allegra,usbvax}!uwvax!uwmacc!anderson   Madison, WI 53706 |
==BITNET:======================anderson@wiscmacc===608/263-6988=======