Or 640x400, at the rate that laptop resolution is going.

Well, let's see: 640x480, 16bpp = 614 400 bytes of RAM 1680x1050, 32bpp = 7 056 000 bytes of RAM That's over a tenfold increase, not counting newer OSes which that spec usually does. Also don't forget music. The Worms CD games I have had 500MB of audio tracks on them - are you counting that?

GTK as a library is big, but not horribly big. If you aren't too tight on disk space or RAM, using a theme available for both (i.e. Oxygen) works well enough for me.

My bag of photodiodes counts, doesn't it? They are basically 1-pixel cameras.

On eInk based readers, it's actually harder than that. How many times do you flip the page in an hour? The number of pageflips per charge seems like a better metric.

You do realize that your car is already driven by a computer? That there is nothing but a CAN bus between the accelerator and the fuel injection nowadays? That various valves and operating parameters are adjusted by control loops running thousands of times per second?

Admittedly, an autopilot of sorts would be much more complicated. However, there's no reason to believe that it wouldn't be written well enough to not crash. And it would certainly not impede manual control of the car, which would probably be a different system and have higher priority on the bus so that a misbehaving autopilot could do no harm.

A watt is a unit of power, not energy. The lifetime of the shoes is unspecified. Speaking of a watt, that's a lot of power for an energy harvester like this, and sounds too good to be true - because it is. The article only shows a 10mW generator, though that is still enough for periodic radio transmissions. Also, I would guess because it is electrostatic in operation, it would also work as a fairly large capacitor for temporarily storing the energy.

No, when they support the 2.3 API (revision 10), they also support all API versions below that. In fact, Google encourages developers to target the lowest possible API level to support needed features, to maximize compatibility.

You are exactly right. The Fukushima plant actually had steam-powered water pumps that could have kept the core cool during operation. But the reactor was automatically (or procedurally?) SCRAM'd at the first sign of the earthquake, which means that the reactor wasn't putting out close to enough steam to power the pumps.

Yes and no. The copy protection of a blu-ray disk depends on a special region of a disk which can't be burned by commercial blu-ray burners (in fact it's prerecorded with a serial number). So if you had special hardware, yes, a bit-by-bit copy including that region would work, but most people don't have access to that hardware.

You seem to assume that the only point of sharing code and APIs is to run desktop applications. This is not the case. If you look at Maemo, Meego, and webOS, you'll find they share many things in common with the Linux desktop - Pulseaudio, d-bus (maemo), libpurple (webOS), SDL (webOS), bluez, WebKit, and many more drivers, services, daemons, and libraries that can be used for both desktop systems and phones. The point of these APIs isn't so that you, as the end user, can run applications written for the API. It's so that developers already familiar with one API can easily write for both platforms. In addition, the many pieces of software used by webOS, etc are sent upstream.

Have you possibly tried changing a setting in KDE before?

Seriously, it's not that hard. My desktop is entirely bare, I have a vertical panel with just a task bar, tray, and clock. My plasma theme almost completely lacks gradients. Oxygen is probably least offensive in this regard - it looks great on my high dpi screen, and isn't ridiculously glassed like certain themes are.

Note that hardware that includes a H.264 decoder has already paid for a license. So the browser does not need to pay any fees for the license.

In fact, I think it's generally true that any browser should not have to pay licensing fees - the decoder shouldn't be part of the browser. Major OSes already come with their own video API which either uses a software or hardware decoder.

I thought the whole point of the video tag was to allow in-browser video to reach parity with standalone player, not to force the browser to become a software video decoder too (Flash already does that mighty well).

There's some truth to the fluorescent light complainers... old magnetic ballasts run the light at 60Hz, which can create noticeable flickering (you can see it easier if you look with the side of your vision).
Modern electronic ballasts run at very high (30khz+) frequencies and so don't have this problem.

I think the point was that cell phones weren't allowed, and so any cell phone usage detected could be assumed as cheating, if not at least breaking the rules of the test.