PKVSARC.TXT ----------- MSG #4496 Dated Sun Aug 28 22:23 1988 [76] Received From: TOM SHINN To: ISAAC RABINOVITCH Subj: PKARC (make that PKUNPAK) vs. ARC I think that's probably hitting the old nail on the head. ARC, or MAC (and don't forget Mc) is still pretty much the same thing. Can't say I completely agree with it in either case as there was never ANY confusion in my mind! Oh, well. Mark Twain was right. #4496 (Msg# 1 to 5001) Related Msgs *4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P > = Msg# Q or ? -> MSG #4766 Dated Sat Sep 03 14:07 1988 [49] Received From: JOHN NAVAS To: TOM SHINN Subj: PKARC (make that PKUNPAK) vs. ARC Re: Phil Katz > He just carelessly (or recklessly) used THEIR copyrighted program > name as part of his and then had the audacity to rub their noses > in it. He also "carelessly (or recklessly)" >> stole their source code < = Msg# Q or ? -> MSG #4768 Dated Sat Sep 03 14:13 1988 [51] Received From: JOHN NAVAS To: TRUETT SMITH Subj: PKARC (make that PKUNPAK) vs. ARC > Unless someone can show me precise legal language in the judgement > saying otherwise, I don't think either the structure of the files > produced or the file name extension was at issue As the expert for SEA in the case, I have read all the papers, and I can assure you that the trademark use in the file name extension >> for ARChives that were incompatible with SEA due to "squashing" << was very much at issue! #4768 (Msg# 1 to 5001) Related Msgs 4496 4766 *4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4770 Dated Sat Sep 03 14:16 1988 [50] Received From: JOHN NAVAS To: ISAAC RABINOVITCH Subj: PKARC (make that PKUNPAK) vs. ARC > I've noticed something interesting -- the latest versions of ARC > and PKPAK are out, and there are *no* changes beyond the name of > the latter program! So has SEA -- and a request for a >> contempt citation << has been filed against PKWARE! Given that PK stole SEA's source code, should we be surprised that he failed to comply with the settlement? #4770 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 *4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4774 Dated Sat Sep 03 15:30 1988 [51] Received From: ISAAC RABINOVITCH To: JOHN NAVAS Subj: PKARC (make that PKUNPAK) vs. ARC That's the first I heard that Katz is supposed to have stolen SEA's source code. Are you sure you read it right? They might just be accusing him of stealing their expertise, a subtle but important distinction. I think I probably basically share your dim view of Katz's approach to software, etc. But you ought to remember that the main reason PKARC is so popular is that it's bleeding *fast*. I presume he didn't steal the code for *that* from SEA, since SEA is still hopeless in that department. (This thread probably ought to be in M9, though computer law/ethics arguments are complicated enough to possibily rate their own SIG!) #4774 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 *4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4793 Dated Sat Sep 03 18:05 1988 [53] Received From: CARL LINDEN To: JOHN NAVAS Subj: PKARC (make that PKUNPAK) vs. ARC If you use Vern Buerg's programs, Arca & Arce will work in much less memory that PKXarc, and are comparable for speed. #4793 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 *4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4804 Dated Sat Sep 03 19:18 1988 [54] From: JOHN NAVAS To: CARL LINDEN Subj: PKARC (make that PKUNPAK) vs. ARC > If you use Vern Buerg's programs, Arca & Arce will work in much > less memory that PKXarc, and are comparable for speed. They are also legally licensed by SEA. #4804 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 *4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4805 Dated Sat Sep 03 19:22 1988 [54] Received From: JOHN NAVAS To: ISAAC RABINOVITCH Subj: PKARC (make that PKUNPAK) vs. ARC > That's the first I heard that Katz is supposed to have stolen > SEA's source code. Are you sure you read it right? Yes -- I am the expert for SEA and I personally found the conclusive proof of flat-out code stealing! (That's why Phil settled so fast.) > But you ought to remember that the main reason PKARC is so popular > is that it's bleeding *fast*. I disagree. I know of many that use it because ARC won't unsquash the trojan archives that PKARC creates. #4805 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 *4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4806 Dated Sat Sep 03 19:48 1988 [56] Received From: ISAAC RABINOVITCH To: JOHN NAVAS Subj: PKARC (make that PKUNPAK) vs. ARC It took me a moment to figure out what you meant by "trojan archive" -- I thought you meant that PKARC archives plant bugs in the systems they're copied to. That *is* what the word "trojan" means to most poeple. But of course, you mean that nonsense with PKARC pre-empting ARC conventions without allowing for ARC compatibility. Now it's perfectly true that this lack of compatibility would force people to switch -- but they don't need to be forced. I know many people who didn't even stick with ARC long enough to encounter the compatibility problem, myself among them. I switched when I noticed a five-fold (conservative estimate) improvement in execution time. This BBS is a case in point. All the ARC files here (so the sysops say) are compatible ("non-trojan", you would say) to accomdate people who have stuck with ARC. So no-one here *has* to use PKARC. But if you ask around, you'll find that most users here use PKARC -- it's faster. I'm interested in your evidence on code theft. I'd enjoy reading the details if you'd elaborate. (Preferrably in M11, in fact this thread really belongs there.) But I doubt if proof of code theft was crucial to the settlement. If it were, then Katz would've had to withdraw the program, not just change the name. #4806 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 *4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4823 Dated Sat Sep 03 22:07 1988 [52] Received From: TOM SHINN To: JOHN NAVAS Subj: PKARC (make that PKUNPAK) vs. ARC Re: Phil Katz > He also "carelessly (or recklessly)" >> stole their source code < = Msg# Q or ? -> MSG #4837 Dated Sun Sep 04 08:05 1988 [48] Received From: JOHN NAVAS To: ISAAC RABINOVITCH Subj: PKARC (make that PKUNPAK) vs. ARC > I thought you meant that PKARC archives plant bugs in the systems > they're copied to. In a very real sense, that is exactly what it does. > you mean that nonsense with PKARC pre-empting ARC conventions > without allowing for ARC compatibility. It's not 'nonsense' that Phil Katz deliberately set out to corrupt and co-opt someone else's standard for his own personal gain. What he did was both unethical and illegal (his theft of ARC source code notwithstanding). And squashing doesn't even qualify as a legitimate improvement (typically -2% to +5%). > I switched when I noticed a five-fold (conservative estimate) > improvement in execution time. The difference is much smaller than that. Why not check it -- and include Buerg's ARCE (that's bundled with ARC) to be fair! > All the ARC files here (so the sysops say) are compatible > ("non-trojan", you would say) Converted at considerable time and effort, I might add. > to accomdate people who have stuck with ARC. As well as all the non-IBM systems that can only run ARC! #4837 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 *4837 4838 4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4838 Dated Sun Sep 04 08:11 1988 [49] Received From: JOHN NAVAS To: ISAAC RABINOVITCH Subj: PKARC (make that PKUNPAK) vs. ARC > So no-one here *has* to use PKARC. On many other boards you do. > I'm interested in your evidence on code theft. I'd enjoy reading > the details if you'd elaborate. I compared Phil's source code to SEA's source code, as well as to other public domain sources. Except for minor changes, portions of Phil's code are *exactly* the same as SEA's code. You can even see where Phil deleted SEA's comments (and left the empty space). More than that I can't say, by Court order (at Phil's request, I might add). > But I doubt if proof of code theft was crucial to the settlement. I guess you know more than I do, even though I was there and you weren't! > If it were, then Katz would've had to withdraw the program, not > just change the name. He has to do far more than change the name -- which is why SEA has requested a contempt citation for non-compliance with the Court Order. #4838 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 *4838 4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4858 Dated Sun Sep 04 13:41 1988 [46] Received From: ISAAC RABINOVITCH To: JOHN NAVAS Subj: PKARC (make that PKUNPAK) vs. ARC >In a very real sense, [planting bugs] is exactly what [PKARC] does. You keep throwing out assertions like that without any elaboration. You should realize that not everyone agree with things that you consider "obvious". It might be possible that Katz deliberately introduced compatibility problem to squeeze out ARC (though calling it a trojan is stretching things); but then again Katz wouldn't be the first hacker to introduce painful kludges into a system to achieve a marginal improvement in performance. >Why don't you actually compare them, to be fair. Come on John, have *some* respect for other people's intelligence. Oh, never mind, I can see it'll take hard numbers to convince you that I've actually done a decent comparison. So this morning, I ran ARC and PKARC on one of my big directories (709K) with lots of files varying in size and content, including some big object and text files. Results: Time to Size/ Time to create comp. fact. extract PKARC, with squashing 59.65 sec 444812/38% 56.08 sec PKARC, with ARC compat. 1.07 min 453174/37% 1.05 min ARC 11.71 min 482377/33% 5.33 min #4858 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 *4858 4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4861 Dated Sun Sep 04 13:55 1988 [45] Received From: ISAAC RABINOVITCH To: JOHN NAVAS Subj: PKARC (make that PKUNPAK) vs. ARC (continued from previous message) I downloaded the new ARC a couple weeks ago, but it didn't seem to perform much (if any) faster, so I discarded it, and didn't feel like getting it again just for this test. I'm confident that it would do little, if anything to invalidate my results. As for ARCE, it is *not* bundled with ARC, it's a separate product that SEA took the the liberty of including on their shareware disk -- if you want to pay for it, you have to send a separate contribution to Buerg. I did notice that ARC seems to be about as fast processing very small files as PKARC. I think most of PKARC's speed comes from more elaborate buffering (I noticed a lot more disk activity with ARC than with PKARC), which doesn't make any difference on small files. But it's the big files where speed counts, no? I share your dim view of the problems Katz has (intentionally or not) caused. But that's really beside the point. You're not gonna understand this hassle until you stop making assumptions about what other people are doing and why. #4861 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 *4861 4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4862 Dated Sun Sep 04 14:05 1988 [46] Received From: TRUETT SMITH To: JOHN NAVAS Subj: PKARC (make that PKUNPAK) vs. ARC Let's be more specific, if you are willing -- Was it the imcompatibilities of the similarly named files that caused a problem or was it the name itself? If you are going to claim that noone can use 'ARC' as a DOS file name without someone's permission, then I will claim that that is an 'unconscionable restriction' in light of the limitations on files names under that system. All it takes, in your case, is about 3,000 copyrights or trademarks and John Navas will be unable to use MS-DOS for ANY commercial purpose without paying through the nose. Truett Lee Smith, Sunnyvale, CA #4862 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 *4862 4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4874 Dated Sun Sep 04 18:48 1988 [43] Received From: CARL LINDEN To: TRUETT SMITH Subj: PKARC (make that PKUNPAK) vs. ARC I think you are missing the point, Truett. There are many programs used, mainly by SYSOPs, which handled arc files, and the confusion caused by Katz gave a lot of people a lot of trouble when it was impossible to distinguish between files created by Pkarc and those created by SEA's Arc program. I think that confusion, added to his attitude that caused his downfall. He tried an underhanded maneuver to get many arc files created that couldn't be used by the other programs that used arc files, thereby sort of forcing us to use his unarcer. The court decision was not made public (the sgreement part), and what was said did not necessarily realte to the actual trouble Katz caused. The world of SYSOPs (FIDO and other who participate in mail networks) are for the most part o very co-operative group, and Katz very obviously tried to steamroller all of us. He got off lighter than he deserved. BTW: I no longer use a=either of Katz' programs. ARCA and ARCE, Vern Buerg's programs are as fast, and take much less memory, and work with the rest of the world which uses .arc files. Pkarc & Pkxarc no longer exist as far as I am concerned. Other SYSOPs have dome likewise. #4874 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 *4874 4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4928 Dated Mon Sep 05 07:17 1988 [38] Received From: BRAD KIDDER To: ISAAC RABINOVITCH Subj: PKARC (make that PKUNPAK) vs. ARC Thanks for the comparison. It is nice to see someone use FACTS for a change. I would not knowingly buy stolen property, but I am not going to stop using PKARC because of this. #4928 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 *4928 4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4988 Dated Tue Sep 06 00:11 1988 [4] From: TRUETT SMITH To: CARL LINDEN Subj: PKARC (make that PKUNPAK) vs. ARC Carl: If use of a similar file name extension which is not compatible is to be considered unethical, then IBM is grossly unethical because its various verious software products products produce .EXE and .COM files which are clearly not executable by earlier versions. Try to run a DOS ver. 3.3 .BAT file in an earlier version. The fact is, the available name space for extensions is limited, so letting any company attach a claim on an extension is not justifiable. If we allow this demented action to continue, then the software industry is in deep yogurt. If we let Big Blue produce the same file name with incompatible files, then we must let little guys like Katz do it. (Please note: I do not argue at all with the contention that Katz 'stole' SEA's source code -- he clearly did; nor do I argue with the fact he violated their copyright in the 'look and feel' of his program to an extent presently protected by court opinion -- he clearly did.) Also, please note that any user who claims to have been inconvenienced is admitting that he used the program without reading the documentation -- to what extent is such an idiot to be rewarded? Is a manufacturer liable for what idiots do with his product (yeah, I know, some people think so -- yech!)? Truett Lee Smith, Sunnyvale, CA #4988 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 *4988 4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4993 Dated Tue Sep 06 01:12 1988 [2] From: JOHN NAVAS To: ISAAC RABINOVITCH Subj: PKARC (make that PKUNPAK) vs. ARC > I can see it'll take hard numbers to convince you that I've > actually done a decent comparison. Which versions did you test? Did you use ARCE (which is bundled with ARC)? Did you time the time it take to add a file to an existing archive? In other words, were the tests both fair and representative? I can easily put together tests that give significantly different results (including cases where squashing is worse than crunching). With apologies to Mark Twain: "There are lies, damn lies, and benchmarks!" #4993 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 *4993 4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4994 Dated Tue Sep 06 01:18 1988 [1] From: JOHN NAVAS To: ISAAC RABINOVITCH Subj: PKARC (make that PKUNPAK) vs. ARC > SEA took the the liberty of including on their shareware disk Correction: SEA and Buerg have a license agreement; ARCE is included with Buerg's permission. > I did notice that ARC seems to be about as fast processing very > small files as PKARC. ... But it's the big files where speed > counts, no? That depends. Personally, I have far more small files than large ones in my personal archives. > You're not gonna understand this hassle until you stop making > assumptions about what other people are doing and why. Thanks for the lecture. I guess you know more about it than I do. #4994 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 4993 *4994 4995 R (N) P < > = Msg# Q or ? -> MSG #4995 Dated Tue Sep 06 01:23 1988 [1] From: JOHN NAVAS To: TRUETT SMITH Subj: PKARC (make that PKUNPAK) vs. ARC > Was it the imcompatibilities of the similarly named files that > caused a problem or was it the name itself? Both. > If you are going to claim that noone can use 'ARC' as a DOS file > name without someone's permission, then I will claim that that is > an 'unconscionable restriction' in light of the limitations on > files names under that system. ARC as a DOS file that stands for an archive as SEA coined the term is a trademark entitled to the same legal protections as any other trademark. You can be sure that IBM would object to any commercial distribution of files with an IBM extension that suggested that those files were in some/any related to IBM. The same principle applies to ARC. A completely unrelated use of ARC might well be legal. #4995 (Msg# 1 to 5001) Related Msgs 4496 4766 4768 4770 4774 4793 4804 4805 4806 4823 4837 4838 4858 4861 4862 4874 4928 4988 4993 4994 *4995 R (N) P < = Msg# Q or ? -> ---------------------------------------------------------------------- MSG #4807 Dated Sat Sep 03 20:42 1988 [51] From: ALI MAHROUYAN To: ALL Subj: PKARC (make that PKUNPAK) vs. ARC Look. SEA has simply been sitting on their butts doing nothing to help the Archiving technology. Phil Katz has been busting his rear, continually improving his Archiving programs. SEA obviously saw some sort of minute violation in Phil's work and let him proceed so that one day they could sue him and steal his source code after painstaking work on Phil's part. This kind of behavior is digusting and repulsive. Everyone who has half a brain knows that Phil's Archivers are the best around in speed and size. Their is NO dispute. For some reason some of you people have decided to be a little stubborn when it comes to squashing. Squashing is a great method to reduce file size. Just because SEA doesn't support it, doesn't mean it is bad. SEA is SO SLOW. It's unbelievable. And as for memory, Pkware includes several versions for minimal memory required to run the program. I say that we all boycot SEA forever, due to their sleezy behavior and promote allegience(sp?) to Phil. His product is simply better. #4807 (Msg# 1 to 5001) Related Msgs *4807 4839 4840 4877 4878 4918 4951 4992 5000 R (N) P > = Msg# Q or ? -> MSG #4839 Dated Sun Sep 04 08:17 1988 [47] Received From: JOHN NAVAS To: ALI MAHROUYAN Subj: PKARC (make that PKUNPAK) vs. ARC > SEA has simply been sitting on their butts doing nothing to help > the Archiving technology. SEA did *all* the work to pioneer the technology. > Phil Katz has been busting his rear, continually improving his > Archiving programs. He's also been 'busting his rear' stealing SEA's source code! > SEA obviously saw some sort of minute violation in Phil's work Only if you consider outright theft a 'minute violation'. > let him proceed so that one day they could sue him On the contrary -- they spent months trying to get him to take a license (as Vern Buerg did). > and steal his source code after painstaking work on Phil's part. You've got the stealing backwards! > This kind of behavior is digusting and repulsive. Phil's conduct certainly is! > Phil's Archivers are the best around in speed and size. Speed yes (though only comparable to Buerg's legitimate ARChivers), but size no. PKARC sometimes is a tiny bit better, and sometimes a tiny bit worse, than ARC. #4839 (Msg# 1 to 5001) Related Msgs 4807 *4839 4840 4877 4878 4918 4951 4992 5000 R (N) P < > = Msg# Q or ? -> MSG #4840 Dated Sun Sep 04 08:20 1988 [49] Received From: JOHN NAVAS To: ALI MAHROUYAN Subj: PKARC (make that PKUNPAK) vs. ARC > For some reason some of you people have decided to be a little > stubborn when it comes to squashing. Squashing is a great method > to reduce file size. Under ideal conditions, it's worth only 2-5% over crunching; under less than ideal conditions, it's actually worse. Have you ever really tested it? Or did you just take Phil's word for it? > Just because SEA doesn't support it, doesn't mean it is bad. It does if the files are called ARC's. Phil should at least have used >> a different filename extension < And as for memory, Pkware includes several versions for minimal > memory required to run the program. A kludge. > I say that we all boycot SEA forever, due to their sleezy behavior > and promote allegience(sp?) to Phil. Do you support shoplifting too? #4840 (Msg# 1 to 5001) Related Msgs 4807 4839 *4840 4877 4878 4918 4951 4992 5000 R (N) P < > = Msg# Q or ? -> MSG #4877 Dated Sun Sep 04 18:58 1988 [39] Received From: CARL LINDEN To: JOHN NAVAS Subj: PKARC (make that PKUNPAK) vs. ARC My reaction was to dump all of the Pk files I have, and remove the PK stuff from my BBS. Katz, and those like him, who needs 'em. #4877 (Msg# 1 to 5001) Related Msgs 4807 4839 4840 *4877 4878 4918 4951 4992 5000 R (N) P < > = Msg# Q or ? -> MSG #4878 Dated Sun Sep 04 19:00 1988 [38] Received From: CARL LINDEN To: JOHN NAVAS Subj: PKARC (make that PKUNPAK) vs. ARC One point being overlooked in all of the discussion is the lack of error detection in Katz programs. He sacrificed data integrity for speed. Do you really want it fast, even if its garbage? #4878 (Msg# 1 to 5001) Related Msgs 4807 4839 4840 4877 *4878 4918 4951 4992 5000 R (N) P < > = Msg# Q or ? -> MSG #4918 Dated Mon Sep 05 05:15 1988 [36] From: JUDITH MOORE To: ALI MAHROUYAN Subj: PKARC (make that PKUNPAK) vs. ARC With your reasoning, we should applaud all technologies that make advances based on spying and theft (industrial or governmental). Obviously the person/agency that steals is 'smarter' than the one that wastes time in developing the original concept. As Isaac says, this belongs in M9. Let's discuss it there. #4918 (Msg# 1 to 5001) Related Msgs 4807 4839 4840 4877 4878 *4918 4951 4992 5000 R (N) P < > = Msg# Q or ? -> MSG #4951 Dated Mon Sep 05 14:27 1988 [26] From: ISAAC RABINOVITCH To: CARL LINDEN Subj: PKARC (make that PKUNPAK) vs. ARC Carl, are you just indulging in your usual mindless rudeness, or do you have a point? Are you saying that if I used fidonet I'd know about the problems PKARC has caused? Well, if you bothered to read anything I'd written you'd know that I *am* aware of the compatbility problems PKARC caused. And I *have* used fidonet. Look, the religious aspects of this argument are pretty useless. People assume that you're either a stalwart upholder of the True Faith of SEA, or a skulking follower of the Katz Cult. So when someone points out that PKARC is faster than ARC and that's why most people use it instead of ARC, the ARC loyalists expect him to defend PKARC and Katz in every respect. That's childish. It's perfectly true that Katz's hacking around with compression methods achieved marginal speed/space improvements at great cost to his users. But how many programmers *haven't* done that? Why do you think we call them "hackers"? If we banned all kludgy, flaky software, this BBS wouldn't have a library at all! And the legal/moral argument is a waste of time. Katz and SEA have settled, the details of who ripped off who are secret, and nobody really has any basis to condemn anybody. Let's drop it. #4951 (Msg# 1 to 5001) Related Msgs 4807 4839 4840 4877 4878 4918 *4951 4992 5000 R (N) P < > = Msg# Q or ? -> MSG #4992 Dated Tue Sep 06 00:36 1988 [4] From: TRUETT SMITH To: ISAAC RABINOVITCH Subj: PKARC (make that PKUNPAK) vs. ARC If we banned all kludgy, flaky software -- then this BBS not only would not have a library, this BBS would not exist. Period. Truett Lee Smith, Sunnyvale, CA #4992 (Msg# 1 to 5001) Related Msgs 4807 4839 4840 4877 4878 4918 4951 *4992 5000 R (N) P < > = Msg# Q or ? -> MSG #5000 Dated Tue Sep 06 01:52 1988 [0] From: JOHN NAVAS To: CARL LINDEN Subj: PKARC (make that PKUNPAK) vs. ARC > My reaction was to dump all of the Pk files I have, and remove the > PK stuff from my BBS. I applaud your responsible actions! #5000 (Msg# 1 to 5001) Related Msgs 4807 4839 4840 4877 4878 4918 4951 4992 *5000 R (N) P < = Msg# Q or ? ->