But none of their methodology actually stands up to any scrutiny (never mind their numbers). Their argument is that feeding a dog (as measured in calories) requires more hectares of land to sustain than an SUV (as measured in joules). By looking at the amount of land theoretically required to produce x calories of food and comparing that to the amount of land to theoretically produce y joules of energy, they arrive at a ratio. Simple enough?

The basic problem is that oversimplified theory and practice don't agree. First, most dogs' diets consist almost entirely of food that would otherwise be waste product, as it's not fit for human consumption. So taking a measure for land productivity for human food production and using that as a proxy for a dog's eco-footprint is basically meaningless. Their actual food impact is so small it's hard to measure. Also note that dogs are "built" from renewable materials with very low upfront energy costs.

In contrast, SUVs aren't built from renewable materials and don't run on renewable fuels so their footprint can't be measured. There are no solar-powered SUVs and the energy efficiency of biodiesel is extremely low (and thought to be negative in many cases). And if we started running all the SUVs in the world on today's biodiesel, there would be no land left to grow food (there are already food riots being caused by ethanol demand). So the effective eco-footprint of an SUV is tremendously higher than the theoretical fraction of a hectares per year they quote.

Compare these two meaningless numbers and you get a result that is orders of magnitude out of touch with reality. If your instinct tells you that a 15kg dog chasing a ball around the yard and basking in the sun uses less of the world's resources than an 2500kg SUV roaring down a freeway or sitting in traffic, you're right.

The relicensing process is mostly about having all our ducks in a row to make distributors and co-developers happy. We're 98% done, but the end game is hard due to people that can't be located. I expect we'll have this wrapped up in time for the 1.5 release on March 1st.

The best way to help make the 1.4 release a success is of course to run the latest development version from the main repository and report any problems you encounter. There are also nightly builds available for Windows users. We generally keep our development tip end-user ready at all times (and do all our own day to day work with it), so testing tip is pretty safe.

A lot of the work that I hoped would happen for 1.4 didn't get done, but we've been getting a steady stream of nice usability improvements. The one I'm most excited about is the new summary command, which combines the output of a bunch of commands in one place, giving you a quick view of what's going on in your repo:

$ hg sum --remote
parent: 9665:1de5ebfa5585 tip
 walkchangerevs: drop ui arg
branch: default
commit: 15 unknown (clean)
update: (current)
remote: 1 or more incoming

First off, note that there are hundreds, probably thousands of technical domains where the kilo prefix means 1000. Even in the domain of computer science, it is usually assumed to mean 1000. Consider: megahertz, kilobaud, gigabit, megapixel, MIPS, gigaflops. In fact, the only place where power of two nomenclature can be taken for granted is in the size of memory devices, where the wiring of address lines dictate that only powers of two are possible. Claiming that disk sizes should be measured the same as RAM is invoking a false consistency: RAM is the odd one out and always has been.

Further, there's essentially no reason for anyone but electrical engineers and kernel developers directly concerned with the geometry of RAM to have any exposure to the powers of two issue at all. No one writing a web app should care, no one writing a word processor should care, and certainly no one using a word processor should have to care. For the vast majority of computer users there is no upside to measuring things in units of 1024, only confusion.

In the future, we're going to have to find a way to get more real users on big projects to test pre-release code, which means: easily available nightly builds.

Exciting things in the queue for 1.4 including an improved wire protocol and possibly a new hashing algorithm. And hopefully support for a couple non-native subrepository types.

He was a researcher for many decades at Bell Labs. He was intimately involved with the Apollo program, not to mention countless other efforts ranging from sonar to the invention of videoconferencing. He was there for the invention of the transistor.

He was colorblind (a trait he passed to me), but memorized the colorblindness eye charts in attempt to qualify for the astronaut program. He taught me the names of the constellations. And he took me to see Star Wars in the theater.

He also introduced me to Unix via a home-built VT52 terminal that dialed into a server at Bell Labs, the birthplace of Unix. I spent countless hours exploring; I retrieved the Amulet of Yendor at age 7. Not long after that, he sent me a first edition copy of The C Programming Language, also created by his coworkers. I quickly read it cover to cover, despite having no access to a C compiler. Thirty years later, I'm hacking the Linux kernel in C.

I saw him for the last time a couple weeks ago. I showed him the bash shell prompt on my GPhone, a machine thousands of times more capable and portable than the machines he introduced me to, and running a version of Unix I'd helped develop.

The founder of that company was Steve Case, a professor of optics turned entrepreneur. Today I learned he died in a solo plane crash. He was a good guy.

Also, Mercurial now has support for subrepositories which is a way to automatically pull other projects such as libraries into your working directory as part of a larger project. Commits made at the top level repository will recursively record the state of the subrepos, effectively allowing atomic commits across multiple projects.

