5 ms·
This is my first time hearing about it, despite daily driving MacBooks for 10 years. Does it have any advantages over other compression software? I've been usin
by LimeLimestone 3y ago
This is my first time hearing about it, despite daily driving MacBooks for 10 years. Does it have any advantages over other compression software? I've been using Keka for a long time and it has yet to disappoint me.
- egypturnash 3y agoBack in 2000, it was what everything on the Mac was compressed in, because it understood the Mac’s uniquely complex executable file format and was a much more reliable way to transfer executables than compressors designed on simpler file systems. Then in 2001 OSX came out, with a new executable file format of “a specially named and structured directory in a boring UNIX file system”, and Stuffit’s reason for existing began to vanish. I’m honestly very surprised someone is still updating it now.
- rgovostes 3y agoApple pushed compressed disk images (.dmg) early on as the preferred way to distribute software on Mac OS X, so StuffIt wasn't necessary. Mac OS X 10.3 (Panther) introduced native .zip support, and that seems to have largely taken over these days. I wonder how much of that is due to it being easier for CI systems to produce .zip archives rather than DMGs.
- II2II 3y agoIt wasn't limited to executable files. All files were split into data and resource forks. As a bare minimum, the resource fork would define the file type. Without it, the Finder couldn't figure out which program to open the file in. A lot of software couldn't even open its own documents without the resource fork, sometimes because it couldn't figure out the file type and sometimes because it used the resource fork for its own purpose (so the document would be corrupted). Unlike many people, I think the resource fork was a good idea. It structured files in a consistent way, and they were easy to examine if you had the right tools. The shortcoming is that there was not standard way (or maybe too many standard ways) to transfer files between systems intact. There was too much risk of important data being lost because the system you were transferring the data to (or a system you were transferring data through, or the software you were using was configured to ignore the resource fork) didn't recognize the resource fork or its encoding. (It is also worth noting that a lot of file formats tend use something similar to resource forks these days. Resource forks are a bit like using zip files as a wrapper in, say, ODT and ePub files.)
- jccalhoun 3y agoStuffit was relevant in the late 80s and 90s. It hasn't really been relevant for a long time.
- geerlingguy 3y agoIt was basically the zip file for Mac, and almost all software was downloaded as a .sit file. Stuff from Macintosh Garden is still mostly in .sit or .toast
- chongli 3y agoYes, though it's much worse than zip! I recall having tons of issues with incompatibility between different .sit files and different versions of the unarchiver. I don't know if I've ever heard of any binary incompatibility issues with zip files.
- renhanxue 3y agoStuffIt is a thing you might be nostalgic about if you used MacOS 7 through 9 or so in the 90's. I'm surprised it still exists, I don't recall using it on OS X at all.
- alsetmusic 3y agoI think it was there for the first few years. I seem to remember a revised app icon when they went from 32x32 to 128x128. I don't think it mattered much, though.
- gcanyon 3y agoI came to post roughly this. I had literally forgotten StuffIt was a thing, until the headline brought it all flooding back.
- RandallBrown 3y agoI remember many apps being distributed as .sit files on OSX at least in the old Tiger and Leopard days.