🚀 go-pugleaf

>>Why stick with the inefficient?

Because the status quo is always safe. Not better, but safe.

>Efficiency is not the only feature of a transfer program.  I have several
>reasons to stick with the current (BinHex, UnPit) packers:

>1) Binary transfer is complex enough as it is.  To download programs from
>the net, a user needs all of: Kermit (or similar), BinHex, and Packit (or
>UnPit).  StuffIt adds yet another protocol to the minimum set.  Why complicate
>matters?

Well, Delphi is rapidly moving towards Stuffit as default from what I can
see, because it significantly reduces download time/cost. If you expect to
use the stuff crossposted here from Delphi, you better get used to Stuffit.
I expect other Timesharing services will adopt it as well as folks find it.

>2) They are widely available.

Stuffit is at least as available as Binhex.

>3) They are free.  BinHex4.0 and UnPit are free programs.  StuffIt is
>shareware (for the packer).  Why use a shareware program when a free one
>is available?

Binhex 4.0 is shareware. If you copy isn't, someone illegally modified it.

Of course, Binhex doesn't matter. This is packit vs. Stuffit. Packit is
shareware for both the packer and the unpacker. unpit takes care of this for
the unpacker, but the packer is still in the same situation for both
programs.

>4) They are stable.  BinHex4.0 and UnPit have been in use long enough to
>demonstrate that they work.  Why test a new program?

Stuffit has shown itself to be very stable.

All my stuff will be in stuffit format, because I'm interested in living in
today, not yesterday. Packit did its job. Stuffit does it much better. If
you don't want to use any of my stuff, that's your perogative. But you're
artificially limiting yourself.

Stuffit is Good Stuff.


---
Chuq "Fixed in 4.0" Von Rospach			chuq@sun.COM	Delphi: CHUQ