msmith@topaz.rutgers.edu (Mark Robert Smith) (08/09/88)
WEll, Phil has released PKPAK 3.61, with the obvious name change and a bug fix. It seems that big bad SEA forced him to change the name, AND forced him to abandon even the compression algorithms that he was using. Now, he has until early 1989 to develop a new program. I'm gonna vote with my wallet. I have destroyed all SEA programs that I have, and I am sending Phil some bucks. In the docs for this, he requests the usual $20 if you like the program, and for $47 or more, he'll send you the new program when it comes out. I'm sending in at least $47, maybe more. From a poor college student, that's a statement. I urge you all to do the same. I also urge Rahul Dhesi to switch to Phil's new standard as soon as it is available. I also urge SIMTEL20 to convert its archives to the new standard. We need to show SEA that their kind of competition through litigation is unacceptable, and that competition through improvement is the only acceptable form of competition. Mark -- Mark Smith (alias Smitty) "Be careful when looking into the distance, 61 Tenafly Road that you do not miss what is right under your nose." Tenafly, NJ 07670 {backbone}!rutgers!topaz.rutgers.edu!msmith msmith@topaz.rutgers.edu Bill and Opus in '88!!!
manes@marob.MASA.COM (Steve Manes) (08/09/88)
From article <Aug.8.19.49.42.1988.27547@topaz.rutgers.edu>, by msmith@topaz.rutgers.edu (Mark Robert Smith): > I'm gonna vote with my wallet. I have destroyed all SEA programs that > I have, and I am sending Phil some bucks. In the docs for this, he > requests the usual $20 if you like the program, and for $47 or more, > he'll send you the new program when it comes out. I'm sending in at > least $47, maybe more. From a poor college student, that's a > statement. > I urge you all to do the same. I also urge Rahul Dhesi to switch to > Phil's new standard as soon as it is available. Uhhh... why should Rahul Dhesi feel compelled to switch to some "standard" that Phil Katz hasn't even written yet? That aside, ZOO is a much more OS-transparent file archiver and PKARC is still wedded to MS-DOS with its filename and case restrictions. I need an archiver that can talk to both my Unix system and my DOS system and PKxxx ain't it. Better, let Phil adopt Rahul's internal structure. Fact is, while Rahul was trying to tie together many operating systems with a "universal archiver", Phil's program created a Tower of Babel in the .ARC arena. > We need to show SEA that > their kind of competition through litigation is unacceptable, and that > competition through improvement is the only acceptable form of > competition. To a large extent, Phil invited the action made against him. I'm sorry it resulted in a lawsuit but there was bad blood between SEA and PKWARE from the moment Squashing was installed and left SEA answering torrents of irate user mail because its archiver was "broken". Rahul Dhesi managed to produce a wonderful (and public domain, with source) file archiver that used the same L-Z compression method that lies at the base of all these archivers without stepping on anyone's toes or confusing users with an incompatible, proprietary file format masquerading as a familiar, SEA .ARC file. Speaking as both a software developer and a sysop, and knowing to some extent how all these guys think (because I had them all in a dedicated discussion on file archivers for several months), Phil should have cut the thread with the .ARC file extension when he ceased being a truly ARC-compatible program. I side with Thom Henderson on this. Granted, PKARC is a better utility but "better" doesn't give one the right to grab someone else's market by destroying confidence in his product. Besides, if "improvement" is all that matters, did you try the DWC archiver? -- Steve Manes Roxy Recorders, Inc. Magpie-HQ BBS UUCP : {rutgers|cmcl2}!hombre!magpie!manes (212)420-0527 Smail: manes@MASA.COM
msmith@topaz.rutgers.edu (Mark Robert Smith) (08/09/88)
OK, It appears I put my foot in my mouth this time. Rahul, Sorry, I forgot that you are the author of ZOO. What I meant was that if you currently use SEA ARC for comp.binaries.ibm.pc, you should switch to PKPAK, for the reasons I outlined. However, if you see (when it comes out) that ZOO is better than Phil's new program, or that Phil's new program isn't portable, please use ZOO. Steve, Sorry, but stealing somebody else's market is a standard practice inthe world of software. Else, why are word processors able to read WordStar's format? Why can Excel read Lotus 123? Why can Paradox import dBase and RBase files? It is standard to attempt to grab somebody else's users. That's called competition, and is the backbone of the American business world. If you build a better, but still compatible mousetrap, the world will beat a path to your door. Mark -- Mark Smith (alias Smitty) "Be careful when looking into the distance, 61 Tenafly Road that you do not miss what is right under your nose." Tenafly, NJ 07670 {backbone}!rutgers!topaz.rutgers.edu!msmith msmith@topaz.rutgers.edu Bill and Opus in '88!!!
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/10/88)
In article <Aug.8.19.49.42.1988.27547@topaz.rutgers.edu> msmith@topaz.rutgers.edu (Mark Robert Smith) writes: | WEll, Phil has released PKPAK 3.61, with the obvious name change and a | bug fix. | It seems that big bad SEA forced him to change the name, AND forced SEA and PKware are about the same size | him to abandon even the compression algorithms that he was using. Not true. He will abandon the ARC compatible file format, as did zoo and dwc. The code for the compression algorithms is in the public domain or available for free use. | I urge you all to do the same. I also urge Rahul Dhesi to switch to | Phil's new standard as soon as it is available. I also urge SIMTEL20 | to convert its archives to the new standard. We need to show SEA that | their kind of competition through litigation is unacceptable, and that | competition through improvement is the only acceptable form of | competition. I don't think that anyone want to switch until/unless the UNIX source is available for the new compressor. I will probably switch all my postings to zoo format as soon as the new version comes over the net for readers to use, because I'm tired of having to move stuff to a PC to read the docs to see if I should bother to move them to a PC at all. BTW: I think that the settlement reflects the legal issues perfectly. Both zoo and dwc invented new file formats, help menus, directory listings, and commands. PKware "borrowed" most of the above, with very slight changes. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
brad@looking.UUCP (Brad Templeton) (08/10/88)
The posting said it was a "judgement in consent." Could somebody who knows American law tell us if that means what I think it means, namely that it's actually a settlement, agreed to by both parties, and not actually a judgement? If that's what it is, then aside from the usual clause that says "PK admits no fault or blame," PK has appeared to agree that he did infringe on SEA. (He has actually agreed to stop the alleged infringements). So I find destroying all SEA programs and sending money to PKWARE a rather unusual response to this, to say the least! -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
wacey@paul.rutgers.edu ( ) (08/10/88)
Inovation is one thing. Reading someone's source code, converting it to assembler and saying that you wrote it is quite another. From the articles on the settlement this appears to be the case with PKARC. iain wacey
rmpinchback@crocus.waterloo.edu (Reid M. Pinchback) (08/10/88)
In article <1916@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: ..... > >If that's what it is, then aside from the usual clause that says "PK >admits no fault or blame," PK has appeared to agree that he did infringe >on SEA. (He has actually agreed to stop the alleged infringements). > >So I find destroying all SEA programs and sending money to PKWARE a rather >unusual response to this, to say the least! >-- >Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473 Settling a suit has very little to due with "agreeing that he did infringe on SEA". As a commercial lawyer once told me, even when you are 100% in the right, you only have at best a 50% chance of winning the suit. That is the nasty part about using litigation to hammer your competition (though I'm NOT saying that this was SEA's motivation). It is very easy for a financially stronger company to destroy a weaker one this way... the defendant can't afford the legal costs alone, should he lose. It's a favourite trick of Intel, from what I've read about some of their legal battles. Moral of the story? Don't assume that either party was in any sense found, or admitted to, guilt, unless you have access to the judicial commentary (which probably won't say much if the american legalistic lingo does in fact mean that they settled out of court). Reid Pinchback Undergraduate, CS/C&O U. of Waterloo (the opinions here are, of course, my own, and hence are not representative of the opinions of the University, my family, or my Philodendron.)
browning@cory.Berkeley.EDU (Craig Browning) (08/10/88)
In article <11792@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <Aug.8.19.49.42.1988.27547@topaz.rutgers.edu> msmith@topaz.rutgers.edu (Mark Robert Smith) writes: >| I urge you all to do the same. I also urge Rahul Dhesi to switch to >| Phil's new standard as soon as it is available. I also urge SIMTEL20 >| to convert its archives to the new standard. We need to show SEA that >| their kind of competition through litigation is unacceptable, and that >| competition through improvement is the only acceptable form of >| competition. > I don't think that anyone want to switch until/unless the UNIX source >is available for the new compressor. You're in the minority, as I will point out again. >I will probably switch all my >postings to zoo format as soon as the new version comes over the net for >readers to use, because I'm tired of having to move stuff to a PC to >read the docs to see if I should bother to move them to a PC at all. And I hope the moderator repaks (spelling intentional) them to the standard format in use, ARC or whatever. Otherwise we'll have to keep several de-arcers around to use postings. >BTW: I think that the settlement reflects the legal issues perfectly. >Both zoo and dwc invented new file formats, help menus, directory >listings, and commands. PKware "borrowed" most of the above, with very >slight changes. What a weird opinion: Speed is the difference. What's wrong with compatibility? Imcompatibility because word processors use their own format is causing huge problems, even for me. Files have to be saved in ASCII, losing control codes, then loaded and modified in a new word processor, and/or be professionally converted... ARC and PKARC's compatibility helped make them, especially PKARC, popular, yet you praise diversity of formats. Besides, Katz is now going to release a new format, so you should be happy; why don't I see you praising it, saying you'll convert to it? Maybe it will do tree structures, something I haven't seen a practical use for yet but a few seem to strongly desire. People have been saying that Katz deserved this, but I think the only reason SEA 'had' to do this is selfish anti-consumer 'save the bad product through legislation' attitudes. People wouldn't use PKARC if it wasn't so fast, an SEA should improve their product. How can the format be proprietary when it's basically Huffman? Yes, the ARC extension was apparently protected (more craziness, how about ".DOC"? ".WP"? etc.? ) but I don't see any problem with re-writing code to get efficient storage, and what will happen to Vernon Buerg's programs that use ARC format? Most of us use clones instead of IBM's that are compatible and much more of a copy than Katz, but how many of us want to pay the extra to not infringe IBM's copyright? > bill davidsen (wedu@ge-crd.arpa) Craig
spcecdt@ucscb.UCSC.EDU (Space Cadet) (08/10/88)
In article <356@marob.MASA.COM> manes@marob.MASA.COM (Steve Manes) writes: >Better, let Phil adopt Rahul's internal structure. Fact is, while Rahul I think that's a very good idea. The only reason I prefer PK*** over ZOO is that PK*** is, in my experience, about twice as fast. The files are also better compressed, but the difference is not nearly so dramatic. Since the algorithms are basically the same, it would seem that the fast code Phil wrote could be applied to a version of ZOO, if not the better compression. The internal structure of ZOO is certainly much better; it would be nice to have the best of both worlds. Too bad that such an adoption is probably wishful thinking. Maybe someone else will speed ZOO up? It would certainly build support... -- > John H. DuBois III # spcecdt@ucscb.ucsc.EDU ...!ucbvax!ucscc!ucscb!spcecdt <
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/10/88)
In article <Aug.9.08.23.10.1988.12189@topaz.rutgers.edu> msmith@topaz.rutgers.edu (Mark Robert Smith) writes: | Steve, Sorry, but stealing somebody else's market is a standard | practice inthe world of software. Else, why are word processors able | to read WordStar's format? Why can Excel read Lotus 123? Why can | Paradox import dBase and RBase files? It is standard to attempt to | grab somebody else's users. What's not standard is to write Wordstar or 1-2-3 files which can not be read by the original program. The idea seems to be "once you use my program you can never go back." -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
ralf@b.gp.cs.cmu.edu (Ralf Brown) (08/10/88)
In article <4452@saturn.ucsc.edu> spcecdt@ucscb.UCSC.EDU (Space Cadet) writes: } I think that's a very good idea. The only reason I prefer PK*** over }ZOO is that PK*** is, in my experience, about twice as fast. The files }are also better compressed, but the difference is not nearly so dramatic. Most of the speed difference comes from the fact that ZOO is written entirely in C, while PK*** is written mostly in assembler. That's why there are Unix and VMS versions of ZOO, but not PK***. If someone were to recode ZOO in assembly, it would probably be faster than PK*** at compressing, because it would only have to do LZW, rather than doing LZW and in parallel estimating Huffman coding (for "squeezing"). -- {harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school) ARPA: RALF@B.GP.CS.CMU.EDU |"Tolerance means excusing the mistakes others make. FIDO: Ralf Brown at 129/31 | Tact means not noticing them." --Arthur Schnitzler BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA -=-=- DISCLAIMER? I claimed something?
mikes@mntgfx.mentor.com (Mike Stanbro) (08/11/88)
From article <1916@looking.UUCP>, by brad@looking.UUCP (Brad Templeton): > The posting said it was a "judgement in consent." Could somebody who > knows American law tell us if that means what I think it means, namely > that it's actually a settlement, agreed to by both parties, and not > actually a judgement? My wife is a pseudo-lawyer (otherwise known as a para-legal). When asked what "judgement in consent" meant she said that it is similar to "confession of judgement". Here is the legal dictionary definition: "Entry of a judgement upon a written admission or confession of the debtor without the formality, time, or expense of an ordinary legal proceeding." In her own words, it means that rather than continue with a legal process that is too expensive to afford and has little chance of winning, PK decided to settle but hasn't the money at this time to pay the damages to SEA. A formal judgement was recorded in the county of PK's residence that requires PK to pay the damages to SEA at a latter date. -- ----------------------------------------------------------------- Mike Stanbro, Advanced Development, Mentor Graphics Corporation 8500 SW Creekside Place, Beaverton OR 97005, (503) 626-1437 ...!{sequent,tessi,apollo}!mntgfx!mikes OR mikes@pdx.MENTOR.COM
zeeff@b-tech.UUCP (Jon Zeeff) (08/11/88)
I have to agree that the best thing would be for Phil to develop a super fast 100% zoo compatible program for dos. Then DOS users could use it and un*x, etc users can use the C version. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
chuck@eneevax.UUCP (Chuck Harris) (08/11/88)
In article <1916@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: >The posting said it was a "judgement in consent." Could somebody who >knows American law tell us if that means what I think it means, namely According to "Black's Law Dictionary": "Consent judgement. A judgement, the provision and terms of which are settled and agreed to by the parties to the action. See also "Consent" (Consent decree); and Agreed Judgement, supra "Consent decree, see Decree. which says: "Consent decree. Agreement by defendant to cease activities asserted as illegal by government (e.g. deceptive advertising practices as alleged by F.T.C). Upon approval of such agreement by the court the government's action against the defendant is dropped... "Agreed judgement. A judgement entered on agreement of the parties, which receives the sanction of the court, and it constitutes a contract between the parties to the agreement when court gives the agreement its sanction. What this all means I leave to your imagination. -------------------------------------------------------------------------- Chuck Harris, C.F. Harris - Consulting
malloy@nprdc.arpa (Sean Malloy) (08/11/88)
In article <11814@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: |In article <Aug.9.08.23.10.1988.12189@topaz.rutgers.edu> msmith@topaz.rutgers.edu (Mark Robert Smith) writes: | || Steve, Sorry, but stealing somebody else's market is a standard || practice inthe world of software. Else, why are word processors able || to read WordStar's format? Why can Excel read Lotus 123? Why can || Paradox import dBase and RBase files? It is standard to attempt to || grab somebody else's users. | | What's not standard is to write Wordstar or 1-2-3 files which can not |be read by the original program. The idea seems to be "once you use my |program you can never go back." Why should Phil Katz be any different than some of the big software houses? Lotus 1-2-3 v2.0 .WK1 files can't be read by Lotus 1-2-3 v1.A, but 1-2-3 automatically writes a .WK1 file when you save your spreadsheet. You can read a WordPerfect 4.2 file into WordPerfect 5.0, but the file WordPerfect 5.0 writes can't be read by Wordperfect 4.2 -- and there's no way to convert it back, while Lotus at least has a WK1 to WKS conversion utility. If you add a new function to a program that reads the function types out of the file the program is operating on, then there's no way you can keep total downward compatibility, because the old program won't know how to operate on the new information. At least PKARC had the -oct flags that let you write ARC files that SEA's ARC program would read. That's more than WordPerfect does. Sean Malloy Navy Personnel Research & Development Center San Diego, CA 92152-6800 malloy@nprdc.arpa
davis@venus.ee.rochester.edu (Al Davis) (08/11/88)
bill davidsen writes..... > What's not standard is to write Wordstar or 1-2-3 files which can not > be read by the original program. The idea seems to be "once you use my > program you can never go back." A few years ago, ARC changed the format on a regular basis. It was annoying. ARC 4 would not read files created by ARC 5, etc. SEA was changing the format several times a year, and was much criticized for it. There was no way to get backward compatibility. ARC would say "I think you need a newer version of ARC". Also, ARC was too slow, so I didn't use it. Around the time PKARC became available, ARC "improvements" came to a halt. Stability at last. Also, PKARC was fast enough to be useful. When PK added squashing, he put in a switch to turn it off. He preserved backward compatibility, something SEA never did. Still, SEA sat on their butt. No attempt to meet the competition by improving the product. There were two logical improvements: PK compatibility, and make it faster. There are two reasons I can see for not keeping up: don't care and don't know how. Since after over a year of silence, the next step was call the lawyer, ovbiously the reason was don't know how. I wonder who really wrote ARC. The real improvements to ARC in the last year did not come from SEA, but from others working with the published source. I would hope that shareware would be immune from this nonsense: an area where the superior product, not superior legal staff, wins. I wonder who the real winner is. Can someone post an alternative to ARC in source form for UNIX systems? -al davis
ncperson@ndsuvax.UUCP (Missing Person) (08/11/88)
What other products does SEA produce, all I've ever seen is there archive program. Is that their SOUL SOURCE of income? I think that copyrighting the .ARC extension just makes SEA look like idiots. I wonder what would happen if I copyrigted my last name in some kind of hardware product. Would this mean that I had the right to go after companies that made "personal computers"? I doubt it. -- Brett G. Person North Dakota State University uunet!ndsuvax!ncperson | ncperson@ndsuvax.bitnet
simon@ms.uky.edu (Simon Gales) (08/11/88)
In article <Aug.8.19.49.42.1988.27547@topaz.rutgers.edu> msmith@topaz.rutgers.edu (Mark Robert Smith) writes: >WEll, Phil has released PKPAK 3.61, with the obvious name change and a >bug fix. >It seems that big bad SEA forced him to change the name, AND forced >him to abandon even the compression algorithms that he was using. >Now, he has until early 1989 to develop a new program. > ... >I urge you all to do the same. I also urge Rahul Dhesi to switch to >Phil's new standard as soon as it is available. I also urge SIMTEL20 >to convert its archives to the new standard. We need to show SEA that >their kind of competition through litigation is unacceptable, and that >competition through improvement is the only acceptable form of >competition. Why not urge Phil to convert to the same standards zoo is using? It would be interesting to see how many of us like/dislike zoo. If enough of us are using zoo, then another program using the same standards (but more suited to those who dislike zoo) seems to be the best solution. > >Mark > >-- >Mark Smith (alias Smitty) "Be careful when looking into the distance, >Tenafly, NJ 07670 {backbone}!rutgers!topaz.rutgers.edu!msmith >msmith@topaz.rutgers.edu Bill and Opus in '88!!! <--------------------------------------------------------------------------> <--- Simon Gales@University of Ky 254-9387/257-3597 ---> <--- [ simon@ms.uky.edu ] | [ simon@UKMA.BITNET ] ---> <-------------------------------------------------------------------------->
16012_3045@uwovax.uwo.ca (Paul Gomme) (08/11/88)
In article <4936@pasteur.Berkeley.EDU>, browning@cory.Berkeley.EDU (Craig Browning) writes: > In article <11792@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >>BTW: I think that the settlement reflects the legal issues perfectly. >>Both zoo and dwc invented new file formats, help menus, directory >>listings, and commands. PKware "borrowed" most of the above, with very >>slight changes. > > What a weird opinion: Speed is the difference. What's wrong with compatibility? > ... ARC and PKARC's compatibility helped make them, especially PKARC, > popular, yet you praise diversity of formats. I disagree. The first time I found myself using PKARC was when I had an .ARC file which couldn't unarc using ARC; it would unarc using PKXARC. Further, it's been pointed out in this newsgroup that there are other programs which have "improved" on ARC - for example NARC which provides a point-and-shoot layout (too bad it won't allow you to create .ARC files as well). > ... Yes, the ARC extension was apparently protected (more > craziness, how about ".DOC"? ".WP"? etc.? ) Yes, it does seem silly. But how about the three letters IBM? > ... but I don't see any problem with > re-writing code to get efficient storage, and what will happen to Vernon > Buerg's programs that use ARC format? I believe that Buerg's programs are written with the consent of SEA - which Katz never had. I've timed PKARC and the Buerg programs - they're pretty close, and Buerg's programs are slightly faster on a couple of operations. Unfortunately, they're rather less convenient to use than a program like PKARC. ------------------------------------------------------------------------- Paul Gomme E-Mail: Department of Economics University of Western Ontario Bitnet: p.gomme@uwovax.bitnet London, Ontario, Canada p.gomme@uwovax.uwo.ca N6A 5B7 ARPA: p.gomme@uwo.ca (519) 679-2111 ext. 6418 > Most of us use clones instead of IBM's that are compatible and much more > of a copy than Katz, but how many of us want to pay the extra to not infringe > IBM's copyright? > >> bill davidsen (wedu@ge-crd.arpa) > > Craig
heiby@falkor.UUCP (Ron Heiby) (08/11/88)
Craig Browning (browning@cory.Berkeley.EDU.UUCP) writes: > In <11792@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > > I don't think that anyone want to switch until/unless the UNIX source > >is available for the new compressor. > > You're in the minority, as I will point out again. He may be in the minority, but I bet there are a lot of us out here in that same minority. In my world, comp.binaries.ibm.pc comes into a system running UNIX. That's the first place over which I can exert some control. Eventually, stuff that looks interesting/useful gets transferred to my PC. Why not just send everything to the PC? Because, for one thing, it's a pain in the ass. It doesn't just happen automatically, I've got to fire up the file transfer software on both machines. Also, I have to worry about disk space on my twin 20Meg PC drives a lot more than I have to worry about the 150Meg ESDI on my Motorola UNIX box. Also, for software I plan to use, I enjoy printing a copy of what documentation exists. On my PC, I have a 10-year-old Epson MX-100 and a (approx) 10 cps Olympia page-at-a- time printer. On my UNIX box, I have an NEC laser printer. If I send everything to my PC, I have to then extract the documentation down there and ship it back UP to the UNIX box, again. Waste. Even if all this could be automated and made very easy, there's a startling difference in speed of concatenating multiple parts of a posting together, uudecoding the result, running the extraction, and uploading the documentation back to UNIX from the PC and doing the same (less extra upload) operations on a 16MHz 68020 running UNIX (soon a 20MHz 68030!). I mean, it's a BIG difference. Just sitting and watching my PC grind through it all is a waste of time. > >readers to use, because I'm tired of having to move stuff to a PC to > >read the docs to see if I should bother to move them to a PC at all. This is a BIG benefit of being able to deal with the archive format on the HOST computer (UNIX, mostly). > And I hope the moderator repaks (spelling intentional) them to the standard > format in use, ARC or whatever. Otherwise we'll have to keep several de-arcers > around to use postings. Yes, it would be nice if this were done, but I don't see any way around keeping the last version of ARK or the PK* products around. I, at least, have archive floppies with a bunch of .ARC files. Plus, I still get some software from Compuserve and other places. > Maybe it will do tree structures, something I > haven't seen a practical use for yet but a few seem to strongly desire. Some people out here have a hard disk. Tree structures in the file system make life a whole lot easier when you have multiple megabytes of files to organize, much more so than 360K on a single floppy. Besides, when you want to put your 513th file in the root directory of your hard disk, you'll find you have some trouble! (Of course, there's also the whole problem with all of the packages that contain a file called "READ.ME".) These are just a few of the practical uses for tree structures in a file system. Coming from a background that includes having to deal with such directory trees, I recognize the desirability of having an archiver that understands them, too. Most people who have hard disks do (or should do) regular backups. Most of them have multiple directories on their disks. It would be very inconvenient if the backup programs on the market could deal with only the root directory or even only the current directory. I think that when you buy a hard disk, you'll find this to be true. (I know that there are folks out there who don't read the manuals and blithely fill up their hard disk root directory with files until one day their hard disk is "full", containing just a couple Meg of files. Many of them probably go out and buy another or a bigger drive. sigh) -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "Failure is one of the basic Freedoms!" The Doctor (in Robots of Death)
chuck@eneevax.UUCP (Chuck Harris) (08/11/88)
In article <1103@ndsuvax.UUCP> ncperson@ndsuvax.UUCP (Missing Person) writes: >What other products does SEA produce, all I've ever seen is there archive >program. Is that their SOUL SOURCE of income? > I think that copyrighting the .ARC extension just makes SEA look like... Seems to me that there isn't anyway that SEA could hold the copyright to the extension .ARC Computer Innovations, INC has been using that extension for their archive program ARCH since 1981!!! ( and still does. ) Correct me if I'm wrong, but I don't think SEA has been around that long. ------------------------------------------------------------------------------- Chuck Harris, C.F. Harris - Consulting.
roskos@csed-1.IDA.ORG (Eric Roskos) (08/12/88)
The debates over who is "right" aside, it seems that a significant issue is that now, at least for the present, the archival method used for the Usenet's PC archives is based on a commercial product, and thus the Usenet is supporting a commercial product. In the old days, this would have been severely frowned upon. It would seem better to use a freely available archival method, regardless of whether it is nominally "slower", since most people only unarchive the distributions once, and thus speed is not the major concern. It could be argued that the Usenet has fallen victim to one of the occasional practices of competitive businesses: let the illegal competition help you establish a market before you take legal action against them and take over their market share thereby. A variation of "create a need and fill it". Somewhat like the fate of some product clones, and, almost accidentally, 256K dynamic RAMs. Disclaimer: The above is my personal opinion. -- Eric Roskos, IDA (csed-1!roskos or Roskos@DOCKMASTER.ARPA) "The just man's purpose cannot be split on any Grampus." --HDT
haugj@pigs.UUCP (Joe Bob Willie) (08/12/88)
In article <750@james.nprdc.arpa> malloy@nprdc.arpa (Sean Malloy) writes: }In article <11814@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: }|In article <Aug.9.08.23.10.1988.12189@topaz.rutgers.edu> msmith@topaz.rutgers.edu (Mark Robert Smith) writes: }| }|| Steve, Sorry, but stealing somebody else's market is a standard }|| practice inthe world of software. Else, why are word processors able }|| to read WordStar's format? Why can Excel read Lotus 123? Why can }|| Paradox import dBase and RBase files? It is standard to attempt to }|| grab somebody else's users. }| }| What's not standard is to write Wordstar or 1-2-3 files which can not }|be read by the original program. The idea seems to be "once you use my }|program you can never go back." } }Why should Phil Katz be any different than some of the big software }houses? Lotus 1-2-3 v2.0 .WK1 files can't be read by Lotus 1-2-3 v1.A, }but 1-2-3 automatically writes a .WK1 file when you save your }spreadsheet. You can read a WordPerfect 4.2 file into WordPerfect 5.0, }but the file WordPerfect 5.0 writes can't be read by Wordperfect 4.2 -- }and there's no way to convert it back, while Lotus at least has a WK1 }to WKS conversion utility. what is common in each of these cases is that company is the one making themselves incompatible. when you consider the lack of expertise the typical pc user has, they look at an .arc file and really expect their .arc file tools to work with it. and when it doesn't, they call their vendor (assuming they have one) and demand support. in the case of pkware and sea, sea was getting screwed for what phil did. THEY were having to answer stupid questions, not phil, because pk*** could handle the New And Improved(tm) pk format. in the other cases which have been mentioned, no one is going to call lotus if excel can't read the 1-2-3 spreadsheet it gets pointed at. excel is not presenting itself as a drop in replacement. it is harder to try to be 100% compatible with someone elses format and so on. and of course, the more compatible you are the better. i have a clone of informix 3.30's report writing language compilers and executers. when i decided on the report file extension, you can be certain it was NOT .arc. [ by coincidence, informix uses .arc as the extension of their report files. i decided to use .rep to show that the two were not compatible at the binary level ] quite simply, had phil NOT tried to be so damned compatible he wouldn't be in this position. as is, he tried to be real cute and clever and got bit. he has not been permanently enjoined from creating file archiving tools, so, he should be able to come out with one which is quite usable. and given the sympathy which he seems to have, he should even make a few dozen bucks on the venture. the documentation for .arc file formats has been published, and as far as i know you can't copyright a file format. so, anyone of us should be able to create a file archiver from first principles, using the sea format as a guideline, and then go market the thing. -- jfh@rpp386.uucp (The Beach Bum at The Big "D" Home for Wayward Hackers) "Never attribute to malice what is adequately explained by stupidity" -- Hanlon's Razor
rlb@xanth.cs.odu.edu (Robert Lee Bailey) (08/12/88)
In article <4936@pasteur.Berkeley.EDU> browning@cory.Berkeley.EDU.UUCP (Craig Browning) writes: >>| competition. > >> I don't think that anyone want to switch until/unless the UNIX source >>is available for the new compressor. > >You're in the minority, as I will point out again. >Most of us use clones instead of IBM's that are compatible and much more >of a copy than Katz, but how many of us want to pay the extra to not infringe >IBM's copyright? > I agree. Suppose that SEAs attitude had been prevalent at the turn of the century? Can you imagine the early automobile manufacturers suing each other because their competitors product also happened to have 4 wheels, an engine, and a steering wheel? What would your car look like today? Each brand would be so different that a separate class of drivers license would be required for each brand! I guess that the developers of the UNIX ARC utility had better pack their bags and go into hiding. They will probably be next on SEAs "hit list". Oops! I should have said ARC (tm)*. I don't want to get slapped with a law suit either! * ARC is a trademark of SEA
manes@marob.MASA.COM (Steve Manes) (08/12/88)
From article <Aug.9.08.23.10.1988.12189@topaz.rutgers.edu>, by msmith@topaz.rutgers.edu (Mark Robert Smith): > Steve, Sorry, but stealing somebody else's market is a standard > practice inthe world of software. Else, why are word processors able > to read WordStar's format? Why can Excel read Lotus 123? Why can > Paradox import dBase and RBase files? It is standard to attempt to > grab somebody else's users. That's called competition, and is the > backbone of the American business world. If you build a better, but > still compatible mousetrap, the world will beat a path to your door. I wasn't critical of PKARC attempting to maintain (and profit from) compatibility with SEA's ARC. That, as you say, is progress. What annoyed me was PKARC adding Squashing to .ARC files, making SEA's ARC useless for handling such archives. The whole world isn't running MS-DOS, you know. I had a perfectly functional 'arc' utility for Unix that could handle the "standard" ARC format. Then I suddenly found myself (and my Unix BBS) under a flood of .ARC files that I couldn't uncrunch, which meant manually moving them over to my DOS machine and unpacking them with PKXARC so I could make sure that some bozo wasn't uploading Lotus 1-2-3 to my public files directories. Don't misunderstand me; PKARC was a serious improvement over SEA's ARC for >DOS< users. But Thom Henderson was kind enough to publish his source and that led to ARC becoming a semi-standard for moving files across different operating systems. When PKARC became successful, it cut the legs off that portability and made ARC, once again, an MS-DOS archiver. I didn't see that as progressive. If Phil had adopted another file extension for his incompatible Squashed archives I think everyone would have been a lot happier, including SEA. -- Steve Manes Roxy Recorders, Inc. Magpie-HQ BBS UUCP : {rutgers|cmcl2}!hombre!magpie!manes (212)420-0527 Smail: manes@MASA.COM
manes@marob.MASA.COM (Steve Manes) (08/12/88)
From article <750@james.nprdc.arpa>, by malloy@nprdc.arpa (Sean Malloy): > At least PKARC had the > -oct flags that let you write ARC files that SEA's ARC program would > read. What SHOULD have been done is that Squashed archives should have been given a default extension of .PKA or something similar. That seems so obvious as to be almost silly. After all, PK[X]ARC was the only program that could read that format so why maintain the .ARC extension unless your intent IS to confuse the market and reduce confidence in a competitor's product? Because of its speed and compactness, PKARC would have been just as successful either way. -- Steve Manes Roxy Recorders, Inc. Magpie-HQ BBS UUCP : {rutgers|cmcl2}!hombre!magpie!manes (212)420-0527 Smail: manes@MASA.COM
skeeve@mhuxu.UUCP (Chris Riley) (08/13/88)
In article <173@falkor.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: >Craig Browning (browning@cory.Berkeley.EDU.UUCP) writes: >> In <11792@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >> Maybe it will do tree structures, something I >> haven't seen a practical use for yet but a few seem to strongly desire. >Some people out here have a hard disk. Tree structures in the file system >make life a whole lot easier when you have multiple megabytes of files to >organize, much more so than 360K on a single floppy. Besides, when you No kidding. But 99% of all the stuff I archive or extract goes into one directory, the current directory. Therefore you don't need a tree structure for the archive. I have never seen an archiver that only works on the root directory. When I backup my hard disk I use something designed to back up the entire thing, not something that's designed to archive a small portion. I don't use ZOO because it doesnt' suit my needs as well as PK***. I don't really want a tree structure archiver. >Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix -Chris Riley
Ralf.Brown@B.GP.CS.CMU.EDU (08/13/88)
In article <444@csed-47.csed-1.IDA.ORG>, roskos@csed-1.IDA.ORG (Eric Roskos) writes: }is that now, at least for the present, the archival method used for the }Usenet's PC archives is based on a commercial product, and thus the }Usenet is supporting a commercial product. In the old days, this would No one is forcing you to use the commercial ARC or PK***! You could just as easily use V. Buerg's ARCA/ARCE/ARCV to manipulate the archives. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.
manes@marob.MASA.COM (Steve Manes) (08/13/88)
From article <6084@xanth.cs.odu.edu>, by rlb@xanth.cs.odu.edu (Robert Lee Bailey): > I agree. Suppose that SEAs attitude had been prevalent at the turn > of the century? Can you imagine the early automobile manufacturers > suing each other because their competitors product also happened to > have 4 wheels, an engine, and a steering wheel? What would your > car look like today? Each brand would be so different that a > separate class of drivers license would be required for each brand! The analogy ain't right. There seems to be some misapprehension in some quarters about what this case was about. It wasn't about assumed trademarks to the file extension, ".ARC", or about SEA trying to shoot down other competitors in the archiver racket. The case, to which PKware pled no contest, was over use of SEA's copyrighted code in the development of PKARC (the LZ algorithm isn't SEA's but its internal directory structures are) and "unfair trade practices" concerning what PKware did with that information, which was in effect to use SEA's own proprietary code to damage SEA in the marketplace. SEA didn't go after Vern Buerg for ARC-E and didn't go after Rahul Dhesi for ZOO and didn't go after Dean Cooper for DWC. These guys developed their own products and their own markets for programs that do virtually the same thing as SEA's ARC. > I guess that the developers of the UNIX ARC utility had better pack > their bags and go into hiding. They will probably be next on SEAs > "hit list". No, actually Thom Henderson has officially given his blessing to the Unix community to use his ARC source. His demand was that it not be used to develop knock-off ARC binaries for which the author claims a copyright. Nothing wrong with that. -- Steve Manes Roxy Recorders, Inc. Magpie-HQ BBS UUCP : {rutgers|cmcl2}!hombre!magpie!manes (212)420-0527 Smail: manes@MASA.COM
w8sdz@smoke.ARPA (Keith B. Petersen ) (08/14/88)
I think a lot of people have lost sight of the fact that ARC522 and ARCE are able to deal with squashed member files in ARCs. The Unix ARC program (available from any unix.sources archive) also knows about squashing. Squash compatibility should not be an issue in this discussion. Whether or not Phil was right in introducing it is not important at this point because all the programs listed above can now deal with it. -- Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz GEnie: W8SDZ
tmanos@aocgl.UUCP (Theodore W. Manos) (08/14/88)
In article <2663@pt.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: > Most of the speed difference comes from the fact that ZOO is written entirely > in C, while PK*** is written mostly in assembler. That's why there are > Unix and VMS versions of ZOO, but not PK***. While admittedly it won't handle Phil's Squashed format, I do have a program running on our VAX (VMS) that *will* unARC .ARC files. I also have a program running on our mainframe (VM/CMS) that will unARC even the Squashed files. Now if Rahul would just run over to his nearest mainframe running VM and do a quick port of ZOO (in C of course :-) ), I'd be perfectly happy to switch to ZOO. -Ted Ted Manos tmanos@aocgl.{COM,UUCP,UU.NET} or ...!{uunet,mcdchg}!aocgl!tmanos
msmith@topaz.rutgers.edu (Mark Robert Smith) (08/14/88)
Those who need an example of what I mean by "competition by litigation" should see the movie "Tucker", which opened on Friday the 12th. Then come back and say what you've said. Mark -- Mark Smith (alias Smitty) "Be careful when looking into the distance, 61 Tenafly Road that you do not miss what is right under your nose." Tenafly, NJ 07670 {backbone}!rutgers!topaz.rutgers.edu!msmith msmith@topaz.rutgers.edu Bill and Opus in '88!!!
dmt@mtunb.ATT.COM (Dave Tutelman) (08/15/88)
In article <2303813a@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes: > >No one is forcing you to use .... PK***! You could just >as easily use V. Buerg's ARCA/ARCE/ARCV to manipulate the archives. Not quite! As I posted in a query a week or so ago, I can't figure out how to update a file in an archive with the Buerg/Chin suite. Adding a file that already exists creates a SECOND image, and I don't know how to delete a file from an existing archive. If someone can help me on this, I'll be delighted to switch from PK***. Thanks in advance. +---------------------------------------------------------------+ | Dave Tutelman | | Physical - AT&T Bell Labs - Lincroft, NJ | | Logical - ...att!mtunb!dmt | | Audible - (201) 576 2442 | +---------------------------------------------------------------+
iav1917@ritcv.UUCP (alan i. vymetalik) (08/16/88)
With all this talk about PK361.EXE, I have another question: Can someone send it to the moderator on .binaries so that it can be posted? Is this version really a NEW program? Or, is it simply a minor upgrade to the PKARC/PKXARC V3.6 programs I recently pulled off of a BBS? The utilities have (with a small variation) the following header: PKARC FAST! Archive Create/Update Utility Version 3.6 06-01-88 Copyright (c) 1986-1988 PKWARE Inc. All Rights Reserved. PKARC/h for help So, if anyone is feeling helpful, please either post the program or e-mail me a copy. Also, information about the new programs and other such things would also be appreciated. Thanks, Alan All e-mails to: {allegra | seismo}!rochester!ritcv!iav1917 All flames to: !lostnode!hades!flmbckt ------------------------+-------------------------------------------- Alan I. Vymetalik | Standard Disclaimer: The above statements Prism Software Designs | and opinions belong to the author. Any 44 Arborwood Crescent | resemblence to statements found in actual Rochester, New York | reality is simply coincidence. And, as 14615-3807 | always, the above opinions have absolutely (716)-458-4932 (8-10pm) | nothing to do with the little, fat man (leave message) | putting $100 bills in my pocket. ------------------------+--------------------------------------------
mdf@tut.cis.ohio-state.edu (Mark D. Freeman) (08/19/88)
In <34.UUL1.3#935@aocgl.UUCP> tmanos@aocgl.UUCP (Theodore W. Manos) writes: >While admittedly it won't handle Phil's Squashed format, I do have a >program running on our VAX (VMS) that *will* unARC .ARC files. Can your program handle an ARC uploaded via KERMIT? Zoo wants the .zoo file to be 'converted' to a different RMS file type beforextraction. If your program has no such limitation, I'd like to find out how to get a copy. -- Mark D. Freeman (614) 262-1418 Applications Programmer, CompuServe mdf@tut.cis.ohio-state.edu [70003,4277] ...!att!tut.cis.ohio-state.edu!mdf Columbus, OH Guest account at The Ohio State University
kg0r+@andrew.cmu.edu (Kenneth Gober) (08/19/88)
Looking at the settlement from a user's point of view, it seems that 2 problems have been taken care of. 1. Official SEA Arc will now run faster, since SEA has PK's code. 2. The slightly different file formats (i.e. the PK extensions) no longer compete. While I won't say (read- I'm too tired to compose my thoughts) what the effects of this litigation will have on software publishers, from a user's standpoint, I see no disadvantages to this settlement. And, except for those who make tools to make tools, software publishers are in the business of serving users' needs, are they not? Kenneth Gober kg0r@andrew.cmu.edu
fthorn@cix.UUCP (Frank Thornley) (08/19/88)
In article <1724@eneevax.UUCP>, chuck@eneevax.UUCP (Chuck Harris) writes: > In article <1103@ndsuvax.UUCP> ncperson@ndsuvax.UUCP (Missing Person) writes: > >What other products does SEA produce, all I've ever seen is there archive > >program. Is that their SOUL SOURCE of income? > > I think that copyrighting the .ARC extension just makes SEA look like... > > Seems to me that there isn't anyway that SEA could hold the copyright to the > extension .ARC > > Computer Innovations, INC has been using that extension for their archive > program ARCH since 1981!!! ( and still does. ) > > Correct me if I'm wrong, but I don't think SEA has been around that long. > > ------------------------------------------------------------------------------- > Chuck Harris, C.F. Harris - Consulting. I have known of SEA for some years now - indeed Thom Henderson of SEA is extremely well known in the FIDONET world. FIDONET, for those of you not familiar with FIDONET, it's a network of IBM-PC based bulletin boards based on Tom Jenning's FIDO software. There areound 3000 nodes worldwide, and it's been running for over four years now. Thom Henderson is one of the pioneers of FIDONET, and among other products SEA are responsible for the SEADOG mailer program which is a stand-alone electronic mail program for the IBM-PC. Thom is also responsible for editing FIDONEWS which is the weekly newsletter distributed around FIDONET - it runs to something like 100K/week last time I looked. They have also written a proprietry file-transfer protocol which is used in several PC comms packages, and bulletin board systems - SEALINK. =============================================================================== Frank Thornley - CIX - a new era in communic%%#$^**^
evm2y@watt.acc.Virginia.EDU (Ernest V. Mathews III) (08/20/88)
kg0r+@andrew.cmu.edu (Kenneth Gober) writes: >Software publishers are in the business >of serving users' needs, are they not? >Kenneth Gober Are you kidding? Ernie Mathews evm2y@virginia.edu
del@Data-IO.COM (Erik Lindberg) (08/23/88)
In article <7950@mhuxu.UUCP> skeeve@mhuxu.UUCP (79533-riley c) writes: > >No kidding. But 99% of all the stuff I archive or extract goes into >one directory, the current directory. Therefore you don't need a tree >structure for the archive. I have never seen an archiver that only Of course! Since you can't make tree structures with the current popular archiver, software distributions of necessity are created to extract into one directory. Therefore the logical conclusion is that since we've gotten by just fine without it till now, we don't need it now. Many people apply the same logic to computers in general: 99% of all the paper work I do in my job can be done just as well, sometimes faster, without a computer, therefore I see no reason to switch to computers. (No matter what other advantages could be gained, new ways to manipulate the data, etc..... ) -- del (Erik Lindberg) uw-beaver!tikal!pilchuck!del
ECKSTROM@KL.SRI.COM (D.J. Eckstrom) (10/18/88)
Help! I can't get pk361.exe to run on my machine (640K compaq port II), and I have a lot of files to process. My machine says "not enough memory to run program". I tried pkxarc on them but it doesn't work - they need this latest version apparently. Please reply to: msw@cplvax.sri.com (128.18.10.100) as this is not my account. Thanks!