dbercel%toto@Sun.COM (Danielle Bercel, MIS Systems Programming) (07/18/87)
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.