tes@whuts.UUCP (STERKEL) (07/02/87)
In article <10710@clyde.ATT.COM>, feg@clyde.UUCP writes: > > Why all this refusal to accept improvements and innovation? .... > Come on guys, get with it!! > > Forrest Gehrke I use PK*.* for the speed, but immediately applied the patches to prevent my EVER inadvertently creating a non-standard *.ARC. To do otherwise is to demonstrate a callous disregard for others who may not have the latest and greatest Phil Katz concept of how to compress. Incidentally, is it not a bit tacky to rip-off another person's standard, change it to be incompatible with the original, refuse to ensure (through extensions--whatever) that no one ever gets burned in the confusion, and *declare* your standard is the only good version? (Thought I would ask; techies seem to be somewhat loosely connected on business ethics and standards issues when faced with Newer, Bigger, Faster, Smaller:-) elses -- Terry Sterkel {clyde|harvard|cbosgd|allegra|ulysses|ihnp4}!whuts!tes [opinions are obviously only my own]
guest@vu-vlsi.UUCP (visitors) (07/04/87)
In article <2290@whuts.UUCP> tes@whuts.UUCP (STERKEL) writes: >Incidentally, is it not a bit tacky to rip-off another >person's standard, change it to be incompatible with the >original, refuse to ensure (through extensions--whatever) >that no one ever gets burned in the confusion, and *declare* >your standard is the only good version? Well, I don't know about this being tacky, but there is another name for it: progress. This type of thing happens quite often and I am quite thankful for it (could you picture the computer industry, or many other industries, without this type of occurance?) >(Thought I would ask; techies seem to be somewhat loosely >connected on business ethics and standards issues when >faced with Newer, Bigger, Faster, Smaller:-) >elses AAAAAh, true; so true. ============================================================================== | Mark Schaffer | BITNET: 164485913@vuvaxcom | | Villanova University | UUCP: ...{ihnp4!psuvax1,burdvax,cbmvax,pyrnj,bpa} | | (Go Wildcats!) | !vu-vlsi!excalibur!164485913 | ============================================================================== please reply/respond to the above addresses and not guest@vu-vlsi.UUCP
darrylo@hpsrlc.HP.COM (Darryl Okahata) (07/06/87)
In comp.sys.ibm.pc, w8sdz@brl-smoke.ARPA (Keith B. Petersen ) writes: > If SEA and Vernon Buerg won't see the usefulness in the more efficient > compression (on some files) of squash, why should we all suffer? Who > says SEA is the "standard"? Since PKARC is 6 times faster than ARC and > faster than ARCA/ARCE, why do we continue to use the slower programs? > > Maybe it's because Phil Katz hasn't released the source code? I haven't > seen any source code released for Buerg's programs, and there has been > no release that I know of for ARC521 source. > > SEA, during the early history of ARC, revised the "standard" to include > more efficient compression methods. It did generate some complaints > from users who didn't have the latest version. I suggest that PKARC is > no different. > -- > Keith Petersen > Arpa: W8SDZ@SIMTEL20.ARPA > Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz > GEnie: W8SDZ > ---------- Is the algorithm for Squashing known (i.e., published)? If it's something "proprietary", then this would explain why SEA and Vernon Buerg have not incorporated "Squash" into their programs. I believe that SEA "IS" the standard. On the bulletin boards that I've seen, and on the IBM Forums on Compuserve, programs are ARChived using ARC-compatible techniques ONLY (i.e., NO SQUASHING). Also, does Phil Katz advertise? For every copy of ARC sold through an advertisement (to someone who can't or won't call a BBS, etc.), there is one more copy of ARC in the world. Is PKARC only available through BBSes and the like? If so, then he is at a disadvantage at making PKARC the "standard". I'm not trying to say that we should all use ARC instead of PKARC (will those people, who will send me flames after reading the above two paragraphs but before reading this one, please send them to /dev/null). If you want to use PKARC, fine. However, if you do use PKARC, please disable Squashing for the benefit of those people who don't have or don't want to get PKARC. I'm just saying that, for PUBLIC postings, Squashing should be disabled. And, yes, I DO have PKARC. -- Darryl Okahata hplabs!hpcea!hpsrla!darrylo CompuServe: 75206,3074 Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.
darrylo@hpsrlc.HP.COM (Darryl Okahata) (07/07/87)
In comp.sys.ibm.pc, NU013809@NDSUVM1.BITNET (Greg Wettstein) writes: > I have been following the controversy regarding utilitzation of Phil Katz's > program for some time now and frankly I am somewhat concerned. This reply > will probably entitle me to a great number of flames but I would like to come > out in favor of Phil and his new programs. I have had the opportunity to [ ... ] First of all, the following is "constructive criticism", not a true flame :-) :-) :-). > > The incorporation of SQUASHING seems to be the primary objection which people > have to the PK series of archival programs. I think Phil knew this when he > wrote PK.. and very reasonably offered command level control and environmental > control switches to disable this if people did not like to use it. People in ^^^^^^^ Few people seem to use the switches, from the number of Squashed .ARCs that appear. This problem is getting better, as newer PKARCs do not do Squashing by default. > general seem to have ignored this and continually complain about the presence > of SQUASHING when it can be very conveniently disabled. Even if a SQUASHED > file is received by someone, considering how widespread Phil's programs are, I > can hardly believe that anyone with enough knowledge to download a file would ^^^^^^^^^ Beginners may not always know enough to unpack a Squashed file. After all, if the file has a .ARC extension, the ARC program (by SEA) should be able to de-arc it, right? :-) [ ... ] > I guess my biggest concern over this whole controversy is what it says about > the micro-computer hobby/industry as a whole. I see the future for good public > domain/shareware software growing dim in the light of this debate. Everyone > seems to concede that he wrote a fine program but there doesn't seem to be any > reward for doing this, only condemnation and second guessing. If the > microcomputer industry as a whole was this afraid of change we would still be > dosing DOS 1.0 with no pathnames, 8 sector floppies, primitive software and > little or no graphics (EGA, CGA) capabilities. I think that you're getting a little carried away here :-). No one's arguing against progress, it is just that PKARC seems to be causing confusion (and trouble for BEGINNERS). Is the additional confusion worth it? In the case of other advances (floppies, software, etc.), the confusion and trouble generated by the advancement was more than offset by the power, flexibility, etc. that it offered. Is this true of PKARC? I haven't done any timings myself, but, from an issue of DDJ a few month's back, I seem to recall that PKARC was only a few percent faster (5%????) than ARCA/ARCE. If I'm wrong, then please correct me. [ ... ] > Progress in any field is only achieved when individuals or concerns attempt > to improve upon the performance of existing techniques or products. Our > industry and the tremendous change it has produced in society as a whole is > the result of people striving to improve upon the standard. If this industry > gets the reputation of stagnation or unwillingness to change due to sheer > stubborness or jealousy we will no longer be able to advance as we have in the > last seven years. I actively seek out new software and technology and I feel > that since my job exists because of these advances my continued success will > be due to my ability to learn new things and take advantage of the edge that > these techniques give me in terms of increased and enhanced productivity. A good point, but we have to be careful that computers don't get a reputation for being harder to use than they really are. Imagine the beginner who, armed with ARC from SEA (if you want him to use PKARC, you've got to educate him -- ARC is advertised and gets much media coverage, while PKARC does not and spreads via word-of-mouth), tries to de-arc a Squashed file, again and again, until he finally gives up, with a taste of disgust in his mouth. You may think that this does not happen very often but, from reading comp.sys.ibm.pc, I think that this probably happens more often than we all would like. > > I would like to conclude by congratulating Phil on a very fine accomplishment. > I also hope that he continues to improve on an already fine product. > > > As always, > G.W. Wettstein > > > The usual disclaimers apply. These are my opinions and in no way reflect the > opinions of the North Dakota State University Quantum Chemistry Research > Group. > > ----------------------------------------------------------------------------- > ---------- -- Darryl Okahata hplabs!hpcea!hpsrla!darrylo CompuServe: 75206,3074 Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.
davidr@hplsla.HP.COM ( David M. Reed) (07/07/87)
Perhaps I am missing some points also. I really do not perceive complaints against PK as a program, only the choice for archive filename extension, which is creating some confusion. With SEA's ARChive program using the extension of .ARC, and the ZOO archive program using the extension of .ZOO (as was pointed out to me this morning), there is no question as to what kind of file it is, and how to use (manipulate) it. And if I come across a file with the .ARC extension, and my version of ARC can not handle it, then I would determine that it was assembled by a newer version of ARC that I did not have (but would then seek out). I would never have guessed that it was done by a completely different program (i.e. PK), and so would be continually frustrated, upset, and unsuccessful in my attempts to extract something from the .ARC file which was NOT an ARC file. To put it simply, PK should be using, by default, a different extension than .ARC if the file can NOT be manipulated by the most recent version of ARC. I enjoy PK, particularly for its speed (the savings in file space over ARC is often inconsequential to me), and would consider encouraging others to obtain a copy and use it, EXCEPT for the extension factor. Like commented elsewhere, when one has a file with the .ARC extension, one expects to be able to manipulate it on ANY system (UN*X, DOS, etc.) that can (compile and) run the ARC program, and there is now a confusion factor created by use of one extension to possibly mean more than one thing.
zu@ethz.UUCP (07/08/87)
I don't understand why so many of you are against squashing. It produces smaller archives, what's so bad about that? Ok, you have to use PKARC/PKXARC to get that feature. Beeing six times faster then doesn't seem to be a bug, at least to me. But I agree. THERE IS A BIG PROBLEM WITH SQUASHING !!! If an archive contains any squashed files it must have another extension then .ARC This way, everyone is free in his decision which archiver to use. If he sticks with ARC, ok that's up to him. But his won't have any right to complain if he tries to extract files from an archive with that new extension. ...urs
brianc@cognos.uucp (Brian Campbell) (07/15/87)
In article <5280010@hplsla.HP.COM> davidr@hplsla.HP.COM ( David M. Reed) writes: +-- | Perhaps I am missing some points also. I really do not perceive complaints | against PK as a program, only the choice for archive filename extension, which | is creating some confusion. With SEA's ARChive program using the extension of | .ARC, and the ZOO archive program using the extension of .ZOO (as was pointed | [ -- text deleted -- ] | | To put it simply, PK should be using, by default, a different extension than | .ARC if the file can NOT be manipulated by the most recent version of ARC. | [ -- text deleted -- ] +-- Does this mean that any code written for the new ANSI conformant C compilers (such as MSC) should also have a different extension if they use such things as function prototypes? Does this mean that all Turbo Pascal programs should have an extension other than .PAS simply because TP is not really a standard Pascal compiler. An extension does not *have* to uniquely identify the specific program that is need to compile it, or in this case, the specific program that is needed to unARC it. I use PKX?ARC exclusively on my PC. It can handle any archive ever produced by SEA's or V. Buerg's archivers. As an added plus, it is much faster and often produces better results. I really can't understand why you are complaining. Phil Katz has produced a truly useful program that is in direct competition with older archiving programs (hence the extensions are the same). In my opinion, PK has already won. I've been using PKARC for months and months now, and don't know of anyone who has tried it and not continued to use it to the exclusion of all other archivers. [Please don't send me mail telling me that you're an exception!] This includes about a dozen sysops that each have hundred's of archives to manage as well as fighting with users that can't read notices like: "All archives will be created using PKARC v3.5" In short, why don't you get with the times and use the newest, fastest archiver that's available? P.S. If you're out there, PK, thanks and can we have the source for the squashing algorithm? -- Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc Cognos Incorporated mail: 3755 Riverside Drive, Ottawa, Ontario, K1G 3N3 (613) 738-1440 fido: sysop@163/8