A simple — and importantly, public — interest metric that I’ve enjoyed in the past is Google Trends, and in particular, building a comparison between the major distros. It gives you a nice feel for the history of Ubuntu releases, press coverage and growing interest in the platform.

In terms of past performance, 7.10 and 9.10 have enjoyed the biggest spikes (against background noise of the time), while 8.04 LTS and 9.10 look pretty even as the highest peaks. It’s encouraging to see that 9.10 did so well.

But I wonder… how “big” will the 10.04 LTS release be? How much interest will it generate? How will the search and news spikes compare to previous releases?

Canonical has every reason to roll out the red carpet for this release, making a big deal of the release itself (Long Term Support, headline features, new theme and branding), launching new services (such as Ubuntu Enterprise Cloud support and the Ubuntu One music store), complementary announcements from partners, etc.

So… How big do you think the 10.04 LTS spike will be? Lay your bets in the comments. Just name a multiplier against the 7.04 spike — sitting at an even 2.0 on the search volume chart above — and by July we’ll see who nailed it!

Update: Fixed the Red Hat chart, thanks to David in the comments.

* They’re doing stupid shit with GNOME again, but they’ll grow out of the “differentiation means dicking with everything”, “design by finger-painting fiat” and “working with upstream is hard, let’s go shopping” stuff eventually. If Red Hat can see the light, surely Canonical can.

That’s what I would describe as “the hopes and dreams of a generation” (of Software Freedom lovers), and is the result of fantastic product definition, branding, genuine user excitement, years of incredible — and largely unsung — work of thousands of Debian developers (not to mention all the upstreams)… and a pretty substantial X factor.

Update: Whenever I talk about this chart in presentations, I always follow up with another chart which puts that incredible rising line in context: Ubuntu vs. Firefox. Interestingly, that chart is looking far less impressive today than it was last year. Which is great news… The rise and rise of Ubuntu is catching up to the star power of Firefox! Wow!

I suppose the obvious starting point would be…

apt-get install approx

… and that’s almost all there is to it, but let’s fancy it up a bit.

In /etc/approx/approx.conf:

# use my ISP's ubuntu mirror for most packages
# use central mirrors for security, partner and ports
ubuntu     http://mirror.internode.on.net/pub/ubuntu/ubuntu
secure     http://security.ubuntu.com/ubuntu
partner    http://archive.canonical.com/ubuntu
ports      http://ports.ubuntu.com/ubuntu-ports
medibuntu  http://packages.medibuntu.org

# you can cache PPA packages too, see the sources.list example below
ppa        http://ppa.launchpad.net

# ISP's debian mirror, particularly handy for getting sources
debian     http://mirror.internode.on.net/pub/debian

Demonstrative examples from /etc/apt/sources.list:

# get most packages from my ISP
deb http://approx:9999/ubuntu jaunty main restricted universe

# get security packages from my ISP *or* central
deb http://approx:9999/ubuntu jaunty-security main restricted universe
deb http://approx:9999/secure jaunty-security main restricted universe

# partner and medibuntu packages for naughty stuff we need
deb http://approx:9999/partner jaunty partner
deb http://approx:9999/medibuntu jaunty free non-free

# use generic PPA repository to support arbitrary PPAs!
deb http://approx:9999/ppa/jdub/ppa/ubuntu jaunty main
deb http://approx:9999/ppa/gwibber-team/ubuntu intrepid main

Now you can configure all of your Ubuntu (or Debian) machines to grab their package lists and packages from your approx cache. No more wasted bandwidth when you’re updating, and no more wasted time when you’re stuck watching an update — this is particularly awesome for autmated installs, of course!

Other handy tidbits:

• You can use the cache to share source packages too — just change ‘deb’ to ‘deb-src’ at the beginning of the line, as usual.
• approx comes with daily and weekly cronjobs to keep your cache tidy.
• If you have a bunch of packages lying around in /var/cache/apt/archives which could be put to good use in your approx cache, just use approx-import. Very sweet.

Gosh I’m happy that someone has finally nailed this… I’m pretty sure I’ve tried every attempt to implement a dynamic apt proxy/cache that ever was. Interestingly, approx is yet another OCaml success story. Cool.

Enjoy!

I’ve never understood the ${ubuntu_release}-updates thing.

A separate repositry for security I understand due to the need to bypass mirror lag.

But anything worthy of going into ${ubuntu_release}-updates is surely worth putting straight into ${ubuntu_release} ? Or is it just me?

Post-release, that archive is never touched. It means that users get to choose how much damage they’re willing to accept:

• $release: Don’t touch it, I like consistency, even with my bugs.
• $release-security: I’ll accept patches to existing versions (and very rare version upgrades if absolutely necessary) in the process of keeping my system secure.
• $release-updates: Okay, some bugs are worth fixing, and I trust you this much (holds up two fingers like Maxwell Smart).
• $release-backports: I have something akin to technology ADHD, needing the latest of everything I can possibly get, but I’m a sooky little wuss-fart because I can’t handle running the development branch.
• $devel: I can take it. Seriously. If you break my X, I shall become more powerful than you could possibly imagine. I’ll file and maybe even fix the bugs and I’ll do it even if power management is not so much ‘managed’ as vomited all over the wall. Come get some.
• Debian: We do the work so you don’t have to.

Amazingly, a number of followups suggest that this summary should form some kind of official description on the Ubuntu Wiki or similar. I’m sure someone in Ubuntu land will be keen to… revise some of my verbiage… should they choose to use it.

The variation is not quite large enough to make any serious judgements about the impact of Ubuntu, but the spike in 2004 has a certain whiff of intrigue about it. Perhaps that’s just me.

Of course, I soon wondered what GNOME’s yearly bug submission count looked like. Based on a very simple query against the creation date of all bugs in the database, we get…

2008 … 1554
2007 … 115178
2006 … 66011
2005 … 37838
2004 … 39927
2003 … 36432
2002 … 44130
2001 … 33426
2000 … 12362

Keeping in mind that it’s usually fairly quiet at the beginning of the year, the progress so far in 2008 puts us closer to the 2006 total than 2007′s mammoth results… I wonder if there’s a systemic reason for the massive spike? Perhaps one of the bugsquad folks can provide some insight in the comments.

Meanwhile, something (buggy?) must in the water, because almost as soon as I mentioned the numbers, someone on IRC pointed out Andre Klapper’s timely and informative annual Bugzilla statistics post, based on the output of Olav Vitter’s analysis scripts.

Rock on!