malpass@LL-VLSI.ARPA (Don Malpass) (10/18/88)
>From: Keith Petersen <W8SDZ@simtel20.army.mil> >Subject: GSARC - non-compatible more efficient archiver >Just uploaded to SIMTEL20... > >Beware - the >ARCs it produces cannot be read by ARC, ARCE or PKUNPAK unless GSARC's >compatibility switch is used. Please Keith, if it's another program which can make NON-COMPATIBLE files called xxx.arc, then for God's sake, DON'T TOUCH IT WITH TONGS! A two-sided war is bad enough. Let's not add a third player. Maybe the author can be persuaded to change the default OUTput file names to .sht or something. If Katz had done that we'd all be better off. don malpass [malpass@LL-vlsi.arpa]
W8SDZ@SIMTEL20.ARMY.MIL (Keith Petersen) (10/19/88)
Don, are you suggesting that files on SIMTEL20 be censored? As I said in my posting, I do not endorse the program, but it does bring up some interesting questions. The mailing address of the author is included in my announcement and in the extracted DOC file. Why not express your concerns to him in a letter? The significant thing, in my opinion, is that a major breakthrough has been made in compression efficiency. Must everyone be forever locked into less efficient algorithms just because the older programs can't read the new format? If that were true, everyone would still be using SEA's original version of ARC, which cannot read files created by SEA's own ARC5xx. --Keith
raf@cup.portal.COM (10/20/88)
[Keith: FYI. Posted to comp.sys.ibm.pc and comp.os.cpm. --Bob] In article <KPETERSEN.12439280069.BABYL@SIMTEL20.ARMY.MIL>, W8SDZ@SIMTEL20.ARMY.MIL (Keith Petersen) writes about the new MS-DOS program, GSARC, by NoGate Consulting: > This is an interesting development. A new program that makes and > extracts ARC files using a more efficient variation on LZW compression, > called "Crushing". I have included the .INF file below. Beware - the > ARCs it produces cannot be read by ARC, ARCE or PKUNPAK unless GSARC's > compatibility switch is used. The program does work, and it does > produce *signficantly* smaller ARC files. I have examined the output of this program, and it is impressive. "Crushing" consistently generates smaller files than either "Crunching" or "Squashing". And it does this without resorting to memory-hungry brute force methods (such as LZW compression with 16-bit codes, as used by the UNIX public domain COMPRESS program.) > The information below is presented "as-is". I have no connection with > NoGate Consulting and this posting should not be interpreted as an > endorsement of yet another incompatible ARC-maker. However, it does > pose an interesting question: are we to resist this just because it's > incompatible - even though it is a significant step forward in > compression efficiency? ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ Please consider this carefully, people! Most of the recent discussion pertaining to compressing archivers, such as ARC, PKPAK (nee PKARC), ZOO, DWC, and now GSARC (to name just a few :-)), has related to the issue of portability. While that is understandably of great concern to many USENET readers, it should not be overlooked that *compression efficiency* is the primary reason for the existence and popularity of these programs. Some of us, who have actively researched LZW and other data compression techniques, have known that further improvement of current methods is technologically feasible. I predict that this "Crushing" variation is not even the ultimate we are likely to see in the near future. Legal, moral, and philosophical concerns aside, I urge continued support for such advancements in the state of the art. In this spirit, I have begun making the necessary modifications to my CP/M archive extraction program, UNARC, to handle .ARC files generated by GSARC10. (Just as I did almost two years ago, when Phil Katz' PKARC20 introduced an improved compression method to .ARC files.) Bob Freed Internet: raf@cup.portal.com Newton Centre, MA UUCP: ...!sun!portal!cup!raf
malpass@LL-VLSI.ARPA (Don Malpass) (11/01/88)
Forgive the delayed response - I've been out of town. >From: Keith Petersen <W8SDZ@simtel20.army.mil> >Subject: GSARC - non-compatible more efficient archiver > >Don, are you suggesting that files on SIMTEL20 be censored? >The significant thing, in my opinion, is that a major breakthrough has >been made in compression efficiency. Must everyone be forever locked >into less efficient algorithms just because the older programs can't >read the new format? >--Keith Since you and I have tended to be on the same side of most issues until the arc warfare, I shouldn't give you a seemingly smartass answer. But if electing to "Ban all SEA software and/or arc files from Simtel and BB's" isn't censorship, I don't know what else to call it. My argument, as I've frequently stated, is not against "progress" but against INCOMPATIBILITY, also known as CONFUSION. Being able to try out an endless supply of new software is great, but if every new program were named command.com we'd shortly tire of the puzzle as to what each one did. This is no less true of data files, and the world is NOT a better place for having a proliferation of incompatible files that end in ".arc". As evidence I offer the fact that collectively the computer community has blown away tens of [wo]man-years writing and reading flames and messages like this one. You're as tired of it as I am. It is not a legal or even an emotional issue; it is a practical one. I applaud the efforts to specify and generate the next generation of archiving/compressing/smart-backup software. I only wish it were being done with harmony instead of acrimony. But at least by now we should all have learned what NOT to call it or the files it generates. Cheers, don --- Don Malpass [malpass@LL-vlsi.arpa], [malpass@spenser.ll.mit.edu] My opinions are seldom shared by MIT Lincoln Lab, my actual employer RCA (known recently as GE), or my wife.