Mind Mash

Question: why are email, facebook, Twitter, chat, RSS, newspapers all separated?

I want to be able to do the same thing for all of them – which was more or less nailed by email a decade ago:

real-time update (push)
mark as read
thread
filter
spam detection
contact management
search

So why not pull all of these into an email client?

I was thinking about this this afternoon, and when I saw a Techcrunch article about Xonbi Facebook integration I had to blog.

My Twitter life has been exploding thanks to the RWW semantic web twitterers post, and I am now jacked in to a lot of very interesting feeds.

whuffie mentioned cognitively endowed objects as something big coming down the pipe. I can’t agree more.

My recent experiments with robotics and sensors have been really eye opening. Almost everything that computers do is limited by available means of interaction. For the most part, output to the user is constrained to a few million scintillating points of light, and user input to a grid of 100 square tiles and a fake rodent. These provide sufficient bandwidth only for written and visual communication directly between the computer and the user.

A notable recent trend has been the expansion of user input mechanisms, particularly in gaming, where the intent of a three dimensional, mobile, interacting user has to pass through communications channel of miniscule capacity (e.g. a joystick pad + fire and jump buttons) to instruct an increasingly three dimensional, mobile, interacting game character. So, Nintendo and others have brought us the analog joystick, the vibrating joystick, force feedback, the Wii controller. Apple understood that a touch surface is not just a way to swap a mouse for a pen (different physical input mechanism – same bandwidth), but a way to increase bandwidth (multi-touch). Microsoft have done something similar with the Surface (as far as I can tell, a ton of people would buy one at a price ~ iPhone’s $400 – Microsoft’s problem seems to be manufacturing).

Voice input has not yet broken through, although Google’s iPhone app is quite compelling (except for an unfortunate problem with British accents). A limitation there is the compute power needed to do speech recognition, something which Google smartly got around by sending the data to their servers for processing.

Another important kind of input and output is provided by the computer’s network connection, which admits information into the computer faster than a keyboard, but provides slower output than a visual display unit. The network connection does not usually provide data which is immediately relevant to the user’s immediate situation: it does not provide data relating to the user at a small scale, and does not provide information which is actionable at that small scale. By “small scale”, I mean the scale of things we can ourselves see, touch, taste, move, like, love. This is important, because most of what we experience, think, and do is carried out at this small scale.

Your phone might let you talk and browse the web. Your PC might be able to play you a movie or control the lights in your house. Your city might have a computer which monitors the traffic and adjusts the traffic lights. Your country might have a computer which predicts the weather or models the spread of disease, or which computes stock prices. The larger the area from which the computer’s inputs are drawn, the more the computed outputs are relevant to people in the aggregate, and less they are relevant to people as individuals.

There is a huge scope, and, I think, a lot of benefit, to making computation much more local and therefore personal. A natural conclusion (but in no ways a limit) is provided by endowing every significant object with computation, sensing, and networking. I cannot put my finger on a single killer benefit from doing this… but I think that even small benefits, when multiplied by every object you own or interact with, would become huge and game-changing. You could use a search engine to find your lost keys, have your car schedule its own service and drive itself to the garage while you were out, recall everything you had touched or seen in a day. Pills would know when they need to be taken, food would know when it was bad.

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.

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!

How often does it happen that you get a shiny new device home, plug it into your computer to set it up, and then the problems start? You need to upgrade to Music Player 4.3, you need to enter a 28 digit registration code, the device is not recognized, Music Player 4.3 is no longer available, … fail, fail, FAIL. So… you need to mount the device as a disk, reformat, drag an updated firmware image onto the device disk, reboot the device, reboot again…

You are led to expect by the software and manuals which come with your device that you will be able to do what you want, but you end up in a situation where it is either impossible to do that, or it is only possible with very detailed knowledge of the device and its accompanying software. I’m trying to think of a name for this kind of problem and the best I can come up with is “packaging failure”.

Last week a friend and I did an iPhone switcheroo. She had her old phone stolen but didn’t want to get the new more expensive iPhone plan with a new iPhone, and preferred the iPhone v.1 look as well. I was happy to get the new iPhone. So she bought the new phone and then we switched. Everything went smoothly at the AT&T store. I synchronized my new phone with iTunes without a problem. But when it came to synchronize her new phone (my old one) with her iTunes, we turned up a problem: iTunes was complaining that there was a security lock on the old phone and that it should be removed before synchronizing. It made sense – I always put a 4 digit combination lock on my phone in case it gets lost – but the problem was that the phone now only offered the option of emergency phone call and there was no option to enter the security code. So, I plugged the phone into my Mac and reinstalled the firmware, and that wiped the lock. It worked and we synchronized her phone after that without any problem.

How often does this kind of thing happen? ALL THE TIME. My next question is:

WHY?

