The OHA is pushing the notion that it’s all about the applications (copying Apple’s “there’s an app for that“):

• “The platform will continue to evolve as the developer community works together to build innovative mobile applications.”
• “Android breaks down the barriers to building new and innovative applications.”
• “Android provides access to a wide range of useful libraries and tools that can be used to build rich applications.”

This notion that it’s all about the apps seems to be working well for Apple. One big difference between Apple and OHA is that Apple only needs to support its own platform, and Apple owns the entire software stack. This lets Apple provide developers with well-defined boundaries around what the platform can do. Android, however, isn’t playing in such a simple environment, and needs to deliver benefits beyond a single platform if it wishes to live up to its claims.

Matt points out that there are several problems with the Android stack that could prevent or hamper development on Android, at least for traditional Linux/UNIX developers.

• Bionic: Android’s own libc implementation is for ARM/x86 only, has only partial pthreads support, has no IPC support, has no STL support. That’s a lot of stuff that Linux app developers need to work without.
• Device Management: Standard Linux distros use the highly-configurable udev and hal components to manage system device enumeration and hotplug support. Android has hard-coded devices into their own init system, so developers will need to modify the init system for any “non-standard” hardware.
• Power Management: Hard-coded for handsets. If you have a disk or other non-handset devices, you’re on your own.

So the benefit to Android device users may be the applications from the Android Market. From the perspective of device manufacturers, you get a high-investment, low-differentiation, ARM-based phone, that can participate in the Android market. Does Google care about the technical issues Matt points out? We’ll have to see whether Google invests in lowering the barriers-to-entry on Android, making system-level configuration easier, supporting a larger number of architectures, and providing standard programming interfaces that developers expect.

UPDATE: Andy in Meld has also pointed me to an interesting post discussing how to get rid of the first-stage bootloader entirely. Now that’s creative!

Back when Linus & Co used odd version numbers for dev releases and even numbers for production releases (e.g. 2.5 & 2.6), users of Linux got some clear expectations from the kernel development team, and commercializers got some breathing room for packaging up their Linux products. Since the inception of the 2.6.x.y development methodology, the kernel guys have drastically increased the volume and rate of changes they pull into the kernel, and no longer provide any breathing room for users and distributors to stabilize.

Making this problem worse, there is also the widely-held belief that the latest kernel is the best kernel.  This just is not the case, as the kernel release trees are peppered with error-prone releases. I think this guy’s problem (and that of his users) comes with trying to keep up with the Community - which is about as useful as keeping up with the Jones’.  Unfortunately, everyone seems to think this is what they need to do.

How will Linux users be able to find a stable, usable system, that provides bugfix updates, and doesn’t ruin total-system functionality?

First, Google has the right to own their applications, but beyond that they also need to provide assurance to the public that Google-branded applications are safe and secure. This is nothing new, the Symbian Signed program was designed to provide this type of assurance to device makers, and network operators. It seems necessary and essential that Google protect the distribution channel of their applications.

On the other hand, Google also has a desire to exert control over the market to direct people to their web properties. The Android platform was sold to developers as an attractive, new open-source project, the next big thing. But ultimately Google wants to make sure their apps show up on whatever devices hit the market - All Your Internets Belong to Us. It’s my guess that this is just the reason that Apple rejected the Google Voice app from the iPhone. Google’s application strategy could have the effect of turning the iPhone into just-another-Google-device.

For the time being, device makers and network operators seem to be warm to the Android platform since it gives them time-to-market advantage for developing interesting devices. But will the market tolerate a Google strategy that effectively renders all players subservient to Google? And does this recent C&D Order represent the first Darth Vader move for Google?

A few bloggers have erroneously surmised that the OS could be SUSE Enterprise Edition, or some other off-the-shelf distro. Around here we know better—it was actually developed in-house by MontaVista. We call it Montabello. I provided a Montabello demo at the CELF Embedded Linux Conference this past spring. It was running very well on a TI Beagle Board, which gives some indication of its flexibility.

What is most innovative about Montabello is not actually the technology—after all, single-board computers have been running variants of Linux for a long time, and certainly there are other MID packages available. The exciting aspect of Montabello is the hybrid arrangement, putting two separate computers in the same case. In the course of a normal business day, I know I spend far more time on email and browsing than I do on pretty much any other task, and it is getting to be more that way as more of my activities are handled in the cloud, sometimes our private cloud here at work and sometimes out in the world. It makes no more sense to run a full laptop for that activity than it does to take a dump truck to the grocery store. Latitude ON is more like a Tesla: not a lot of hauling capacity, but it gets you where you need to go quickly and extremely efficiently. Like a cell phone it is literally always on, so boot time is immaterial.

