tes@whuts.UUCP (STERKEL) (06/07/87)
In article <4431@iuvax.UUCP>, bobmon@iuvax.UUCP (Che' Flamingo) writes: > [original had results showing about 40% compression, with the pkarc running in about 1/6th of the time of arc.} I posted a test of file compressions about 6 weeks ago that similarly showed only 2-3% compression results spread and the same 1/6th execution time advantage of pkarc. (my files were about 1.2MB). I am gratified that your results are so close. HOWEVER, [soap box time], remember that pkarc in the Squashing mode results in a compressed file that is INCOMPATIBLE with SEA's ARC and every other ARC clone that I have access to. I have posted to comp.sources.misc two patch files that correct this problem with no speed penalty, and less than 2% space penalty. To beat the drum again: use pkarc, but patch it to the standard mode. -- ----- Terry Sterkel -====---- AT&T Bell Laboratories --------- {clyde|harvard|cbosgd|allegra|ulysses|ihnp4}!whuts!tes ----- [opinions are obviously only my own]
perry@omepd.UUCP (06/10/87)
In article <2129@whuts.UUCP> tes@whuts.UUCP (STERKEL) writes: > >HOWEVER, [soap box time], remember that pkarc in the Squashing mode >results in a compressed file that is INCOMPATIBLE with SEA's ARC >and every other ARC clone that I have access to. I have posted to >comp.sources.misc two patch files that correct this problem with >no speed penalty, and less than 2% space penalty. To beat the >drum again: use pkarc, but patch it to the standard mode. PKARC version 3.5 (the newest, fresh-from-the-press one) has a small configuration file that it reads automatically when starting up. A command in that file will make it SEA-ARC compatible. No need for patches any more. A hooray for PKWare! By the way, does anyone have information on a compression system called *ZOO* (decompression program *LOOZ*)? OMEN tech. says that they are changing to it, so I assume it must be considerably better than the ol' ARChive format, but I have no hard info at all. Can anybody help? ------------------------------------------------------------------------ << Perry The Cynic >> =>> perry@inteloa.intel.com <<= ...!tektronix!ogcvax!omepd!inteloa!perry (Peter Kiehtreiber) ...!verdix!omepd!inteloa!perry
jdia@osiris.UUCP (06/15/87)
In article <6242@steinmetz.steinmetz.UUCP>, davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) writes: ... > a) it runs portably in most systems, Xenix, MPort, Ultrix, SunOS3, > MS-DOS, etc. I think it runs in VMS. ... > bill davidsen (wedu@ge-crd.arpa) I have used arc on unix v5, 4.2, ultrix, ms-dos, and xenix. I'm pretty sure that it is available for multiport, sunos3, and vms with just a little patchup. Josh / Spidey -- A message from Spidey, and the Spidey Team. ------>>>> \_\ /_/ Yes, it's __________________________________________________________ _[*]_ supposed to \ Reachable via UUCP:...decvax!decuac!aplcen!osiris!jdia / / / \ \ look like a / ...[seismo,allegra]!mimsy!aplcen!osiris!jdia \ spider!
w8sdz@brl-smoke.ARPA (Keith B. Petersen ) (06/21/87)
Why don't we chuck SEA's ARC and use PKARC exclusively? If SEA is
unresponsive to adding an abvious improvement, why should we all suffer
from having to deal with larger ARCs just to stay compatible with it?
PKARC is five times faster and makes smaller ARCs.
This reminds me of the time many years ago when the UHF TV spectrum was
licensed to TV stations and everyone had VHF-only TV sets. You wouldn't
think of buying a TV set without UHF! It's time to move on.
By the way, ARC521 was recently released. It's available from SIMTEL20
for those diehards who want to wait five times longer. It does NOT have
squashing.
--
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZephram@violet.berkeley.edu (06/23/87)
In article <6005@brl-smoke.ARPA> w8sdz@brl.arpa (Keith B. Petersen (WSMR|towson) <w8sdz>) writes: >Why don't we chuck SEA's ARC and use PKARC exclusively? If SEA is >unresponsive to adding an abvious improvement, why should we all suffer >from having to deal with larger ARCs just to stay compatible with it? >PKARC is five times faster and makes smaller ARCs. > Have you ever tried to check an archive with pkxarc (/t I believe) ? Have you ever had to reboot your computer because the arc was munged and pkxarc hung the whole machine? Understand that I am not trying to defend exclusion of an important feature from a product, I am requesting that the bugs be worked out before everyone abandons the already working model. The new stuf is great, when it works. > [ text deleted] >-- >Keith Petersen >Arpa: W8SDZ@SIMTEL20.ARPA >Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz >GEnie: W8SDZ Ephram Cohen ephram@violet.berktionminim
davidr@hplsla.HP.COM ( David M. Reed) (06/26/87)
In my opinion, it was wrong for PKX to create a file (by default) with a .ARC extension that cannot be read by the standard ARC program. They should have the extension .PKX unless the archive is created compatible with SEA's ARC program (in which case a .ARC extension is acceptable). (Likewise, ZOO should put on a .ZOO extension to their archives.) This is, as pointed out, an important consideration (and the value of extensions), becuase one can usually determine what a file is for, or how to use it, by that extension (.COM, .BAT, .EXE, .BAS, .DOC, .C, .PAS, .ASC, .DRW, etc.). And while the new environment variable can be considered nice by many, I do not care for becuase I find my environment getting full (and I already have it defined, under 3.1, as /E60). With the growing length of PATH, and space for a prompt that is meaningful, plus variables for my editor, for LESS, for LAN software, for the compiler, etc., I am close to a point of choice making (which ones can be sacrificed) that I do not want to have to deal with. And I personally do not like the idea of self unpacking archives (but it is acceptable for the archive program to self-extracting). First, because the extension does not truly convey what the file is about, and secondly the access to that file. Whenever I send files to someone (by their request) I have always put the files into an archive, which is then UUENCODED. If they do not have ARC to extract the file, then I send along a UUENCODED self-extracting ARC program. I feel it is most valuable for EVERYONE to have a copy of ARC for their benefit (I consider it invaluable, and do all of my backups to archive files for space considerations and group organization, etc.)