Some may be surprised by the merger, announced this week, of the open source Maemo and Moblin projects, given their architectural differences. Maemo targets ARM, while Moblin aims to enable devices with Intel Architecture (commonly “x86”) processors.
Put aside that difference, though, and the projects are peas in a pod. Furthermore, given that the Linux kernel supports more than two-dozen architectures, can’t open source app stacks evolve beyond architectural boundaries? Sure they can, and many have.
Details about MeeGo are still emerging. However, from materials published so far, it’s pretty easy to guess how the project aims to exploit Maemo and Moblin similarities, where it plans to chart a course of its own (mainly to encourage portability, it seems), and where it could have some work to do ironing out differences between the stacks.
Going Native
Both Maemo and Moblin emphasize native Linux development. This contrasts with managed environments like .NET, Android, and the various Linux/Java mobile phone stacks. Both approaches are good; they are just different.
Native Linux environments like Maemo and Moblin are beloved for their familiarity, flexibility, and performance. Developers link in standard GNU/Linux libraries, and use standard Linux calls, because they are writing native Linux apps. Porting existing open source apps is comparatively easy.
In a managed environment, developers primarily write/port apps to run atop a runtime, such as a virtual machine. Calls to the underlying OS and hardware can be limited by or filtered for this runtime, affording some global control over app behavior.
Like Maemo and Moblin, MeeGo will support native apps. However, it will also support “web runtime” apps. Palm’s Netkit-based WebOS has certainly shown that Javascript/DOM/XML/CSS are increasingly able to provide a viable alternative to traditional managed environments, on phones and elsewhere.
Software, Software Everywhere, and Not a Bit to Twiddle
Ironically, one drawback to native environments is that “full” Linux is just incredibly vast. So, projects like Maemo, Moblin, and now MeeGo aim to bring coherence by “standardizing” things like what libraries are present, and what versions of tools are used to build binaries. Just as “standardized parts” reduce maintenance and support costs in practically every machine since Ely Whitney’s cotton gin, standardized native environments exist to tame the unruly bazaar, foster re-use and create engineering efficiency.
Eventually, the MeeGo project will announce its first “final” API, or application programming interface. This is essentially a list of standard software parts that developers can draw from when writing and porting their apps to the initial MeeGo release.
The MeeGo project has also promised some tools and/or services whereby apps can be validated for compliance. Such items often appear concurrently with or soon after API releases, sometimes accompanied by reference implementations, too.
Both Maemo and Moblin strive to standardize things enough to ensure full application binary interface (ABI) compatibility within major releases. In other words, an application built for Maemo 4.0 should run without recompilation on 4.6, but would need some adjusting and a rebuild to run on 5.0. Look for MeeGo to embrace similar goals, with a year or two of ABI stability between major version releases.
First, though, MeeGo has to pick what parts to include.
Eeny, Miney, API
MeeGo’s website suggests its API will merge the Maemo and Moblin APIs, picking the best of each. As it happens, there’s actually a lot of commonality between the APIs. This isn’t surprising, given the similar device types targeted by Maemo and Moblin. Handhelds, netbooks and the various other targets all have small screens and limited power/CPU budgets, while at the same time demanding sophisticated UIs based on PC motifs, media playback, always-on heterogeneous networking, and ideally, appliance-like stability.
As Maemo and Moblin merge to make MeeGo, some duplication may be found. Some will be tolerated, especially in early releases, for the sake of backwards application compatibility with both projects. Over time, MeeGo will likely gravitate to one alternative or the other, or in some cases toward merged, hybrid versions.
In other cases, MeeGo will actually change directions from both Maemo and Moblin, and strike out in a new direction. That seems to be the case with the move to the MeeGo UI Toolkit (MUT), which will be based on Qt (pronounced “cute”), rather than the GTK option favored in Moblin and the early, more widely distributed versions of Maemo.
Qt’s strength has always been cross-platform portability and tools integration. It started out more than a decade ago as the C++ runtime component of then-Trolltech’s cross-platform toolkit, which aims to let developers reuse significant portions of a single code base when targeting multiple OSes and architectures. So portability was baked in from the start, both in the tools and in the library. Over the years, Qt has been deployed and heavily tested on Windows, Linux, an embedded Linux subset, Mac OS, Mac OS X, Windows CE, and Symbian S60. GTK+, in contrast, supports only Windows, Quartz (Mac OS), DirectFB, and Linux (albeit on several architectures).
Other than MUT, though, MeeGo mostly avoids specific software project names. Still, it’s fun to guess which projects will make the MeeGo “cut,” as it were. So enough with the high-level overview… let’s get down to guessing some actual specifics.
Leggo My MeeGo
We know that MeeGo will use RPM packaging and kickstart build macros, like Moblin, rather than DEB packaging and scratchbox, like Maemo. Some may lament the loss of the powerful dpkg/apt suite of management tools, while others may note that without apt-get dist-upgrade, Maemo’s usage of DEB seemed a bit unfinished, anyway. The payoff for developers could well be nifty “image creation” tools similar to those we’ve seen from the Moblin project.
MeeGo will use an RBAC security framework that apparently spans the complete height of the stack, from kernel to apps. The best-known RBAC implementation for Linux is SELinux, which was at least partially integrated in both Moblin and Maemo, so that looks like a pretty obvious choice for MeeGo, too.
MeeGo will use a kernel.org kernel, along with a “Hardware Adaptation Software” layer that, as in Maemo and Moblin, can apparently include proprietary (binary-only) kernel drivers. Vendors will just have to include appropriate patches and config files to make it all work.
TheMeeGo.comwebsite includes pages for five UX “experience” layers, including netbooks, handhelds, media phones, connected TVs, and in-car infotainment. The netbook page includes a graphic that looks just like Moblin. The MeeGo “Handheld” UX layer will likely look a lot like Maemo 5.0, though no screenshot is included. The in-vehicle infotainment is likely heavily Moblin-based. Media phones and possibly connected TVs, too, will likely be Trolltech’s old Qtopia phone UI layer, which was very big in VOIP phones, and in devices, generally.
Over time, other vertical MeeGo spins could be developed by the community… digital signage, PIN-pad terminals, and HMI (human machine interfaces) come to mind as possibilities. However, since UI stack components will be encouraged to use a permissive OSI license, like BSD, there may not be a heck of a lot of incentive for contributions in this area.
If complete vertical stacks do emerge, they could well attract new architecture ports from the community. The MeeGo FAQ page notes that community-contributed architecture ports may happen. At the same time, it’s hard to imagine ports of MeeGo to other architectures, without support for that platform appearing first in QtCreator — which is something Nokia/Qt Software would be best-positioned to drive.
The Beginning is in Sight
Things will begin to take a more definite shape in the coming weeks, as the MeeGo project website begins adding source code. The first release is currently scheduled for Q2, 2010. Once that happens, we’ll not only be able to peek under the hood, but kick the tires, too.
* Disclosure: Linux.com is a Linux Foundation web property.
