Chrome Beta for Android, first impressions

So Google published a beta of Chrome for Android.  It's only available for Android 4.0 "Ice Cream Sandwich", which caused many complaints.  I find this somewhat understandable because Chrome uses fancy graphics, e.g. for the interface of changing between multiple tabs.  What I have a harder time understanding is why they restricted it to a handful of countries in Android Market.  Fortunately the comments on a Google+ post contain hints on how this can be circumvented - thanks, +AJ Stang!
First impressions from using this for a few minutes on a Nexus S: The multiple-tabs feature seems very powerful, and the UI for changing between them seems to work really well on a small mobile device.  Being able to use the Chrome development tools (profiler, DOM inspector etc.) over USB is also quite cool.  It does seem a little slower than the standard Web browser in Android though.  As a heroic experiment on myself I'm making this my default browser for now.

The inexorable growth of bandwidth, or lack thereof

I moved offices recently, so I threw away some old posters.  One of them was an old map of the GÉANT backbone.  On a first look, I was wondering how old it was - the main backbone links were all 10Gb/s, much like today (a few links have been updated to 2-3*10Gb/s or 40Gb/s last year).  To my surprise, the poster was from 2001.  So for ten of the last eleven years, the standard backbone link capacity for large research backbones has stagnated at 10 Gb/s.  (I know other things have changed... these things have become more "hybrid" and stuff.)
In a similar vein, the standard network interface for a standard 1RU or 2RU rackmount server has been Gigabit Ethernet (1Gb/s) in 2001, and it is still GigE in 2012 - although servers generally have at least two and commonly four of them.  You can get servers with 10GE interfaces, but this is not the norm.
The main reason is probably that the upgrades to 10Gb/s or GigE in 2001 were "too early", or based on too optimistic assumptions of future growth.  Anybody remember Sidgmore's law?
But I think that demand has eventually caught up, and that we're on the brink of moving beyond these steps.  For servers, it seems clear that GigE will be replaced by 10GE.  For this to happen, it needs to be on the motherboard, and probably in the twisted-pair variety.  For backbones, the preferred option in most circles seems to be to move to 100GE.  Personally I think that 40GE or even 10GE, in connection with link bundling (as is already done in the commercial world) could be interesting alternative options, also for research networks.

Traceroute puzzle

Which ISPs appear in the following traceroute, and where do they interconnect?

  1 swiCE3-10GE-1-4.switch.ch (130.59.36.210) 0 msec # local AS: 559
  2 bb1.tor.primus.ca (195.69.145.154) [AS 3549] 108 msec
  3 216.254.129.3 (216.254.129.3) [AS 6407] 108 msec
  4 www.primus.ca (216.254.141.10) [AS 6407] 104 msec

This Blog now speaks IPv6

Google just posted an announcement on Google App Engine Blog: App Engine and IPv6, Round 2. This announces that ghs.google.com now has an IPv6 address, although, as with many other Google hostnames, the IPv6 address is only visible if your organisation or ISP has been "whitelisted" for IPv6/AAAA records in Google's DNS.

In addition, Google have added an alternate name, ghs46.google.com, that announces both traditional IP (IPv4) and IPv6 addresses even for non-whitelisted users. This allows users of Google Apps to "opt-in" to IPv6. One example where you can do this is if you have your blog hosted on Blogger, but use your own domain name - like this blog. I have already changed blog.simon.leinen.ch to point to ghs46, so if you have IPv6 connectivity, you might already have loaded this blog post over IPv6.

GCJ 2010: Load Testing in Common Lisp (wrong)

I thought a little about this problem, and then had the idea that the optimal strategy would be to do a binary search between L and P in log-C space. So the required number of tries would be

(defun min-tests (l p c)
  (max 0 (ceiling (log (- (log p c) (log l c)) 2))))

This gave the correct results for the tiny input set on the problem description page, but unfortunately failed on even the small competition set. At this point I gave up and passed on to C (Making Chess Boards), which was more fun anyway.

Later I noticed that someone else solved the small set in Lisp in an identical way, except they computed the log-C distance differenty:

(defun min-tests (l p c)
  (max 0 (ceiling (log (log )/ p l) c) 2))))

With this modification, my code successfully solved the small practice set! Just shows that floating-point arithmetic should never be trusted.

Unfortunately this fails on the large input set, probably because the approach is too simplistic.