hdiutil Requires sudo for Read/Write

Another unwelcome surprise from Apple: in some recent OS X update (I don’t know exactly which one as I ran into the problem this morning) they changed how hdiutil behaves when mounting sparsebundles in read/write mode (it is used in my build scripts as a step toward generating the final setup DMG): it now requires sudo-ing when you use the -readwrite flag.

The problem is that sudo by default prompts for a password and silently fails when used from a script. The solution is to remove that password requirement. This is carried out by adding a line to the /etc/sudoers file:

%admin ALL=(ALL) NOPASSWD: /usr/bin/hdiutil

This innocent one-line edit requires lots of command-line gymnastics, however. Permissions on the sudoers file is 440 by default, and the sudo command fails to work with anything other that that.

So you have to boot your Mac in single user mode to do the edit (by holding down Command+S at startup). Then you have to mount the root file system in read-write mode and change the permissions on the file:

mount -o update /
cd /etc
chmod 640 sudoers
vim sudoers

Add the line to the end of the file, save it and restore the file’s permissions:

chmod 440 sudoers

You can now reboot, and sudo hdiutil will not ask for a password any more! So it can be safely used from within build scripts.

MacBook Pro with Retina Display

It took a month, but my machine finally arrived two days ago. I spent the whole yesterday on moving my digital life over to the new machine and set it up for work. This post is a collection of my initial impressions. I will not reiterate the specs that can be found in numerous online reviews. All of those I recommend watching just this one.

My configuration is the 2.6GHz machine with 16GB of RAM and a 500GB SSD.

Winner of Two Lotteries

You enter two “lotteries” when you buy an Apple notebook. The SSD lottery and the display lottery. The reason is that Apple sources these components from two vendors: Samsung and Toshiba for SSDs/flash memory (I will use the Solid State Disk term instead of Apple’s “flash memory” marketing talk from now on – because these are all SATA connected SSDs – although in different form factors) and Samsung and LG in case of displays. Unfortunately the non-Samsung options are vastly inferior to the Samsung ones.

For example, Samsung SSDs are using the great Samsung PM830 controller. The Toshiba one use a Sandforce SSD controller. Sandforce SSD controllers compress all the data before it gets written into the chips for an almost twofold throughput increase. But if you are like me, and use FileVault to encrypt your disk then this compression becomes useless: almost random data can’t be compressed. Which results in halved performance. Fortunately, for larger capacity drives Apple seems to be using the Samsung ones. So I ended up with an 500GB Samsung SSD. One win.

You might wonder why did I mention 500GB instead of the advertised 512GB. Because the 512GB is simply a lie. The drive actually measures 500GB (if you count 1,000,000 bytes as one GB – as the storage industry as well as Apple does) and 476GB if you count (1,048,576 bytes as one GB – which is how many bytes a GB truly is).

Regarding the display lottery, lots of LG manufactured panels are defective out of the box. Just execute the command in the linked article to show your display’s manufacturer. LP is for LG and LSN stands for Samsung. I have a Samsung panel. Another win.

Is the Lack of Upgradeability a True Problem?

Lots of people on the Internet fret about this. Frankly, in the last 15 years I can only mention two occasions when I upgraded memory in my machines. And CPUs were never changed. Disks are another story. Before SSDs I regularly went to faster disks as they became available. But since I’m using SSDs I don’t feel the need to upgrade yearly. I usually buy my machines maxed out with RAM and disk, and opt for the one-less-that-the-fastest CPU option (they cost way less and the performance difference is negligible). So the lack of upgradeability is not a problem for me.

And on the positive side, soldering RAM to the motherboard gives some huge performance benefits (read the section below the graph). Wow, 99.9% processor bandwidth utilization IS something!

Two Missing Pro Features

ECC memory and 30-bit display output capability. I know that ECC (Error Check and Correction) has disappeared from consumer machines and Intel only supports ECC with their Xeon processor line, but 16GB is a lot and for mission critical work (like huge CAD models) ECC is a must. So for situations where it is not acceptable that your memory can forget a few bits here and there, the Mac Pro is the way to go. For example I use a Xeon E3-based server machine with 16GB of ECC memory.

