The public was not fooled, however, and found ways to test coins for purity, including folkloric ones like biting a coin to see if it is made of malleable gold, rather than harder metals. People would then hoard pure gold coins, and try to rid themselves of debased coins at the earliest opportunity. This led to Gresham’s Law: bad money drives out good money in circulation.

After a year of using Amazon Web Services’ EC2 service at scale for my company (we moved to our own servers at the end of 2011), I conjecture there is a Gresham’s Law of Amazon EC2 instances – bad instances drive out good ones. Let me elaborate:

Amazon EC2 is a good way to launch a service for a startup, without incurring heavy capital expenditures when getting started and prior to securing funding. Unfortunately, EC2 is not a quality service. Instances are unreliable (we used over 80 instances at Amazon, and there was at least one instance failure a week, and sometimes up to 4). Amazon instances have poor disk I/O performance that makes them particularly unsuitable to hosting non-trivial databases (EBS is even worse, and notoriously unreliable).

Performance is also inconsistent—I routinely observed “runt” m1.large instances that performed half as well as the others. We experienced all sorts of failure modes, including disk corruptions, disks that would block forever without timing out, sporadic losses of network connectivity, and many more. Even more puzzling, I would get 50% to 70% failure rate on new instances that would not come up cleanly after being launched.

Some of this is probably due to the fact we use an uncommon OS, OpenSolaris, that is barely supported on EC2, but I suspect a big part of this is that Amazon uses low-end commodity parts, and does not proactively retire failed or flaky hardware from service. Instances that have the bad luck of being assigned to flaky hardware are more likely to fail or perform poorly, and thus more likely to be be destroyed, released and a new one reassigned in the same slot. The inevitable consequence of this is that new instances have a higher likelihood of being runts or otherwise defective than long-running ones.

One work-around is to spin up a large number of instances, test them, and destroy the poor-performing ones. AWS runts are usually correlated with slower CPU clock speeds, as older machines would be running older versions of the Zen hypervisor Amazon uses under the hood, have less cache, slower drives and so on. Iterating through virtual machines as if you are picking melons at a supermarket is a slow and painful job, however, and even their newer machines have their share of runts. We were trying to keep only machines with 2.6 or 2.66GHz processors, but more than 70% of the instances we were getting assigned were 2.2GHz runts, and it would usually take creating 5 or 6 instances on average to get a non-runt.

In the end, we migrated to our own facility in colo, because Amazon’s costs, reliability and performance were just not acceptable, and we had long passed the threshold beyond which it is cheaper to own than rent (I estimate it at $5,000 to $10,000 per month Amazon spend, depending on your workload). It is not as if other cloud providers are any better—before Amazon we had started on Joyent, which supports OpenSolaris natively, and their MTBF was in the order of 2 weeks, apparently because they replaced their original Sun hardware with substandard Dell servers and had issues with power management C-states in the Dell server BIOS.

The dirty secret of cloud services is that there is no reliable source of information on actual performance and reliability of cloud services. This brings out another economic concept, George Akerlof’s famous paper on the market for lemons. In a market where information asymmetry exists, the market will eventually collapse in the absence of guarantees. Until Amazon and others offer SLAs with teeth, you should remain skeptical about their ability to deliver on their promises.

I have a Withings body weight scale that I really like and I was excited to learn they were going to release a networked video baby monitor. It took a while to get to market in the US, however, so in the interim I purchased a Philips Advent DECT digital baby monitor, which ended up unusable in practice, because its microphone sensitivity is so poor that you can barely hear anything. When the Withings baby monitor finally became available in the US, I immediately ordered it.

Withings is clearly taking design cues from Apple, from the lavishly designed packaging to the glossy white plastic RoundedRect aesthetic and the use of a magnetic clip to attach the baby monitor to the crib. The clip is serviceable, but the magnets are not quite strong enough to hold the unit firmly onto the crib. I would not trust it to keep the monitor from toppling when the baby grows and kicks at the crib.

The wall wart is a generic black model with swappable AC prongs for international markets, and detracts from the overall package, but since the monitor has a micro-USB input, you can always use another adapter like the iPhone’s. A rechargeable battery is included, with 2 hours’ claimed life, I did not verify that spec.

