Raspberry Pi Software Is Rapidly Maturing
Linked by Howard Fosdick on Sat 24th Nov 2012 04:12 UTC
Linux 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.
E-mail Print r 2   51 Comment(s) http://osne.ws/khu
Thread beginning with comment 543087
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Just in time for a successor?
by Zobeid on Sat 24th Nov 2012 11:19 UTC in reply to "Just in time for a successor?"
Zobeid
Member since:
2012-04-28

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.

Reply Parent Score: 3

ssokolow Member since:
2010-01-21

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.

http://cm.bell-labs.com/who/ken/trust.html

Edited 2012-11-24 13:11 UTC

Reply Parent Score: 6

_txf_ Member since:
2008-03-17

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.


As further clarification. The GPU runs what you'd consider a graphics driver on an RTOS (threadX). The application processor running linux then sends commands to the GPU much like an application would send commands to the OGL driver.

Things that require direct access to the hardware like OpenCL, or even X acceleration (Render) cannot be done (without broadcom offering updated firmware).

Objectively, it is quite an interesting encapsulation, but ultimately a useless one if you want access to the hardware. Ultimately, the Rpi foundation was mischaracterising the open nature of their driver.

Edited 2012-11-24 13:25 UTC

Reply Parent Score: 7

Read more of this thread... >