765 words on Mac OS X
One thing about Mac OS X is that beneath the shiny cover it is somewhat Unixoid. I guess by that I mean that all of the sudden we have the Terminal geeks hanging around because what’s under the proverbial hood suddenly was somewhat documented structured and tinkerable. This gave us some half-assed GUIs for command line tools. And it also removed the convenience that making a bootable copy of your hard drive required you to have another hard drive plus a single drag and drop operation in the Finder. – As opposed to a degree in geek science or some third party tools these days.
But while the user experience deteriorated in some areas, the users – the power users at least – became more powerful thanks to the clearer structure and the less secret details of the OS. I don’t think this balance has been struck in a perfect way. But it’s tolerable nonetheless.
One thing does annoy me on a constant basis, though. And that’s the fact that the whole friggin’ OS and all of its applications consist of gazillions of little files. Just go to the Finder and copy your iTunes application to another hard drive. It is about sixty megabytes in size and even with normal speed drives this should be accomplished in ten seconds. Yet, the Finder needs about a minute for that trivial task.
Of course I can see the benefit of this. It makes it extremely easy to replace parts of an application only and to fiddle with the application … by digging around its resources or replacing text, say. But those things only benefit developers and don’t benefit the average user.
In fact, whenever I’m using a desktop computer with a fast hard drive, I notice how applications just launch faster there. And I suspect (I didn’t time and test this!) that this suggests that a lot of time of the application launch is spent waiting for some frameworks or libraries to be loaded. A process which might be easier to optimise if those countless folders and files were stored in single, specially structured file – which, optimistically, might let developers indicate which resources need immediate loading and which don’t.
Ironically, some of the more modern parts of Mac OS X seem to abandon that approach to use many files instead of a single one. Safari’s feature to save a web page completely, for example, will not create a bundle on your hard drive containing all the relevant files but instead generate a single file which has all the content crammed into it (and by that keeps you from conveniently looking at the files of the site or manipulating them).
While the examples of that aren’t too numerous yet, it seems that CoreData’s database style files also consist of a single file only. That certainly makes sense for a database, but once you start thinking about large amounts of data and backups, this means that you’ll have to backup the complete large file every single time you change a single bit in it. (Which in turn could be blamed on the cleverness of the backup software you are using… but then point me to backup software that is affordable and reliable, please). Another example for that is iTunes’ library file. While it’s most likely that the only thing changing in typical day-to-day operations are the last played times and counts for how often a song has been played.
While all this isn’t a complete deal breaker, it still seems a bit twisted to me that parts of the system which don’t change frequently and don’t necessarily need to be backed up are actually extremely suited for just that – possibly at the sacrifice of speed even – while the parts of the system which change frequently are stored in single large files.
[Well, Mail switched to using a one file per message scheme in X.4, so my observation above isn’t true in general. While I didn’t have problems with Mail’s previous per-mailbox storage of messages, I wonder why this change happened. The obvious pointer would be to Spotlight which – sadly – is incapable of properly indexing several items of data (mail messages) for a single file (mailbox). On the other hand, having a file per message feels a bit safer: if shit hits the fan my e-mails will be destroyed a message at a time rather than a mailbox at a time which can make a huge difference. On yet another hand, it means that copying your Mail folder to a backup location will take an eternity.]
Launching apps is fast enough for me, backing up isn’t. Those gazillions of small files may reduce backup volume but really slow it down. I’d like to see “files system level bundles” which are stored as one piece but otherwise normal directories, navigable in the Finder and Terminal. A new API call to read/copy whole directories would recognize them and do it en block. Didn’t Classic use something similar for fonts?
