The Oracle Java 7 JRE (a web plugin) began shipping last year, and has grown a small maze of clever mechanisms to maintain a schedule of checking for updates. It’s a sad tale of the misuse and abuse of launchd schedule re-writes and re-loads, the Sparkle Framework, storing Java properties-like prefs in OS X defaults, and having two different systems that actually check for updates implemented in two different languages and runtimes.
I covered this earlier this year in a couple posts. It also prompted me to write an overly-opinionated recipe for AutoPkg.
Update-checking control in the Java Control Panel
The takeaway from those previous two posts is that the plugin has a mechanism triggered by the applet to check for updates, but because this only runs once the plugin is loaded via a browser, there is also a background-check LaunchAgent that prompts the user to install the latest version via a Sparkle dialog (a process which later goes and re-loads LaunchAgents as root instead of you, but read the earlier blog posts if you care.)
Now that Update 40 has been out for over a week, I’ve taken some time to look at the changes to the installation that should be of interest to anyone deploying it en masse.
Managing ColorSync ICC profiles for displays is something I do for certain workstations via MCX, and it’s always been a pain. Typically I would manually configure a profile for a display, then open up that user’s ByHost .GlobalPreferences preference stored on disk, extract the keys for the hardware-specific GUID that corresponds to that monitor (something like
Device.mntr.00000610-0000-9C6B-0000-000004271AC0), and import them into MCX, ending up with a blob like this:
…which works, but I had to do a lot of manual work to get this configured, and I don’t want to repeat this for 1) every machine needing a managed profile, and 2) every time a Mac or display gets changed. It would be nice if we could just specify a profile on the command line for a given display, and make it so.
Sure enough, there is a supported ColorSync API that can handle this, and the PyObjC Python-Objective-C bridge is there to help us implement it with little code, and no Xcode project or compilation required. I wrote a simple command-line utility that I’ve put up on GitHub here.
It turns out that this preference can also be configured at the “any-user” level, so this tool supports that. There’s also a sample helper script in the GitHub repo that demonstrates how you could run this run this utility at login time for all users, such that these profiles can be managed easily by those calibrating the monitors.