Raspberry Pi Gets More Open Code

October 24, 2012

Today, in a post on its Web site, the Raspberry Pi Foundation announced that the source code for the video drivers used in its $35 single-board Linux computer would be available under an open-source license.

As of right now, all of the VideoCore driver code which runs on the ARM is available under a FOSS license (3-Clause BSD to be precise).

According to Alex Bradbury, author of the post and lead Linux developer at the Foundation, all the software running on the Pi’s ARM processor is now open source.  (The post has a link to the source repository.)

This development will please advocates of free and open-source software.  It should also make it easier for developers to make use of the graphics acceleration capability that is part of the Pi, including those who are porting various OS environments to the device.

We’ve been excitedly following the progress of FreeBSD, NetBSD, Plan9, RISC OS, Haiku and others. All these projects could now potentially port these libraries and make use of the full hardware accelerated graphics facilities of the Raspberry Pi.

I have seen some grousing that some of the code that runs on the graphics chip itself has not been open-sourced.  I don’t know enough about the hardware to evaluate this claim, but it seems to me that half a loaf is preferable to none, especially since the original goal of the Raspberry Pi project was largely educational.  In any case, Broadcom, the chip vendor, has taken a significant step in the direction of openness, and deserves credit for that.

Ars Technica also has an article on this announcement.

Java Survey Results

October 24, 2012

Last Friday, I posted a note here about an article and informal survey at Ars Technica, on whether keeping Java on the desktop was a significant security risk; and, if so, whether the risk was worth running.  Ars has posted a follow-up article, summarizing the results of their survey.  The results are interesting, although likely to disappoint anyone expecting a clear-cut, black and white sort of answer.

There seems to be a consensus of sorts that the most risky part of the Java system is the browser plug-in.  Those respondents who had security concerns often focused on mitigating that aspect of risk,

Some users have disabled or uninstalled Java entirely. But the most common solution for those worried about security risks is to leave the Java Runtime Environment in place on the desktop while disabling the browser plugins that allow Java applets to run on websites. Those plugins are often vulnerable to attacks involving remote code execution.

This approach, which I mentioned in an earlier post on getting rid of Java, probably removes the most serious threat, while leaving the Java Runtime Environment available to support features of packages like the open-source office suite, Libre Office (the successor to Open Office).   Libre Office can still be installed without Java, but some features will not be available.

Not surprisingly, the responses also indicated that Java still enjoys substantial popularity among developers; one respondent wrote:

I use Java heavily at work because it has the killer combination of: being good enough as a programming language; being cross-platform; having a great set of libraries; running fast.

Java is also used extensively in enterprise environments.

Java has lots of real-world use cases, enough that uninstalling or disabling the platform isn’t realistic for many users. Numerous people report keeping Java enabled in browsers because of banking, government, work, and school-related websites.

For both the developers and enterprise users, a common theme seems to be that Java, while not being perfect for any particular application, offers a practical approach for many things.  That it is available and gives decent performance across a variety of platforms is an obvious selling point.   Beyond that, it is a reasonably structured language, and much better for sizable projects than a scripting language like Perl.

For the average individual user, I’d recommend the following approach:

  1. Look through the list of software and Web sites that you use regularly, and see if any of them require Java.
  2. If none does, then removing Java will reduce your risk at minimal cost.  (You can always re-install it if your situation changes, of course.)
  3. If you have application software, like Libre Office or Minecraft, that requires Java, you can leave the Java environment installed, but remove or disable the browser plugin.
  4. If you regularly use Web sites that require Java, you can leave the plugin enabled, or disable it, re-enabliing it when you need the Java-dependent site, depending on how frequently that occurs.

As always in security, there are trade-offs, but I hope that making this sort of information available will help people in making choices.

%d bloggers like this: