Mind Mash

Let’s get one thing straight. If I open the lid of my MacBook Pro and type my password into the prompt then I DO NOT WANT MY MAC TO IMMEDIATELY GO BACK TO SLEEP. Dammit.

Yesterday I wrote about my problems with Mozy. This morning I had a response from their tech support, and a comment to my blog post, both of which helped to clarify the issues:

From tech support:

• Reinstall the software to correct the corrupted configuration database problem – not the subtlest of solutions but I will give it a bash.
• When Mozy can’t find the files it doesn’t actually delete them from the backup, it just says it does. When it tries to back them up again, it should find them still in the Mozy server and will compare them to the copies on my hard drive. If they are the same, then the one on my hard drive will not be uploaded again. I understand the solution but in this case they should not say they are deleting the files, but instead marking them as not found.

Jimmy pointed out in the comments that a lot of the problem is my limited upload speed, which is not Mozy’s problem, but concludes that their service is not ready for prime time yet. Two fair points.

I would like to have a disaster backup, so that if the whole house burns down, and all the computers are burnt to cinders, I still have my photos, my music collection, my PhD dissertation and years of email.

A week ago I decided to try Mozy. The price was sweet, and the service backs up your files over the network to the Mozy servers in Utah (at least, that is where their offices are).

Problem number 1: I have 350 Gb of files I want to backup and the maximum I can squeeze through my DSL’s limited upstream connection is 2Gb/day. That’s 170 days – half a year – just to do the initial backup, during which time my internet connection is very slow. Ah, those memories of my first modem, a 300 baud dial-up. BAD MEMORIES.

Problem number 2: Mozy has a configuration utility you use to tell it which files to back up, but whenever I try to change that configuration, the utility crashes, complaining about a corrupted configuration database.

Problem number 3: I started my Mac this morning with the external hard drive turned off. Mozy backup started in the background, couldn’t fine the 250 Gb or so of files I had asked it to back up from that drive, and so concluded I had deleted them, and deleted them all from the backup on its servers. A week of uploading wasted.

I have emailed Mozy’s tech support. No reply yet. I am thinking I need to change tack and ask someone a few hundred miles away to look after a hard drive with a complete backup of my system on it.

Test photo- yum!

The Chrome comic pointed out that the browser has gone beyond the web and is now often used for running applications, and therefore that we should adapt the browser to go beyond the web metaphor. The same considerations apply to the OS, coming from the other direction. One example here is files. On the web, references to resources can include some extra state information as part of the URL, e.g. http://www.example.com/mypage&tab=12&encoding=3&secret=banana. You can copy, email, bookmark this URL and use it to return at a later time to the resource in the desired state. You cannot pass extra state as part of a filename. The best you can do is have the application which opens the files store this working state to the file along with the data.

With the Google Chrome announcement over the weekend, it is really clear that Google totally want to own the desktop. The underlying OS will become less and less relevant, and more and more applications will run inside the browser.

I have suspected as much for a while. Here is my comment from a slashdot article 3 years ago:

> Is there a GoogleOS in our future?
Effectively, yes. The internet and associated protocols, data structures etc are becoming more and more important, and the underlying OS less and less important – you can do a lot now (email, edit notes, images etc, dispatch compute jobs etc) with a web browser without caring about the underlying OS.

Web browsers currently are limiting. Many user interface aspects of web browsers suck, therefore so do any applications which rely on the browser for user interface.

But gradually standards are emerging which provide software infrastructure for web applications, e.g. the Google Maps thing. I guess Java is too slow to be the infrastructure, and the standard Java interface libraries are also a but weak for GUIs. Google are producing some of this infrastructure, which might end up as a kind of middleware OS. Some of it might end up in the browser itself; there was a rumor a while ago that Google were writing their own browser – I think that is likely.

For a laugh, I decided to create a calendar event in Gmail for a very old event. In fact, I was looking for a date in the region of 2 BC.

When adding an event to a Gmail message, you enter the year/month/date of the start of the event into one box, and of the end of the event into another box. The boxes are prepopulated with today’s date. Entering “2BC” as the year gets changed automatically to 2002 when you click outside the box, as does “0002″. Dates down to “100″ do not get changed, but entering “10″ gets mapped to “2010″. Entering “49″ gets mapped to “2049″ but “50″ gets mapped to “1950″. In summary, one or two digit dates 0..49 map to 2000..2049, and 50..99 map to 1950..1999.

On to iCal. iCal only offers a two digit year field. 0..50 map to 2000..2050, and 51..99 map to 1951..1999.

On to Emacs. Surely Emacs gets it right. Well, nearly. Emacs calendar mode allows you to create an event for any year > 0.

So Emacs wins with 1 AD, followed closely by Gmail with 100 AD and iCal a distant third at 1951.

While this exercise was fairly frivolous, the consequences of the results could be nontrivial: what happens if you want to exchange dates and events between calendars? What happens in 1951? What happens if you want to add historical dates to your calendar?

PS Yes, I remember Y2K!