This weekend, Ken, myself and Matt (aka HaveAHennessey on #buglabs) will be in Los Angeles for SCALE 7x, marking the second year Bug Labs attends the SoCal Linux Expo. After a great turnout for Ken and Angel’s session at SCaLE 6x, we’re looking forward updating the crowd in Building open source gadgets with Linux, OSGI and Web Services, taking place on Sunday between 1:30pm and 2:30pm in Concourse A.

If you’re at the show, you can also have a chance to walk away with one of two free BUGbundles! Just look for any of us (we’re wearing BUG shirts) and we’ll give you more information. UPDATE: The Win-a-BUGbundle at SCALE 7x survey is up!

See you there!

One thing we’ve had in the works for a few months now are some tools to integrate OpenEmbedded and Poky with Eclipse.  We are a big fan of Eclipse as a modern development tool and use it as the foundation of our Java-based SDK.  Poky (based on OpenEmbedded) forms the foundation of the BUG Linux operating system.  In addition to making Java and OSGi apps easy to write, we’re also adding tools to make it easier for those of us that work down in the pipes.  Here is a screenshot of a BitBake recipe editor.  If you are interested in this kind of functionality, we’d love to hear from you!

I had a great time at Gnomedex last Fri/Sat, it was my first time at the show. I made the presentation (below) over the course of the show itself, as I really wanted to gear it for the audience. I knew it was a tech-savvy crowd, and also wanted to avoid “pitching” Bug Labs while still sharing the company’s vision.

You can watch the video below (first ~30 minutes are my presenting, rest of the time is Q&A), or you can check out the slides (also below) – but I will say the deck doesn’t really “work” without the voiceover.

Lastly, don’t forget the FREE BUGBUNDLE CONTEST is still live until this coming Friday! So easy to enter…

Live Streaming by Ustream.TV

The video doesn’t necessarily capture all the slides, so if you want to see them raw (read: out of context), here they are:

Ken announced earlier this week that the next software release for the BUG includes some big changes. Many will be immediately visible to the user, but some of the biggest changes are coming under the hood. The new system is significantly more flexible allowing us to change the packages in our Linux distribution easily.

Our current stack is based on phoneME Advanced, a configuration not available in Open Embedded. That forced us to look at other options as we started working with Poky. The original prototype of the BUG used JamVM and and GNU Classpath, but we have been using phoneME for quite a while. Now was a perfect opportunity to look at other VMs. The obvious alternative is JamVM, but we also tested the Cacao virtual machine due to its support by the Jalimo and OpenMoko projects.

It seems not many people have been comparing VMs on ARM recently so some benchmarks were in order. We based our tests on this article on benchmarking. Our three benchmarks were Scimark2, Linpack, and startup time comparison.

First up was Scimark2, the most comprehensive of the benchmarks. The suite runs various algorithms and reports these scores in mega-flops per second. It also makes a composite score of these tests. JamVM is the clear winner. While Cacao has solid performance on the Monte Carlo prime number finding algorithm, it falls behind in all of the rest of the tests. PhoneME seems to be about 10-20% slower than JamVM in most tests.

Next up was the Linpack benchmark. The first graph is a measure of the speed of the processor in mega flops per second. The second graph is the overall time for running the benchmark so lower is better. Again here we see the same order as the Scimark2 tests. JamVM runs on top for both tests followed by phoneME and Cacao.

Finally, our startup time test. Starting up the OSGi stack currently takes a few seconds, so startup time of the VM has a significant impact on the overall boot time. For this benchmark we started up the Concierge OSGi framework – though it did not load any bundles since we had not ported all of them to the new build system at the time.

Here JamVM performed as expected with an impressive startup time. Note that this is not a constant time, these gains will increase with a larger load. When starting up our full OSGi stack you will probably gain a few seconds with JamVM.

All of this makes it look like the best choice is JamVM, but there are a lot of variables that are swept under the rug above. Most importantly, a 20% difference on a synthetic benchmark does not indicate a 20% improvement in end user experience.

Second, there are some differences in the configurations. We ran these tests using GNU Classpath on JamVM and Cacao. Keep in mind that GNU Classpath is J2SE-like in size, while phoneME Advanced is significantly lighter. This will make a big difference on a benchmark that measures full system performance. These benchmarks are designed for CPU throughput so the additional overhead of Classpath does not show up. However, both Cacao and JamVM can run with phoneME rather than Classpath, it is just not the default behavior in OpenEmbedded.

Perhaps the biggest red herring stems from us not building phoneME with JIT right now. This is due to a problem with older versions of the Linux kernel. With the new build system we will build phoneME with JIT which will gain significant performance. These benchmarks are comparing the current build of phoneME to the Cacao and JamVM default setups in OpenEmbedded, we are not comparing the maximum performance that can be squeezed out of each VM.

Finally, on Thursday Matthias Klose was able to get OpenJDK built for ARM. We will have to take a look at its performance as soon as we have it running on the BUG.

We still are very excited to see the community based VMs performing so well. While there are more factors to consider when choosing a JVM implementation (such as TCK validation, branding concerns, and community support) JamVM definitely warrants a look for anyone interested in embedded Java development on ARM based systems, it certainly impressed us. Look here for a follow up post sometime in the coming months.

I’ll be doing a BOF in room F150 at OSCON on Thursday at 8 PM.  For those interested I’ll give a brief technical overview of the BUG device and answer questions.  Please stop by if you can!

Update: The Open House has been postponed, we’ll keep this space updated once we’re ready to reschedule.

For those of you that were unable to make it to our first two Open Houses, or for those that have been anxiously awaiting the next one, we’re opening the doors again on Wednesday the 9th from 6 to 8PM. This will be your last chance to check out our current digs, as we’re moving to a new location further south on Broadway in just a few short days.

Why spend your Wednesday night at our humble office? Because we’ll have cool BUG applications and other demos to show off. You’ll get a chance to play around with the hardware and we’ll be on hand to talk about the SDK, BUGnet, applications, stuff you’re interested in building, whatever you like. Perhaps most importantly, there will be beer. There might even be a free T-shirt or two as giveaways (distribution methods of aforementioned T-shirts still pending). No matter what your reasons for stopping by, we’d love to see you.

You can find us at 915 Broadway (between 20th and 21st) on the 11th floor, at the end of the hall in Suite 1109. Look for the fancy red Bug Labs sign on the door.

I’m very happy to say that we’ve moved the blog to the Wordpress platform. I’ve been a big fan of WP since I first started my own blog there years ago (after a short-lived stay at the earliest version of blogger.com). In context to Bug Labs, I think it’s a very “fitting” choice. Here’s why:

1. Both are built using open source technologies and ideals
2. Both use the GPL
3. Both start good but get tremendously better with a developer community
4. Both are fully extensible, with practically no limitations to the final product (Guy Kawasaki launched a business, Truemors, purely by customizing wordpress!)
5. Both are “blank canvases” for creation, which could result in a motion-controllable slideshow playback device or… pictures of cats with bizarre captions

We’re working the kinks out of the system now, so you may see an oddity here or there (if so, please do leave a comment on this post!).

Frank Sommers had a very interesting post on JCP/FOSS topics at JavaOne earlier this month. Essentially the question is; do the JCP processes (specification, implementation, and test suite) impose too much overhead such that purely FOSS-based JCPs do not make sense? It’s certainly worth considering, and also fills out for me some of the ongoing issues surrounding the issues surrounding TCKs with PhoneME. So the interesting question that follows is; if the JCP as it exists is not suitable for FOSS communities, what if anything should be done? Change the processes? Work on a new community-based system for defining open source standards based on Java?

Well, I do. There is a whole lot of activity these days in the mobile Java/open source world. Harmony, Android, PhoneME, OSGi, and MIDP 3.0 are all causing waves, in one form or another. The latest MIDP JCP, initialized about 3 years ago, has been rumbling towards an initial release as of late. Back then open source mobile Java did not exist in any meaningful way. Well, things have changed. I think the PhoneME MIDP implementation needs to be opened up. If you agree you may want to let the PhoneME engineers know. I’m sure they would appreciate the feedback.