iPhone shipments overtake Windows Mobile

As reported by Silicon Valley Insider. Their analysis covers the challenge to the current wisdom (that buyers want customised models) that this poses, and the fact that other manufacturers seem to be turning to non-Windows OSes such as Android to counter Apple.

All of which must be deeply embarassing for Microsoft. I suppose they'll just have to grin and bear it (there'll be a lot of people wanting to help them with that — at least with the grinnning part) while they do yet another revision of Windows Mobile.

It looks to me like Microsoft's in real trouble here though. It wouldn't be so bad if they'd "only" been pushed out of the number three spot (after Symbian and BlackBerry). Symbian is clearly in trouble itself and has been more or less abandoned by Nokia (that's the perception at least, after the recent open-sourcing, whatever Nokia might say) so you might expect its market share to be gobbled up by the others over time. However Windows Mobile shipments were actualy down in real terms, not just as a proportion of a growing pie: by 3% over the year.

In a world where perception matters, Windows Mobile is looking weak: the only one doing all-around worse in the mobile space is Linux. Manufacturers, like investers, tend to stampede. Will 2009 be the year Windows Mobile collapses?

Notes on the Fiscal Crisis and Bail Out

A very useful, exceptionally clear analysis of what went wrong with the US mortgage investments market. It's very good at showing the causal chain (if I may use such a discredited notion) of events. Find it here (PDF). Hat tip, if that's the right phrase, to Tyler Cowen at Marginal Revolution.

The Jules Verne

The video of the re-entry of the cargo ship Jules Verne into the atmosphere is quite spectacular. (If you don't know, the Jules Verne took supplies up to a space station, stayed docked for a while, and was then packed full of rubbish and set off on a trajectory that ensured it would burn up during reentry thus disposing of both itself and all the rubbish.) It looked, of course, like a rather large meteorite burning up in the same manner. There's something very pretty about such fireworks, even if you know that it's "really" just incinerating rubbish. It's the distance I suppose.

What really interested me though was reading that the crew of the space station had found the Jules Verne, while it was docked, to be a nice, quiet place to go and spend some free time. Some of them even chose to sleep there.

Excuse me? They went to sleep in a vehicle that they knew was going to undock, blast off, fall hundreds of miles while burning up and finally explode in a million fiery pieces? I know that the moment I fell asleep there the nightmare would start. The clang of the airlock shutting, locking. The hiss and rattle of the couplings disconnecting. The roar of the engines that, curiously, wouldn't be enough to wake me up... Astronauts it seems, are made of sterner stuff.

The Hand that throws the dice :)

Reading Richard's latest post, I eventually stumble upon his reading list for the 9th September. A little way down I find Ian Stewart's Does God play Dice with its reference to Einstein's famous statement that he didn't believe that God played dice with the universe, and suddenly realise what's been troubling me about that remark ever since the first time I heard it.

Which is that, in classical mechanics at least, throwing dice gives you a perfectly causal and non-random result!

Interesting Google Reader behaviour

Quite a while back I decided to try to drum up some page rank for wow.gedsguides.com by creating a few blogs. Whenever one of my characters completed an interesting quest, or quest line, as well as updating gedsguides.com I would write about it in that character's blog. The end result of course, as any seasoned blogger could have told me, was four blogs that weren't updated frequently enough to be interesting, and that still didn't cover all the WoW characters I've got.

So I've decided to amalgamate all these blogs into one new blog — the hard way. Instead of spending a couple of hours tediously cutting and pasting from one window to another, and then fiddling with the settings of each post to faithfully reproduce the date of the original, I'm going to spend a couple of days writing a python script to do the same thing programmatically.

Of course, the real objective is to kill two birds with one stone and to improve my still extremely sketchy knowledge of Python. That will then feed back into useful skills should I eventually decide to Django-ise gedsguides.com, as I'm still thinking about doing, and also for anything I might do with Google App Engine.

Anyway, along the way, I saved the xml data feed that the script was getting back from the Blogger API, and looked at it in a browser. Lots of guff, lots of urls. One url being an Atom feed of the list of all (that is, all four of) the blogs belonging to the account that I set up to publish them.

So I rather naively took that url off to Google Reader and plugged it into the Add Subscription box. I suppose I vaguely thought that Google Reader might be clever enough to add the Atom or RSS feeds for all four of those blogs at once.

Instead, it simple-mindedly read the Atom feed, containing brief descriptions of the blogs taken from their settings, and presented that as its list of "new postings".

OK, so it wasn't as clever as I thought, and I reached for the Delete button to remove the feed. But wait! I'd been thinking of Google Reader as a blog / news reader. What it really is, is a vehicle for presenting any old Atom / RSS feed!

Well I knew that Google Calendar presents an XML feed, so I copied the feed url and tried adding it as a subscription in Google Reader. Success! Seconds later I was reading my calendar entries in Google Reader!

I wonder what else you could munge into an Atom publishing format and usefully view using Google Reader? I was thinking you could use it as a cheap workflow engine: someone could subscribe to an intranet url that gave them their to-do list for the day. Of course, the rather limited list of actions that you can do using Google Reader might not suit everything: you can jump to the posting's url or open it in a new tab or window, and you can mark the posting as read. Still...

If you could take an Atom feed from forum software, say for a partiular forum, or for a particular thread that you were interested in within that forum, then you could browse new postings in Google Reader.

A few years ago I worked with a crude kind of laboratory automation software at a pharmaceutical company. If you had a bioreactor chugging away, say, under program control, that program could expose an Atom feed with a new post every time it passed a particular milestone (sterilisation, cooling, adding medium, adding nutrients, adding organism) and you could check on the progress of your culture at the same time as browsing Slashdot :)))

Django - first data!

With Django installed it was a question of seeing if I could get data out of the wow.gedsguides.com database. So I munged the table definition parts of my database build (structure) script, create.sql, into a Django-style model definition in a new model.py. OK, so I only did two of the tables, but it's the thought that counts.

Then just a matter of validating the models using Django's built-in manage.py tool, and once I'd fixed a couple of newbie bugs I looked at the generated sql, and it was certainly close enough to the original DDL in create.sql for me to be confident that the Django models were going to work with the existing database just fine.

Then it was time to go into the webmin interface of the new (soon-to-be-migrated-to) virtual server running on a box in jsp-servlet.net's data centre somewhere in San Francisco and tell postgres to let my home PC connect to the database.

Then an SSH session into the same virtual server, to run the actual database creation script — my original create.sql, naturally. I wasn't going to run the Django one for the pretty obvious reason that other applications have to be able to work with this database, so Django just can't be the lord and master there.

