Archive for August 28, 2017

Monday, August 28, 2017

Carbon Copy Cloner 5

Mike Bombich:

I introduced CCC to the world over 15 years ago. With the debut of CCC 5 within reach, I thought it would be neat to see how CCC has changed over the years.

Carbon Copy Cloner 5 costs $40, with upgrades discounted 50%.

What’s new (tweet):

Create a bootable clone of your hard drive, but also keep copies of your recently deleted and changed files — just in case. SafetyNet is smarter than ever: if you run out of space during a backup, CCC can free up space automatically and resume your backup.

This should fix my number one annoyance with previous versions, which was that a backup would run for a long time and eventually fail because the SafetyNet made it run out of space. You had to guess up-front how much space you’d need, and CCC would prune the SafetyNet before starting the backup. Guess too low, and the backup would fail in the middle of the night. In the morning, you’d have to free up some space and try again. Guess too high, and you’d waste time pruning files that didn’t need to be pruned, and also lose access to those versions, which you actually did have room to keep. It sounds like this new “Auto adjust” option will do the right thing automatically, pruning just enough old versions so that the backup will complete. And it should provide certainty that when you start a backup it will definitely succeed—important if you need to depart on a trip or update the OS.

Excluding a folder or two from a backup task has always been trivial with CCC, and now it’s even easier to precisely define what should and should not be backed up. You can also now visualize the effects of custom filter rules, and now CCC will report how much data is going to be backed up.

[…]

The setup procedure for backing up to a remote Macintosh has been greatly simplified. SafetyNet pruning is now available for remote Mac destinations, and CCC can now show you the content of a remote Mac source.

[…]

Have you ever worried that your backup might fail when you need it? CCC has you covered. CCC can run a special monthly or weekly corruption check to identify damaged files in your backup – and automatically replace them.

The checksumming feature was there before, but you had to manually turn it on and off if you didn’t want to verify the backup every time. Now, CCC can manage the verification schedule for you.

There are lots of other new “task” features like this, which are designed around the idea that CCC is managing and scheduling your backups. This is a nice idea, but it doesn’t really work for me in practice. I need to keep track of backups made by a variety of apps (Arq, CCC, SuperDuper, and Time Machine) on multiple Macs. Most of the backup drives are not attached, so CCC cannot initiate a backup on its own, anyway. And for each backup, I need to keep track of where it is, what it contains (e.g. “last 10.11.x clone” rather than just the date of the backup), when it was started, when the media and contents were last verified, problems encountered, and rotation information. So I end up managing all this with a text file and OmniFocus, and I have a CCC task for each type of backup rather than for each backup disk.

The bundled ccc command line application allows pros to incorporate CCC backup tasks into larger and more complex workflows. Pre- and postflight scripts bring that same level of customization into existing CCC task workflows. Task and individual task filters can be imported and exported, allowing you to manage exclusion lists across tasks and to duplicate tasks to other Macs.

All backup products should provide this last feature, in a way that works across different home folder paths.

See also: Everything you need to know about Carbon Copy Cloner and APFS.

Previously: Pondering the Conversion From HFS+ to APFS.

Update (2017-08-30): Bombich informs me that CCC checksums the resource fork and extended attributes in addition to the data fork.

Dylan and Newton History

There’s lots of interesting stuff in this Hacker News thread.

Mikel Evins:

Larry asked me and a couple of other people to see what we could do with Dylan. We took that ball and ran with it--maybe too far. Like maybe Larry wanted us to run it down to the end zone and instead we ran it across the border and into Patagonia somewhere. We, the five of us or so, wrote a whole OS in Dylan, essentially competing with the 60 or so people working on Scully’s mandated C++ OS.

[…]

From a business point of view, though, it was silly. Obviously Apple was never going to ship 2 Newton OSes. Equally obviously, it wasn’t going to choose to develop our weirdo Lisp OS instead of Capps’ C++ OS that was developed by almost the whole Newton team in response to an order from on high.

In those days (and perhaps nowadays, too, for all I know), Apple didn’t really invent products by having some visionary leader invent a goal and directing engineers to fulfill the vision. Instead, it tolerated skunkworks projects hither and yon, and the visionary leader(s) cherry-picked the ones they thought most promising. Newton itself had been created as a means to keep Steve Sakoman from leaving Apple, rather than as a product vision. So you can perhaps forgive us for imagining that if we just made our project good enough, Apple would find a place for it.

[…]

My meeting with Steve was memorable. He carved out a fairly large chunk of time to give me the hard sell about how I should give up on Apple and come change the world with NeXT. I hadn’t met him before. His famous charisma was real enough. It was a little odd, though, too. He tried a bunch of different angles to convince me, and he could tell really quickly when it wasn’t working. In fact, nothing worked in that meeting. I was skeptical that NeXT would survive, and all of Steve’s pitches were pegging my BS meters. It was kind of cool to see him start a pitch, recognize that it wasn’t working, and instantly flip to a different one, as if changing channels on a TV. Eventually he gave up and ended the meeting.

Oliver Steele:

The original Apple [Dylan] implementation compiled to native ARM code. The runtime was intended to be competitive with C, but by the time we approached that target, large parts of the toolbox had already been written in C, and Walter Smith had created NewtonScript as a scripting language that worked as an alternative for non-performance-critical code. At that point the Cambridge team re-targetted the implementation to build Macintosh applications, but that wasn’t a sufficiently compelling (to Apple management) use, and we had lost our executive sponsor when the director of the Apple Cambridge lab was promoted to a position in Cupertino.

Landon Dyer:

The decision was made to ship “junior” (the handheld unit that became the MessagePad 100) using C++, while work was still being done in Dylan on “senior”, the tablet unit. Eventually the Junior project grew in importance (“Holy crap, we have to ship this in a year”) and it was all hands on deck to get it out the door. For a while there were a bunch of Dylan programmers roaming the hallways, they were clutching copies of the C++ Annotated Reference Manual and looking really unhappy. The writing was on the wall, Senior got canceled a few months later and a bunch of the Dylan folks quit.

Just Following Orders

Robert C. Martin:

The year is 2006. Executives at VW know that their diesel engine can not meet American emissions standards. So they ask the enginers for a solution that does not require a redesign of the engine. […] We may never know all the details; but it’s clear that the executives asked the engineers to find a way to defeat the emission tests.

[…]

Engineers take note: Your employer can’t cover for you. Doing your job does not mean that you just follow orders. The courts are going to hold you to a high ethical standard, even if your employer does not.

Update (2017-08-29): See also: Hacker News.