Re: 7-ZIP for Mac OSX ???

["Michael J. Mahon" <mjmahon@aol.com>]

winston19842005 wrote:
> On 7/3/09 11:24 AM, in article
> 9dfb877e-db8d-4156-8003-9f267da07490@i4g2000prm.googlegroups.com, "mdj"
> <mdj.mdj@gmail.com> wrote:
>
> > On Jul 4, 12:04 am, "sfahey" <sfa...@a2central.com.remove-exp-this>
> > wrote:
> > >   To: mdj
> > >   Re: Re: 7-ZIP for Mac OSX ???
> > >   By: mdj to comp.sys.apple2 on Thu Jul 02 2009 08:09 pm
> > >
> > >  > And now that we're free of all that patent/proprietary malarky, are
> > >  > you advocating that we go back ?
> > >
> > > Missed the /sarcasm tag?
> > No, but there's a line (or perhaps it's a chasm) between mockery and
> > ridicule ...
> >
> > Sometimes it's hard to tell ;-)
>
> But he has a VERY good point...
> I'm a TI-er - one thing we were guilty of was once we designed the wheel,
> that was it.
> Seems like once something was done, it was done. With a few exceptions, if
> you have a program to do "A", that is how you do it.
>
> If a TI-er had designed the original wheel by carving it out of stone, we'd
> all be enjoying really rough rides!

I got the joke, Sean.  ;-)

And, of course, I wasn't advocating freezing the world--in fact, my
career was mainly spent trying to establish new computing standards.

But that's the point--to inject a new compression format into the mix
at this point demands that it be a *significant* improvement on the
existing standards, which most of the zip "fiddles" do not do.

In the late 1980s, there was a maxim in the Unix community which summed
this up pretty well:  "Being standard is better than being better."

The issue is not ruling out (significant) improvements, the issue is
gaining the benefits of stability that standards offer all of us.
This usually means that a new standard must remain backward compatible
with the old standard, so that they can interoperate during a transition
period of indefinite length.

Of course, this process eventually leads to an impasse, so that a major
break must occur with the launch of a new standard, and early adopters
get to deal with all the transition confusion.

Such technology transitions are 1) inevitable and ultimately beneficial,
and 2) to be avoided until the cost/benefit ratio justifies the pain of
a transition.

Making incompatible "fiddley" changes to a pervasive standard for no
real gain actually "poisons the well" for eventually needed changes
by causing users pain for little gain--and we all have long memories
of pain.  ;-)

This does not mean that specialized compression schemes don't have their
uses, but it does mean that when they are used, they should be "wrapped"
in otherwise application-specific file formats if they are persistent.

This is the case with the hi-res packer/unpacker that inspired this
thread.  It is intended to be used within an application, not used for
a public distribution format.  If used for distribution, the unpacker
would generally be included with the distribution.

I've even done this myself!  SOUND.EDITOR can save sounds as 2:1
ADPCM-compressed files, which it packs and unpacks.  (It and the source
for the ADPCM compressor/decompressor are on my web site.)

The purpose was to make sound files practical on a 5.25" disk system,
and the algorithm is an 8-bit version of the standard Intel DVI
ADPCM algorithm, so it's about as "standard" as fast execution on
an Apple II permits.  ;-)

(In fact, it should decompress using the standard 16-bit codec, though
I haven't actually tried that.)

-michael

NadaNet 3.0 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."