The initial out of the box experience is good: you connect to the device from your iPhone or iPad using Bluetooth (no messing around with a USB cable as with the Withings scale), enter the WiFi settings in the Withbaby app, and then use WiFi to access the device afterwards. It is as streamlined an experience as you can expect without a keyboard on the unit. There is also an Ethernet jack (it is unclear whether it supports power over Ethernet), but my house was built in 1928 and is not wired upstairs where the baby lives.

Once you enter your credentials into the app, it connects to the monitor and shows you the video and sound. If you put it in the background, you have the option of monitoring audio. Withings will also send you alerts via push notifications if the temperature or humidity is excessive, or if it detects noise or motion. The default settings are way too twitchy, however, and you will find yourself disabling audio notifications as the deluge of alerts is just too much.

The device includes a night light with selectable color, a lullaby player, and the ability to speak to your baby, all controlled through the app. At the front you also have touch controls to turn some of these features on. This is actually a bad idea, as on two occasions I started the lullaby by accident as I was fumbling with it in a dark room, and woke up my baby as a result. Another design flaw is the pulsing blue night light when the unit is rebooting, the Airport Express like amber/green status LED in the back is quite sufficient. Frankly the only one of these features that is useful is the speaker, and the ability to stream from your music collection, such as Dr. Harvey Karp’s white noise selections would be preferable to the canned lullabies.

The video camera is advertised as having a 3 megapixel sensor. It has a wide-angle lens and you can “pan” using the usual iPhone or iPad gestures. The lens is a fixed-focus plastic one, and optical clarity is so-so at best, optimal focus seems to be at 50cm or so. One great feature is the monitor has a normal and night vision mode, similar to the one on some Sony HAD camcorders, with an IR illuminator that provides light for the night vision mode. This means you can watch your baby toss and turn in an otherwise pitch-black room.

You can use the baby monitor from outside your network, but I have not tested that function. Withings allows you up to 15 minutes per day, anything beyond that requires paying them $6 for each 100 minutes. Coming on top of an already expensive device, this seems like a naked money grab from anxious parents.

When the unit works, it is absolutely great: good sound sensitivity and the video feature mostly works as advertised. Unfortunately it frequently does not function, and I find myself performing a hard reboot by removing the battery far more often than I would like. Among the pathologies:

• Once it falsely reported the unit was closed and thus video inaccessible
• Once the camera was in a frozen state, it took a power cycling to get the video moving again.
• Yesterday I could not connect at all, no matter how many times I rebooted my Airport Extreme, the monitor and my wife’s or my iPads. Some detective work using a packet sniffer showed the app was trying to connect to babyws.withings.net using HTTP, which is aliased to s11.withings.net, and that server was down. Some of the documentation suggests you can use the Bluetooth connection to access the monitor, but I was not able to figure out how to do this.

This brings me to a crucial point. The baby monitor is a safety device, and it is utterly unacceptable for its functioning to be dependent on a cloud service, which can and will be a single point of failure. It should use Bonjour or similar discovery methods to work on the LAN, and rely on Withings’ servers only when accessing it from outside the home LAN’s perimeter. I wonder if Withings’ eagerness to nickel-and-dime users by charging for outside monitoring led to this critical design flaw.

The bottom line is the Withings smart baby monitor is a very frustrating device, with its obvious potential marred by failures of execution. If it worked consistently, it would be a top-notch product worthy of its Apple inspiration and lofty price tag, but the general lack of reliability means I cannot recommend it until the bugs are ironed out. Consider it an alpha release at best.

Both mother and child are exhausted and recovering at California Pacific Medical Center, and learning to know one another. I can only watch with rapt attention at the miracle of life unfolding, bursting as I am with joy.

Of these, the camera business is still going strong, buoyed by sales of digital cameras and upgraders to DSLRs (although market saturation looms). Negatives are an endangered species as digital photography largely supplanted film. Prints are still going strong, whether using traditional silver halide, inkjet or offset printing, but that probably won’t stave off Kodak’s impending demise.

Last year, I wrote to X-Rite to complain that their software for the Colormunki color calibrator wouldn’t let me profile the full brightness range of my monitor, and limited it to an artificial ceiling designed around the limitations of print. Their response:

