Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!amdcad!sun!toto!dbercel From: dbercel%toto@Sun.COM (Danielle Bercel, MIS Systems Programming) Newsgroups: comp.sys.ibm.pc Subject: PKARC again and again Message-ID: <23785@sun.uucp> Date: Sat, 18-Jul-87 15:20:05 EDT Article-I.D.: sun.23785 Posted: Sat Jul 18 15:20:05 1987 Date-Received: Sun, 19-Jul-87 01:30:39 EDT Sender: news@sun.uucp Reply-To: dbercel@sun.UUCP (Danielle Bercel, MIS Systems Programming) Distribution: na Organization: Sun Microsystems, Inc. - Mtn View, CA Lines: 53 I think that there are a lot of us who basically agree with some of the flames that have been shooting out. It would have been nice if Phil did things differently so that another extension or compatibility remained. *However*, most of us don't really care about these issues. The thing is fast, it works on the old stuff and that's fine with most of us. Extensions come and go, their meanings are not carved out of granite. Programs come and go, and standards change. These are not really issues of serious concern to most of us. What is of concern, is how long do I have to wait for data to be compressed and/or extracted? If the difference between the two ARC programs were not so significant we'd all still be using the original because then compatability would be the most important thing. Now, however, it's the speed that is the significant factor and not the compression method used. If someone can drastically improve the compression ratio and their product is not very fast, we'll probably start switching to that to take advantage of more free disk space. I guess, then, that for most of us there is a hierarchy of importance to these features. * Disk storage * speed * Compression esthetics, etc. Give me more disk space first. Give me something *A LOT* better than squashing and PKARC is history. However, compression ratios being within a few percent of each other, I'll take speed. If speed is about the same then I really have nothing to agrue about and I'll consider the esthetics of the various implementations. Obviously, these are all my personal preferences, but I think many of us feel alike on this. We don't exactly disagree with the flamers but it's just that not big a deal to worry about. What I want to see is 50% compression on binary files. Give me that in a slow product and PKARC and ARC will be relagated to doing only ASCII files. For me, I'm out of here, I'm historical. danielle -- UUCP: {hplabs,decvax,}!sun!toto!{danielle,dbercel} COM: dbercel%toto@sun.com ARPA: dbercel@sun.arpa /-------------------------------------\ | Toto, I don't think this is Kansas. | -- Danielle Bercel \-------------------------------------/ Sun Microsystems, Inc.