As the usage of cron is now deprecated on OS X and OS X Server in favour of launchd, I thought it was about time I learnt how to use launchd so I could move all my cronjobs across to it. launchd is one of Apple’s various contributions to the Unix world, and its purpose is to be a single tool to take the place of init and to replace a variety of startup mechanisms such as the rc/rc.d startup architecture, cron, and inetd/xinetd. In keeping with most other technologies emanating from Apple it is simple, elegant, efficient and powerful. If you do a significant amount of Mac administration then now is the time to learn launchd if you haven’t already.

However… it’s a bit of a hassle to learn launchd and Apple’s XML property list (‘plist’) files when you were comfortable with cron and it was doing the job fine before. But I found that launchd-related stuff is pretty well documented and quite straightforward once you get going with it. Here’s an example of a plist file I created which triggers a script that runs a backup job then emails me the output:

This gives the timings of when the script should run, and it works very much like the first five fields in a standard crontab. In this case the script runs every day at 8:08 in the morning.

<key>Debug</key>
<false/>

Debugging is set to ‘off’, but it can easily be turned on to debug problems. Output from launchd appears in /var/log/system.log and is not always as helpful as it could be, but it’s certainly better than nothing.

<key>AbandonProcessGroup</key>
<true/>

For a while I couldn’t work out why the backup script was being triggered by launchd but was failing to email me its output. This error message appeared in the system log each time:

After a while I learnt that when launchd had finished running the backup script, it was also killing all processes started from within the script – in this case the process of mailing me the results of the backup. Setting ‘AbandonProcessGroup’ to true tells launchd to leave all child processes running rather than killing them. It’s quite an important thing to know about, really, otherwise it becomes an irritating mystery as to why bits of your script are not getting finished.

I called my plist file svn_sync.plist and put it in /Library/LaunchDaemons. With plist files for launchd it appears you basically have a choice between putting them in /Library/LaunchDaemons or /Library/LaunchAgents. Apple’s Daemonomicon (what a lovely word!) explains all of this in detail, but basically, if I’ve understood correctly, the plist file should go into /Library/LaunchAgents if it might interact with a user whilst it runs, otherwise it should go into /Library/LaunchDaemons. The latter seemed more appropriate in this case because the script will never interact directly with a user.

Once your launchd plist file is in place, just use launchctl to load it into launchd:

I checked out the first beta of Chrome for Mac in December and found it to be lacking essential features, but Google have finally released a fully usable version for Mac. It might almost be worth the wait. It’s wonderfully fast, lightweight and transparent, and it does absolutely everything I want a browser to do, in exactly the right ways.

Exactly as I predicted, variable pricing on iTunes has turned out to be a bad idea. It confuses customers and makes them feel ripped off, and the stupid record companies have seen slower growth as a result of forcing Apple to implement it.

For a long time I’ve hated Flash content on the Web. It’s a bloated and unstable piece of rubbish that causes frequent slowdowns and crashes. For a while I’ve been using the marvellous ClickToFlash which disables Flash and thus enables me to enjoy Safari blazing away at full speed all the time, unencumbered by the abomination that is Adobe Flash Player. Another benefit of ClickToFlash is that it lets you watch videos on YouTube using H.264, thus bypassing the Flash monstrosity even for YouTube content. On the occasions when there is some Flash content that you actually need to see, you can temporarily enable it for that individual item without having to switch it on for anything else.

I’m certainly glad I don’t have to tolerate Flash on my iPhone, and in many ways I’m happy it won’t be appearing on the iPad either. Whilst I have reservations about the lack of control users have over their iPads, I can’t help but feel pleased that Apple’s anti-Flash strategy will help to kill off Flash and promote the use of the HTML5 video tag instead. I look forward to the day when Flash is dead, and video can be enjoyed properly on the Web without one’s Mac grinding to a halt.