Check out the video demonstration that puts Montabello through its paces. It’s interesting, innovative stuff, and I predict there will be many more products using this arrangement in the future.

I downloaded an ISO which I booted into VMWare, and after just a few seconds I was asked whether I wanted to Install, or proceed to the Desktop. I liked that. Once I got to the desktop, I’ll admit I was a bit lost. I started clicking on icons to see if I could find anything interesting. I quickly found the documentation, which appeared to be aimed at developers, not users. The docs launched in a browser, with a link to Access at the bottom - I didn’t investigate that relationship any further. I then launched the Wonder Brush drawing app which performed fairly well IMHO for inside a virtual machine.

For now Haiku appears to be a novelty. I had fun spending 15 minutes playing with it, but it’s not immediately apparent how it can become relevant beyond a few enthusiasts or hobbyists. And if you’re working on an open-source implementation of OS/2 Warp 4, let me know.

The MontaVista Integration Platform centerpiece is BitBake, an open-source build system that makes make look absolutely steampunk by comparison. BitBake is an object-oriented, Python-based build system that uses “recipes” as instruction sets. Recipes build on each other using straightforward rules of inheritance. Frequently-used instructions can be collected in a class and called rather than replicated, making new recipes very easy to write. MVL6 comes with a set of metadata that enables developers to mix and match recipes with impunity.

MVL6 has been compared with OpenEmbedded, the open-source metadata system on which MVL6 was originally based. OpenEmbedded also enables developers to build images using BitBake recipes. However, MVL6 is as similar to OpenEmbedded as MVL5 was to RedHat Enterprise Linux (RHEL), which is to say, not even close. The actual bits that are used by BitBake in MVL6 are customized for each hardware platform that MontaVista supports, and are collected into MSDs. Each MSD represents a custom, per-board distribution, fully tested, that provides features and functionality above and beyond anything available from OpenEmbedded, served from a central Content Server that is guaranteed to contain the content described in the MSD.

At a previous employer I was on a small engineering team responsible for producing a commercial Linux distribution. Our “build system” was 1) a guy on the East Coast and, 2) some scripts on his workstation - the workstation could never be updated or modified lest we risk breaking the build.

A large conference was coming up and we needed to demo our latest software, so we crunched to get the latest bits checked in and our build guy produced some DVD images and FedEx’d them to San Francisco. We receieved the DVDs on a Friday afternoon, only to discover that upon booting the new OS the kernel panic’d.

With less than 2 days to get the system ready to ship over to the conference, and the East Coast build guy off for two weeks of vacation, the two West Coast engineers (myself and a co-worker) spent the weekend in the office pulling apart SRPMs, manually patching sources, and doing whatever we needed to cobble together something that would boot and demonstrate the applications we had ready for the show.

The products we shipped at that company were enterprise-oriented, and so the build system was really only critical to our internal process - our customers never ripped the system apart, even though it was Linux-based and they had every right to do that. Now that I’m out of Enterprise and in Embedded, I see that customers almost always want to take our products apart and put them back together to customize for the embedded devices they’re making. IMHO, this makes a build system a basic necessity of any embedded Linux product, and I’m glad MontaVista has been able to rally around the open-source build engine
bitbake and ship it in our latest product.

To start with, the biggest change in MVL6 is in content delivery—how we get bits to you to play with. In the past, MontaVista Linux shipped with a standardized kernel, the same for all platforms, and a Linux Support Package (LSP) which consisted of a set of supporting patches, utilities, drivers, userland bits, and development tools. The patched kernel and the rest of the LSP provided developers with a customized work environment for a particular hardware platform.

MontaVista Linux 6 improves on that by serving all those bits from a central Content Server. The tools we provide to access that content are called the Integration Platform, and they consist of a few very easy-to-use project management utilities and a very powerful open-source build tool called BitBake. BitBake is like make on steroids, and it has the ability to automatically download all of the content you need from the MontaVista Content Server. BitBake’s real strength is in the large, integrated, tested set of metadata that enables it to build an bootable image (kernel and root filesystem) with a single command. Adding new components or customizing existing ones is easy, repeatable, and well-planned.

The other major change from previous versions of MontaVista Linux is the introduction of Market-Specific Distributions (MSDs). These are functionally similar to LSPs, but instead of being a set of patches and additional bits, MSDs are complete, optimized distribution mechanisms in themselves: specific to a market rather than an individual board, feature-complete with the Linux distribution from the hardware vendor, and packed with MontaVista-supplied add-ons, quality testing, support, and build metadata.

