tes@whuts.UUCP (04/10/87)
In article <433@csm9a.UUCP>, japplega@csm9a.UUCP (Joe Applegate) writes: > The latest version of > ARC from SEA is 5.20... Most BBS's now carry ARC520.COM, > which is the self unarcing version from SEA. > > As to PKARC, I am currently discouraging the use of PKARC to archive files > until it is modified to use another extension. PKARC archives are NOT > compatible with ARC 5.12 or 5.20!!! This is seriously complicated by the > fact that it's files are labeled with the same extension! ARC is an industry > standard... PKARC is not! Running in where angels fear to tread..... This a re-run of the quarterly ARC-wars. Approximately once a quarter either PKware or SEA issues a new release, claiming instant victory. It has not been true in the past. Each package has trade offs. To check out the new releases, I downloaded both as both had gone through at least two upgrades since I last bothered, and ran a test..... The test was of 20 files of legitimate text material totalling 1,148,280 bytes. Text material was selected because 90%+ of the creative effort of engineers (and related professions) is in text (or source code which is the same thing). I ran ARC, PKARC (old compress), and PKARC (native mode). The "old compress" is a concession by PKware to allow de-ARCing by ARC. The comments feature of PKARC neither hindered nor helped de-ARCing. I did not check for truncation of comments. With this background, here are the results: Version |Cmnd Line | Time |Arc Size-Bytes |Can Be de-Arced by? | | | (and %)| arc -e|| pkxarc =================================================================== arc520.com |arc -a |17.9min|488,473 (42.6%)| yes || yes pkx24a20.com|pkarc /oc -a|3.2min|507,720 (44.4%)| yes || yes pkx24a20.com|pkarc -a | 3.2min|479,524 (41.9%)| NO! || yes ==================================================================== Notes: 1. Version is the file name of the self-de-arcing file you download. NEVER accept other forms, may be a TROJAN. 2. Versions are the latest announced by respective companies. 3. Remember the "pkarc /oc" can be considered the "SEA-compatible" mode. PKware has released a patch that reverses the meaning of the compatibility mode, making "native mode" the option. 4. The size differences are trivial, see below for analysis. 5. The time differences are not trivial. Conclusions: 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. 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. 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. 4. Looking at it from another viewpoint, the size differences create LESS THAN 5 minutes difference in connect time at 1200bps. (my true transfer rate at 1200bps is 99 bytes per second). Recommendation: Use PKARC/PKXARC in the "/oc" mode to save time while remaining truly compatible.
anderson@uwmacc.UUCP (04/12/87)
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=======
caf@omen.UUCP (04/13/87)
How about releasing the source code to PKARC to allow the Unix ARC clones to be upgraded to decipher these mutant .ARC files?