The ColorMunki software will not allow a range over 140cd/m luminance value.  This would basically defeat the purpose of using a device to measure luminance when you set the values this high.  While your monitor can be extremely bright however using a value of 300+ would allow your monitor to show you a brightness value that would negatively affect your prints and they would end up coming out so dark that you would be unable to see them.  The industry standard for photographic works is to use the luminance values setup at anywhere from 80 – 120cd/m.  That said, if your ambient light conditions are ranging very high then you should probably be using a value of 120cd/m which is the industry standard and what we recommend.

In the ColorMunki software there is an option to set the luminance according to your ambient light conditions.  This is a pretty high threshold in the software where as you have to read somewhere around 350-400 lux to get a target luminance above the 80 threshold.  If it does go above this value then you certainly will want to stay within the 120 range.  Anything below that will give you a target value of 80.

Implicit in this response is the assumption the only reason why you would want to calibrate your monitor is so you can make more accurate prints. Prints only have a 100:1 or so contrast ratio, compared to LCD monitors for which the static contrast ratio is closer to 1000:1, and plasma TVs go higher yet. This is why images on screen look more vibrant and punchy than prints, as did slides back in the day.

If Apple does indeed come up with the oft-rumored iPad 3 with double the resolution of current models, or 2048×1536 at 260ppi, you would have an easily portable display device with near gallery-grade resolution and massive storage capacity. At that point, prints would lose the last advantage they still hold over digital display technologies.

Image display on screen is the new normal, and X-Rite needs to get with the program. I want to see the full dynamic range and contrast of my images on my screen, not a Hobson’s choice between inaccurate color and crippling them with limitations from legacy print technology.

After much twiddling, it turns out the problem was with a misconfigured Arial font. Microsoft in its great wisdom installs a copy of Arial that conflicts with the system-supplied one, as explained in Karl Lang’s must-read article on OS X font management, but that was not the root cause of the problem.

Arial was not appearing at all in the PowerPoint font menu, and opening the slides in Keynote yielded a font warning saying non-existent Arial was replaced by Arial Narrow. Clearly PowerPoint is much less resilient than Keynote to missing fonts (crashing in outline view mode is inexcusable, but that’s Microsoft coding sloppiness for you). If Arial is so vital, it should have been included as a resource in the application bundle itself, but I digress.

Font Book did show Arial as installed, with only a single copy after I purged the conflicting fonts as per Kurt Lang’s recommendations. Validating Arial in Font Book yielded a warning about duplicate fonts, but with no indication of where the duplicate may be, since Font Book itself did not know of any other instance.

It turns out I had an old pre-OpenType copy of Arial in my ~/Library/Fonts folder that was causing a conflict. It was functional enough to be picked up as conflicting and disabling Arial in PowerPoint and Keynote, but not functional enough to be listed by Font Book. I am not sure how it got there, possibly from an older version of Office and transferred over many machine upgrades. Removing the file fixed the problem. of blank slides and the crash in switching to outline view.

Of course, if you care at all about typography, you should use Helvetica rather than an inferior ersatz like Arial, but Arial is so prevalent in the taste-impaired Windows world that one cannot escape its gaucheness entirely.

The new HP-15C is not strictly speaking a reissue but a replica, as it does not use the original’s Saturn processor, but instead an emulation thereof running on an ARM CPU. Even emulated, it should be much faster than the original 640 kilohertz processor. I ordered two, and received them today.

As expected, the quality is in line with the current HP-12C, i.e. not as good as the 1980s models in terms of key feel, but still leagues ahead of any competing product. The originals used a special 47-point bonding process to ensure the utmost in rigidity and reliability, I doubt the current model had as much attention paid to detail. It is made in China, obviously, the Corvallis facility is long gone. The slipcover fits very poorly (too tight, and the seams are not trimmed properly) and feels thinner and outright cheap compared to the original. The labels on the keys are accurately positioned, at least, unlike the train wreck that was the HP-12C Platinum. The cheat sheet in the back is a garish black on silver as on the 35S, instead of the original’s silver on black. It also uses two 3V CR2032 batteries instead of the 3 button cells in  the original.

Speed-wise, the Limited Edition integrates the normal distribution nearly instantly, when that test that took 34 seconds on the original.

In short: not as good as the original, but still an excellent calculator for those who prize ergonomics.