The other one is 30-bit color. This is available on all current high end graphics displays and NVIDIA makes mobile chips that support 30-bit. Usually these chips are completely identical to the consumers ones Apple is using, just high precision stuff is enabled in them (I remember those times when I hacked consumer NVIDIA cards to Quadro ones…). For a notebook at this price point, pro graphics should be the standard.

Needs a Thunberbolt Dock

On the left side of the machine I have:

  • The power cable.
  • A mini displayport to DVI adapter for my EIZO CG241W display.
  • A Thunderbolt to Gigabit Ethernet adapter.
  • An USB connection to the EIZO. Keyboard and mouse is attached to the EIZO’s hub.

Looks ugly. And plugging in all these when I use the machine as a desktop is a hassle. I can hardly wait for Matrox’s solution.


The machine is light (for such a powerhouse), fits neatly into the notebook pocket of my Lowepro Pro Trekker 400. Key travel is a bit short, but it’s not really a problem. I miss PageUp/PageDown and Home/End keys…

It gets a bit warm during use, but it’s bearable. As the majority of current applications are incapable of driving the four processor cores (with eight processing threads), so fans are spinning silently. Even if you can put some heavy load on the machine they produce an almost pleasant noise. Nothing disturbing (and believe me I’m overly sensitive to machine vibration and noise).

Battery life is rather short – I found it about 5 hours in my normal usage patters. This is way less than Apple’s advertised 7 hours, but there are reports that Mountain Lion causes this reduction. We’ll see.

Applications and the Retina Screen

The screen resolution is astonishing. Brightness uniformity is not on the same level as my EIZO (actually I would score this as pretty bad). The display calibrates very accurately (in one spot at least). I was surprised that it produced less deltaE2000 than the EIZO. If uniformity would be better, this could be a great graphics display. All in all I want this high resolution on my desktop graphics monitor! Hope that either EIZO or NEC will come out with a high resolution display like this.

I would also note that the Intel integrated graphics is not capable of handling such large amount of pixels. You can’t even watch a movie full screen using integrated graphics, so the machine uses the NVIDIA chip a lot.

The real problem is that most of the applications are not yet ready for supporting the HiDPI modes of the Retina display. These apps would really need the upgrade:

  • Photoshop
  • Lightroom (it displays UI text in high res, but everything else is pixel-doubled)
  • Capture One
  • Kindle

Others, like Parallels Dekstop and VLC, already support the display. It’s still a waiting game. And the display would only realize its full potential when these apps become ready.

Canon Software Crashing on OS X 10.8

Shameless plug: If you are shooting tethered, I recommend you to check out Kuuvik Capture, an app that I wrote for Kuuvik Digital. It’s light years ahead of EOS Utility. You can find my posts related to the app here.

October 10, 2012: Canon has released EOS Utility 2.12.0, which resolves the problem. You can download it from here.

September 24, 2012: both applications produce the exact same behavior on the latest OS X 10.7.5 update. So now Lion users are also affected.

Let’s begin with the hard facts: Canon’s latest EOS Utility (2.11.4, released a week before the public 10.8) crashes on Mountain Lion each every time I connect my 5D Mark III. The version I got with the camera on the included CD (2.11.0) works just fine. Also, the current version of the app works fine on Lion.

EOS Utility Crash

Moreover, the CaptureCoreServer component in Capture One 6.4.3 is also crashing every time I connect the camera. This happens periodically, as the main app tries to restart the just crashed server.

Capture One Crash

Phase One states in the 6.4.3 release notes that new features are (among others):

  • Added support for Mac OS X 10.8 Mountain Lion.
  • Tethered support for Canon 1D X and 5D Mark III.

It seems that Phase One has serious issues with their quality assurance department (nobody ever tried this setup, they just blindly released it). Which is a bad thing for such an expensive software.

Being really upset with these I decided to do a little private investigation on my own. I’m a developer, so the goal was to at least identify who is responsible for screwing things up so badly. From the crash logs I was able to quickly identify a component named “com.canon.edsdk”, which lives in the EDSDK framework. The following is a prettified excerpt from the crash log:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib
    objc_msgSend + 27
