A look at Mer
The Mer project was born out of the ashes of the MeeGo mobile-oriented distribution in 2011. In an admittedly provocatively titled talk ("Mer & Qt : What MeeGo Should Have Been!"), Mer advisory board member David Greaves gave an overview of the distribution project, some of its history, and its plans. "MeeGo is dead", he said, but it did a lot of good; Mer is one of the good things that came out of it.
We owe thanks to both Intel and Nokia for MeeGo, Greaves said. MeeGo didn't succeed in what it set out to do, but it did succeed in other ways. Mer is part of the "story of what happened after the big guns left" the MeeGo project. Mer is being used by numerous projects including Jolla/Sailfish OS, Vivaldi, in-vehicle-infotainment (IVI) systems, and others. The project is proud of what it has achieved so far, but would like to see more people using it.
What is Mer?
Mer is targeted at phones ("of course"), but also TVs, cars, tablets, and even appliances like refrigerators. More and more small businesses are prototyping devices on hardware like the Raspberry Pi, and many of them are doing so using Qt or Qt-based frameworks. Mer fits well in that world.
As part of the formative process of Mer, Greaves and others looked at "what MeeGo did right" and concluded that it was the focus on "making it easy to make devices" that was a major selling point. But, MeeGo was monolithic and had lots of packages. Mer needed to break that up and make a distribution that was non-monolithic: a small core that would make a good foundation for mobile and smaller devices.
Mer has had "good success" in attracting vendor interest, Greaves said. Qt and QML (the JavaScript-based language for building Qt user interface elements) are at the heart of Mer. Quality is another important aspect of the Mer project and various automated testing processes are used to help ensure that the distribution works well.
But Mer is not a "user experience" (UX) and has no user interface as part of the core. There is a "splash screen" that exercises GLES, but that's it. Mer is roughly 300 packages, down from MeeGo's 1500, which means there is less to test. It also makes choices among competing packages, reducing the number of alternatives for vendors—at least in the core. Device vendors can change to different technologies if they wish, though. Greaves noted that Plasma Active (the KDE-based tablet UX) uses NetworkManager, rather than ConnMan from the core.
Various UXes have been added atop Mer for different device niches including Nemo for mobile, Plasma Active and Vivaldi for tablets, TVOS (from China) for TVs, Lincor for healthcare, Nomovok for IVI, and more. It supports x86 (both 32 and 64 bit), ARM, and MIPS. It is available for multiple platforms as well, including Nokia N950/N900/N9, ExoPC, Raspberry Pi, PandaBoard, and BeagleBoard.
Mer makes sense for a company on a couple of levels, but some management persuasion may still be required to make the switch. Greaves said. It will allow the company to operate efficiently and deliver products quickly. Companies can use closed code if they so desire, as well. There is also a low barrier to entry to the Mer community. There is no consortium or "joining required"; basically all it takes is to come to the IRC channel and start talking with the community, he said.
The Mer project is pragmatic and operates entirely in the open, Greaves said. It is a meritocratic community that aims to be inclusive. The management layer for the project is thin, most of the work goes into technical efforts to make Mer better.
Mer is a core part of the Sailfish OS mobile operating system from Jolla. That means there is an open source project at the heart of Sailfish OS, he said. He likened the Mer ecosystem to that of Qt, which has multiple companies and organizations, including Digia, KDE, KDAB, and others, all working together to make Qt better.
The Mer core has a "whole load of stuff" in it, but it is really just the minimal set of packages to get Qt running. But "code is not enough"; there needs to be build, QA, and collaboration systems, as well as documentation, support, and information on "best practices". So, beyond just the code, Mer offers a number of other services, including Open Build Service (OBS) systems, a Business Operations Support System (BOSS) based on ruote, and cross-building support based on Scratchbox 2 that is integrated with OBS.
Greaves then turned to libhybris, which was created by Mer founder Carsten Munk. It came about after a meeting in Finland where there was "quite a bit" of drinking—and talking. There is a basic mismatch between Android libraries, which use the Bionic C library, and systems that use the GNU C library (glibc). So Android graphics drivers can't be used by Qt, for example. The meeting participants were not convinced that there was no way to bridge that gap between the two C libraries, and Munk put together a library to get glibc programs working with Bionic-based libraries: libhybris. Canonical is using libhybris in devices, he said; it allows companies to take a board that only has Android graphics drivers and run Qt (and Mer) on it.
The SDK
There is a Mer SDK that allows developers on multiple platforms (Windows, Mac OS X, and Linux) to build Mer itself as well as apps for Mer. It can also be used to develop a full user interface for a device. The Mer SDK consists of two parts: a Platform SDK and plugins for Qt Creator to communicate with the Platform SDK. Jolla has supported a lot of the work on the SDK, he said.
The Platform SDK runs in a virtual machine using VirtualBox. Instead of creating a version for each distribution and operating system, it is a self-hosting platform. It could also be done using LXC or chroot() and namespaces, but it is using VirtualBox for now. It has all of the low level packages for building and testing that are needed to build Mer packages for a specific target.
On top of the low-level pieces, there is a Qt Creator–based interface that includes Mer-specific plugins to talk to the Platform SDK. Those plugins control emulators and devices, which is not normally a part of Qt development. There are also plugins to handle packaging metadata and to interface with app stores. The Mer project will be working with the Qt project to get those pieces upstream, he said.
The Platform SDK plus the Qt Creator plugins make an overall Mer SDK, which is a starting point for a vendor SDK. For example, Jolla has added Sailfish OS targets to turn it into a Sailfish SDK. It is designed to be extensible and to be used for different targets, such as MIPS, ARM, or x86.
Qt Creator runs natively on the developer's system, but interfaces with the Platform SDK via the plugins. Building the code is done the same way, whether it is initiated from Qt Creator or OBS. VirtualBox shared folders are used between the workstation and the Platform SDK, so a build from Qt Creator does an ssh into the virtual machine and executes make there. Apps can be deployed that way as well, so that developers don't have to build and install a package each time they want to test on an emulator or a real device.
Plans
So there is a build engine, but what is needed now are more emulators and targets, Greaves said. Nemo, Plasma Active, and Raspberry Pi are all good candidates. Better emulation support is also on the roadmap, including simulating hardware events in the kernel. A move from VirtualBox to LXC is also in the cards, as is better debugging support.
As with most projects, Mer needs help, so Greaves issued a "call to action". He noted that Mer is a vendor community, but that using the term "cooperative" may be more successful when talking to management. There are a number of benefits to working with Mer, but the biggest is that those working on the project can influence its development direction. There are multiple choices for mobile development, including Windows Mobile, iOS, Android, and Tizen, but none of those will give a device maker the freedom that it wants, he said. Even though Android is open source, how many have actually gotten patches accepted into it? For that reason alone, Mer should be very appealing to smaller device vendors.
[Thanks to KDE e.V. for travel assistance to Bilbao for Akademy.]
| Index entries for this article | |
|---|---|
| Conference | Akademy/2013 |
Posted Jul 30, 2013 6:18 UTC (Tue)
by jeff@uclinux.org (guest, #8024)
[Link] (3 responses)
After reading this, I have less of an idea than I had before. I thought it was a graphics server/layer...
"The Mer core has a "whole load of stuff" in it, but it is really just the minimal set of packages to get Qt running."
What does that mean? Anyone can run Qt on a frame buffer in an afternoon, without a graphics server. Embedded systems (you mentioned fridges) are not about "packages", generally. Finally, graphics servers that are tied to a widgets kit kind of miss the point.
So... what is Mer again?
Posted Jul 30, 2013 6:22 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Jul 30, 2013 11:16 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (1 responses)
- Mir is an alternative to Weyland, a graphics layer; both intend to substitute X11R7's graphics layer as the default; Mir is a canonical.com project while Weyland is a x.org project.
- Mer is a fork of MeeGo; both are (semi-?)complete distro/stacks for smartphones; the history goes like "once upon a time there was Intel's Moblin and Nokia's Maemo but they got married and became MeeGo; but Nokia got in bed with Microsoft and Maemo became Harmattan but now she wants to be called Maemo again, MeeGo became Tizen and went to Samsung, and the community forked it into Mer."
Posted Aug 4, 2013 19:14 UTC (Sun)
by nlucas (guest, #33793)
[Link]
NOTE: I have no inside information about this. It's just what I remember of reading about.
A look at Mer
A look at Mer
A look at Mer
A look at Mer
