bradn@tekig4.TEK.COM (Bradford Needham) (11/02/87)
In article <7507@dartvax.UUCP> borscht@dartvax.UUCP (Andy J. Williams) writes: >Why stick with the inefficient? 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? 2) They are widely available. How many times have you seen requests for BinHex on this newsgroup? Remember all the confused and frustrated requests for Packit? Why repeat that experience? 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? 4) They are stable. BinHex4.0 and UnPit have been in use long enough to demonstrate that they work. Why test a new program? To authors who would write yet another binary transfer protocol for the Mac: There are so many fantastically useful applications that haven't been written; why waste your creativity rewriting those that already exist? Brad Needham brupbe socatrdche bri
chuq%plaid@Sun.COM (Chuq Von Rospach) (11/03/87)
>>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
jww@sdcsvax.UCSD.EDU (Joel West) (11/03/87)
I'm told my someone whose opinion I respect that StuffIt
a) is far superior in compression density (up to 3:1)
b) will be the standard for Compu$erve
Certainly enough for me to get a copy and, if what I hear about
the user interface and pricing (free for unpacking) make the switch.
--
Joel West (c/o UCSD)
Palomar Software, Inc., P.O. Box 2635, Vista, CA 92083
Author, Programming with Macintosh Programmer's Workshop (Bantam)
{ucbvax,ihnp4}!sdcsvax!jww jww@sdcsvax.ucsd.edudtw@F.GP.CS.CMU.EDU (Duane Williams) (11/03/87)
| StuffIt adds yet another protocol to the minimum set. Why complicate | matters? It's too late. Have you looked at the files on GEnie and CompuServe lately? StuffIt is here to stay. The thing to do is to persuade the author to build BinHex into StuffIt; then you would have all the protocols in one program. | StuffIt is shareware (for the packer). Why use a shareware program when a | free one is available? StuffIt is free for the unpacker. No one is forced to use it for packing. | Why test a new program? Progress. Finally, StuffIt is a nifty compression and archiving program, even if you don't want to use it for binary file transfer. Duane Williams dtw@cs.cmu.edu
mentat@auscso.UUCP (Robert Dorsett) (11/03/87)
In article <2103@tekig4.TEK.COM> bradn@tekig4.UUCP (Bradford Needham) writes: >In article <7507@dartvax.UUCP> borscht@dartvax.UUCP (Andy J. Williams) writes: >>Why stick with the inefficient? > >Efficiency is not the only feature of a transfer program. I have several >reasons to stick with the current (BinHex, UnPit) packers: So why not trash your COMPUTER and go back to pencil/paper, typewriter/paper, because it's "standardized"? :-) >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? Because it's so INCREDIBLY efficient. It's at least three times as fast as PackIt III, has MUCH more efficient data compression, has a much friendlier user environment, and has better error handling/diagnostics (i.e., you know what's going on when something screws up). >2) They are widely available. How many times have you seen requests for >BinHex on this newsgroup? Remember all the confused and frustrated requests >for Packit? Why repeat that experience? So let's dream up a form letter for such people. Such a letter would read: "Contact your local computer store or users group." No big deal. The "con- fusing and frustrating experience" is something we have to go through once, when we're *first* getting started. StuffIt is similar enough to PackIt in philosophy of operation that the "replacement" notices should be sufficient to get it used without undue problems. And the fact remains: StuffIt is being used WIDELY already. The BMUG BBS already has programs uploaded in StuffIt format, and several local BBS's *insist* on the format. Mainly due to the length savings: one will spend less time uploading/downloading the program, reducing inconvenience to other users, and permitting more software to be stored on a disk with a given capacity. >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? Okay, so maybe 1 out of every 50 people will send in a couple of bucks to the author. So what? I happen to think authors should stand some hope of being rewarded for the work they do. StuffIt clearly represents a deal more work than PackIt. The difference between "shareware" and "not shareware but freely accessible" (I got flamed on my use of "Public domain" recently :-)) is that, after writing a program, the author sits down and writes a little notice asking for money. That's about it. That implies a confidence in his work, although I've seen the shareware label on some real trash. I doubt if many people enthusiastically write a program for the immensely profitable share- ware market, so if altruism is your concern, no need to be. >4) They are stable. BinHex4.0 and UnPit have been in use long enough to >demonstrate that they work. Why test a new program? I've used StuffIt extensively the last couple of weeks, and haven't run into a single error. I suspect the algorithm is stable; the version differences seem to deal with polishing the user interface (i.e., StuffIt 1.13 seems friendlier than StuffIt 0.97). -- Robert Dorsett {allegra,ihnp4}!ut-sally!ut-ngp!walt!mentat University of Texas at Austin {allegra, ihnp4}!ut-sally!ut-ngp!auscso!mentat
dowdy@apple.UUCP (Tom Dowdy) (11/03/87)
In article <2103@tekig4.TEK.COM> bradn@tekig4.UUCP (Bradford Needham) writes: > >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? > I agree. I don't mind binary transfers, but why I have to go through so many steps and procedures sometimes really makes me wonder. I don't agree with the point to avoid StuffIt, as net bandwidth is a serious matter to "the powers that be". But I think I have a suggestion that would fix the problem of having all of those applications just to convert files. >To authors who would write yet another binary transfer protocol for the Mac: >There are so many fantastically useful applications that haven't been written; >why waste your creativity rewriting those that already exist? > I have something for people like this to write. When I was still in school I had a great idea. Write a public domain conversion program that did BinHex and Packit in one place, plus provided routines to automatically convert any incoming or outgoing ASCII character into another either before or after BINHEXing. (We had a problem with Kermit and our IBM when I tried to BITNET a file to a VAX, the only solution was some clever character translations before sending) Add onto this a hot interface and you're all set. Maybe even provide a way to automatically combine multitple files. (IE, with this program you would only need your transfer software and that would be it. No two different conversion programs, plus a text editor just in case you needed to strip files) Think about it, the BINHEX/PackIt combination is *so* common, it would be very easy to automate the process, even detecting if PackIting (is that a word) needed to be done. I was all ready to write this one, but was unable to come up with formats for PackIt and BinHex (although that one I could have figured out). I'm not really in a position to write such a thing now, but I would love to see someone do it. >Brad Needham Tom Dowdy CSNET: dowdy@apple.CSNET Apple Computer MS:27Y AppleLink:DOWDY1 20525 Mariani Ave UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy Cupertino, CA 95014 "IN VENICE STOP STREETS FILLED WITH WATER STOP PLEASE ADVISE STOP"
t-jacobs@utah-cs.UUCP (Tony Jacobs) (11/03/87)
In article <2103@tekig4.TEK.COM> bradn@tekig4.UUCP (Bradford Needham) writes: >In article <7507@dartvax.UUCP> borscht@dartvax.UUCP (Andy J. Williams) writes: >>Why stick with the inefficient? > >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? Stuffit does not add to the minimum set, it replaces Packit. >2) They are widely available. How many times have you seen requests for >BinHex on this newsgroup? Remember all the confused and frustrated requests >for Packit? Why repeat that experience? Stuffit is available on this net, Genie, Compuserve, and others. How much wider can you get? >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? If the shareware program is much, much better, then it is worth it in both time savings and thus money saved. >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 is a not in beta test, it has gone through testing before release, it's stable. >To authors who would write yet another binary transfer protocol for the Mac: >There are so many fantastically useful applications that haven't been written; >why waste your creativity rewriting those that already exist? > >Brad Needham >bradn@tekig4.TEK.COM Packit is useful but far from fantastic. Stuffit is fantastic. It is not a binary transfer protocol it is a file compacting program. Why innovate, why improve things. I guess MicroSoft just wasted all their creativity rewriting another wordprocessor! Come on Brad, are you really that afraid of a little change, or imrovement? -- Tony Jacobs * Center for Engineering Design * U of U * t-jacobs@ced.utah.edu
tedj@hpcilzb.HP.COM (Ted Johnson) (11/04/87)
I couldn't have said it better myself! -Ted
tdn@K.GP.CS.CMU.EDU (Thomas Newton) (11/04/87)
In article <32710@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: >>3) They are free. BinHex4.0 and UnPit are free programs. . . > >Binhex 4.0 is shareware. If you copy isn't, someone illegally modified it. > Binhex 4.0 is NOT shareware. All the versions of BinHex before 4.0 were free and contained no advertisements. BinHex 4.0 is also free, but displays an ad for Mainstay on startup. BinHex 5.0 IS shareware -- but who needs it? Every major Macintosh terminal program except MacKermit can deal with the MacBinary format directly, and BinHex 4.0 is sufficient to handle everything else. >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. I don't want to get into the PackIt vs. StuffIt debate, but the current Mac version of Unpit can produce both compressed and uncompressed PackIt files. The current user interface does not allow one to compress only some of the files being packed, but otherwise Unpit 0.3 has all of the functionality of PackIt II. -- Thomas Newton
dtw@F.GP.CS.CMU.EDU (Duane Williams) (11/04/87)
| >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 is a not in beta test, it has gone through testing before release, | it's stable. Actually, StuffIt is still under development and the latest version (1.13) on GEnie crashes when you issue the "Generate report..." command. A new version that corrects this bug and adds some useful new features is due out this weekend. Duane Williams dtw@cs.cmu.edu
drc@dbase.UUCP (Dennis Cohen) (11/04/87)
In article <2103@tekig4.TEK.COM>, bradn@tekig4.TEK.COM (Bradford Needham) writes: > In article <7507@dartvax.UUCP> borscht@dartvax.UUCP (Andy J. Williams) writes: > >Why stick with the inefficient? > > 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? No, the unloader needs StuffIt rather than PackIt now as it will unpack either. > > 2) They are widely available. How many times have you seen requests for > BinHex on this newsgroup? Remember all the confused and frustrated requests > for Packit? Why repeat that experience? If other networks are any indication, StuffIt is becoming far more used than PackIt very quickly. > > 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? Unpit is free, but it was written by a generous person to duplicate PackIt's capabilities for people on the net. Someone could do the same for StuffIt. The author included enough info in the docs to make that task reasonable. Besides, Unpit is not that readily available (I don't have it, yet). > > 4) They are stable. BinHex4.0 and UnPit have been in use long enough to > demonstrate that they work. Why test a new program? If that's an argument then everyone should still be using MacWrite and MacPaint rather than Word, WriteNow, FullPaint, and SuperPaint. It's called progress. > > To authors who would write yet another binary transfer protocol for the Mac: > There are so many fantastically useful applications that haven't been written; > why waste your creativity rewriting those that already exist? > A file archiver did not yet exist! StuffIt has a directory, you can add to and delete files from existing archives, get a list of what's available, etc. Besides, it even does a better job of compressing things. What are some of these "fantastically useful applications" as I'm having trouble coming up with ideas for spare-time projects? Everything I come up with is just an evolutionary program, a better (?) way of doing something that some other program already does. Dennis Cohen Ashton-Tate Glendale Development Center dBASE Mac Development Team -------------------------- Disclaimer: Above opinions are MINE. Leave my employers out of it, I do.
jwhitnel@csi.UUCP (Jerry Whitnell) (11/04/87)
In article <4241@sdcsvax.UCSD.EDU> jww@sdcsvax.UCSD.EDU (Joel West) writes: |I'm told my someone whose opinion I respect that StuffIt | a) is far superior in compression density (up to 3:1) | b) will be the standard for Compu$erve It is standard on both Compuserve and Delphi. Actually, they accept either PackIt or StuffIt. | Joel West (c/o UCSD) Jerry Whitnell It's a damn poor mind that can only Communication Solutions, Inc. think of one way to spell a word. -- Andrew Jackson
garth@swatsun (Garth Snyder) (11/05/87)
I am writing to throw in my two cents about stuffit. First of all, I
think stuffit is beautifully executed and reliable. There is no question
in my mind that it beats Packit hands down.
I really wish the author of stuffit had gone whole hog and included a
couple of other features. These would not have been trivial, but would
have made stuffit a guaranteed smash shareware success. To wit:
1) It should subsume all the functions of Binhex 4.0.
2) It should have complete (encryption, etc.) Packit compatibility.
3) It should do DES encrption.
4) It should be able to pack up <complete> folders. It will pack all
simple files in a given folder now, but should be able to do
recursive folder packing.
5) It's contents display window should have a neat-o way of dealing
with #4, i.e. selectively show contents of folders.
Of these, #4 is the one that makes me drool the most.
If the author of stuffit wants to add these features or someone wants to
write yet another program that can handle this type of thing in as classy
a way as stuffit, I promise to buy it.
--------------------
Garth Snyder UUCP: {seismo!bpa,rutgers!liberty}!swatsun!garth
Swarthmore College ARPA: garth@boulder.colorado.edu
Swarthmore, PA 19081 ALSO: {hao,nbires}!boulder!garth
--------------------ssegan@dasys1.UUCP (Sascha Segan) (11/05/87)
I've heard a bunch of people badmouthing StuffIt. I 'live' at Ray's home site,
and I've been talking to him. StuffIt is DOWNWARD COMPATIBLE, folks!
Pretty soon, if what I've heard is right, StuffIt will be the only program
you need. It CAN unpit PackIt files, and a version in the works(?,Ray?)
can unBinHex!
So, periodically, you post StuffIt to comp.binaries.mac, but even people
who DON't have it can pack with PackIt and StuffIt can unpack!
Sheesh.
----Sascha
--
Sascha I. Segan {allegra,philabs,cmcl2}!phri\
Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!ssegan!
New York, NY, USA {hoptoad,bc-cis,aecom,orville,raspi}!/ raylau@dasys1.UUCP (Raymond Lau) (11/05/87)
Thus far, I have avoided defending the positioning of StuffIt...and I will continue to do so. But I'd just like to add a little note.
I do plan to add in a BinHex type command to the menus... So that you can do everything in one prgm. This won't satisfy those who want the ability to have integrated auto-.hqx'ing, but it will provide the next best thing.
That's it for now...
-----------------------------------------------------------------------------
Raymond Lau {allegra,philabs,cmcl2}!phri\
Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!raylau
New York, NY, USA {sun}!hoptoad/
GEnie:RayLau Delphi:RaymondLau CIS:76174,2617
"Take it and StuffIt."bono@dartvax.UUCP (Christopher North) (11/05/87)
Well it is time for me to add my opinion on Stuffit vs. Packit. First of All...Packit too is shareware for the packer so it is not a completely costless protocol. Now what I don't understand is why people are resisting a 'better' procedure. Stuffit makes files smaller. That means a lot to many people. To me ...it means that I don't have to free up as much room on my communications disk to do a download. It also means that I can archive files on disks and put a lot more files on a disk. AND...it means that files sent over the .net are smaller and thus save money in transmission times. Stuffit gets my vote. Say yes to progress and no to old stuffies! -- Chris North Dartmouth College or 320 Mammoth Road Hanover NH 03755 Manchester, NH 03103 CSNET: bono@dartmouth.edu
isle@dartvax.UUCP (Ken Hancock) (11/05/87)
In article <2103@tekig4.TEK.COM> bradn@tekig4.UUCP (Bradford Needham) writes: >In article <7507@dartvax.UUCP> borscht@dartvax.UUCP (Andy J. Williams) writes: >>Why stick with the inefficient? > >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? StuffIt does not add. It replaces Packit. >2) They are widely available. How many times have you seen requests for >BinHex on this newsgroup? Remember all the confused and frustrated requests >for Packit? Why repeat that experience? SuffIt will become widely available as more people use it. Do you think Packit appeared overnight? >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? The author of StuffIt, I believe, has allowed StuffIt to be free for unpacking. Packing will cost you $15. Come on, you have a job.... >4) They are stable. BinHex4.0 and UnPit have been in use long enough to >demonstrate that they work. Why test a new program? Why? Frankly becuase unPit isn't so good. It's better than nothing, as most things go, but StuffIt is better. It does a better job, AND, it should save the net time and money. Also, if you're a Compuserve, GEnie, Source, etc. user, it saves you a LOT of money.... Ken -- Ken Hancock UUCP: isle@dartvax BITNET: isle@u2.dartmouth.edu DISCLAIMER: If people weren't so sue-happy, I wouldn't need one!
pgn@usceast.UUCP (11/06/87)
Yes we want StuffIt to stuff folders!!!
c60b-ia@buddy.Berkeley.EDU (Sugih Jamin) (11/06/87)
Reminds me of a heated debate in comp.sys.ibm.pc some time ago, it was between "arc" and "pkarc," or more specifically, between "squashed" and "unsquashed" arc files. There is always a big inertia with changing the current standard, but I have been happy with squashed archives as I am happy wiht the mac, as opposed to the pc. sugih jamin
robby@eiibank.UUCP (Robby Kates) (11/07/87)
In article <1895@dasys1.UUCP> ssegan@dasys1.UUCP (Sascha Segan) writes: > >I've heard a bunch of people badmouthing StuffIt. I 'live' at Ray's home site, >and I've been talking to him. StuffIt is DOWNWARD COMPATIBLE, folks! >Pretty soon, if what I've heard is right, StuffIt will be the only program >you need. It CAN unpit PackIt files, and a version in the works(?,Ray?) >can unBinHex! >So, periodically, you post StuffIt to comp.binaries.mac, but even people >who DON't have it can pack with PackIt and StuffIt can unpack! >Sheesh. >----Sascha > >-- >Sascha I. Segan {allegra,philabs,cmcl2}!phri\ >Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!ssegan! >New York, NY, USA {hoptoad,bc-cis,aecom,orville,raspi}!/ I too have been following this debate. Frankly I've got this to say: smaller volume of news to uucp is a good thing. As system administrator at this site I get pretty scared when I see how much news comes in every day. Using StuffIt is an ideal way of decreasing volume, simply because no news is lost, and space is saved. We have to pay (like real $$$) for the phone lines, and I expect that StuffIt will pay for itself in phone bills (since there is the cost both of getting the news in the feed and from downloading the files to the mac). Sascha (above) described how StuffIt is great functionally. The other side of the coin is the saved space and time, and that is quite valuable. I will be happy to mail copies of StuffIt to anyone who needs one, and ask people who post to please use StuffIt to compress the files. It will save us time and money. -Robby -- Robby Kates Beatrice Corporate Headquarters ...ihnp4!eiibank!robby Chicago "...and a lover who looks straaaaangly, like Time the Avenga..." -CH- #include <disclaimer.h>