Software for the Raspberry Pi is quickly moving forward. Beyond the several core Linux distros, another couple dozen systems are available, with NetBSD, FreeBSD, and Chromium imminently stepping into the mix. (Ubuntu will not join them as it requires ARMv7 and the Pi is ARMv6). Two dozen programming languages are available, including Python, Perl, Java, Ruby 1.9.2, BASIC, and more. Since the Pi
is a full fledged ARM computer, it should run nearly any ARM app within its system requirements. See the RPi Wiki or Foundation website for more info.

I've read recently on the RPi website that the creators give the project a three year shelf life before it ends as we know it. Whether that means a new, more advanced device at the same price point or the actual end of the experiment altogether is what I wonder about.

I haven't picked up one of the Rev. 2 boards yet, as so far I haven't had any issues with my "original" board, but I do plan to get one soon just for the doubled RAM. That aspect alone has made a difference in a lot of projects documented on the forum. I'm hoping for continued improvements to the USB circuitry in a third revision if one should come to pass.

One thing is for sure: The release of the Pi has spurred competition in its price range. There are no less than four excellent ARM boards for under $60 out there now, with varying degrees of F/OSS support via open drivers. If Broadcom will ever open up the drivers for the BCM2385* we could have perhaps the most versatile SoC board in existence. I'm not holding my breath, but I'm not giving up on the platform either.

*Unlikely as long as commercial devices like the Roku 2 continue to use it in a proprietary fashion.

Well, I've always understood the A10 to be the go-to chip for cheap Chinese knock-off tablets. However, it seems to hold its own especially when you consider the price/performance matrix. Given the openness too, I'd love to get my hands on a Pi-like dev board based on it.

Not sure if I understand this about the drivers... I had gotten the impression that they've already made the drivers open-source. The part that's still proprietary is the chip's internal firmware, which is something you don't need to access its functions.

I suppose it means you can't fix Broadcom's bugs for them, and you can't repurpose the GPU for other computing tasks (OpenCL?), but those seem more like quibbles than real obstacles, to me.

Not sure if I understand this about the drivers... I had gotten the impression that they've already made the drivers open-source. The part that's still proprietary is the chip's internal firmware, which is something you don't need to access its functions.

I suppose it means you can't fix Broadcom's bugs for them, and you can't repurpose the GPU for other computing tasks (OpenCL?), but those seem more like quibbles than real obstacles, to me.

The argument is that, if a firmware is so complex that there's a GLSL compiler in it, then it's a co-processor with a closed-source OS of its own, not mere firmware on a subordinate processor.

Heck, on the Pi, the GPU is responsible for loading the image off the SD card and setting up initial state before handing off to the CPU so, if you're of the tinfoil hat persuasion, you could plausibly rant about the possibility of backdoors and the risk of techniques similar to Ken Thompson's hypothetical compromised C compiler.