1   libobjc.A.dylib
    (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 490
2   com.apple.CoreFoundation
    _CFAutoreleasePoolPop + 51
3   com.apple.Foundation
    -[NSAutoreleasePool release] + 125
4   com.canon.edsdk
    CIccMan::SendPtpCommand(void*, tagEdsPassThrough*) + 961
5   com.canon.edsdk
    CMacPtpInterface::SendCommandSelf(void*, SPtpParam*) + 120
6   com.canon.edsdk
    CPtpInterface::DS_SetRemoteMode(void*, DS_REMOTE_MODE_T) + 156
7   com.canon.edsdk
    CPtpCamera::OpenSessionSelf() + 314
8   com.canon.edsdk
    CEdsCamera::OpenSession(long) + 69
9   com.canon.edsdk
    EdsOpenSession + 77
10  com.canon.EOS Utility 2
    -[MainController openSession] + 182
11  com.canon.EOS Utility 2
    -[MainController connectCamera] + 353
12  com.canon.EOS Utility 2
    -[MainController launchApp] + 555

0xb0000000 - 0xb0050ffb +com.canon.edsdk ( -
EOS Utility.app/Contents/Frameworks/EDSDK.framework/Versions/A/EDSDK

It seems that the EOS Utility calls the EdsOpenSession function (in stack frame 9, marked with bold) in the EDSDK framework, which causes the crash down the road.

Now that I know the name of the component that causes the crash I quickly checked the EDSDK version in the old and new EOS Utility as well as in Capture One. The numbers are the following:

  • EOS Utility 2.11.0 – EDSDK version
  • EOS Utility 2.11.4 – EDSDK version
  • Capture One 6.4.3 – EDSDK version

So the responsible party (for the crash) is either Canon or Apple. My bet is that Canon introduced this bug between and versions of their framework. Even if Apple has changed something that caused the framework to break, Canon is guilty in not testing their software on upcoming OS releases. This is especially irritating in these days when platform providers like Apple release a new operating system each year. Saying that “oh, it works fine on last year tech” is a surefire way to alienate customers. Phase is just guilty in not testing what they release (which is also a cardinal sin in my book).

I had filed bug reports with all three companies when I ran into the issue. Canon Europe’s response was the usual: nothing, nada, zip. Not even a “thank you for your feedback” message. Apple and Phase are both working on the bug, but made no progress during the last week or so.

I’ll let you know when progress is made, but given Canon’s track record of fixing things don’t expect it to happen overnight. Do your tethered shooting with the old EOS Utility in the meantime. Oh, and don’t forget to disable the Canon provider in Capture One to avoid interference between the two apps!

Disable the Canon provide in Preferences

EIZO ColorEdge Monitors with OS X 10.8

As I mentioned in my previous post, EIZO’s ColorNagivator software (that is used to calibrate and profile their hardware-calibration capable ColorEdge line of monitors) does not work correctly on Mountain Lion. After installation colors looked awful on my CG241W, which the calibration only made worse. Checking the validation results clearly shows why.

ColorNavigator 6 Validation Results

Instead of the usual ~2 deltaE2000 maximum difference I got more than 5. Even cheap, crappy LCD panels produce better results. This is totally unacceptable.

There’s a solution, however.

About a year ago I had tested the basICColor display package. It worked great, but I had decided against it as the quality difference over ColorNavigator had not been  that big.  So I downloaded and installed the 14-day trial on my current machine. Although the manufacturer says it’s Mountain Lion compatible, the installer is not digitally signed, so Gatekeeper prevented the install. The usual right-click – Open trick worked like a charm (opening an app this way you have the option to add it to the Gatekeeper white list).

Besides this glitch the app worked flawlessly. Here is the validation result.

basICColor 5 display Validation Result

The calibration is even more precise than it was with ColorNavigator. This proves that the cause of this issue lies within EIZO’s software. Unfortunately, they have no usable technical support at all (you can contact the local reseller, but this effectively shields the development team from any user feedback).

I’ll give EIZO a week or two to fix this issue, then I’ll give up and buy basICColor display. It is EUR 100, but the manufacturer has no web shop, so purchasing it might present some issues… All in all, I’m really angry that manufacturers of super-high-tech (and super expensive) equipment does leave their customers in the dirt, and they doesn’t seem to care at all. An even better example of this is Canon, but I’ll tell you about that in the next post.