SnuffIt, Expander
Ground control to Mac OS X developers from around the World, we have an important message for you: please stop using StuffIt to compress the disk images on which you distribute your software, it’s a very silly thing to do, really1.
Mac OS X disk images (.dmg) have no resource fork and thus don’t need to be encoded in BinHex (.hqx, baaad) or MacBinary (.bin, mostly harmless) for Internet transfers. Moreover, they can be compressed in Disk Utility when they’re created (or converted to the compressed format). Just choose Image Format > compressed instead of read-only in the save dialogue. These compressed disk images mount about as quickly as the uncompressed ones and are usually a little bit smaller than a stuffed read-only image.
On the other hand, StuffIt archives take ages to stuff and unstuff. And I mean ages as in an order of magnitude longer that it takes to mount a compressed disk image. The worst is when an image contains an installer or a Mac OS X package. These files are already compressed so the only benefit of compressing the disk image is to reclaim the small amount of free space that it may have. This is best done by Disk Utility.
As an example, think about a 208 MB installer on a disk image with 17 MB free space, totalling 225 MB2. Stuffing the image will probably not shrink it to less than 208 MB but StuffIt Expander will take several minutes to decompress it, whereas the same image zipped using Panther’s archive feature will extract in ten seconds and a compressed disk image will mount in three seconds, if you skip the checksum. The icing on the cake is that the zipped and the compressed image both make slightly smaller downloads than the StuffIt archive.
The only sort-of valid reason for compressing a disk image using a third party format is when the web server cannot be configured to associate the .dmg extension with the application/octet-stream MIME type, resulting in the web browser trying to display the image as text. In this case, MacBinary is better suited as it’s very quick to decode since it does not try to compress the image, but dumping (or threatening to do so) the hosting provider who’s too lazy to add an entry to the mime.types file is also perfectly reasonable.