tlhingan@unsvax.UUCP (Eugene Tramaglino) (04/04/88)
I think that I would have no major objection to using ZOO as an archive format, IF it (the ZOO program) was made available IN ADVANCE of standardizing. Why can't we simply send everyone a copy of ZOO? Note: I have not used ZOO. I have used ARC and pkarc. Personal Note: I cannot stand pkarc. I prefer ARC's one (1) program that does the job just as well. I don't like invoking different commands to 'v' an archive and 'e' an archive. #==============================================#=========================# # Eugene Tramaglino -- tlhingan@unsvax.uns.edu # USS Mahagonny, NCC-1929 # # 1450 E Harmon 207A, Las Vegas, NV 89119 #=========================# # Data: "All paths are equally dangerous." # Member, Institute of # # Riker: "Let's go!" # General Semantics. # #==============================================#=========================#
dick@slvblc.UUCP (Dick Flanagan) (04/07/88)
In article <230@unsvax.UUCP> tlhingan@unsvax.UUCP (Eugene Tramaglino) writes: > I think that I would have no major objection to using ZOO as an archive > format, IF it (the ZOO program) was made available IN ADVANCE of > standardizing. Why can't we simply send everyone a copy of ZOO? > Note: I have not used ZOO. I have used ARC and pkarc. I have used all three and I am VERY impressed with ZOO. Unlike ARC which sort of evolved from the COMPRESS/LU/SQ days, Rahul designed ZOO from the very beginning to be an extensible archiver to satisfy today's requirements while remaining flexible enough to address tomorrow's. ZOO is *NOT* compatible with ARC, but then it was never designed to be for very sound reasons. In my opinion, ZOO will eventually prevail because of its technical superiority. However, whether or not comp.binaries.ibm.pc should _start_ out ZOO-based is another story. While ZOO is continually being adopted by more and more universities and companies, it has by no means reached "household word" status, and a great deal of user education still needs to be accomplished. I think a phased approach might make sense. Start out with a 9-to-1 ARC-to-ZOO ratio and gradually, over, say twelve months, work towards reversing that ratio. All the while making sure that ZOO binaries and portable sources are made as accessible as possible. However, one source of potential trouble if Rahul is elected moderator of comp.binaries.ibm.pc (which I think he should be) might be the appearance of his "pushing" ZOO for personal, rather than technical, reasons. He did, after all, design and write it. I'm not sure if that can be prevented, but I feel the net is intelligent enough to evaluate ZOO on its technical merits and respond accordingly. > Personal Note: I cannot stand pkarc. I prefer ARC's one (1) program > that does the job just as well. I don't like invoking different > commands to 'v' an archive and 'e' an archive. I don't like pk(x)arc either, but primarily because of the arrogance of its author. I have no problem with Phil Katz writing a set of fast ARC- compatible utilities for the PC. If he had done just that, he would be in healthy competition with Vern Buerg and his set of fast ARCA, ARCE, ARCV, and ARCF utilities, and everyone would benefit. But, no. Katz had to come up with an "improved" compression method that only his programs could extract. Then he had the arrogance to continue calling them .ARC files, knowing full well that people using the more prevalent SEA-compatible ARC programs would not be able to extract them. Only after much user screaming did he provide a means of "turning off" his new compression method. Thanks a lot, Phil. Vern Buerg, on the other hand, did it right. His ARC utilities are 100% compatible with SEA's ARC program, are blazing fast, and now they can even extract Katz's damned "squashed" files. Vern even goes so far as to ask that donations be sent to SEA, not to himself. Now that's class! By the way, I handle the use of multiple, specialized ARC programs with a single ARC.BAT file that essentially looks at the %1 parameter. If it's an "a" or "m" it builds a call to Buerg's ARCA127, if it's a "v" it calls ARCV117, "e" or "x" calls ARCE31B, and anything else calls ARC521. Although the batch file is fairly straight forward, I'll be happy to email a copy of it to anyone who wants it as a template for their own. I have no affiliation with Rahul Dhesi, SEA, or Vern Buerg other than being a licensed user of ARC and a satisfied user of ZOO, ARCA, ARCE, ARCV, and ARCF. Dick -- Dick Flanagan, W6OLD GEnie: FLANAGAN UUCP: ...!ucbvax!ucscc!slvblc!dick Voice: +1 408 336 3481 Internet: slvblc!dick@ucscc.UCSC.EDU LORAN: N037 04.7 W122 04.6 USPO: PO Box 155, Ben Lomond, CA 95005
feg@clyde.ATT.COM (Forrest Gehrke) (04/08/88)
In article <230@unsvax.UUCP>, tlhingan@unsvax.UUCP (Eugene Tramaglino) writes: > > Personal Note: I cannot stand pkarc. I prefer ARC's one (1) program > that does the job just as well. I don't like invoking different > commands to 'v' an archive and 'e' an archive. Apparently you have not had the boredom of waiting for a couple dozen small files being archived by SEA's ARC--it's almost like watching paint dry. PKARC does it at least 5 times faster. Forrest Gehrke
rjchen@phoenix.Princeton.EDU (Raymond Juimong Chen) (04/10/88)
In article <230@unsvax.UUCP>, tlhingan@unsvax.UUCP (Eugene Tramaglino) writes: > Personal Note: I cannot stand pkarc. I prefer ARC's one (1) program > that does the job just as well. I don't like invoking different > commands to 'v' an archive and 'e' an archive. You've got to be kidding. Do you use V.Buerg's ARCE program for fast de-archiving? If so, then you have no reason to complain. Rename PKARC.COM to ARC.COM and PKXARC.COM to ARCE.COM, and nothing will have changed; except that you'll notice that everything happens much much faster than before. If it STILL bothers you that you have to type two different commands, you can do the following: ARC.BAT if !%1==!e goto unarc pkarc -oct %1 %2 %3 %4 %5 %6 %7 %8 %9 goto end :unarc pkxarc %2 %3 %4 %5 %6 %7 %8 %9 :end There. Now this ARC.BAT acts *just like the original*; the -oct option to pkarc guarantees that PKARC will not do any squashing, for those of you whose UN*X machines can't handle squashed archives. (Well, I lied when I said it works just like the original. It's faster.) -- Raymond Chen UUCP: ...allegra!princeton!{phoenix|pucc}!rjchen BITNET: rjchen@phoenix.UUCP, rjchen@pucc ARPA: rjchen@phoenix.PRINCETON.EDU "Say something, please! ('Yes' would be best.)" - The Doctor
feg@clyde.ATT.COM (Forrest Gehrke) (04/12/88)
> I don't like pk(x)arc either, but primarily because of the arrogance of > its author. I have no problem with Phil Katz writing a set of fast ARC- > compatible utilities for the PC. If he had done just that, he would be > in healthy competition with Vern Buerg and his set of fast ARCA, ARCE, > ARCV, and ARCF utilities, and everyone would benefit. > > But, no. Katz had to come up with an "improved" compression method that > only his programs could extract. Then he had the arrogance to continue > calling them .ARC files, knowing full well that people using the more > prevalent SEA-compatible ARC programs would not be able to extract them. > Only after much user screaming did he provide a means of "turning off" > his new compression method. Thanks a lot, Phil. Arrogance? For making improvements and using a common extension name? System Enhancement Associates did the same as they evolved to v5.12 with improvements that were not always backward compatible. Why this attack on Katz? He was simply being practical, as was SEA. The argument about extension names holds fascinating possibilities. Does this mean Lotus has a lock on .wks? Digital Research with its CPM can closeout .com? Who owns .exe and .bat? As for .arc, for those whose C compiler experience encompasses Borland and Microsoft, a few years ago the powers were Lattice and Computer Innovations. With CI's compiler came an archiving utility called ARCH. It's syntax was much like SEA's and their extension was .arc. When SEA co-opted this extension with a completely incompatible archiver were they being arrogant? Let's agree to discuss the pros and cons of which archiver to use without accusing the authors of nonexistent transgressions.
feg@clyde.ATT.COM (Forrest Gehrke) (04/12/88)
In article <1322@slvblc.UUCP>, dick@slvblc.UUCP (Dick Flanagan) writes: > > I don't like pk(x)arc either, but primarily because of the arrogance of > its author. I have no problem with Phil Katz writing a set of fast ARC- > compatible utilities for the PC. If he had done just that, he would be > in healthy competition with Vern Buerg and his set of fast ARCA, ARCE, > ARCV, and ARCF utilities, and everyone would benefit. > > But, no. Katz had to come up with an "improved" compression method that > only his programs could extract. Then he had the arrogance to continue > calling them .ARC files, knowing full well that people using the more > prevalent SEA-compatible ARC programs would not be able to extract them. > Only after much user screaming did he provide a means of "turning off" > his new compression method. Thanks a lot, Phil. Arrogance? For making improvements and using a common extension name? System Enhancement Associates did the same as they evolved to v5.12 with improvements that were not always backward compatible. Why this attack on Katz? He was simply being practical, as was SEA. The argument about extension names holds fascinating possibilities. Does this mean Lotus has a lock on .wks? Digital Research with its CPM can closeout .com? Who owns .exe and .bat? As for .arc, for those whose C compiler experience encompasses Borland and Microsoft, a few years ago the powers were Lattice and Computer Innovations. With CI's compiler came an archiving utility called ARCH. It's syntax was much like SEA's and their extension was .arc. When SEA co-opted this extension with a completely incompatible archiver were they being arrogant? Let's agree to discuss the pros and cons of which archiver to use without accusing the authors of nonexistent transgressions. Forrest Gehrke