A couple of days ago my work iMac started experiencing intermittent freezing, and very slow searches in Mail.app. Rebuilding my Spotlight index overnight using sudo mdutil -Eav did not help. I started suspecting problems with recent versions of Chrome, or iTunes 10.5 Beta 7, but quitting those apps did not help either.

After running the Console.app, I noticed the following messages in my logs:

2011-09-14 17:39:20 	com.apple.launchd[1]	(com.apple.ocspd[3197]) Job appears to have crashed: Bus error
2011-09-14 17:39:21 	com.apple.ReportCrash.Root[3201]	2011-09-14 17:39:21.325 ReportCrash[3201:2903] Saved crash report for ocspd[3197] version ??? (???) to /Library/Logs/DiagnosticReports/ocspd_2011-09-14-173921_localhost.crash
2011-09-14 17:50:29 	com.apple.launchd[1]	(com.apple.ocspd[3269]) Job appears to have crashed: Bus error
2011-09-14 17:50:29 	com.apple.ReportCrash.Root[3270]	2011-09-14 17:50:29.964 ReportCrash[3270:2903] Saved crash report for ocspd[3269] version ??? (???) to /Library/Logs/DiagnosticReports/ocspd_2011-09-14-175029_localhost.crash
2011-09-14 17:50:45 	com.apple.launchd[1]	(com.apple.ocspd[3271]) Job appears to have crashed: Bus error
2011-09-14 17:50:45 	com.apple.ReportCrash.Root[3270]	2011-09-14 17:50:45.117 ReportCrash[3270:2807] Saved crash report for ocspd[3271] version ??? (???) to /Library/Logs/DiagnosticReports/ocspd_2011-09-14-175045_localhost.crash

Looking at those crash dumps did not yield very useful information, just some blather like this:

Process:         ocspd [3197]
Path:            /usr/sbin/ocspd
Identifier:      ocspd
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  launchd [1]
 
Date/Time:       2011-09-14 17:39:19.339 -0700
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6
 
Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: 0x000000000000000a, 0x000000010009b210
Crashed Thread:  0  Dispatch queue: com.apple.main-thread
 
Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.apple.security            	0x00007fff87b59d0b Security::ReadSection::at(unsigned int) const + 25
1   com.apple.security            	0x00007fff87b59172 Security::DbVersion::open() + 62
2   com.apple.security            	0x00007fff87b58cc1 Security::DbVersion::DbVersion(Security::AppleDatabase const&, Security::RefPointer const&) + 179
3   com.apple.security            	0x00007fff87b587ce Security::DbModifier::getDbVersion(bool) + 330
4   com.apple.security            	0x00007fff87b58675 Security::DbModifier::openDatabase() + 33
5   com.apple.security            	0x00007fff87b582b9 Security::Database::_dbOpen(Security::DatabaseSession&, unsigned int, Security::AccessCredentials const*, void const*) + 221
6   com.apple.security            	0x00007fff87b576c1 Security::DatabaseManager::dbOpen(Security::DatabaseSession&, Security::DbName const&, unsigned int, Security::AccessCredentials const*, void const*) + 77
7   com.apple.security            	0x00007fff87b575a3 Security::DatabaseSession::DbOpen(char const*, cssm_net_address const*, unsigned int, Security::AccessCredentials const*, void const*, long&) + 285
8   com.apple.security            	0x00007fff87b6b294 cssm_DbOpen(long, char const*, cssm_net_address const*, unsigned int, cssm_access_credentials const*, void const*, long*) + 108
9   com.apple.security            	0x00007fff87b6ae3a CSSM_DL_DbOpen + 106
10  ocspd                         	0x0000000100006ad9 0x100000000 + 27353
11  ocspd                         	0x0000000100006cab 0x100000000 + 27819
12  ocspd                         	0x0000000100001f68 0x100000000 + 8040
13  ocspd                         	0x00000001000176ed 0x100000000 + 95981
14  ocspd                         	0x000000010001787b 0x100000000 + 96379
15  ocspd                         	0x0000000100017e4f 0x100000000 + 97871
16  ocspd                         	0x0000000100004613 0x100000000 + 17939
17  ocspd                         	0x0000000100001d48 0x100000000 + 7496
 
Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x000000010008e000  rbx: 0x000000010008e000  rcx: 0x00007fff88f0d47a  rdx: 0x000000000000d210
  rdi: 0x0000000100115478  rsi: 0x000000000000d210  rbp: 0x00007fff5fbfe850  rsp: 0x00007fff5fbfe850
   r8: 0x0000000000000003   r9: 0x0000000000000000  r10: 0x00007fff88f0597a  r11: 0x0000000000000206
  r12: 0x0000000100115478  r13: 0x00007fff5fbfecd0  r14: 0x00007fff5fbfecd0  r15: 0x00007fff5fbfed20
  rip: 0x00007fff87b59d0b  rfl: 0x0000000000010297  cr2: 0x000000010009b210
 
