Ironick

Carbonite: I’ll check back in a couple of years

I finally decided to systematically back up my home computer – the one I have for family/personal use. I’ve been using one sort of PC or another since the Compaq Portable in the mid-1980s. In all that time, I’ve only done sporadic backups of various directories when paranoia kicked in. Despite this utter lack of care, I’ve pretty much never lost an important file due to a failure or accident. I have had two hard drives fail on me, but in both cases a data recovery service was able to recover all the files.

But I figure that after 20 years, I may be pushing my luck a wee bit too far. So I decided to check out Carbonite, based on David Pogue’s review of the leading web (oops, now cloud) based backup services: Carbonite and Mozy.

I’m currently in the middle of a 15-day free trial of Carbonite and I’m loving it: simple to install, completely unobtrusive, continuously operating. There’s only one problem, but it’s a show-stopper for me: Carbonite will not backup external drives! In my case that means it won’t back up the USB drive that I use to store all my photographs and videos and music.

I was (and I still am) incredulous. I didn’t recall a single review mentioning this crippling feature. I was so incredulous that I searched the web to confirm it. My first confirmation was from this 2007 blog post comment (Carbonite: FAIL, Mozy: ON NOTICE) by the (then?) CEO of Carbonite:

David Friend wrote:

James: Hi, I’m the CEO of Carbonite and I noticed your comments about Carbonite on your blog. Backing up external hard drives is a feature that is available in our PLUS product which will be available shortly. Carbonite didn’t fail to back up your hard drive – we state clearly on the web site that the BASIC version does not back up external hard drives. Doing so would alter the economics of our business model and would require that we charge everyone a much higher price, or abandon our UNLIMITED backup policy which most of our customers really like.

Regards,
Dave Friend, CEO
Carbonite, Inc.
http://www.carbonite.com Carbonite Online Backup

Posted on 23-Oct-07 at 9:03 am | Permalink

When I read this I thought to myself, “Great! Let’s check out Carbonite Plus to see how much it costs. It’s been almost two years since this post, so I’m sure it’s available now.” So I go to the Carbonite site and search for “carbonite plus”. Unfortunately, this is what I found:

1074 : [General] External, Network, and USB Drives

Article Viewed 3

Reviewed 6/11/2009

The current version of Carbonite backs up only the files that reside on permanent hard drives on your PC.

Check back soon for a Carbonite service plan that will allow you to back up your external drives.

So I guess I’ll check back around mid-2011. In the meantime, I’m off to check out Mozy…

Related articles by Zemanta

• Online Backup Company Carbonite Loses Customers' Data, Blames And Sues Suppliers (Updated) (techcrunch.com)

Zemanta

I'm trying our Zemanta, an add on to Windows Live Writer. Zemanta is supposedly a semantic web application that automagically enriches your blog posts with suggested links, tags, related articles, pictures, etc.

For example, if I type the phrase mars lander, Zemanta will automatically do wonderful things. Well it's supposed to do amazing things, but I don't see anything happening. Would the concept of Gartner make a difference. Or the happenings in Iran. Nada. The movie, The Watchmen seems pretty cool.

It’s working now as you can see. The problem was that I was running an old version of Windows Live Writer. Now let’s see if it can handle more obscure terms like meiosis, or stigmergy, or tsallis entropy. Wow, it did all of them except for stigmergy, even though stigmergy is in Wikipedia.

Hmmn… It looks as if pictures is not working. I’d love to see a picture of Dolphins, or some Transformers, or maybe even Spider-Man.

I think I’ll try it for a while…

Related articles by Zemanta

• Zemanta is a good social media tool (zemanta.com)

Two Timely T-Shirts

Is Google Chrome Taking Off?

I got a lot of hits on my post My 2¢ on Google Wave.... When I looked at the browser share stats (which I rarely do), I was surprised to find Google Chrome had more than a 12% share for the day:

Contrast this with Chrome's under 5% share since the beginning of the year:

Does this mean Chrome is taking off with the technorati? Or was the sample skewed by the fact that my popular post was about Google Wave?

I guess we'll have to wait and see...

Epiphany: Replace HATEOAS With "Hypermedia Describes Protocols"

As a few of my friends know, I live for epiphanies. I love to connect concepts. So I'm really happy to be having one now (it's been a while as regular readers of my blog -- if any remain -- can tell).

For a LONG time, I've been talking about how all interfaces can be defined in terms of IFaPs (Identifiers, Formats, and Protocols). My canonical example of an interface composed of IFaPs is of course the Web: URL (I), HTML (F), and HTTP (P). All three intersect in a particular instance of HTML, say my blog's home page. The HTML for my blog's home page is filled with URLs, HTML tags, and even HTTP "verbs" (though these are quite rare, mostly in an HTML form or embedded JavaScript).

Then along came REST and with it the concept of HATEOAS: Hypermedia As The Engine of Application State. And everyone, myself included, spent a lot of time trying to grok it and explain it to others. We're still trying. One way I try to explain it is by highlighting that HATEOAS requires that each server response must contain not only the requested data -- but also control information (in the forms of specially tagged URLs) describing the next set of permitted interactions with the server. It is this additional control information (at a bare minimum just some links to more data) that turns mere media into hypermedia.

