Installation Issue with Carbon Copy Cloner 3.1

For those of you eying Time Machine but still not ready to fully commit to OS X Leopard — sure, 10.5.2 is a big improvement, but I'm still waiting for that third time charm — I recommend Carbon Copy Cloner, which has just been updated to version 3.1.

CCC is free software. It can make scheduled backups to an external drive behind the scenes while you work. Your backup can even be bootable. But there is a minor installation hurdle for users of previous versions.

Despite being only a point release, Carbon Copy Cloner 3.1 sports some big improvements in capability over 3.0, most notably a much finer set of controls for both backup item lists and scheduling. I have also noticed that it is significantly faster, completing my backups in as little as two-thirds the time (even when copying the same amount of data).

In classic Mac fashion, upgrading CCC is theoretically as easy as dragging the application from the installer window to your Applications folder. But when I attempted to do just that, my Mac had this to say:


The above-referenced 'ccc_helper' is the background daemon that handles scheduled tasks, which I use liberally (one for duping my basic OS X installation once a month, and another twice a week for all my data). Alarmingly, this failed copy operation rendered my previous copy of CCC non-functional, and there was no warning at all about it in the accompanying ReadMe.

Luckily it wasn't fatal. Simply dragging the original to the trash first (an old Mac trick) enabled the subsequent copy to occur. And upon launch, the new version instantly detected the obsolete backup schedules and replaced those, too. The developer seems to have anticipated this issue and covered all the bases except for actual installation — which one might easily think of as home plate. This may seem odd, but it's human for a coder to take the download package for granted in testing, much as you might dress up perfectly for a night out and then forget your keys. It's the simple stuff that gets you. Unfortunately, the last step for the coder is the first step for the user, so this kind of oversight can exact a heavy toll in frustration if you don't immediately discover the workaround.

Once you've got it installed, however, CCC performs with the reliability, transparency, and simplicity I have come to expect from Mike Bombich.

• UPDATE: The headline was changed from 'Installation Bug' to 'Installation Issue' in response to mike's comment below.

Why No Background Scheduling in the iPhone SDK?

What is the real reason? Craig Hockenberry claims, in an otherwise very insightful article about why third-party background apps are a Very Bad Thing for your battery life, that the natural solution — letting the iPhone OS schedule access to the network and then giving apps the greenlight to connect in a single cooperative burst instead of activating the antenna piecemeal — was a little beyond Apple's capability for the beta Software Developer's Kit. He writes

Do I expect such a sophisticated system to be available in a beta of version 1.0? Hell no. And neither should you.

Maybe it's just me, but this system really does not sound all that sophisticated, not compared to the enormous piece of engineering that is already the iPhone SDK. In fact, it's downright simple. A scheduler/notifier that maintains a queue with a few new API calls — what's so damn difficult?

Not that I am advocating everybody whine some more about this issue. But nonsense is nonsense. As I see it, this is not rocket science.

It's far more likely that the reason for omitting this capability for now is that Apple doesn't want iPhone developers to use it as a crutch, or as a backdoor into executing non-network-related background tasks. They want you to learn to do without. When the consensus becomes that background processing is not nearly as necessary as everyone believed — then we'll have our network scheduler.

The Embarrassing State of Web Authoring

If the read path of a document on my computer is

     file://root/manwhoknows/posts/embarrassing-web-authoring.txt

then it's very easy to deduce the write path for this same document. Because the two paths are identical.

But what if they weren't? What if every document had two separate paths, one for reading and one for writing, either of which could be arbitrarily chosen? Nobody would be able to deduce the write path of a document from its read path! Updating anything on your computer would become a complex endeavour in which each application would make its own decisions about how to structure the write paths of its documents, and those write paths would be undiscoverable outside of that application. It would be like iTunes went insane and stole all write functionality away from your operating system. If this sounds to you like a hellish hypothetical, consider that it isn't hypothetical at all. You are already living in this world, online.

The read path for a web document might be

     http://manwhoknows.blogspot.com/embarrassing-web-authoring.html

From this, what we can deduce about the write path for this document is nothing at all. We can assume that the top and sub domains would be the same, but we would not be right all the time. Not without host-specific contextual knowledge. There is just no standard way for your computer to figure out how to update what you're reading online. At this point you might be tempted to say 'FTP', but there is not even a standard way to construct the proper FTP upload path for a given URL. The only correct single answer is, it depends. (And figure it out for yourself, or else no update for you!)

What I'm trying to tell you is that if you have ever found authoring files on the web to be an unholy mess, most of which no one has been able to automate effectively — this is why.

All that needs be done is to define a standard discoverable write path for all web documents (probably via password-protected FTP). Once we have that, we will be able to build truly instantaneous intraspecies publishing into our technology at a basic system level. Until we have it, web authoring will continue to be a quasi-penetrable codex for communicating with a planet of charmingly ineffective bureaucrats.

Let's not be the laughing stock of the Milky Way — not again.