These devices are very complex. This complexity is hidden underneath a software and/or documentation layer which lets you easily achieve what you want to do. As long as you remain in a situation which is covered by the the software and/or documentation, you are OK. But if you need to perform some task which was not anticipated by that software, or if you somehow end up in a situation not handled by the software, then you have to start dealing with the device at a much lower level, a lower level which requires a lot of expertise to understand.

So one cause of these kinds of packaging failures is failure of the designers to anticipate and provide for all the ways in which the device might be used.

Another kind of failure is failure of the designers to protect against errors which can occur. For example, you are following the setup process and get error -53 and the setup wizard quits and won’t restart, and the device won’t wake up.

Typically, the GUI and the instructions guide the user through a sequence of intermediate states towards successful completion of the task at hand. When I was working at NASA Ames, there was a group there which had designed a software system called CLARISSA to help astronauts by verbally guiding the astronauts through their procedures in space. An important part of the work of writing such procedures is verifying that they achieve the task and handle all contingencies.

Astronauts’ procedures, and packaging software and documentation, are effectively based on finite state machines. The arcs of the machines are labeled with steps in the procedures, or actions in the software interface. Packaging failures are events which lead from a state in the finite state machine to an unanticipated state which is not part of the machine.

In order to handle these problems, the finite state machines need to be extended: the instructions finite state machine could be extended, e.g. “if the device displays an error message, unplug it, hold down the power button for 10 seconds, then plug it back in to restart the installation”, or the software finite state machine could be extended to handle this error condition.

I just read an article in Inforworld suggesting that Microsoft is preparing a web-based successor to Windows, based on the Singularity Microkernel OS.

To start with, I have zero inside knowledge about this move (just lots of opinions , and I would not put too much weight on the article, but I have been thinking along the same lines for a while.

First, the successor to Vista has to be great. Windows 7 is an evolution of NT and I am not sure whether this can provide the necessary edge.

What I would really like to see would be a new Windows, reengineered from the ground up as a modern, microkernel operating system. The Unix concept seems to me to represent the minimum operating system which is mature, powerful, and well-engineered enough to be a robust foundation for general purpose computation. There has been a lot of operating systems research in the last 40 years which surely can be used to build something much better than Unix. With the widescale adoption of virtual machine technology, it should be perfectly possible to run Windows NT type (XP, Vista) applications inside a virtual machine in a completely new operating system.

Interfaces Contribute to Software Risk

When I was at NASA, I did some research on software risk. The most common identifiable cause of software failures, apart from “functional defect” (i.e. the code was perfectly valid, but just did not implement the right thing) is “interface defect”, i.e. a failure in the interfaces between components.

Interface Problems are Worse in Large Multilanguage Systems

The reason why interface defects are particularly common is probably two-fold: compilers and other tools do not provide good support for preventing this kind of cross-component defect, components tend to correspond to the boundaries between the work of different people, and interface defects are due to lack of coordination between different people.

A large system – especially one providing a consumer web interface – is often composed from many components, written in several different languages, some of them running on a single machine and others broken into client and server parts. The system and its components may be evolving quite rapidly and different parts are usually written by different people. The checks provided by compilers are only of benefit on a component-by-component basis and so are not very helpful in this situation.

Check Types + Properties At Runtime

The kinds of type-checking available in programming languages are generally limited by the need to check types statically, which imposes a severe restriction on the notion of “type”. Many types in practice would be well represented by specifying an underlying data type plus properties which must hold of valid elements, e.g. lists (underlying type) whose elements are pairs (property), arrays of strings (underlying type) which are sorted (property). Such types are known as dependent types. Dependent types are not supported by most programming languages, because their use sacrifices automation of static type inference and checking.

Although dependent types cannot be checked statically, or used explicitly in most programming languages, a lot of the benefit of dependent types can be realized by writing functions which check whether given data have the right underlying data type and satisfy the required properties. Instead of statically checking types, which is mathematically hard or impossible, we just check data input to or output from functions to ensure they satisfy the properties, i.e. have the right (dependent) types.

Represent Interface Contracts As Types + Properties

These runtime checkable properties (dependent types) provide a good way to tackle part of the interface problem, by representing the interfaces in a machine-checkable way and building mechanisms to check the consistency of the component interfaces both at build time and at runtime. Speed is often important, so components should distinguish between a “development” environment, in which the interface checks are performed, and a “production” environment in which they are skipped.

My proposal is, therefore, to define APIs which specify the classes/functions/methods provided by the components in a system. Those APIs should specify at an appropriate level of detail the signatures, types, and properties of those classes/functions/methods. “Appropriate level of detail” here means exercising judgement about when to use heavy-weight, detailed representations, and when simpler abstractions are good enough. The functions which check the required properties of data can be used both at runtime in the development environment to check much or all of the data passing between components, and can be used at build time to check aspects of the correctness of test results. One way to view these functions is as test oracles.