Something is in the air in 2016: this weekend marked the second time this month that a product I’ve come to rely on has made dramatic changes to their data handling practices. This time it’s Day One, who have announced a major version update that will remove Dropbox and iCloud sync in favor of their home-brew Day One Sync backend. Before that it was YNAB, who have migrated from a local-data only solution to an entirely cloud-based system.

I’m not interested in putting either my personal financial data, or my personal journal, on unproven servers with uncertain access policies, and without two-factor authentication. Gabe and Jeff discuss this more completely on Episode 57 of Nerds on Draft — my thoughts very closely mirror Gabe’s.

I’ve entrusted this data with Dropbox, reluctantly, because the value of sync has been greater than my need for absolute privacy. While Dropbox has had breaches, the addition of two-factor authentication has provided me with additional peace of mind. Their brand also relies entirely on their reputation for security and reliability, and they have a reasonable track record. Neither YNAB nor Day One have earned my trust, and I don’t intend to follow them as they migrate.

I sent the following note off to Day One support just now:

Hello,

This doesn’t require any response, but I wanted to submit a response to your announcement of Day One 2. I’m a very, very happy customer of Day One, and I have been since shortly after your launch. I intend to buy Day One 2 when it comes out, because I want to continue to support you, but I have no intention of using v2 until you offer alternative sync methods.

I’m not interested in storing my private data on your servers. I don’t know exactly what is meant by ‘private-key encryption’, but I’m certainly not convinced it will address my concern. My journal is private, and I have no sense of the security of your backend.

I hope that you’ll reconsider and add either iCloud or Dropbox back into the application.

Thanks, Jeff

I seriously hope both services reconsider these decisions.

Update February 2, 2016:

Sven at Simplicity is Bliss has a great post on this as well. I particularly agree with this comment:

There is no 100% security and hopefully everyone knows this. Both Dropbox and iCloud have been compromised before and will be in the future. At the same time Apple and Dropbox have huge engineering and security teams. It is unlikely that Bloom, the makers of Day One, can defend and protect Day One Sync in a similar way in a worst case scenario.

I think that’s the crux of my feelings - I’d rather trust a larger corporation to have the proper security protocols in place. That doesn’t mean they’ll always do the right thing, just that they have greater resources to deploy to keep my data safe.

I’ve been thinking about buying a camera.

I had pretty much convinced myself that the Olympus OM-D E-M10 Mk II was the right camera to buy, until I stumbled on a $670 price for a new OM-D E-M1 body. Now I’m conflicted. The E-M10 Mk II is a brand-new design, while the E-M1 was announced in September of 2013, though it’s still actively receiving firmware updates (here’s a Youtube video explaining the new features). Also, a Mk II version of the E-M1 is expected imminently (though it will be well outside of my price range).

In the < $1000 price range, the OM-D E-M10 Mk II is regarded as the top pick by The Wirecutter, and is the ‘also consider’ choice of DPReview in their 2015 Roundup of $500-800 cameras¹. The Wirecutter has picked the E-M1 as its runner-up for overall Best Mirrorless Camera, after the $1,700 (with kit lens) Fujifilm X-T1.

I’ve found it hard to find a direct comparison of the E-M10 Mk II against E-M1, since they’re usually regarded as existing at wildly different price points. This is my attempt to compare the two, but it’s actually tough to find modern data on the E-M1 as so much has been improved via firmware updates. Unless otherwise noted, this data has come from the DPReview reviews of the E-M10 Mk II and the E-M1.

I’m leaning heavily toward the E-M1, though I’m a little worried that the heavier and larger body may not be ideal - but the Phase-Detect Continuous Auto-Focus would be very welcome with our poorly-behaved dogs.

I haven’t settled on anything yet, but I’ll post when I do. These are some other links I’ve found useful:

• Imaging Resource Olympus E-M1 Review
• This DPReview discussion thread compares the E-M1 against the E-M10 and the Mk II variants of the E-M10 and E-M5.

It’s not often I get to write about what I do at work, but Bose put together a big event at CES this year. This video summaries the experience:

I was fortunate enough to have the opportunity to contribute to all of the technologies we exhibited, including the new NEAR technology:

In a demonstration of NEAR at CES, Bose showed how it could place navigation prompts where they made the most sense, and keep phone calls focused on the driver.

Of course, all of the projects were team efforts — I’m thrilled to have contributed to all of them, and to be able to share some of what I’ve been working on over the last five years.

Update May 6, 2016: Here’s a link to a Motor Trend article about the CES presentation, including NEAR.

For the last few weeks I’ve been receiving periodic emails from Crashplan telling me my iMac hasn’t been able to reach their servers. When I received the emails, I would check and find that the menu bar application was no longer running. I saw this two years ago when I first setup the iMac, but things had been running smoothly for a long time.

Crashplan has a great support article detailing this issue. Essentially, the Java engine can run out of memory while scanning files, resulting in a crash. You can confirm the behavior by checking the log files¹ for the string “OutOfMemoryError”.

They recommend allocating 1 GB of or memory for every 1 TB of files, with a default setting of 1 GB. My iMac has a 3 TB internal drive, and a 2 TB included in the backup, so the default 1 GB allocation is definitely insufficient. The support article details the process of changing the memory allocation, which involves entering a command in the Crashplan console:

java mx 5120, restart

I set the memory to 5 GB to match the recommendation. While I was looking into the issue, I stumbled on this post, which describes where the memory allocation value is stored. It’s in a plist file located at:

/library/launchdaemons/com.crashplan.engine.plist

There’s a string value in the plist that will have the value Xmx1024m by default. This is the memory allocation, and after changing the value through the Crashplan console, I checked the plist to confirm the change had taken.

I expect I won’t see the issue again, until the app reverts to the default setting again.