I’m at the UC Berkeley Human Rights Center “The Soul of the New Machine” conference.  We have teamed with Human Rights Watch to present a submission to their Mobility Challenge.  We were thrilled to make it to the top ten finalists and have the next two days to make our case to the judges.

I’ll let you know how we do.

One of my favorite movies of ‘07 was “Ratatouille” from Disney.  In it, there is a character named Chef Gusteau who’s sole message in life was “Anyone can cook!”.  And in the movie, the theme plays out with a rat becoming a star chef in France.

I loved the theme because it’s very close to how I feel about what we’re trying to do here at Bug Labs.  I would modify the theme slightly to say something like “Anyone Can Build a Gadget”, but the intent is exactly the same.

One of the most gratifying things about working with groups like Human Rights Watch on this UCB Mobility Challenge project is that they have taken this to heart.  They can build a device of their own.  They don’t have to become a big hardware developer, or raise tens of millions of dollars.  They don’t have to learn how to solder or become solid state electronics experts.  They can just build a gadget.  And use it for what they want.  I think that’s enormously liberating.

I firmly believe we will see much more of this in the coming quarters.  Companies, organizations and individuals that you would have never thought would be in the “gadget business” will suddenly start building and selling very custom/personalized devices.  Amazon’s Kindle is a great case in point.  It is a great trend that will benefit everyone.

Bug Labs took a long lunch yesterday to help a local organization deliver Holiday gifts to seniors in the area.  Here is our new development intern, Irvin, with one of the Holiday gift bags.

Visiting Neighbors is a non-profit organization with the mission of providing older adults mental stimulation, encouraging physical independence, and helping to alleviate loneliness.   Beyond our obvious goal of delivering gifts and chatting, Visiting Neighbors uses our visits to gather information about the state of their members - health, living conditions, etc…  I think this is great, a truly creative and resourceful community collaboration!

We were a bit surprised that half of us weren’t invited inside - the seniors we were paired with just opened the door and took the bag.  Peter and Kevin were stopped at the door, but each were given a banana :-).   Those of us that did sit and visit awhile came back with neat stories from some great personalities.  Brian and Al met with a feisty lady that lit her cigarette from a candle on her 100th year old birthday cake, Riba and Amie met with a senior determined to get her first computer, and Irvin and I talked with a Holocaust survivor that described for us, among other amazing stories, how the people in her building and neighborhood have changed over the last 60 years.

It’s amazing to talk with someone that has seen and experienced things I’ve only read about in history books, a living witness to the progress we make as humans.  I also enjoyed how all the members we met with were brutally honest - “oh, a crossword book…take this back.  I’ve never done these puzzles and I’m not going to start now”.  If only we all could be so honest.

For those of us invited beyond the threshold, they said they really enjoyed our visit - but I think our days were brightened even more.   Volunteering is such a synergistic activity.  I admit, the concept of interrupting my workday and sitting with an old stranger was not enticing.  I was even nervous.  But it felt great listening to stories that wanted to be told, and I learned lessons about how to appreciate life and the most basic things around me.  I feel like we made the coming days, maybe even weeks, better for some folks in our neighborhood.  I know we’ll be back.

Bug Labs was at the Austin Maker Faire this weekend, where we won a Editor’s Choice award from Make! We were really honored to be part of Maker Faire and excited to show everyone our product!

Just before Maker Faire, at our Open House, we got our breakout board module (The Von Hippel) talking to an Arduino mini! It was a collaborative effort with help from NYC Resistor, who brought us a much needed R232 to TTY chip at a moment’s notice.

The folks at Maker Faire enjoyed clipping together modules together and coming up with new module ideas we should consider for the future, such as the Jelly Bean module and a Robot Wheels module (pictured below).

Hope everyone enjoyed seeing demos of the Bug! If we took your picture with the DrawPad app, check for it on Bugnet!  View more pictures of Bug Labs at Maker Faire here!

Using the VonHippel module and a simple c program compiled for the ARM, BUG can talk to the Arduino (in the picture, the USB cable and USB to serial chip on the breadboard are probably superfluous as the VonHippel has serial on it).

After Kevin Schultz’s recent work on jvm benchmarking for BUG, I thought it was time to put cacao + classpath to work. I have been exploring the possibility of using Processing with BUG for some time, but the limited API available in phoneME Advanced Personal put that effort just beyond reach. Building cacao and classpath for my BUG is cake with the new platform, and deploying Processing isn’t very difficult either. It’s not stable yet, but it’s a pretty cool proof of concept.

Updated 9/19: Note that cacao + classpath is not part of the R1.3 build.  See our wiki page on tweaking your build to customize your own BUG platform, including some pointers on getting openembedded addons onto your BUG.  Notes on how to build Processing for your BUG forthcoming.   If this seems like something you’re interested in doing, feel free to contact me at john@buglabs.net or drop into our IRC channel: irc://irc.freenode.net/buglabs

