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.

For the past few months we’ve had continuous delays in producing sufficient units to meet/exceed demand. From the emails we’ve received we know this is frustrating to our current (and likely future) customers, and it’s mighty frustrating to us as well. This update has been in the works for a few months, but we wanted to make sure we had a good handle on all the issues before we just kept saying “one more delay” (if you’ve ever seen The Money Pit, it’s reminiscent of the contractor saying “about two weeks”).

Some brief backstory is important. As a small developer of electronic hardware, one of the biggest bets you make is your choice of contract manufacturer (CM). We had initially chosen a well-respected, domestic CM and everything was lined up to go. To make a long story short, they left us at the altar. I’m still not sure why, other than the fact that what we’re doing is completely new and did not fit neatly into any of their existing product categories. So we scrambled to find another one. Luckily we came up with a good alternative quickly. But we then had to start the long process of getting them geared up for production. This took longer than it should but we got it done.

As the new CM got up to speed, a few other minor setbacks occurred. We had quality issues with some of the plastic molds and the snap-on feature for our modules was not working as advertised. Any of these issue by themselves would not have added up to much of a delay but when added together they complicated the delivery schedule. By the time we cleared these up, we had already missed our original target ship date (w (more…)

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!

I’m currently attending OSCON, and with BUG being on the front page of Linux Journal this seems like the perfect time to announce that the next release of the BUG software will be based on Poky Linux!  This means almost every aspect of the software will change for the better, but the most apparent change is a fresh new interface*.  Other changes are important for developers and others that want deep control over the software running on their BUG.

Years ago when we started this crazy mess, we looked at several different build systems for which all our application and operating code would be defined and generated. We decided at the time to go with LTIB, a build tool maintained by Freescale and the system that ships with the initial hardware we used to develop the BUG. LTIB is a great tool for generating Linux-based kernels and root-filesystems for applications, and is actively supported and maintained by Freescale.  However BUG, as a platform, has outgrown the scope of what LTIB is designed to provide. We recognized a need for a general purpose Linux operating system with a great community and plenty of software.

After looking at several projects and distributions, we ended up choosing Poky, a subset of Open Embedded.  Open Embedded is a true community-based project for building and running Linux on small computers. Essentially Poky provides a set of scripts used to handle cross compiling and a set of package metadata that allows anyone to add and configure software for a machine. Because Poky is based on Open Embedded, users are able to take advantage of its huge package library. Poky is produced by Opened Hand, a great set of folks of which I had the opportunity to meet at GUADEC 2008.

If you’d like to see more, we have a getting started guide on our wiki for building Poky Linux for BUG.  Note that this is still preliminary so if you run into problems please let us know!

*: For those that were happy with xeyes as the primary BUG application, don’t worry, we have ported it to Poky.

Had a great time at foo camp. I don’t think I can remember an event where I had so many interesting conversations in so short a time. I even hosted a talk on Art+Music+Technology. And people came to it. Miracle.

What I found most interesting about my session were the conclusions we reached. I started by asking “what’s now artistically/musically possible with today’s Internet connected gadgets?”. I figured the group would come up with some cool ideas for applications and/or gadget types.

Instead we concluded something I didn’t expect: the Internet and new technologies are going to radically increase the number of people who can participate in the making of art/music because the bar for mastering new types of instruments and tools will be dramatically lowered. In essence, new technologies and connectivity are making it easier for anyone to become an artist. I think that’s a huge win and incredibly important.

Art and music creation/performance should not just be reserved for the elite. A couple people in the group voiced the concern that by lowering the bar you increase the pressure on existing artists as their craft becomes less meaningful. I would bet that this is true for every technical leap that increases our ability to create or distribute content. In other words, it’s an issue that content creators have faced with technology since the printing press was invented. I think we can call that one a success…

Thanks to the whole O’Reilly team for hosting such an awesome event.

Thanks to the amazing talents of our designer, Mateo Zlatar, the company’s sported some cool shirts at the various conferences we attend.  On quite a few more than one occasion people have asked if we had extra shirts, hats, or other schwag to hand out, and being the small startup operating on a responsible budget that we are, we haven’t.  But we really wanted to have some for the big fans out there, so we decided to create a Zazzle-hosted shop to solve the problem.

Now you too can have your own Bug Labs hat, mug, t-shirt, mousepad, and, uhm… necktie.  Yes, that’s right, a Bug Labs necktie.  Perfect for the occasion where you need to dress it up a bit, but still want to represent open source and DIY gadgets in a fashionable way.  All the options are available here.  Have fun!

I’m very sorry to say that we have to postpone the Open House we scheduled for this Wednesday.  A number of conflicts have arisen since the original post was made – we’ve been trying to juggle the schedules of Bug folks while timing the move to our new office, and suddenly realized that we were a bit too optimistic.  We regret having to push this one off, but we’d like to have a full staff and some furniture present before inviting everyone in.

I’d like to apologize for any inconvenience caused.  Stay tuned and we’ll schedule another one just as soon as we’re back up and running at full capacity in the new building.

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.

This is a quick update, could probably have done it in 140 characters or less, but since I may be verbose, why not?  When the blog was first launched (on Typepad), the RSS feed was autocreated, with the following URL: http://feeds.feedburner.com/typepad/buglabs/bugblogger.  Odd one, ain’t it?  Anyhow, we’ve updated, and while the old one is still alive, please update your reader to point to our new (and improved?) feed here: http://feeds.feedburner.com/bugblogger/rss.