Now along comes Jim Webber with a much better (dare I say brilliant) way of explaining HATEOAS and hypermedia: "Hypermedia Describes Protocols!" (See slide 26.) At first this might seem counterintuitive, since I said that HTTP is the Protocol and HTML is the Format in the WWW. But URLs, HTML, and HTTP are just generic description languages for describing domain-specific identifiers, formats, and protocols. Thus, think of a web of specific HTML pages as a domain-specific protocol. Jim Webber uses the example of ordering a Starbuck's coffee. (What's important is that each hypermedia DSL is composed using the generic languages of URL, HTML, and HTTP.)

This notion of bringing together identifiers, formats and verbs to describe a protocol is not new. One of the best descriptions of this was in the WS-BPEL 1.1 spec:

In thinking about the data handling aspects of business protocols it is instructive to consider the analogy with network communication protocols. Network protocols define the shape and content of the protocol envelopes that flow on the wire, and the protocol behavior they describe is driven solely by the data in these envelopes. In other words, there is a clear physical separation between protocol-relevant data and "payload" data. The separation is far less clear cut in business protocols because the protocol-relevant data tends to be embedded in other application data.

So if WS-BPEL was already thinking about mixing protocol data with "payload" data, what's so new about HATEOAS? The fundamental difference is that WS-BPEL is based on the concept of providing an entire static protocol description up front once and for all -- and providing it out of band. But HATEOAS is based on the notion of progressive description (don't bother Googling the term, I coined it; and not to be confused with progressive disclosure). More and more of the description of the protocol is provided to the client (in band in the protocol itself) as the client executes its part of the protocol. I guess another good term might be JIT Protocol Description (Just In Time). Another good term might be "self-describing protocol". So now when explaining HATEOAS, instead of saying "each server response must contain control information" (huh?), I can say "each server response progressively self-describes the current protocol."

Now there are pros and cons to static/complete vs dynamic/progressive protocol descriptions. How can I program a client to execute its part of a protocol if I don't have a full description of it up front? But if I encode the complete static description of the protocol into my client up front, how can I change the protocol dynamically?

Love to hear others' thoughts. I'm going to think about this some more. That's why I love epiphanies -- they make you think about things in new ways.

My 2¢ on Google Wave: WWW is a Unidirectional Web of Published Documents -- Wave is a bidirectional Web of Instant Messages

I viewed the Google Wave demo over the past several days:

I'm already convinced that Wave represents a Web paradigm shift on par with Ajax/Web 2.0. Just as Google Maps was the killer app that opened the Ajax floodgates (even though the component technologies/standards were already in place) Wave will be the killer app that opens the HTML5/XMPP floodgates. The Wave protocol is arguably the first advance worthy of the title Web 3.0 (though I'm not encouraging anyone to use the term).

My only MAJOR concern is the Wave protocol's impact on the core standards of the Web. Clearly, Wave embraces HTML5. What is not clear is how Wave uses URLs and HTTP? A key question for me is "Can I create a bookmark to a wave or a wavelet?" I'm less concerned with HTTP, though maximizing "backward" compatibility between HTTP actions and XMPP actions would be good evolutionary design. The reason I'm less concerned about HTTP is that URLs are the foundation of the "shared information space" that is the Web. SMTP coexists with HTTP and both use HTML and URLs in the content they transfer. Even Roy Fielding is eager to replace HTTP, e.g., with Waka. It raises the interesting question of whether the Wave protocol is roughly what Roy was proposing with Waka.

Here are a couple of my major take aways:

1. The Wave client is a major proof of concept (or pilot project) for HTML5. If the wave client becomes a killer app, it will have a major (negative) impact on other RIA architectures.
2. The Wave protocol is a major proof of concept for the extended use of XMPP. It transforms it from a IM/Presence protocol to a general purpose bidirectional streaming protocol.
3. Whether or not the Wave client succeeds, Wave is undoubtedly going to have a major impact on how application designers approach web applications. The analogy would be that even if Google Maps had "failed" to become the dominant map site/service, it still had major impact on web app design.

Last but not least -- an observation from left field:

Wave is far closer in approach and capability to Ted Nelson's Xanadu vision than it is to Tim Berners-Lee WWW vision. Both had visions of a READ/WRITE web of linked information. One of the major design decisions TBL made was to drop the then-canonical-requirement of bidirectional links because of the scalability/complexity issue of the required "link servers" (or "link intermediaries"). Wave is fundamentally based on Wave servers. The Google tech talk on the design of the wave protocol explicitly mentions that Google rejected the approach of enabling P2P Wave interactions.

One major accidental design "decision" was when the NCSA Mosaic team decided to only implement rendering in their browser -- not editing. TBL and many others have observed that the last decade or so has been a series of attempts to return to the original vision of a read/write web, eg wikis, blogs, micro-blogging. Wave seems to me to be one of the best approaches ever put forward to redesigning the WWW to be read/write (real time read/write in fact).