Binary Images:
       0x100000000 -        0x10003cfef +ocspd ??? (???)  /usr/sbin/ocspd
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???)  /usr/lib/dyld
    0x7fff80853000 -     0x7fff80859ff7  com.apple.DiskArbitration 2.3 (2.3)  /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff80baa000 -     0x7fff80c27fef  libstdc++.6.dylib 7.9.0 (compatibility 7.0.0)  /usr/lib/libstdc++.6.dylib
    0x7fff811af000 -     0x7fff81268fff  libsqlite3.dylib 9.6.0 (compatibility 9.0.0)  /usr/lib/libsqlite3.dylib
    0x7fff812e9000 -     0x7fff8161dfef  com.apple.CoreServices.CarbonCore 861.39 (861.39)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff82092000 -     0x7fff82122fff  com.apple.SearchKit 1.3.0 (1.3.0)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff8229d000 -     0x7fff822c8ff7  libxslt.1.dylib 3.24.0 (compatibility 3.0.0)  /usr/lib/libxslt.1.dylib
    0x7fff82695000 -     0x7fff826d2fff  com.apple.LDAPFramework 2.0 (120.1)  /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
    0x7fff82954000 -     0x7fff82966fe7  libsasl2.2.dylib 3.15.0 (compatibility 3.0.0)  /usr/lib/libsasl2.2.dylib
    0x7fff82ae1000 -     0x7fff82b81fff  com.apple.LaunchServices 362.3 (362.3)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff82c8f000 -     0x7fff82c9dff7  libkxld.dylib ??? (???)  /usr/lib/system/libkxld.dylib
    0x7fff82d0e000 -     0x7fff82dc4ff7  libobjc.A.dylib 227.0.0 (compatibility 1.0.0)  /usr/lib/libobjc.A.dylib
    0x7fff82dc5000 -     0x7fff82de6fff  libresolv.9.dylib 41.0.0 (compatibility 1.0.0)  /usr/lib/libresolv.9.dylib
    0x7fff8349e000 -     0x7fff834adfff  com.apple.NetFS 3.2.2 (3.2.2)  /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff83a2b000 -     0x7fff83a41fef  libbsm.0.dylib ??? (???)  /usr/lib/libbsm.0.dylib
    0x7fff83a42000 -     0x7fff83bb9fe7  com.apple.CoreFoundation 6.6.5 (550.43)  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff83bbe000 -     0x7fff83c92fe7  com.apple.CFNetwork 454.12.4 (454.12.4)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff83c93000 -     0x7fff83cbbfff  com.apple.DictionaryServices 1.1.2 (1.1.2)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff84905000 -     0x7fff849c2fff  com.apple.CoreServices.OSServices 359.2 (359.2)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff849d8000 -     0x7fff84a38fe7  com.apple.framework.IOKit 2.0 (???)  /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff850ef000 -     0x7fff8513bfff  libauto.dylib ??? (???)  /usr/lib/libauto.dylib
    0x7fff851a2000 -     0x7fff851ddfff  com.apple.AE 496.5 (496.5)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff8525f000 -     0x7fff85270ff7  libz.1.dylib 1.2.3 (compatibility 1.0.0)  /usr/lib/libz.1.dylib
    0x7fff85b42000 -     0x7fff85b43ff7  com.apple.TrustEvaluationAgent 1.1 (1)  /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
    0x7fff87921000 -     0x7fff8796bff7  com.apple.Metadata 10.6.3 (507.15)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff87b2b000 -     0x7fff87db4ff7  com.apple.security 6.1.2 (55002)  /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff88b46000 -     0x7fff88b4aff7  libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0)  /usr/lib/system/libmathCommon.A.dylib
    0x7fff88f02000 -     0x7fff890c3fef  libSystem.B.dylib 125.2.11 (compatibility 1.0.0)  /usr/lib/libSystem.B.dylib
    0x7fff8921b000 -     0x7fff8933afe7  libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8)  /usr/lib/libcrypto.0.9.8.dylib
    0x7fff8933b000 -     0x7fff89378ff7  libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8)  /usr/lib/libssl.0.9.8.dylib
    0x7fff89494000 -     0x7fff894d5fff  com.apple.SystemConfiguration 1.10.8 (1.10.2)  /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff8953e000 -     0x7fff896fcfff  libicucore.A.dylib 40.0.0 (compatibility 1.0.0)  /usr/lib/libicucore.A.dylib
    0x7fff89b66000 -     0x7fff89b66ff7  com.apple.CoreServices 44 (44)  /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff8a545000 -     0x7fff8a65cfef  libxml2.2.dylib 10.3.0 (compatibility 10.0.0)  /usr/lib/libxml2.2.dylib
    0x7fffffe00000 -     0x7fffffe01fff  libSystem.B.dylib ??? (???)  /usr/lib/libSystem.B.dylib

