Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A gzip could represent HFS+ forks and attributes the same way the article is discussing - AppleDouble files and .DS_Store files. In fact, this is exactly what is done with zip files you create in the Finder.

Anyway, there's no way Apple is going to make improvements to the manual app install process anymore now that they have the App Store.



tar (which is what you mean) could do this, but until OSX Macs didn't ship with tar. DMG (technically the UDIF file format) came about as a continuation of .img files (the NDIF file format); there had already been built up some ecosystem around .img and .smi files and Apple wasn't going to suddenly switch to thinking in terms of tar files when they didn't have to.

Plus, a UDIF image can be simply passed to the kernel as a loopback image for a block device, and the files on it will then be discovered as plain files. For the same to work with tar or zip files, Apple would have had to introduce either something like the concept of Plan9/FUSE-like server processes that translate arbitrary backing stores into filesystem mounts; or break the universal abstraction of a filesystem by creating a higher-level shell namespace that could "see into" archives (like Windows and GNOME do) making OSX's Unix integration much less useful.

Mainly, though, it's that zip and tar are archival file formats. They're suboptimal for doing random-access updates on their contents, which is an important use-case of disk image formats. DMGs exist on OSX for the same reason that VHD(X)s exist on Windows: it turns out they're just a pretty great and flexible format for doing a lot of things OSes want to do.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: