Socks and Sandals

In case anyone is interested, the answer to the Google Treasure Hunt 2008 robot path question is as follows:

For a board of size RxC, where R is the number of rows and C is the number of columns and P is the number of distinct paths the robot could take, we find that:

By the way, this particular question has little to do with networking or computer science and nothing at all to do with low-level UNIX trivia. Wonder if the subsequent questions will be more pertinent.

Stop me if you’ve heard this one: a “semi-stealth” startup spends 2.5 years, hires ~200 people and gives them all new MacBook Pros, takes untold millions in multiple rounds of VC funding, makes a bunch of noise about being the next generation of search and then launches with a search engine that basically re-indexes Wikipedia and not much else. ROFLOL, right?

Not if you’re Powerset its not. This is exactly what they’ve done.

As far as I can tell, their burn rate can’t be any less than ~$21MM/year. This is counting 200 people at an average $100K/year salary and 1,000 small EC2 instances for a year. I’m pretty sure they are using more EC2 instances and lots of their people are making more than $100K/yr in downtown San Francisco, but I’m being conservative here. This doesn’t seem that bad until you realize that their revenue is $0/forever thus far. Conservatively, they’ve probably burned $40MM already building the product as it currently stands. Geez, that’s a lot. Google got something useful up and running for $100K.

And where is that product? Discussing it on Twitter today, my boy Cliff Moon (a Powerset engineer), sent me a link to show how good the results were. Here is that link:

http://skitch.com/moonpolysoft/mjx5/who-shot-the-man-who-shot-jfk-powerset

That’s a pretty awesome result, I have to admit. Direct and to the point and right with the info you’d need to win that bar bet. However, I replied back with this link, pertinent to some work I’m doing currently (and something that Wikipedia definitely has an article on):

http://www.powerset.com/explore/pset?q=mondrian+database&x=0&y=0

Not so much.

Now, this little exchange proves nothing. The real thing that struck me was that every result I searched for was basically a re-ambiguated list of Wikipedia results. Powerset claims to be using Wikipedia and Freebase as its base data for now so that makes some sense. However, I took a look at Freebase and it appears that most of Freebase is Wikipedia data, too! Thus, one could (semi)facetiously claim that the powerset of Powerset is {Wikipedia}. This is not great for them. I don’t really switch search engines for this little incentive. Why would I want to use Powerset when Wikipedia already has its own search engine? If that fails I can always hit Google and pare down the results to wikipedia.org, which I’m sure is what a lot of power-Wikipedia users already do.

The larger question is whether or not people would switch to Powerset. If it were an order of magnitude better, yeah, I think they would. However, the Powerset I’m seeing is nowhere near as robust or helpful as Google is today and those guys aren’t exactly standing still over there in Mountain View.

As well, I would question whether or not the question-based interface is as useful for everyday searching as the keyword-based interface of the current crop of search engines. Perhaps I’m just ingrained to that method by now, but the question-based interface seems clunkier and is definitely slower and less flexible than the keyword-based interface. There’s just more ways to query an engine based on a set of keywords than there is if you have to formulate a question to do the same job. I can see how a question-based interface would be superior in certain cases, but in general? Doesn’t seem so to me.

On the advertiser side, the question-based interface brings problems there, too. Today’s search engines allow engines to buy keywords in conjunction with the ads they want to display when said keywords are queried. How is Powerset to build a CPC engine on top of a question-based engine? Are advertisers expected to have to guess at the questions Powerset’s searchers are likely to query? That seems to me to be an order of magnitude more difficult than today’s keyword-guessing-game, which is already hard enough for the advertisers as it is.

Most of the “questions” I ask to search engines don’t have one paragraph answers. When I’m researching, I want to quickly skim a bunch of sites that relate to my general query topic and then get down deeper and deeper as I learn more. Only once I’ve done that might I have some “questions” that I could properly formulate for consumption by Powerset. Am I to assume that Powerset would have me use Google or MSN for the first 80% or more of my researching? I hope that’s not their goal or their VCs are taking an acid bath right now.

I can’t remember being this underwhelmed from such an overhyped product before. Powerset really let me down. If this is the next generation of search, I’m sticking with the current generation, thank you very much. As the eminent Internet sage Ted Dziuba would say: FAIL. Google’s probably throwing a victory party in the volleyball courts right now. I really hope that Powerset gets its act together and makes me look like an idiot for posting this, but after today, its looking to me like that will be a very tough proposition, indeed.

I was thinking about AppEngine some more today and it occurred to me that not only could AppEngine be responsible for a lot of people learning/using Python, but it very well might be Python’s answer to Rails. Its so-called “killer app”, if you will.

Up until this point, Python has been plagued with multiple, competing Web frameworks all taking some mindshare and there really hasn’t been a strong rallying point in the Python Web community like Rails. It appears that Django has been winning out in the blogosphere lately, but its nothing like Rails’ devout following in Ruby-land.

However, with AppEngine, Google does Rails one better: instead of just making it easy to code your app, they make it just as easy as Rails to code and dirt simple to deploy and reduce the operation maintenance to near zero. The need for things like ActiveRecord and migrations is pretty reduced in the AppEngine environment, as is all but a tiny knowledge of SQL (called GQL in that realm). That’s really, really attractive if you’re a Web consultancy shop that’s looking to turn over clients as fast as possible or a side project with a mandate for speed, quality and low cost. To me, that seems like it would be worth learning a little Python for.

AppEngine is pretty clearly aimed at Facebook’s F8 platform but it could end up hitting Python with a major boost in popularity as an aside. I bet Guido is smiling all the way to the bank on this one…

I just read a little bit about the recent announcement of Google AppEngine and I think its a pretty good service overall for certain kinds of Web applications. Unlike the rumors that were floating about prior to its announcement, its not a competitor to AWS directly, nor even a competitor to Ning as some have also claimed. To me, it seems more directly in competition with Heroku if such a thing could even be said. It is clearly based on Bigtable, though, so that part of the rumor appears to have been true.

Being so simple has some advantages and presents some interesting constraints. Because you don’t have root and can’t run the “box” yourself, you’re forced to think simply about the app itself. This seems as if it would be quite a welcome constraint for a lot of Web developers who don’t care about running a network. But the constraint really serves to enable Google-style scalability at its heart. As well, the use of CGI allows Google to run your code wherever they deem it best at the moment underneath, without you having to care about that sort of thing. This is something they already do quite well.

As well, the lack of a traditional RDBMS is something that obviously works well in a shared-nothing environment and makes a lot of sense since Google’s infrastructure is already based on such. This gives real credence to the idea that the RDBMS isn’t the be-all-end-all and will introduce a lot of developers out there to this new way of thinking.

A few things I don’t like:

• Users of an AppEngine app must login with Google Accounts
• You do have to upload your Python source to Google and this leads to obvious privacy and IP concerns
• No recurring job scheduling (essential for lots of different kinds of apps)

One more obvious thing is that an application built on AppEngine is one that is much, much easier for Google to acquire than one that is not. Don’t underestimate that piece of it, as its likely this service will be a loss-leader for Google.

Finally, I think this announcement will be very good for Python. As AppEngine only supports Python right now and for the foreseeable future, anyone interested in AppEngine will have to learn some Python. This will shed some more light on Python for people who might not have otherwise given it a try.

UPDATE: Apparently, others agree about the acquisition potential of apps on AppEngine. Good stuff.

I’ve been noticing a bunch of references lately attributing projects on Google Code to Google itself. Google Code does indeed house a bunch of open source projects from Google itself, but it now also houses lots more projects from random developers across the Web. Think of it as Google’s personal SourceForge.

So remember: just because you see it on Google Code doesn’t mean someone at Google was responsible for it.

This is not a knock on Google Code, of course. I have two projects up there and I like it so far.

This interview with Peter Norvig reveals the real reason that Google built and deployed 1-800-GOOG-411. Hint: its all about increasing relevance (and thus monetization through ads) of that $1.65 billion purchase they made a little while ago.

I’m here at WWW2007 and so far its been really good. Here are some of the better papers I’ve seen so far:

Google News Personalization: Scalable Online Collaborative Filtering

Navigation Aided Retrieval

I wanted to see these, but missed them:

Visibly Pushdown Automata for Streaming XML

CSurf: A Context-Driven Non-Visual Web-Browser

The hallway and evening beer conversations have been really great, as well. And, of course, the view’s not bad, either ;-) I can’t send the pics from my phone while I’m here in Canada, but I will post some when I get back.

Wow, Sun is really hitting on all cylinders lately. Project Blackbox is an especially neat idea of putting a datacenter-sized array of boxes inside a portable box (in relative terms). I remember that Cringley was going off about Google building things like this for themself a while ago, but I never heard anything more about it. Now, anyone can grab one ;-) Man, they look good, too.

Google published a paper on their Chubby lock manager service in preparation for OSDI ‘06. The most interesting thing about this paper is the Paxos algorithm for distributed consensus. I do agree with Greg Linden, in that the tone of the paper is somewhat derogatory towards other Google programmers. Perhaps this is an indication of the culture loss that comes when you grow too large, too fast?

UPDATE: I saw the presentation of this paper live at OSDI 2006. Turns out that Mike Burrows is British and the tone of the paper was just some self-deprecating British humour for us ;)

Google just posted a paper about BigTable in advance of the OSDI 2006 conference where they will be presenting on the topic. This fills out a lot of information for me that I hadn’t known at the time I did my Google Internals talk at PLUG last month. Definitely check it out if you want to read about a pretty cool distributed database system.