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!

Jan came in for a visit a few days back, during an OSGi Alliance meeting going on nearby.  Concierge, the OSGi framework that enables some of the BUG’s features such as abstract hardware services, was written by Jan as part of his research at ETH.  We had an interesting conversation on the state of various efforts going on with OSGi, and we are glad that Jan is involved in the alliance.  It seems all-too-common for standards, specs, and projects to bloat over time.  Concierge is a great example of simplicity and minimalism and we hope that same spirit continues in the alliance.  Thanks for stopping by Jan!

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.

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.

When I was an early teen, the issue of security was of paramount concern to me.  Not computer, social, national, or even homeland security.  No, it was Room Security.  My room.  The one in the basement.  The mostly unfinished basement that smelled like concrete and pine 2×4’s.  I wanted to build an early detection system for parents.  I called it S.H.A.R.K..  It began simply enough with some parts from Radio Shack:  Some infrared diodes, a relay or two, and a piezo electric speaker.  I had a lot of time for this project, and naturally the system requirements exploded.  I didn’t really see it that way at the time (thankfully), but I ended up drawing master plans for a general purpose computer.  While not yet introduced to Alan’s machines, I knew S.H.A.R.K. needed memory and some sort of execution system.  I envisioned a tape with rows, each where a hole could be cut.  Through a hole light would cause a relay to trip, closing some circuit that was paramount to Room Security and the prevention of unannounced parental intrusion (UPI).  See the tape allowed me to have a modular, dynamic approach to security.  Swap in a fresh roll and have a brand new security strategy.  Brilliant.  Kind of like programming, or modular hardware, or..well BUG.  Sadly my imaginations never actually worked in practice, but I had a bunch of wires in a shoebox and it did something.

This week I have the honor of speaking on Bug’s behalf at Maker Faire.  I’m a huge fan of the publication and when reading it get the same stimulating, awesome feeling of creating that I did when S.H.A.R.K. was fresh in my mind.  I’m really looking forward to seeing all the freaky cool things people are doing, and hope BUG makes a few people smile.

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.

I’m currently reading William Gibson’s latest release, Spook Country. I’ve been a fan of him since first stumbling through Neuromancer as an early teen. It was a very important book for me at the time because of the concepts that technology is not just in the domain of math nerds, NOCs, and ROI, but interacts with almost every aspect of the human universe. Gibson’s stories usually involve some kind of hacker immersed in a crime or scandal and, for me, the biggest thrill is in how Gibson’s characters modify and subvert top-down megacorp driven consumer products into things of real human interest. How the world, as designed by focus groups and industrial designers, is never really how it turns out in the end. The essence of this of course is Gibson’s statement: “the street finds its own uses for things” (”Burning Chrome“, 1981).

Back to Spook Country. There are a couple of characters that are involved in an emergent underground art-scene known as “locative art”. A viewer goes to a specific physical location and visual art accessed through some network-enabled hardware. Typically pieces have some direct connection to the physical space and there is a direct connection between the digital art and the physical world. One problem Gibson’s characters have though, in this near-future tale, is the hardware. There is some vague reference to a cell phone ducted taped to a GPS receiver. More specifically, the problem is that Gibson essentially sees technology as always being generated by massive, top-down systems, and hackers, artists, and criminals subvert these systems for their own needs, but only in highly localized ways.

Is Gibson right? Are we forever doomed to Maas-Neotek decks, Sense/net media, and Sony camcorders? Or will bottom-up, user-directed technologies become popular and skew us all from Gibson’s near-term future worlds?

What do I love more than lolcats?

Why, EclipseCON of course.

I’ve noticed a great deal of interest lately among Eclipse bloggers about Bug Labs and BUG, particularly given our involvement with the Eclipse and OSGi communities. So with the buzz about BUG growing, especially as we begin shipping soon, I’m pleased to announce that we’ll be showing off the BUG and the Dragonfly SDK all throughout next week’s event.

Angel, Alex, and myself will be at EclipseCon 2008 between Monday and Thursday, and attending as many of activities as possible. In addition to our BUG+SV next Tuesday and speaking at the show next Wednesday, we’ll also be hosting a BUG+Hack event at EclipseCon on Tuesday and Wednesday. Bug Labs will be camping with Cloudsmith in their CloudLounge, located in the lobby of the mezzanine level of the Santa Clara Convention Center. Stop by, load up Eclipse and your OSGi bundles, and have some fun. There will be some great prizes in store (hint hint: a BUGbundle or two) for whoever makes the best BUG apps by the end of Wednesday.

On the OSGi front, there has been some interesting discussion on OSGI consoles. Looks like there should be a standard at some point soon. Have a wish-list or gripes? Might be a good time to check out the mailing list or come to a BoF (Birds of a Feather) session at the show, as I’m sure the topic will come up.

Lastly, I’ve been working on a personal project in PHP and gave the PDT project a try. Wow! The PDT team did a fantastic job. It’s simple, elegant, and “just works”. Reminds me of the profiler we had back in Eclipse 2.11. If you do any PHP development I highly recommend it.

Looking forward to seeing everyone at EclipseCON!

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.