Some of the information you get when googling for the error message is misleading, suggesting ocspd is somehow tied to nVidia graphics drivers. It is in fact the system daemon that handles verification and revocation of SSL certificates using the Online Certificate Status Protocol (OCSP), a vital component of the Internet’s security architecture, as evidenced by the recent Diginotar fiasco. Thus presumably it is used throughout Internet apps like Mail.app or Chrome, and the regular crashes (at 3 minute intervals or so) would also freeze any apps that make use of cryptography.

The solution was to delete the the temporary certificate revocation list (CRL) databases ocspd maintains:

sudo rm -rf /private/var/db/crls/*
sudo rm -rf /private/var/db/crls/.fl*

A corrupted database is probably responsible for the repeated crashes I observed, and clearing those solved my problem. You may want to make backups of those files instead of just deleting them.

As usual, I disclaim responsibility for any harm this procedure may do to your computer, or induce it to eat your dog, who ate your homework.

So much for the theory that the Mac “just works”. To paraphrase Churchill, it is the worst operating system, with the exception of all others…

On a popular forum for users of Micro Four Thirds cameras (which struggle beyond ISO 800), a poster recently questioned the rationale for high ISO performance, stating 99% of users will never shoot beyond ISO 800. I quickly looked at my statistics in Lightroom, and found over 54% of the photos I took in 2011 (to date) are at higher than ISO 800.

That begs the question: who is more representative, him or me? Flickr.com publishes statistics on popular camera models, but apparently not on other interesting EXIF metadata. I whipped up a quick and dirty Python script to sample recently uploaded photos from Flickr and collect the ISO speed from their EXIF tags, when available.

Of 3020 photos I sampled, fully 399 were shot at ISO higher than 800, or 13% (the 95% confidence interval is 12% to 14.4%). Thus significantly less than my proportion, but far higher than 1%.

Python on the Mac and SQLite to the rescue: this simple script  lraspect.zip will reset them. If you use a non-default name for your Lightroom catalog, you will need to edit it. To run it, quit Lightroom and run the script. It will back up your catalog for you just in case.

Needless to say, I cannot be held liable if this script corrupts your catalog or eats your dog (who ate your homework), use at your own risk.

#!/usr/bin/python
import sys, os, sqlite3
 
# edit this to point to your LR3 catalog if you do not use the default location
lrcat = os.path.expanduser('~/Pictures/Lightroom/Lightroom 3 Catalog.lrcat')
 
os.system('cp -i "%s" "%s.bak"' % (lrcat, lrcat))
db = sqlite3.connect(lrcat)
c = db.cursor()
c.execute("""select value from Adobe_variablesTable
where name='Adobe_customCropAspects'""")
crops = c.fetchone()[0]
print 'aspect ratios:', crops
c.execute("""update Adobe_variablesTable
set value='{}'
where name='Adobe_customCropAspects'""")
db.commit()
print 'Custom crop aspect ratios reset successfully'