I've also managed to design the code in such a way that it should be quite easy to extend this to support subrepositories from other systems like SVN or git.

And today I hear Google is adding Mercurial support to Google Code. They've apparently implemented a Mercurial storage backend based on BigTable to take advantage of their cluster infrastructure.

Many years passed without me thinking much about the Cube until I read a paper about computerized searches to find the minimum number of moves to solve the cube. Not long after, I discovered the Mirror Cube and the Void Cube and that reawakened some toy lust a mild obsession with actually properly solving the Cube from scratch.

And late last night, I happened upon a classic Cube at the local pharmacy.

Here's roughly how I went about solving the cube:

• Solve the top layer (~1 minute)
• Solve the middle layer (~5 minutes)
• Solve the bottom layer (~3 hours)

The bottom layer is obviously the hard part. My strategy was to find various patterns of moves that scrambled the bottom while keeping the top layers intact and figure out how to do useful things with them. These aren't too tricky to find, but making sense of them is.

This part pretty much requires paper. First, write down a series of moves in a useful notation (eg F' for turn front face counter-clockwise). Then record the pattern of cubes on the bottom before and after applying the sequence. Now it's possible to work out what the combination of moves is doing in the abstract. For instance, this sequence flips the north and west edges, rotates the northwest and southeast corners clockwise, and the southwest corner counter-clockwise.

The things that can be wrong with the last face include: edges rotated, edges out of position, corners rotated, and corners out of position. Most of the simple patterns will change all of these at once. But combining sequences (and their mirror images) will let you cancel out some the unwanted changes in each sequence to narrow in on the solution.

That's one childhood dream down, now to become a writer and an astronaut.

On the upside, this means we'll get to start using a small handful of nice features added in Python 2.4. Namely decorators, sorted(), and generator expressions.

A quick aside about Linux and Youtube: I've had mixed results with swfdec for in-browser viewing, so I often use clive to download videos and view them outside my browser (and nicely buffered). I find "xsel | clive" is quite handy to grab a link I've copied to the clipboard.

The Mario Kartel is pleased to announce Puzzle Quest 4: Your Princess Is In Another Castle.

A typical votive candle is about 2 ounces of paraffin and burns for about 15 hours. Its brightness is approximately 1 candela or 12 lumens and consumes power (in the form of paraffin fuel) at a rate of about 40W. That's one or two (or 15!) laptops' worth of power per candle.

Paraffin (like most fuels) is nearly all carbon by weight and when burned it generates more than its weight in carbon dioxide (12 atomic units of carbon from the candle + 32 atomic units of oxygen from the air per CO2 molecule). About .2kg total or about 13g per hour. Not much, but put a couple dozen of these out every night for a year, and you're beginning to talk about a substantial amount of carbon.

Now let's compare this to a 14W compact fluorescent bulb (as bright as a 75W conventional bulb). This generates about 840 lumens of light. That's equivalent to 70 candles. If we hooked this up to a dirty old coal-fired power plant (generating 1050g of CO2 per kWh), we'd generate about 14.7g of CO2 per hour - almost the same as our candle! If instead we used wind power (readily available in Minnesota) and include the amortized impact of building the wind turbines (something like 22g/kWh worst case), that drops to less than .3 grams per hour.

In other words, the global warming impact of candles is on the order of 60 to way more than 3000 times worse than fluorescent lighting for the same amount of light.

This doesn't consider heat though. In the winter, a candle is quite an efficient heat source as almost all of its energy is converted to heat. So we end up with 13g of CO2 per hour per candle to get 40 watts of heat. That same heat from an electric heater powered by our coal worst-case would result in 42 grams of CO2/hour. But with wind power, it'd be less than 1 gram of CO2 per hour in the worst case.

In the summer, there's no upside: candle heat battles against air conditioning. A single candle produces enough heat to cancel out more than 1% of a so-called "ton" of refrigeration (12000 BTUs / hour).

Lastly, we should look at production cost and impact. Light bulbs of any variety almost certainly win, simply because they have lifespans of thousands of hours and are so much brighter. It would take something like 45000 candles to match both the brightness and lifespan of our typical CFL bulb.

So wish for a greener tomorrow and blow out those candles.

Not electronics, but another thing I've been experimenting with. This is a granola recipe reduced to its bare minimum for ease of preparation.

Preheat oven to 200°F
In a large pot, mix 1/4 cup each of sugar, cooking oil and maple syrup
Add 1/2tsp salt (optional)
Heat on stove until bubbly
Reduce heat and fold in 4 cups rolled oats
Place pot in oven for 1 hour

If you're the type of person who likes to ruin things with raisins (and we are, but we ate them already), add 1/2 cup of 'em when you're finished.