LinuxCon: MeeGo architecture update

Day three of LinuxCon 2011 reserved a separate track to serve as a MeeGo project "mini-summit," consisting of update reports and sessions for application developers. Intel's Sunil Saxena kicked off the agenda with an update on the progress of the MeeGo architecture, including what components changed over the current (1.2) release's development cycle, and where they are headed for 1.3.

MeeGo 1.2, inside and out

Saxena led off with a block diagram of the system components planned for the 1.2 stack, then highlighted which pieces did not make it to the final release (which was made in May 2011). Security was the major hiccup, with several subsystems still flagged as gaps, but system control, resource policy, and backup frameworks remained incomplete as well. Later in the afternoon, Ryan Ware presented a more in-depth look at the security frameworks — worthy of separate discussion — but Saxena addressed the basics.

The old security architecture, Mobile Simplified Security Framework (MSSF), was drafted by Nokia several cycles ago, and put most of the emphasis on constructing a framework for operators to implement handset device lock-down. Since Nokia took MeeGo handset development off of its own product roadmap, MSSF did not reach maturity in time for 1.2 (partly due to the difficulties wrought by Nokia's attempt to make MSSF compatible with Symbian as well as MeeGo). Still, 1.2 did include other key security components, such as the Smack Linux kernel security module, which enables simple file and socket access control.

Other planned frameworks that slipped from the 1.2 release were the Mode Control Entity (MCE), Sharing framework, and some additional low-level APIs. MCE is used to monitor switch and key events from the device, and to control hardware states like LEDs and backlighting. The Sharing framework is a unified API for sharing files through a user-selectable set of channels (email, Bluetooth OBEX, and various web services). The miscellaneous APIs include a Profiles API to manipulate profile options, a Non-Graphic Feedback API to trigger vibration or audio indicators, and the QmSystem API to provide Qt-like access to various system services.

Saxena only briefly mentioned the backup framework and resource policy components that were marked as incomplete in the block diagram. As one might expect, the backup framework is intended to be a flexible API for backing up and restoring both data and device settings. The resource policy component is a bit more involved, allowing device makers to set up rule-based policies that reconfigure pieces of the system in response to events. The canonical example is a rule that automatically re-routes the audio output whenever a headset is plugged in to the device. Because the components listed above were not complete in time for the 1.2 release, Saxena said, they will not be part of the 1.2 compliance testing process.

He then discussed the elements of MeeGo 1.2 that underwent substitutions or significant changes during the development cycle. The first was the Personal Information Manager (PIM) Storage and Sync framework for address book contacts, calendar data, and email. The project has been using Evolution Data Server (EDS) for PIM storage since the 1.1 days, but had initially considered switching to Tracker for 1.2. Upon investigation, the developers found Tracker's privacy controls inadequate — essentially any application with access to Tracker storage would have full access to all (potentially private) PIM data — and its performance and SyncML support insufficient. Likewise, the Buteo framework was investigated as a possible replacement for SyncEvolution, but was found to be immature, so EDS and SyncEvolution remain the storage/synchronization platform for 1.2.

Similarly, the network time daemon timed was under consideration for 1.2, but was found to be too high of a security risk, because it requires privileged access to set the system time, but must be accessible by non-privileged applications. On top of that, it would have required reworking to support the remote time sources (such as cellular) used by handsets to synchronize the local clock. On the plus side, the ConnMan connection manager (which is already used by MeeGo to manage Internet connections) has added time synchronization functionality of its own, so in 1.2 it takes on the duty of clock management as well.

MeeGo 1.2 also introduced a new suite of default applications, written entirely in QML and Qt, and deprecated the MeeGo Touch Framework (MTF) versions of the PIM tools, email client, media player, and other "reference" applications. MTF does live on in several places at least in the Tablet User Experience (UX), Saxena said, such as the window manager MCompositor, and in the input methods.

Progress

MCompositor remains a pain point moving forward, Saxena continued. It runs on top of the standard X.org server, which the project has『been struggling with』in trying to get good, flicker-free application switching. The root trouble, he said, is that X invalidates all graphics buffers on an application switch, which forces the window manager to reload them. Unfortunately, the X server and Qt 4.7 are both required components in MeeGo 1.2. Qt 4.8 introduces a new scene graph that relies on the Wayland display server, and Saxena said that the MeeGo project regards the Wayland/Qt 4.8 pairing as the ultimate solution — although it could be a ways off.

There are other changes in the works, most notably a switch from fastinit to systemd, and substantial work on the resource policy components for the more appliance-like IVI and Smart TV UXes. Saxena also described the effort required to rewrite the MeeGo reference applications from scratch using QML as "huge," and added that performance and stability work remains. The project is also interested in reducing overall size of the MeeGo stack, which he described as noticeably larger than most embedded Linux distributions.

Saxena ended his talk with a discussion of "web app" support. MeeGo does not yet have a web runtime for third-party applications, but he added that the project knows it needs to integrate one "sooner, rather than later." He cited recent developments in Web APIs for audio, video, and local storage, plus improvements in multi-threaded JavaScript as being key functionality that make a web runtime viable for full-fledged application development. On top of that, he pointed out, one of MeeGo's primary selling points with OEMs is the ability to present the same APIs across devices, from cars to smartphones to TVs, and HTML5 simplifies that process.

MeeGo 1.3 is currently slated to be released in October or November of 2011. It should be noted that Saxena's details of the development process and plans for the future apply to the MeeGo Core specification, which is common across all of the device UXes. The individual UX projects may have additional goals and milestones unique to their own device class.

WebOS, privacy, and more

Looking at the plan for the next development cycle (and possibly next few, considering the scope of some of the changes), the web runtime is particularly interesting. It has been in discussion since the 1.1 cycle (2010), and both the developer documentation and SDK mention it in various places — although they call it experimental. Yet it has not made it into the core MeeGo releases.

As luck would have it, just 24 hours before the MeeGo mini-summit, Hewlett Packard dropped a minor bombshell on the industry by announcing its intention to shut down its WebOS hardware business. Immediately after the announcement most of the buzz was that this move spelled the end for WebOS, which was a Linux-based mobile device OS that used a web runtime as its sole application development framework. The remainder of the buzz was spent noting the irony that HP's announcement came mere hours after Phil Robb, director of the company's Open Source Program Office, delivered a keynote at LinuxCon highlighting WebOS's strengths (although it should be noted that no one seemed to have anything other than empathy for the awkward position that HP placed Robb in through this chain of events).

HP subsequently "clarified" its commitment to developing WebOS as a platform, although it is not clear who will be producing WebOS-based products. The senior vice president of Palm (which created WebOS and was acquired by HP) would not rule out the idea of selling WebOS to another company, but the effect that move would have on MeeGo, Android, and other Linux-based platforms depends entirely on the identity of the buyer.

Perhaps predictably, debate in the open source crowd quickly turned to the idea of HP releasing WebOS as free software. Despite containing the Linux kernel and a long list of open source utilities, the remainder of the stack was proprietary. One Identi.ca discussion speculated that there was little value in WebOS's proprietary components, which is ironic considering that its web runtime is a key component currently missing in MeeGo.

Without a vendor making products, HP has a tough fight ahead in pitching WebOS to application developers. In yet another irony, because HP made open standards like HTML and JavaScript the only development option, independent developers have little investment in WebOS itself as a platform. Unless a new champion picks up the cause, WebOS's legacy may end up being an illustration of how difficult it is to "go it alone" developing a mobile Linux platform. MeeGo is not yet shipping on consumer smartphones, but at least by counting on multiple vendors, its fate does not rest in the hands of a single product line.

Naturally, MeeGo faced a challenge in the first half of the year as one of its vendors suddenly changed directions. In his security talk, Ware called this turn of events a chance to redefine the platform, and in some cases, to differentiate MeeGo from the mobile Linux competition. One way to do that, he said, would be to design the security framework that replaces MSSF as one that puts end-user privacy first.

OEMs will no doubt want to include lock-down frameworks and mechanisms to ensure chipset security and trusted application updates. But MSSF is gone for good, Ware said, and the opportunity exists to develop something better. The replacement framework Ware and his team (some of whom are refugees from Nokia) are working on is called the Mobile Security Model (MSM). It includes access control (already implemented by Smack), but encompasses application sandboxing, userspace access to the kernel cryptographic APIs, and integrity-checking as well.

MSM is still in the early stages of development, but Ware also takes the security of the MeeGo project framework seriously. He and the others on the security team have implemented access restrictions on some of the tools, and even did a source audit of the Open Build System that uncovered two previously unidentified issues. They scour the CVE RSS feed and patch all defects, releasing security updates every six weeks.

Remaking MeeGo's security model without Nokia's MSSF certainly is not a trivial task — as Ware pointed out in his talk, the rapid growth of smartphones and the relatively sparse data-protection they tend to offer makes them an attractive target for malware writers. At least in the current plan, MeeGo device owners can count on someone trying to protect their privacy, whether they end up using a smartphone or some entirely different form-factor.

Between its general tendency toward working in the upstream projects and its collection of distinct UX platforms that often seem to operate independently, MeeGo can sometimes be a tricky project to keep tabs on. Now that Nokia's contribution comes almost entirely through Qt development, a much greater percentage of MeeGo's Core development happens at Intel and inside various UX-specific OEMs, such as set-top box vendor Amino along with tablet vendors WeTab and Trinity Audio Group, which makes the problem worse. Thus the mini-conference at LinuxCon made for a good check-up opportunity for those that don't follow the project closely. Like any distribution, it has its fits and starts, but development is moving ahead at the same pace as before.

My first thought was to imagine what android devs must think when reading this report, and how hard they must laugh. Get something out the door, now! Meego does not sound compelling even now, so imagine in a few years time. As a litmus test: how many cool KDE apps do you miss on your android phone?