After hours of blood, sweat, and tears* xeyes has made it into our latest operating system image, as seen here.  With xeyes, our final application requirements have been met. 

* It actually took about 5 minutes to copy the existing recipe from org.openembedded.dev into the Poky build.

We did it! We moved to our bigger space in SoHo and are getting settled in. We love the neighborhood - it’s super active, colorful and lots of good eats - Kelly and Ping and Cafe Habana are all right around the corner (not sure if it’s a pro or a con, but Riba saw Lindsay Lohan eating at Habana).

In the office, work is under way for our Test Kitchen - an in-house lab for getting dirty with electronics and trying out apps. More importantly, at least for the purposes of this post, we have added desks and want to fill them.

We are actively interviewing for folks that can write linux device drivers, help with marketing and outreach (like our .edu program), or help write technical documentation. You can see more details for each of these jobs at www.buglabs.net/jobs.

We are also keeping our eyes open for a controller, biz dev, and ops person with loads of experience with start-ups, CE, light manufacturing, the works.

If this is you, or someone you know, let me know at matthew[at]buglabs.net

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 have been a huge fan of Gentoo Linux for several years. Why? Is it the elitist appeal of compiling your operating system from scratch? Could it be performance gains achieved by compiler and package optimizations for a particular piece of hardware? The excellent forums? Nope, none of the above. The Gentoo community instills a culture of looking under the hood, of customizing and tweaking, of not being afraid of greasy hands. I get laughed at in the office sometimes because of this and I have to spend more time installing, but I think it’s worth it. Deep customization seems to be the wave of the future, and here is why I think so.

Enterprise Application Servers: great idea! Provide a uniform platform optimized for a specific type of application. Abstract the hardware layer with some operating system and a JVM. Serve up Ebay! But why stop there? Why can’t the app server run on bare metal? What is the use of all that OS overhead/complexity/variance underneath? In software design, we constantly make compromises between optimization and generality. What if we didn’t have to? What if we could develop and deploy an entire operating system for a specific application or job position or organization? Well of course you could but it would be incredibly expensive and take forever. And who’s gonna write all those device drivers?

At SCALE in LA a few months back I had the opportunity to see a presentation by and briefly talk with Bruno Gonçalves de Albuquerque of the Haiku project. The concepts behind the operating system are fantastic. The level of optimization at the user experience level when you control the entire OS (read: filesystem) is really amazing, and clearly blows the doors off any desktop OS I’ve ever used. Why am I not using Haiku right now? Well apart from it not being quite done yet, hardware support. Developing device drivers is a constant and thankless battle, typically undertaken by Microsofts and OEMs. Where is the incentive for a Taiwanese OEM to provide a device driver for Haiku? While listening to Bruno Gonçalves de Albuquerque it occurred to me that this problem may just go away if Haiku had binary compatibility with the Linux driver model. All of a sudden my graphics card works, and my wifi (gasp) too! Linux, besides being an operating system, provides support for a very large number of devices and systems. Fresh off the presss, 2.6.25 supports a new hardware platform. The fact that all of this work is open source presents an opportunity for other OS producers to leverage this work. It lowers the cost and increases the potential user base by supporting a greater variety of hardware. But who cares? We have OS X and Ubuntu and XP. Do we really need another operating system?

On the hardware front things are changing radically. Eight cores today, 64 tomorrow. Specialized (audio, physics, credit card validators) cores on the same chip. There is talk of doing away with the graphics card altogether and putting that in the CPU too. The list goes on… But where is the software? Where are the operating systems and languages and runtime environments to fully take advantage of this latest round of hardware innovation? And who decides where virtualization occurs? Is it KVM…or perhaps some JVMs? Do I have to run one master OS that virtualizes all the others? Can I partition, version, and manage OSs per core? Dynamically? Can I have a custom OS for Crysis III that gives me a few more frames per second because my machine isn’t looking for security patches? Do I really have one machine or many?

There is a shift happening in software caused by new hardware platforms. Component based design, concurrency, functional programming, and virtualization are all, in part, results of trying to utilize new hardware designs. This change is similar, but hopefully more fundamental to the shift from single-task operating systems to multitasking ones. From TSRs to Windows. It took so much time for that earlier change to manifest*. What’s the difference between then and now? How long do we have to wait for MS Windows 95 part II?

Well I think the difference is Linux and open source. The difference is an open driver model that allows OS developers to focus on new ideas rather than supporting 3000 network cards. The ability to see solutions in the open, and the ability to collaborate. No more silos, no more ivory towers. The demand for radical OS customization will increase as divergence grows between hardware potential and what our existing operating systems, languages, and runtimes are capable of. And as this demand increases I hope to see new, radical, highly-custom new operating systems and runtimes emerge. Exciting times!

* And yes, I had an Amiga too back in 1989. And yes, it was sweet.