Once that was all done I tested connection from my home PC to the remote database by running pgAdmin III and that was fine, so I edited my new Django app's settings to tell it how to connect up, and then it was time to go into manage.py's interactive shell and start instantiating database objects:

>>> from ggw.admin.models import Stages
>>> qs = Stages.objects.all()
>>> print [p.name for p in qs]
[u'Stub', u'Notes', u'Rough draft', u'Final draft', u'Complete']
>>> print [p.id for p in qs]
[10, 25, 50, 75, 99]

Tomorrow I'll look at what it's come up with in the way of an automatically generated admin interface, and at that point I'll know whether I want to proceed or not.

Some things do stand out though. The rather ad-hoc nature of Django's query filter language being one. I don't know, it may be modelled on some absolutely standard object query language (I don't like them either) but it seems to have had to replicate, in an amazingly clunky and obtuse way, what you get as a nice, clear syntax in SQL itself. For example, I don't know how anyone can think that a where-clause expressed like this:

Entry.objects.filter(pub_date__lte='2006-01-01')

is an improvement on one expressed like this:

SELECT * FROM blog_entry WHERE pub_date <= '2006-01-01';

"Publication date less than or equal to equals some date" ... I don't know — how do you read that in a way that doesn't insult your linguistic sensibility? But obviously it's what you have to do when you have all that enormous object-relational machinery in the way. (It reminds me of the old saw about all applications evolving until they include a complete lisp interpreter, implemented very badly.)

---

Update: Sheesh, them thar interwebs are humbling things: no sooner do I write my half-baked objections in the last few paragraphs above, than I stumble — from a completely different direction — on someone making exactly the same point, a hundred times better, in a different-but-comparable context.

Moving to Django

Well wow.gedsguides.com needs a bit of t.l.c. — a facelift and some new functionality. And rather than plod through acres of Java code (and, IMHO, now that everything is supposed to be done via annotations it's actually more error-prone rather than less) I'm looking at Django to do the business.

Mostly I like what I see. The Django developers seem to be a pretty smart bunch, and if they've had to balance power, flexibility, economy and expressivity they seem to have got a very good bargain.

So there's just a few things I don't like. Number one (and I won't bother about the rest) is syncdb. I want to design my database first, and then have the ORM layer work with that. I don't want to design the object layer first and then have the database constructed from it automatically. I suppose I'm showing my age, swimming against the tide of history, etc. etc. And to a degree, it's a bit cheeky of me to expect to be able to use an ORM approach like Django's without having to pay the price.

Still, so far I've only installed Django and worked through the tutorial. I've yet to read the reference documentation for the models module(s). It may be that you can finesse the default behaviour, I hope so — and the flexibility and customisability I've seen in the rest of Django certainly gives me cause to hope; it would be a shame if it was completely hard wired in this one area.

I'll look at Djangoising the admin interface first. Since it's a completely separate application, I can do it in Django while leaving the public site still running with servlets/jsps. And I get the benefit that all I have to do is define the models and Django will generate an automatic admin interface for me — that's very attractive! (Subject to the proviso above, of course.)

And when and if the time comes to deploy it, I can even do it in baby steps, by simulating python/Django on the java server with the magic of jython: Deploying Django/Jython Projects on a J2EE App Server.

Google Chrome - what, no coffee?

Well it was here when they said it would be, and I downloaded it. It installed, and crashed at the last minute when the browser had just started up and was importing settings and bookmarks from IE and Firefox, and it looked like it was the bookmarks that were responsible.

But, just like it says on the box, only the tab that was doing the imports fell over, and I was able to carry on and start browsing the web immediately. Later, I went to the options menu and got it to load the bookmarks again, and this time it completed without incident. So score +1 for Chrome.

So what about this blazingly fast Javascript engine then? I've deliberately refrained from running any official tests, on account of being lazy, but just let's say that I'm once again impressed at just how important network and server latency are in the browser experience. That is to say, working with Gmail and Google Reader, sure it seemed a little bit faster at opening the pages, but even in these Javascript-heavy apps, it's the I/O that's the bottleneck.

I decided to look at plugin support. Flash/Flex is there as you might expect (what with having to support YouTube and all!) but, very surprisingly, Java was absent. I managed to find some pages with applets on by going to the Sun website (what a blast from the past!) and got a message saying "No plug-in available to display this content". Here's one of the pages I tried, see what you get.

At first I was a little staggered. Could the status of Java applets have fallen so low that Google weren't even going to bother supporting Java in the browser? (And see here for what I found out about current antipathy to Java in the browser.) Well yes it could, I suppose. Maybe Google have simply concluded that Java in the browser has had its day.

I expect though that the explanation is simpler: Chrome is a beta after all, and there's no compelling need for Google to support applets from day one in the same way that YouTube makes it necessary for them to support Flash. Also maybe something technical about the way the JRE integrates with the browser makes it harder to support than Flash? Maybe. But Safari 3.1.2 (as kindly downloaded for me by iTunes when I wasn't paying attention during a product update) seems to have managed it without any problem. Hmm, this smells kinda bad, kinda fishy...

Of course, Google have got a JVM of their own though, haven't they? Maybe instead of incorporating the Sun product, they'll simply port Dalvik to run inside Chrome? That would unify two of their platforms very nicely indeed, thank you. Android games running in Chrome tabs? I'll have some of that!

If I were Google though, I keep it very quiet if that was indeed my plan, since it would undoubtedly cause a massive outcry (assuming anyone still cares, which is moot, but I bet a lot of people who didn't really care would still enjoy complaining for its own sake). In fact, the best way to do it might be to release Chrome without any Java support at all, and wait for annoyed voices to demand it, and then say something like "Well licensing restrictions mean we can't support yer actual Sun Java in Chrome, but we got something 'ere that's just as good, honest guv'nor."

---

Update: OK, panic over, Chrome does support Java! You just have to have the absolute latest, bleeding edge development release, version 6 update 10. If you click on the toolbar menu and then on the Help submenu it'll take you to a page where you can search for Java support, and that'll take you to a page where they explain what's going on. Or just take my word for it and go to http://java.sun.com/javase/downloads/ea.jsp and download and install Java SE 6 Update 10. Phew!

Still think Android apps in Chrome would be a great idea though.

Google Chrome. OH. MY. GOD.

Apologies for the quality of this post. There's so much to say and my thought processes are just running all over the place as various connections are being made. I've just read about Google's new Chrome web browser tonight, it's all over the web.

My first reaction was, "How odd!" Why would Google want to bring out a new browser? There are new browsers appearing all the time, and it would be much more in keeping with G's modus operandi to date for them to simply help out with advice, code and a bit of cash here and there, rather than to up-end the whole apple-cart like this.

Then I read the 38-page cartoon that they sent out explaining things. And my second reaction was, "Oh. My. God."

It seems obvious now that development of current browsers was either not going in the right direction for Google, or just wasn't getting there fast enough. Things are scrappy. They're fragmented. Google have big plans for the browser, and it looks like they've decided to start bringing all the strands of their work together, so that we can begin to see the shape of what's coming.

Strands? Heck, let's change metaphor. It's like when the tide starts to come in on a nice warm beach. At first all you can see is tiny rivulets of water coming from all directions and going in all directions. It's only later you realise that THE SEA is on its way and your little spot in the sun is soon going to be under six feet of water (and yes, Microsoft, it is you on that towel).

So they've made all these little moves. And they looked a bit odd and a bit disconnected. Google Apps — a bit slow, a bit underpowered, but they would be see, 'cos they're running in a browser. GWT — what's the point of a development environment that has you writing web apps like they were desktop apps? Gmail — nice example of what you can do with Ajax, was it written using GWT? Android — what browser does it use?

But now Google are bringing out Chrome, whose intent seems to be to run applications as complicated as the most complicated ones that you run natively on your operating system, and to run them just as fast (or at least, in the same ball-park). Hmm, Google Apps, they're going to be a bit snappier now, aren't they? Hmm, I can see the point of a big-iron development environment based on a typed language now! And Android, currently sporting the browser that Chrome is based on, will likely be running Chrome or a Chrome-alike in the next release (after the one that we still haven't had yet).

That's enough hot air and pontificating. The rest of this post is specific reactions to things in the cartoon, which you may not understand unless you follow the link above and read the cartoon.

---

They are using the Webkit code base. Not Mozilla. By my reckoning that's now about a million billion important new browsers have been built on webkit, versus ... erm ... (I can't think of any) built on the Mozilla codebase. OK, so I'm using "important" in a very particular sense: "big", that is to say, backed by an organisation (probably a commercial company) and guaranteed a large user base. (And I know that there are lots of browsers based on Mozilla, but together they must have a user base approaching, what, 10,000 people?) [Yes, other than Mozilla itself and Firefox.]

Mozilla are #?*&ed! Now the flow of money from Google to the Mozilla foundation is not charity, it's a deal whereby Mozilla preferentially funnels its searches to Google. So that can stay in place. As long as Mozilla users search on Google, Mozilla can get money out of that deal, there's no sense in Google just killing it. So Mozilla is not #?*&ed immediately then, but stand by to see it lose market share vertiginously if Chrome is as good as Google thinks it's going to be.

Stand by also to see Microsoft scramble to match Chrome in terms of features. This comes at a particularly bad time for Microsoft, with IE 8 code very likely closed to new functionality, and the release only a few months away [GOOGLE SMACKS MICROSOFT, #1]. What do MS do now? Do they stick to the original release timeframe and release it as-is, and smart when nobody notices because Google released a better browser a few months back [and that's TOMORROW folks!] and everybody's using it? Or do they pull the release and desperately try to match Chrome, feature for feature?

Omnibox. I can see this running into trouble very quickly. This business of remembering what site-based search boxes you've used, and allowing you to reuse them by typing in a site identifier and then a tab and then your search terms? Think of the controversy caused by deep linking a few years back. This is an excellent way to cut a website's search page out of the loop. So now, instead of first going to Amazon's home page and having to skim over all the stuff they've kindly prioritised for you as your eye hunts for their search box, you'll go straight to their results page. Hmm. Site publishers are going to regard this as kidnapping their search boxes, and I would be surprised if there weren't a few legal challenges to it soon.

Interesting to see the places in the cartoon where they have obviously decided to put the wind up the competition. Some of them really made me chuckle.

On page 4 they say that each tab is a separate OS process. If memory serves, Unix/Linux processes used to be lighter weight than Windows ones. Assuming that's still the case, Chrome may be a bit sprightlier and more performant on Linux than on Windows [GOOGLE SMACKS MICROSOFT, #2] — just the thing for those Linux-powered net-tops that are springing up all over the place.

On page 5 they point out that this means that the sort of badly-behaved page that used to make your entire browser crash will now only affect the one tab. This must happen to me about once a day at least: four separate browser windows open, themed for work-related stuff (several pages of documentation from assorted sites), news (Google Reader for scanning, then I open up any interesting stories in their own tabs), mail, and one for anything else; that's twenty or thirty pages all open at once, some of them regularly updating in the background. When a bad page takes down that lot it's annoying and I thank heaven for Firefox's auto-reopen feature. When the bad page is really bad, and Firefox goes down again straight away as soon as it tries to reopen it, that's when I get annoyed.

Pages 9-11 must be putting the fear of God into Microsoft right now. Google are showing off how they can push automated Chrome testing out over their famous distributed server network, testing tens of thousands of web pages per hour [GOOGLE SMACKS MICROSOFT, #3] and making sure that they cover them in order of importance, as indicated by their very own page ranking alogrithm.

Page 13 is very interesting. They mention no names, but I immediately thought of Adobe's Tamarin VM for Javascript, now donated to Apache. Were they thinking of Tamarin? Did they look at it and reject it, or was it not open source back when they decided to write one themselves? I need to look at the timescale for that more carefully. One thing: Tamarin is built for the version of Javascript that didn't make it into the new standard, and work is apparently under way at Apache to convert it for the version that did. Good luck with that. Google probably thought it was better to start from scratch [GOOGLE SMACKS ADOBE]. And if the boys that did the new Javascript VM are more or less the same ones that did the Dalvik VM for Android, then Google probably thinks it can do a damn good job on its own, and rightly so.

Interesting also that they are seem to be JIT-compiling Javascript to machine code. That's been a perilous way to go in the past, partly because of what can happen with variables. Javascript variables are untyped, but the values that they hold do have types (number, string, object, ...). Now there's nothing to stop me coding a for-next loop where the value held in some variable used inside the loop changes type on each pass through, and in the past that's either killed efforts to compile Javascript or put serious constraints on the efficiency of the resulting code (by making it have to be too general).

In this context, it's especially interesting to look at the latest release of the Google Web Toolkit (GWT). GWT you will remember lets you write your web application in Java, a heavy-duty, strongly-typed language, which GWT then "compiles" to Javascript for actual execution in the web page. The release notes for the latest version of GWT noted that this "compilation" phase effectively throws away the valuable type information, in the transformation from typed Java to untyped Javascript, and that in previous releases this negatively impacted performance. But the current release takes advantage of the fact that any Javascript variable in a web page produced by GWT is guaranteed to have come from a typed Java variable! In other words, you can guarantee that that sort of type-bending naughtiness isn't going to happen in a respectable GWT application. So you can do type inference based on the first value of a variable that you see... And then the release notes said that that had led to sundry improvements that were beyond my understanding, because all I could think of was that Javascript was still untyped.

So what's the betting that GWT-produced web applications will run especially well in Chrome, because of the good behaviour of their variables (and, no doubt, for many other reasons way above my head)?

---

Michael Arrington at TechCrunch says:

Make no mistake. The cute comic book and the touchy-feely talk about user experience is little more than a coat of paint on top of a monumental hatred of Microsoft.

I hope this doesn't mean that MS have got so far under Google's skin that they are letting hatred guide their actions. That would be a colossal mistake. So far, Google have been the nimble players. They are the ones who, in every case [May not be true. I have a terrible memory!], have led the way with an unexpected paradigm-shift, leaving others scrambling to catch up. Letting Microsoft-hatred guide your actions is a mistake other companies have made in the past, and it's ruined them because it hands the initiative to MS, who are not slow to capitalise on the opportunity.

---

Update: Dave Methvin over at Information Week points to where Google may have got some of the technology they are using to sandbox Chrome tabs.

Single-child families and population decline

There's worry in certain circles right now about population decline in much of Europe. Families are becoming smaller as investment in individual children (supposedly) continues to rise. And if average family size is below, what is it, 2.1, then voila, it's below replacement level.

I wonder if there's another factor that's contributing, making the effect larger and more self-reinforcing. With very few exceptions, all the only-children I know are single in their adult lives, and all those who had at least one brother or sister are now partnered, again with very few exceptions.

If this is true, then as average family size decreases, logically, the number of single-child families increases as a proportion of the whole. If most of those children are not going to reproduce, then you have a runaway decline.

Those enterprising cloud warriors

It seems that no sooner does a technology appear than it is subverted by those who want to abuse it.

A while back I started renting a virtual server to which I was (am) going to move a website that I own. The site is currently on a small hosting account, and it's starting to need a bit more than that. Anyway, I didn't do anything for a while, and just let the virtual server gather dust. Then, the other night, I got a burst of energy and started to look at what I could port over first.

As I was doing that, I was also idly browsing through the log files in /var/log and I see an enormous messages file and an enormous secure file. And their backups were big too... This is a server that, while it's on the internet, didn't even have a domain name until the last few days, it was just a raw ip address. Why were those files so big?

It seems that someone is trying an automated dictionary attack on the server. As far as I can tell, each login attempt, via ssh, is supplying a username but no password. Each name is being tried once, and then on to the next. So it's looking for unprotected accounts rather than trying to guess passwords (I think a "dictionary attack" really refers to when they are using a dictionary to try to guess passwords, but I'll stick with it since they must be storing their list of usernames in a dictionary too.) It seems fairly primitive but it's still immensely worrying, especially since I really don't want to have to become a linux security expert.

Each attack starts about the same time every evening, and lasts about eight minutes. That's it, but in that time it's doing a couple of login attempts every second. Of course, the source ip address of each attempt is logged, so I've been busily adding them to /etc/hosts.deny whenever I see a new one. Last night was quiet, first time in a couple of weeks, apparently. Time will tell whether just adding addresses to hosts.deny will work; in the short run maybe, I rather doubt it in the long run.

So what has any of this got to do with "the cloud"? Just that the attacking ip address sometimes resolves to an Amazon AWS instance, ec2-75-101-154-0.compute-1.amazonaws.com to be exact. Either some nerveless criminal is renting out EC2 instances with the intent of using them specifically to crack whatever insecure hosts they can find or, perhaps more likely, some of the startup images that EC2 instances use — and these images are huge, containing a whole operating system, as well as whatever applications they are going to run — have been compromised.

Looking at the way Amazon run EC2, they provide a number of basic instance images, but there are a lot of others mentioned on their forums, created by "helpful" users and containing just the right applications for people to find them attractive. An obvious security hole you might think, but people must be using them, or they wouldn't exist. Maybe Amazon need to virus-scan their EC2 images before starting them up, what a horrible thought.

---

Update: I see that at least one other person has noticed the same thing happening too: David in Sweden. I wonder if he ever got an answer out of Amazon?

Amazon Elastic Block Store

This has been presented as a small, incremental step forward for Amazon's cloud-based computing. It's not. It's a big deal.

First, some grossly-simplified terminology. In the beginning there was Amazon Elastic Compute Cloud (EC2), which is your server(s). There was also Amazon Simple Storage Service (S3) which you can think of as being your network-attached file system. A little later they also brought out (though it's still in beta a.t.m.) Amazon SimpleDB which is your database and Amazon Simple Queue Service which is your messaging infrastructure. So what's the problem? Why do we need EBS?

Well I said "servers" above, but it's more accurate to think of EC2 instances as being like a CPU + RAM, where the RAM has enough space for a virtual disk. Your server does have some disk space attached ("instance storage" in the lingo) to which it can write files, but remember that the whole point of EC2 is that servers can get started automatically in response to demand, and that when demand falls, they can get automatically switched off. At that point, anything they've written to their local disk just disappears. I suppose it's the same as an object going out of scope and getting garbage-collected.

So if your web application, running on your EC2 instance, has done some work and updated some records, then it needs to salt them away somewhere outside the server-instance itself, and that's where S3 and SimpleDB come in. And of course, once you realise that your EC2 instance is probably going to need to save some data, it's but a step to see that it's also probably going to have to initialise itself, once it's up and running, from a data store too. So data passes between EC2 and S3 and SimpleDB in both directions.

So again, where's the problem? Well, I said that S3 was like a file system. It is, it's like some old, clunky PC-DOS 1.x floppy-disk-only file system, before you had directories and certainly before you had subdirectories. Each user account gets I think it's 100 bags (they're the floppies) and each of those bags can hold vast amounts of objects, but all at the top level, and all in the same namespace. If you want to impose any kind of structure on top of that, then you must do it by appropriately decorating the names (keys) that you use. It's as though your whole hard disk could only have a single folder and you had to keep everything organised by using tremendously long filenames.

Again, I said SimpleDB was the database, but it's not an SQL database. In fact it doesn't even have tables. It's more like a set of objects and a set of attributes, and any object can have (or not have) any of those attributes, and you can search on the attributes. So imaging that you could add some kind of metadata tags to S3 files and search on the tags, and that's SimpleDB.

I'm not criticising them, the constraints of replication, timeliness, availability etc. etc. very likely imposed all these limitations. And in an odd kind of way, the objects you get in S3 and SimpleDB remind me more of the sort of constructs you get in programming languages like Java or Javascript, so you can see that as building blocks they might be very powerful and useful.

But it's probably true to say that the software that would run well in this environment would have to be written or adapted specially for it. A lot has been written too, in the couple of years that EC2 and S3 have been available. But there's a whole class of more traditional applications that haven't, and which won't work in this environment, and they represent 99.9999% of all the software that's out there.

So now Amazon introduce EBS, and you can think of that as an infinite array of network-attached hard disks (but this time they are proper ones, with subdirectories and everything :) ). Previously, if I wanted to store my web application's data in say a PostgreSQL database, to get the benefit of SQL based access, I had to put that database on the EC2 instance's hard disk (instance storage) and had to make sure that the data in that database got pickled to S3 before the instance was shut down. Now I can just put the database on the EBS disk and forget about it.

Of course, for the very largest, most fault-tolerant and distributed of applications, EC2 + S3 + SimpleDB + SQS was probably architecturally the right way to go anyway; the sheer size of such applications might make exactly the same constraints necessary. The difference is in the area where I live: the web site that can fit comfortably on a single server, or even a single virtual server, with an SQL database on the same machine or on a different machine on the same network. That's to say, the space where the smallest to the medium sized database driven websites live.

These are well served at the moment by the numerous small hosting providers who'll give you a virtual server or two, or your own box. But if your web site does well, then the upgrade path can be difficult and expensive. And if your web site very suddenly does well then you likely won't be able to resource-up in time and it may fall over. And the pricing models are very coarse-grained in comparison to Amazon's.

For those web sites, Amazon EC2 wasn't an option because they would have had to rewrite their data layer and still end up with something that wasn't as flexible as SQL. But with EBS, those kinds of sites can be ported directly.

South Ossetia

It's anyone's guess what the Russians' ultimate goals are, but I suppose there are three possibilities, in ascending order of seriousness.

First, simply to defend the (independence of the) South Ossetians, which is their ostensible motive. If that's the case, one might reasonably ask if invading Georgia is the right way to go about it. However the ultimate consequences might not be all bad.

Second, to annexe South Ossetia. No doubt pliant S.O. nationals could be found to publically thank them for doing so. This would definitely qualify as adventurism, and its successful accomplishment would likely increase the Kremlin's appetite for more such moves - Abkhazia probably being the first.

Third, a full-scale and prolonged occupation of Georgia, leading eventually perhaps to: the incorporation of large tracts of its territory (South Ossetia, Abkhazia, and the corridor between them) into Russia; the emergence of rump Georgia as a vassal state; or even the complete annexation of Georgia. This would be extremely bad, and would likely lead to instability in the surrounding areas.

Something that would worry me very much if it happened after successful Russian action in S.E. (defined as the second or third possibilities above) would be a coup in Serbia, followed by an invitation to Russia to safeguard Serbian borders. Conflict between Russia and the EC would seem likely at that point, followed almost immediately by a Russian energy embargo and a collapse of European will.

Absinthe

Good to see that Absinthe is making a comeback. Interesting that the American market is where all the new action is, and that the products available there are higher quality than in Europe:

To date, there are four brands on US shelves: Lucid (Breaux's formula), Kuebler, Green Moon, and St. George Absinthe Verte. "The US is lucky in that its first absinthes are high-quality products, distilled from whole herbs," Breaux says. "In the European market, 80 to 90 percent is industrial junk."

I want my grave-photo to show me sitting at a table, having just finished an excellent repast, smoking a Cuban cigar and drinking a fine Absinthe.*

* Does one drink Absinthe after dinner or before? Perhaps I could make do with a fine champagne cognac.

GWT and GAE

One always looks, of course, for the ideal toolkit with which to develop AJAX-style web applications. It's a pastime into which one can put as little or as much effort as one desires, and it rarely seems to result in satisfaction. In that, it resembles the search for happiness... but I digress.

Some toolkits promise much and deliver little. Many seem focused on flashy effects rather than functionality. Most seem to have large and inexplicable gaps ("surely they must have realised they would need to..."). You end up combining, or trying to combine, different kits that are built on different principles and have no unifying structure, and whose subtle interactions lead to difficult bugs.

I'd more or less settled on YUI (The Yahoo! User Interface Library) as having the best functionality for my purposes. It's a bit heavy and a bit clunky, and new developments spend entirely too long in beta, but it's comprehensive and versatile, even powerful. I use it in the editing application for gedsguides.com.

Along the way, I'd had a look, along with everyone else, when Google brought out the Google Web Toolkit. An interesting approach: compile a Java source to a Javascript runtime (the delicious irony didn't go unnoticed — the Java you'd write using the GWT would once upon a time have run natively in a JApplet). The potential was obvious, as were the potential gotchas: differences between the development environment (a Java runtime) and the production environment (in-browser Javascript) might lead to severe debugging problems.

Happily, the quality of engineering that went into GWT seems to have been high enough for it to have garnered a good-sized community, so maybe the fears were overstated. There's even a version of Ext JS available for it, Ext GWT to give it a bit of extra pizzaz in the GUI. The combination seems excellent and I'm nerving myself up to rewriting a page of the GGW Admin Console with it, as a test.

Another area where GWT shows evidence of independent creativity is its approach to cross-browser compatibility. Most other toolkits, insofar as they attempt to solve this problem, approach it by abstracting it away the differences. The result is that they invariably have a base module that has to be loaded by the browser, and that translates their general code into browser specific calls, for whichever browsers are supported. This module needn't be very large, 10 to 20 kilobytes perhaps, but it does have to contain code paths for all supported browsers. And that's a reasonable price to pay for the independence it provides.

The reason all the Javascript toolkits have to adopt this approach is because they are entirely runtime, browser-based affairs. GWT offers the same browser independence to your code, but this is a pre compile-time affair! GWT then produces lots of different run-time support files for your app, one set of files for each browser (even, for each version of each browser). The end result is that the Javascript footprint of your application, when it actually runs in a particular browser, may be much smaller than with other toolkit: each browser has to load only the code that it needs. Extremely smart. The cost of course is that your server has to have room for tons of files; your application takes much more space on your server's disk than with the other approaches; there may also be an impact on your server's cacheing. These are all things that we know how to solve on the server though, and they play to its strengths; all in all, I rather like the balance that GWT has adopted.

Here's the Achilles heel. If your web application needs to contact the server for data (which, given that it's a web app, it's bound to do a lot of!), then the support that GWT provides for RPC on the server is implemented using Java servlets. This means that your server has to be Java based: Tomcat, or Resin, or JBoss or whatever. This is a matter of a particular implementation rather than anything essential of course, though there's a fair bit of work for anyone that wants to re-implement the server-side stuff using something like, say ... Python.

Why would anyone want to re-implement GWT's server side using something like, say ... Python?

Well say hello to Google App Engine! I remember getting very excited when this came out: "run your web applications on Google's infrastructure"! Who wouldn't want to do that? This would be instant death to the thousands of tiny ISPs who host millions of modest LAMP sites. The sort of stuff that uses a MySQL database for small amounts of data. Things like game guild sites with membership lists of a couple of hundred people, raid calendars, little bits of news and so on. (I still think it will impact these things severely, but over a much longer timescale than I first thought.)

The thing is that App Engine is Python-only. Lots of people have been wondering if it's possible to combine GWT, which is mostly a browser-client (AJAX) technology, with GAE, which is mostly a server techology. Trivially it is, since the pages you serve from your GAE web-app can contain anything of course, including GWT applications. But that only works with the most basic of applications. If you need to pass data between the AJAXy GWT application running in your browser and your server, then GWT wants to talk to a Java servlet. Or you could jettison GWT's preferred approach (RPC) and go for something RESTful (there's a JSON example app comes with the GWT SDK). In which case a Python back-end is as good as anything else; it's very doable, but there'd be somewhat more coding for you if you did that.

So Google need to adopt a more joined-up approach to web applications. They could commit to writing a GWT-compatible back end in Python and running on GAE. That's not such a bad idea; it migh even be the least work for them. Make it a compiler option, with a flag saying if its server code should be emitted in Java for Tomcat et al. or in in Python for (Django and) GAE.

Don't look for Protocol Buffers to help here though, even though it's touted as "Google's Data Interchange Format". Although Protocol Buffers already supports both Java and Python (that is to say, the supporting tools can emit code in both those languages) it's a binary wire protocol: suitable for slinging data around on an internal network, but not so good for (typically text-based) conversations between a browser and a web server, especially if there's a firewall in the way.

Update. Note that Google App Engine uses Protocol Buffers internally, to communicate between the application (i.e., your web app) and the App Engine server, and between the App Engine server and the BigTable servers (all internal to Google's private network see? — exactly the use case envisaged in the previous paragraph).

Different attitudes to what immigrants bring with them

Marginally more interesting than usual (which is to say, ever so slightly interesting) post at language log: When two become four on the subject of attmepts to make English the official language of the United States.

On this question I find my feelings ambiguous. When I was young, and interested in everything, especially languages, I considered it a tragedy if someone who grew up in a second-generation immigrant household didn't speak their parents' mother tongue. What a loss! They would never have that as it were stereoscopic vision of things that even a rough and ready biligualism can bring. As someone who won a small proficiency with French the hard way, I thought people who had rejected, or otherwise been denied, the chance to be bilingual were the most pitiable kind of unfortunates.

Now that I'm getting old, and somewhat tired, I like to be able to understand what's being said to me without having to go to too much effort. In sum, I want it to be presented in my native tongue. The people I feel sorry for now are those who've lived all their lives in one place, and find that that one place has become a foreign country, no longer their home.

But enough about the deficiences of my twilight years. What I think is interesting is not just attitudes to the languages that immigrants bring with them, but the wide differences in attitudes to the different things that they bring with them. so for example, I'd characterise anglo-american attitudes broadly thus:

• Food: "Yum! More please!"
• Politics and/or religions: "Please keep it to yourselves."
• Languages: "Hmm. Not for me thank you."
• Money: "You can't use that stuff here."

It's the contrast between the first and the last one that's strongest. Most westerners like to try foreign food, and some cuisines get a really rapturous welcome. Nobody in the West, neither the general population nor the state itself, wants foreigners to try to pay for things in anything other than our own currency. Languages — somewhere in between.

Amateur Economists

Thanks to the Marginal Utility blog, I've found a new site for amateurs of economics at http://www.amateureconomists.com/.

Today my boxroom, tomorrow the world!

A very interesting and not too taxingly written article by two Microsoft researchers on usenix.org: Handling Flash Crowds from your Garage. Takes a look at things like Amazon and Google "compute cloud" services, and presents the authors' experiences with them, drawing some conclusions along the way.

squirrelfish

A new engine for the javascript interpreter in webkit: http://webkit.org/blog/189/announcing-squirrelfish/. Looks interesting, I'd always wanted to have a good root around in the internals of a JS interpreter. Be interesting to compare it to something like parrot - I wasn't very impressed with the tiny bit of parrot that I saw.

Bjarne's C++ FAQ

This one has answers for a few points I'd always sort of wondered about, or sort of known the answer to but wasn't quite sure if I was right. This one is more general but still interesting.

Oh dear, Steve ate it!

Vastly amused by the Steve, Don't Eat It! series, where Steve eats appalling things technically fit for human consumption. Note particularly the first one, and now look here...

Not quite so funny any more. I really don't think Steve should have eaten it.

So long, Flex

Well so much for Flex! I've now spent three or four days looking at it, reading about it, finding my way around the publicly available resources, and I don't like it.

I've had a simple form ready for hooking up for the last three days, and for the last three days it's had the same two problems: controls that were perfectly well aligned before I put them in an accordion or in a tab set become badly aligned when I put them in one, and Flex's HTTPService (their version of an XMLHttpRequest) seems unable to provide credentials to a url protected by basic authentication, even though it has a setCredentials(userid, password) function that looks as though it is supposed to do just that (but rumour has it that it only works when talking to Adobe's own LiveCycle data services).

So that's just not good enough. I can only conclude that people using Flex, who presumably care about things like form layout if they are using a tool that maxes teh pretty, are willing to spend inordinate amounts of time aligning child controls by hand in code (or by setting the parent's layout to Absolute and then moving the children around in the IDE, which amounts to the same thing), and that their RIAs are busily communicating with unsecured web services on the server - or that they've given up trying to make secured communication work on their own, and have stumped up the money for LiveCycle.

Honestly, Java can do that sort of stuff in its sleep. If only it didn't look so bad! Oh well, I'm still not going to go the applet route (hear that, Sun?) so it's back to making the YUI tabs work with my crappy html content, by loading their content via an xmlhttprequest after the page has loaded, rather than by including their content with the page, which somehow buggers the tabbing up.

Web 2.0 RIAs - the brave, new world.

I've spent my free time over the last couple of days looking at Adobe's Flex technology, and the ecosystem surrounding it. I'd always known about Flash of course, and I'd read the occasional article on Flex, Flux, AIR or whatever Adobe is calling it nowadays (they seem to have a really high churn rate on products, or maybe it's just product names). But as a Java guy, I'd never been able to understand what was wrong with the good old applet — perhaps not the very oldest, AWT-based applets, but certainly the (slightly) newer Swing-based JApplets. Sure, the flash-based stuff looked good, but I didn't see anything I couldn't do with Java.

So I was in for a bit of a shock. Java, which let's remember invented the whole idea of sectioning off a rectangle of window and offering it as a UI to a program embedded in the web page, seems to have completely lost the minds and hearts of browser-side developers. Java developers of 10 or more years standing are saying that Flex is the way to go for RIAs (rich internet applications) now.

It seems that after a decade of Java programming, while Sun has more or less abandoned the browser and chased the server, people have finally given up waiting for usable in-browser technology. Sun let themselves be distracted by Microsoft, and failed to see that Adobe was quietly taking their market. Applets still look clunky, they still have funny fonts, they still take forever to load, as the browser has to load and run the complete JRE (at least)... Meanwhile the Flex developers have noted all these failings of Java and quietly ensured that Flash/Flex doesn't suffer from them.

Well the market was Sun's to lose, and they lost it; indeed, they seem not to have cared about it at all. I suppose you could say that Sun was a more server-oriented company, while Macromedia and Adobe were more desktop oriented. But Sun has always made workstations too... It's shocking really: for a fraction of what they must have spent buffing Java for the server, they could have licensed some decent fonts, told a few designers to make the graphics look sleek and sexy, and licensed a decent codec for movies. Instead they jumped aboard an ill-conceived server-side beans bandwagon and ended up producing the J2EE monstrosity — its latest addition, Java Server Faces, piling yet another badly designed, badly implemented and altogether half baked piece of cack on top of all the rest.

(I mustn't go on about JSF, but please, someone tell me, when the entire rest of the industry was conspicuously moving towards client-side processing, with first DHTML and then Ajax, why did Sun adopt a model where even little things like a combo box dropping down its list portion required a complete page refresh from the server? What idiot thought that was a good idea?) ... I'd better rest a while, and wipe some of the froth away from my mouth ... I'll be alright in a moment ...

So, yes, I wasn't prepared for the degree of, frankly, hatred of in-browser Java that I found, even amongst ex Java developers. Like lovers who've been deceived, strung along, and humbled once too often.

But serious questions remain. A long time ago, early on in browser-centric Java, Sun spent a lot of effort on the Java sandbox. A poorish initial implementation gave way to a flexible one with fine-grained permissions, one that eventually most people felt they could trust. I've not done a lot of reading about Flex, but I haven't heard anything about sandboxing. I understand that it does have one, but I haven't heard any discussion about how good it is. And then of course, the entire world + dog moaned at Sun to open source Java, and it's finally done someting about it. Beyond open sourcing the basic flex product, Adobe has kept all the value-add stuff and the flash player itself closed. If Flex/Flash becomes the standard delivery mechanism for RIAs, Adobe will make a lot of money and we'll all wish we had stayed free.

Compute cloud is the end for Microsoft on the server

Every so often I look at Amazon Web Services (AWS), and though the traffic on my web site doesn't justify even their smallest offering, it's still intriguing to think about how this offering will affect other peoples' businesses.

The most obvious is web hosting. There was a time, several years ago, when I thought that the hosting business was dead except for the largest players. Nobody else would be able to achieve the economies of scale necessary to compete. But there are a lot of hosting companies around, of all sizes. Absurdly many of them seem to offer the same combination: Apache, Linux or BSD, and MySQL for if you're really advanced :). It took me a while to find someone that could offer me both Postgresql and Java servlets.

I don't pretend to understand why it is that so many so similar hosting providers can coexist, though I suspect at least some of them are rebranding efforts, reselling services from the bigger boys. Even so, there seems to be money in it.

The latest thing to hit the world of the smaller hosting provider, at least as far as the somewhat glacial state of affairs at gedsguides is concerned, is virtual hosting. That's actually been around for some years, but about a year ago everyone started to offer it, as the virtualisation products matured (and, I suppose, as the open source ones became viable). Gedsguides.com will be moving from a simple hosting account to a real virtual server just as soon as I can be bothered to do it.

With a virtual server though, the competitive landscape changes. The model now is that you get administrator access to your own Linux server, and though it may well have the usual trio of Apache, PHP and MySQL installed on it as standard, you can install pretty much anything you want on it. Suddenly I don't have to go to California to find a hosting provider that supports the software I want to use. With virtual server products in other words, hosting providers are differentiated less by the software you can use for your web site and more by their pricing, reliability, knowledge and support.

And that's it, up to the limits of a single physical machine. But supposing, just supposing, gedsguides.com became wildly successful, on the order of a wowwiki or a thottbot. Would I order a second, a third, a fourth machine at my current hosting provider? Would they be interested in supporting a distributed database, a distributed application server, a distributed file system? What sort of support could they provide? And I would be sure to need to acquire a new set of programming skills for such a distributed, failover-prone world.

Much more likely, assuming the site was showing a profit, I'd finally bite the bullet and move everything to Amazon Web Services, where new servers and new storage are available at the drop of a hat; where the failure of a single box would be invisible to me, as it would be swapped out and another one prepped and swapped in in minutes.

So AWS stands to take the high end from the current crop of hosting providers. And because each AWS server is just another virtual server as far as the user is concerned, there's no worrying about whether it will provide the right software environment. You just package your website software up into an installable binary, and it gets distributed as necessary across machines.

Of course, there's no reason (other perhaps than using http as a data transfer mechanism) why only web sites and web applications should be using AWS. Sun has recently been talking about eating its own dog food by moving its in-house IT to its compute grid (Sun's version of AWS). I'm sure the idea will catch on, even if Sun fails there will be others who succeed.

For the purposes of a thought experiment, let's take this idea to its logical, if absurd conclusion. Let's say Amazon, Sun, Google and Microsoft all enter this market (Amazon and Sun are already in it, Google and Microsoft are rumoured to want to enter it). And then let's say that everybody — all businesses that is — rather than starting up their own IT and support department simply buy services from them. So, no server software sold to businesses any more, just billing for the computation done and storage used. Sure, some of this billing would cover the cost of server software, but in the form of capabilities available to your applications.

Now look at what software everyone would be using. For Amazon and Google it would be Linux (maybe BSD too?) and a software stack that runs on top of that, almost all of it open sourced. For Sun it would be Solaris, also open source and, if not blessed with developers to the same extent as the Linux world, at least largely compatible with it due to their shared *nix heritage, and able to incorporate any advances made in the Linux world fairly easily and quickly. Not so Microsoft. Microsoft would be the odd man out, using proprietary software all the way from Windows at the bottom to IIS and SQL Server in the middle to whatever in-house developed accounts, CRM, content-management etc. solutions they chose to supply at the top.

Microsoft suddenly looks awfully lonely there. What used to be a competitive advantage — user lock-in — suddenly becomes a liability: they are the ones locked in! They will have to do a lot of running to stay abreast of their competition. Nobody will be using their server software except them. They'll major on ease of use of course. Since everything is developed in-house, there is the potential for all the bits to fit together much more smoothly than with their competitors. Well, they'd better start coding all that now then, because that scenario is at least a couple of complete rewrites away. Vista, anybody?

The thing is, if you're providing a compute cloud environment to users, you need to provide either best of breed or cheapest (or a choice) at every level of the stack. For sure, Microsoft will be providing Windows at the bottom, but will they permit you to use alternatives to IIS and SQL Server in the middle? They could, but it would hurt their pride an awful lot. And what about areas where their offerings are complete also-rans? Who uses Microsoft Content Management Server anyway? Everyone uses Documentum. If you wanted to move your content management needs to the MS compute cloud, could you use Documentum or would they shove Content Management Server down your throat? It's easy to see that in the compute cloud scenario, Microsoft's less competitive offerings would be witheringly exposed.

Of course, such a massive and complete move away from in house IT to compute cloud IT may not ever happen. But something along those lines will, I think; the question is how far it will go, and how quickly. To the degree it does, Microsoft's ecosystem will shrink, its ability to compete on all fronts will be reduced, and its ability to be the first and the biggest, and to impose its standards, will diminish.

Oh, and if I was Documentum? Or SAP or Sage? I'd be talking to Amazon really nicely, right about now.

Nokia buys Trolltech

For 105 million euros, apparently.

The main interest is presumably Trolltech's Qtopia, but hopefully it's also good news for their Qt product (Qtopia is based on Qt) and KDE (a community-developed free software desktop also based on Qt) as well. I'd expect Nokia to be able to make a better fist of KDE than Sun has with Gnome, should they choose to do so.

Perhaps it wouldn't be altogether too fanciful to see this as Nokia's answer to Google's Android. It's interesting that Google Earth is said to be written in Qt — I wonder if there's any Trolltech technology in Android at all?

Trolltech's stock price shows something typical for a new technology company: a nice, steady decline from its initial IPO after a (very) brief burst of enthusiasm in the hours immediately following it, and reaching some kind of support level at about May 2007. There was still a slight decline going on even after this, so I doubt I'd have picked it. I wonder if there's now going to be a burst of purchases in this sector?

Pat Robertson on why the sky is blue

A morning surf brought me to Phil Karn's site, wherein he hat tips James Randi for this quote from the ever-amazing Pat Robertson, explaining why the sky is blue:

I think the sky is blue because it's a shift from black through purple to blue, and it has to do with where the light is. You know, the farther we get into darkness, and there's a shifting of color of light into the blueness, and I think as you go farther and farther away from the reflected light we have from the sun or the light that's bouncing off this earth, uh, the darker it gets . . . I think if you look at the color scale, you start at black, move it through purple, move it on out, it's the shifting of color. We mentioned before about the stars singing, and that's one of the effects of the shifting of colors.

The thing is, even if by some extreme chance everything else Robertson believes were completely true, I still wouldn't expect him to be able to articulate his beliefs faithfully, based on that example.

Android

If Android does well in the mobile phone arena then it will pretty soon move to set-top boxes and, eventually, perhaps even as a native OS on a PC near you.

I've been looking a little bit at Google's Android OS for mobile phones. It seems to use a Be-developed technology called OpenBinder that puts a rich object layer between the kernel and the applications (including the OS-level applications themselves). OpenBinder handles threading and IPC too, and seems to make it natural to use a multithreaded approach to the UI - something you're explicity told *not* to do in the less-capable UI development environments that I'm used to.

Just read this fascinating interview (with Dianne Hackborn, a key engineer in the creation of PalmOS Cobalt) for much more about OpenBinder — a name that I think we're all going to hear more often in the next few years.

One of the most intriguing paragraphs in the article is where Dianne states that OpenBinder lets "an application ... put parts of itself it may not trust (a web browser UI, video player, etc.) into a separate process without any visible difference seen by the user". Now let's think... Who might want to be able to have applications distributed between your mobile phone and its own hyperfarm of servers... Why, Google might! If you think of the way Google's been going with online disk space and online apps for your browser, it's not so far fetched to think that one day soon those browser apps might just be front ends for OpenBinder objects running natively on their server farms, and that you'll also be able to access them from your mobile phone — not just from your mobile phone's browser but from its native applications too.

Dianne states in the interview that the Be engineers hadn't yet network-enabled OpenBinder. I presume Google have rectified that situation. Hmm, I would dearly love to know if perhaps OpenBinder forms part of the heavily-modified Linux distribution that they are supposed to run internally. It may be one of their secret weapons against Microsoft: a better .Net than .Net...

I also wonder if the use of OpenBinder is linked to the "All applications are equal" philosphy that developers were shaking their heads over when the Android SDK first came out.

And then, and then... If Google know where your phone is, they also know who else is nearby, and applications could potentially distribute themselves over a nearby mesh of mobile phones. Great for games and business cards, less good for your medical records.

It also becomes apparent that the mobile phone "emulator" in the Android SDK could turn out to be a Trojan horse against Microsoft. There's nothing that limits OpenBinder to a quarter-vga screen. I doubt there's any hard limit in the rest of the Android SDK either. So, what if some genius hacker changes it to a 1280 x 1024 display? Suddenly you've got a VM and a UI as good as anything in Java or Flash/Flex running full screen on your PC, with network communication and distributed execution built in.

If you read to the bottom of the article linked above, you'll see that Dianne went on to work at ... Google. Hmm. We're used to thinking of Microsoft as the ocean, isolating and gradually drowning out everyone else. Suddenly they look as though the water is rising on them. There are already more mobile phones than PCs; if Android does well in the mobile phone arena then it will pretty soon move to set-top boxes and, eventually, perhaps even become the native OS on a PC near you.