Watch this space for more information about MVL6.

http://www.ibm.com/developerworks/linux/library/l-beagle-board/index.html

After you read it, be sure to visit us in the Meld TI discussion group to discuss!

Watch this space in the coming weeks for more on MVL6.

What I like best about this representation is its family tree aspect, specifically the part showing the “new” Atom processor evolving directly from the older P6 architecture rather than from more modern (some might say “overmodern”) generations of packaged cleverness. The drawing was created by Klaas van Gend, one of my colleages at MontaVista. Thanks, Klaas!

Full disclosure—I am an admin for the Meld community. Feel free to poke around and join us, as there is more where that came from.

The news today says that design automation leader and Nucleus RTOS provider Mentor Graphics is buying embedded Linux tools provider and professional services contractor Embedded Alley for an undisclosed amount.

The most notable aspect of this is that it comes on the heels of Intel’s acquisition of Wind River Systems. Fire sales and mergers are not unusual during flagging economic times, but this is the first time I have been aware of such consolidation happening in the embedded Linux space—not unusual, as that space has only existed for 10 years and this is its first recession.

I would wax poetic on the ramifications of this merger, but Bill Weinberg has already done so. (Hi Bill!)

Meanwhile, I’ll continue to concentrate on helping to get MontaVista Linux 6 out the door.

However, there still exist some corners of the tubes where actual technical conversation still happens. These are a few of those corners that cater to those of us with a taste for embedded Linux. Please feel free to add to this list in the comments below.

Social media:

These include communities dedicated to embedded Linux, wikis, etc. Blogs are listed in a separate section.

• Meld has been called the “Facebook of embedded Linux”, and not just by me. Conversations tend to get very technical. Stop in and join the discussion groups. [full disclosure: MontaVista sponsors Meld, and I am a Meld admin]
• Elinux.org is an excellent wiki maintained by CELF. The wiki contains a huge amount of embedded Linux information and is growing all the time.
• Embedded group on Linux.com, recently absorbed by the Linux Foundation.

Blogs:

Do blogs count as social media? Almost certainly. Here are just a few that discuss embedded Linux:

• Jeff’s Open Source Resource [full disclosure - that’s me]
• Kate Alhola’s Maemo blog
• Embedded Linux Interfacing, serving the Embedded Linux community since 2001

Embedded Linux appearances in other social media:

Our presence is small, but loud.

• Twitter supports many fascinating twigs and branches, some of which, like Meld and MontaVista, relate to embedded Linux.
• Google Groups hosts many groups related to specific projects, e.g. the Beagle Board discussion group.
• LinkedIn Embedded Linux group.
• Facebook Embedded Linux group. Be sure to also visit MontaVista’s page.
• MontaVista on YouTube. There are more embedded Linux videos there as well, just search on “embedded linux”.

The short answer is that I am an ambassador for Linux developers, currently acting within this corporate structure. Obviously I have a vested interest in helping MontaVista succeed. What that means to me, though, is that a major component of that interest is to help embedded Linux developers succeed in general, partly because they may someday become MontaVista customers, but mostly because they help to advance the cause and penetration of the current best embedded operating system.

As a community admin, technical writer, and developer, I have several avenues by which I advocate.

One is that I help to administer an open community called Meld. Meld is sponsored by MontaVista, but it is truly open, meaning that anyone can join and discuss any embedded Linux topic, including the merger of Wind River with Intel, the recent webinar about fault-tolerant memory management, or even the thrill of rolling your own kernel, none of which directly involve MontaVista. In company meetings about Meld and at conferences, I try to represent the needs of developers at large and help to keep Meld open and non-corporate, although I’m swimming with the flow in that case—MontaVista as a corporation and the entire Meld team are as dedicated as I am to that level of openness.

Another way I advocate for developers is as a technical writer, by helping to document important tools, like MontaVista Linux 6. It is fascinating to be a part of building such a complex tool and useful tool and to try to find the best ways to explain it.

A third method is to find ways we as a company can give back to the communities that support us. This is more than just the kernel community, of course: CELF and elinux.org, the Linux Foundation, OpenEmbedded and BitBake, and Moblin are all organizations and projects that share a common goal in helping embedded Linux succeed.

Actually, to boil it down, I figure it is my job to help embedded Linux developers succeed. I think that sums it up nicely.

If you are an embedded Linux developer, don’t be shy about letting me know how I can help YOU succeed, by email or in the comments below.