Meh, the compositor has to draw the pixels, one way or another. KDE has two backends, XRender and OpenGL. If acceleration isn't available, the XRender backend can still run in software, and is pretty fast. KDE also supports no compositing at all, but with software compositing it's becoming irrelevant.

Note that compositing != GPU acceleration. Mac OS X has always used compositing, but it was entirely software. There are still good reasons to do so. I'll compare for you:

No compositing, one frontbuffer: You don't get your own pixmap to draw onto. You have to send drawing commands to the display server to draw on your behalf, to prevent you from drawing wherever you want on the frontbuffer. Unfortunately, if you have something complicated to draw, the user gets to watch as the drawing happens. When drawing a new object, generally the algorithm used is to draw the background, and then draw the objects in order from back to front. This means whenever the screen is updated, the user will see flicker whenever any objects are updated because they may briefly flicker to the background color. To work around this most modern toolkits (Qt 4, GTK 3) render to a pixmap, and then just tell X to draw their pixmap when they are done. This avoids the flicker but uses a bit more RAM.

With a compositor, the application still draws to the pixmap, but instead of requesting the X server to immediately draw their pixmap to the screen, they pass it a handle to the pixmap and the display server can draw it whenever. This makes a lot of things easier, like vertical sync and effects, as well as things like color format and color space conversion.

Drawing the pixmap on the screen is really the same operations, no matter if compositing is on or off. And the API your compositor uses shouldn't matter too much either if the underlying implementation is optimized. The highly optimized Gallium3D blitter is going to just as good as the traditional X blitter, if not better. The only thing slowing it down in this case is the fact that OpenGL API is rather overkill for blitting, but hopefully the llvmpipe backend is optimized for this use case. And it's probably not worth it to make the compositor support two drawing APIs, like KDE, as they both end up doing the same thing anyway.

This isn't going to happen. The initial boot HAS to happen off word-addressable memory. So it's not like you can brick your PC by losing that partition.

I think you missed what the parent was talking about. He didn't mean implementing more things in Javascript, he meant allowing developers to use non-Javascript languages to generate Javascript. It's so people don't have to use Javascript or learn it, not the other way around.

What you mention, the pattern of generating pages using AJAX, is still fairly new. I use it a lot for data that is updated in real time, and some websites are using it for static data as well. I very much like it for cleanly separating the presentation from the backend server side code, even though some NoScript using purists hate it.

So what you're saying is the only thing of value in WebOS and Android is the Linux kernel?

Probably because they add weight and thickness (the encapsulant especially - a cell itself is thin and light). That's probably a more competitive aspect than battery life.

They only get as hot as my black Thinkpad gets in the sun. I think laptops will live.
Durability will be interesting. Solar cells are extremely fragile. However, there are a number of strong encapsulants out there, so it shouldn't be too much of a problem.

no, extremetuxracer ftw. Yay for 4 forks!

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.