LWN.net Weekly Edition for May 8, 2014

Jolla and Mer

As David Greaves held up a phone to begin his Embedded Linux Conference talk, he said that it would be no surprise that phone was not running Windows Mobile or iOS—the surprise is that it is not running Android either. In fact he was holding up the Qt/Wayland/systemd/Btrfs phone, which is better known as the Jolla phone. In reality, though, it is really a "Linux phone", he said, unlike Android-based phones.

Greaves started out at British Telecom, then worked on Maemo, and then its successor, MeeGo. The latter has been shut down, but Nokia and, especially, Intel did an awful lot of work in creating MeeGo. Two guys (he and Carsten Munk) looked at MeeGo and saw much that was useful there, so they founded the Mer project, he said. MeeGo was a bit over-ambitious, though, so Mer slimmed down MeeGo's 1500 packages to around 300.

That's the background for the Jolla (which Greaves pronounced as "Yah-La", which contrasts with our last attempt at capturing the pronunciation) phone. But he stressed that he was not giving a "pitch for Jolla", who he works for now. He is proud of what the team of 90 people has done in less than a year, in hardware design, and the development of an operating system and user interface, but the fact that Jolla has "proven" the Mer approach is also important.

One thing that Greaves's talk did not do was to dispel the murkiness around the boundaries and capabilities of the various components. Projects like Mer, Nemo Mobile, Sailfish OS, and the Jolla phone have been talked about over the years, but it is (and always has been) a bit unclear where one project stops and the next starts up. Part of that is likely caused by the overlap in participants among those projects, but it does, at times, get rather confusing.

In any case, Sailfish OS can (obviously) run on Jolla devices, but it can also run on the Galaxy S3 and the Nexus 4. That is part of the Sailfish for Android project. Support for more devices is in the works using the Hardware Adaption Development Kit (HADK or "haddock" following the nautical theme). The idea is that any device that is rootable and will run CyanogenMod will also be able to run Sailfish OS. That will allow many more folks to try out the phone operating system without buying any new hardware.

Technology

The user interface (UI) is important, Greaves said, and "a good place to start" looking at the technology used in Mer/Sailfish OS. The UI is based on Qt 5.2 and Qt Modeling Language (QML, the JavaScript-based UI language for Qt). Qt was chosen for a number of reasons: it performs well, is open source, is not Java-based, and it has a huge developer base. In addition, the existence of QML played a role in that decision because it allows rapid UI development, he said.

QtWayland replaces Android's SurfaceFlinger as the compositor for Sailfish OS. It is not currently using the Android HWcomposer (for 2D graphics) "strenuously", but there are plans to do more of that. The performance of QtWayland is "pretty damn good". Wayland was chosen because it is not difficult to work with and it meshes well with the Android shared-buffers approach, he said. In the end, the developers don't really notice Wayland at all, since QtWayland basically handles that interaction for them.

One area where Qt has problems is its size. It it is a "big piece of software", which means it eats up a fair amount of phone resources. But Qt 5.2 has started modularizing Qt, so that only certain parts need to be included.

Another technology used in Mer/Sailfish OS is systemd, which has "been quite polarizing" in the open-source world. There is something of a love it or hate it attitude about systemd, but they came down on the "love it" side, Greaves said. There were times where "we swore a little bit" at systemd, but by and large it served their needs well.

Systemd is "really fast", predictable, and well-documented, he said. The Journal is "a good fit for us" as well. There have been some issues with user sessions, but part of that may be that the version of systemd was adopted "a long time ago in systemd time". In fact, the biggest problem they have run into with systemd is its rapid development pace and how closely tied it is to newer kernel versions. He hopes that Debian adopting systemd will help alleviate some of those problems in the future.

For Sailfish OS, there is a mix of systemd and Android init code. In fact, the Android init is being run as a service under systemd. The uevent data from Android is being interpreted by udev rules and mount units are created from the Android rc files. Jolla is still exploring how to manage the "mix of two worlds", he said.

Mer/Sailfish OS uses Btrfs for storing data. No partitions are used; Btrfs's dynamic subvolumes are used instead. Snapshots are used to restore the factory settings, but those settings are old at this point, so Jolla is looking into updating that snapshot. In addition, it is looking at using snapshots for features like rolling back unwanted changes and for easy backups.

For handling the network, ConnMan is used. They ran into some problems using it, but writing ifup/ifdown scripts would have been far worse, he said. A recent upgrade to a newer version of ConnMan has helped, too. There are some difficult issues around network handling, no matter what solution is used. The rules for choosing when to use various data sources (3G, WiFi, etc.) and when to switch between them are rather complicated. For phone features, oFono was used, while PulseAudio handled the audio path; both worked quite well, with few problems, he said.

Libhybris

System-on-Chip (SoC) makers typically only create board support packages (BSPs) for Android. "Open hardware is great", Greaves said, but there is not much of it around. Instead there are a bunch of user-space blobs for various pieces such as the camera and haptic feedback. All of those blobs use the Bionic C library, but Sailfish OS (and many other Linux systems) use glibc. Hybris (or libhybris) is meant to bridge that gap.

The idea is to allow Bionic-using code to co-exist with glibc-using code in the same process address space. It required wrappers around Bionic functions and some name mangling (prepending "android_" on Bionic functions for example). It was done with relatively few patches (around ten) to Bionic, he said, mostly for functionality like POSIX threads, errno, hardware vs. software floating point, and so on.

Using libhybris means that, for example, the Android EGL and GLES libraries can be used by glibc applications. Then it is just a matter of "rinse and repeat" to get wrappers for other Android libraries, like Gralloc, NFC, OpenCL, Camera, and so on. Greaves said that the project(s) will be trying to make libhybris work for any device that has a CyanogenMod build.

The rest of the phone is a "fairly standard Linux stack". It uses Git for phone backups, though some tweaks were made to handle videos since "Git-committing videos is not a bright idea". It uses RPM as its package manager, and Gstreamer for multimedia content. It uses the Linux kernel, too, of course, though the project doesn't do much with it: "if it boots and runs the hardware", it gets left alone.

If you build it ...

The Mer project has a Platform SDK that is used to build it. Mer "didn't want to have to worry" about which tool versions were installed on the builder's system, so it includes all of the right versions to be used inside of a chroot(). It uses Scratchbox2 for cross-compilation support. Scratchbox2 is "sane, sensible, and usable", Greaves said, which is quite a departure from the earlier Scratchbox. It is so much different (and better) that he wishes it had been given a new name.

Packages can be created easily. Typically it requires some minor tweaks to an existing package spec file. The result of the build is an RPM file that can be installed on the device. There is some LD_PRELOAD trickery in Scratchbox2 to invoke the cross-compiler (using Lua to do pattern-matching), all of which is "a little ugly", but makes it "seamless to the developer", he said.

The SDK can run in a virtual machine, which allows Windows and Mac users to use it. There are a small number of people in the company and project, so porting all of the tools to multiple platforms is not a viable solution. Virtualization solves that problem, he said.

Jolla and Mer use the Open Build Service (OBS), which is an "incredibly powerful build system", he said. Mer focuses on trying to enable vendors to make products, and OBS fits right into that model. Someone can submit a package to OBS and it will automatically build versions for multiple architectures.

It is not just packages that are built that way, though. The latest development tree of Mer and Sailfish OS are built regularly, typically driven by Git commits. The automated system will invoke mic (originally, the Moblin Image Creator—and the reason Mer had to start with an "M", he said with a chuckle) to create an image that can be flashed onto a device for testing.

Working in the open

Mer and Jolla came out of Maemo and MeeGo, which taught them a lot about working in the open. In the MeeGo days, some of the now-Jolla folks sometimes gave Nokia and Intel a hard time about not working more in the open. But now, those folks appreciate the problem from the other side. It's a hard problem and they are trying to learn from the mistakes that have been made in the past.

For Jolla, there are (at least) two pieces to the problem: working with its upstream (Mer) and collaborating with other vendors on new devices. Jolla's internal policies are geared toward the way it works, some of which may or may not mesh well with open-source projects and Mer in particular. For example, all commits must refer to or close a bug number (as the bug tracker is also used as a task tracker). There is an automated process that adds the commit message to the bug tracker, but that isn't particularly useful for Mer, which has a public bugzilla.

Jolla has an internal open-source policy as well. To start with, employees should participate in open-source projects as themselves, rather than as representatives of Jolla. But not all employees came from an open-source background, so some amount of education is needed. Policies covering interactions with projects is part of that as well. Helping to create those policies sometimes made Greaves feel like Bill & Ted: "Be excellent to each other", he said with a laugh.

The Mer project consolidates all of the open-source work that Jolla does (much of the UI layer is still closed). The Mer project's vision is "to make it easy to make devices". That explains what the project is doing and why, he said. For example, there is no UI for Mer. Nemo Mobile was a project started to create the middleware and UI for Mer, but most who are using Mer also use the middleware, so the middleware has been moved into Mer. That means that Nemo Mobile is just UI now, which shrinks it down considerably and, he hopes, makes it more accessible as a community project.

From the Mer project's point of view, the Jolla device is "huge credibility shot" for the project. But Mer works with others too, including Ubuntu and Intel on libhybris. Mer aspires to be more than just code, because "code is not enough". For devices to be easier to make, it requires best-practices documentation in lots of areas: quality assurance, how to do releases, how to manage regressions, building images, handling source repositories, bug tracking, and more.

But, the Jolla phone has shown that the Mer approach works. It took around nine months for 90 people to deliver a working phone with a brand new UI. Others can do the same.

All of the projects would love to have more participants, he said. For example, the camera does not currently work on Sailfish for Android on the Galaxy S3, but Ubuntu got the camera working for Ubuntu Touch, so "come help make it work". In addition, phone platforms are really just 3G data platforms with a touchscreen and some other interesting hardware; phones are not the only things that can be created on such a platform.

While Mer-based devices may not be free-software compliant (because of the binary blobs), Mer will be ready when free drivers come along. It doesn't make sense to wait for those drivers and then to start working on phones and other devices, he said. In that scenario, devices that are free-software-only will have fallen way too far behind.

Comments (19 posted)

A look at LyX 2.1

LyX is a graphical document editor that serves as a front end to TeX and various TeX extensions (LaTeX, XeTeX, etc.). In that sense, LyX serves as a bridge between the high-precision world of TeX typesetting and the easier-to-use WYSIWYG world of word processors. Version 2.1.0 was released on April 25, incorporating updates to the handling of special-purpose content like equations or phonetic notation, improvements to LaTeX option support, and several new page-layout features.

The new release is available for download as source code and in binary packages for a variety of Linux distributions. It requires a working LaTeX installation (due to LaTeX's modularity, almost any modern version should be compatible) as well as Qt and Python.

LyX aims at a target that, to some, sounds inherently unattainable: it is designed to make TeX documents as easy to work with as generic letters and memos are in a word processor like LibreOffice Writer. The challenge stems from the fact that TeX was created to enable fine-grained manipulation of typesetting features that word processors gloss right over. TeX succeeds at this goal, which is why it is the de-facto document-preparation system for scientific research—after all, when one's PhD or professional reputation is on the line, having the equations look "more-or-less correct" just does not cut it. But, in practice, TeX achieves its precision by relying on well-honed macro collections and predefined document classes. Projects like LaTeX and BibTeX provide useful macros and shortcuts that authors can employ rather than writing raw TeX markup by hand.

Even so, the fact that authors can always drop down into TeX markup to handle the inevitable corner cases or specify mathematical formulas directly in math syntax is a strength—when no LaTeX option generates perfect output, TeX is always there to come to the rescue. Consequently, there is a school of thought which says that LyX, with its word-processor-like interface, does not add to the TeX-writing experience, it simply hides it behind another layer of indirection. That is, LyX users are not freed from the need to understand LaTeX and TeX, since they will eventually confront the same corner cases.

But that viewpoint short-sells much of what LyX has to offer. Yes, LyX provides a word-processor-like graphical user interface (GUI), but the GUI does not hide TeX's features from the user—it provides a way to access them via visual cues in the document and GUI components (e.g., toolbars and menu items). LyX does not reduce TeX to an implementation detail, but it makes it easier to create a valid TeX document—and, perhaps more importantly, it makes it more difficult to create a bad TeX document.

Many of the improvements found in LyX 2.1 illustrate this fact. For example, the most basic decision about a LaTeX document is the class to which it belongs, but not only do generic offerings like "letter" and "article" exist; each field, journal, and professional organization can have its own stylistic rules, with a separate class to represent them. In LyX 2.1, all of these classes are organized into categories (as opposed to the flat list of previous generations), which helps make sense out of the plethora of alternatives.

Similarly, version 2.1 adds GUI support for accessing far more LaTeX options, and it does a better job of presenting and explaining those options to the user. LaTeX provides macros that simplify formatting for common document features, such as code listings; LyX exposes the various options in pop-up dialogs. In 2.1, these option panels have been rewritten to standardize terminology, make all options visible at the same time, and to allow presets for common values. Support for several new commands has been added as well, many of which deal with mathematical expressions or with horizontal spacing tweaks.

Table support got an update in 2.1. Arguably the most useful new feature is the ability to move or swap table rows and columns (either with keystrokes or menu commands). It is also now possible to rotate tables on the page—to any arbitrary angle, not just 90-degree increments. Perhaps it is difficult to imagine a use for such rotation functionality, but that might be overthinking matters.

The removal of arbitrary restrictions is a recurring theme in TeX; LyX 2.1 also adds support for custom paragraph shapes, but in removing the restriction that limited paragraphs to simple rectangles, the project could have settled for implementing a fixed set of polygons. Instead, any shape is supported, including unusual options like shapes with holes in the middle. It is also now possible to nest multiple columns of text within an existing column (which is useful for citing and quoting other documents where the page layout itself is important).

Several specific use-cases for LyX received their own improvements in the 2.1 release, such as the beamer class for creating presentation slides, phonetic notation using the International Phonetic Alphabet (IPA), and mathematical formulas. The beamer improvements center around a rewrite of the formerly awkward beamer layout module, but also add some new features like the ability to overlay content. Real IPA support is new; the IPA characters are accessible to the user through a special toolbar, providing an editing workflow that resembles the one used to access special math characters. In previous releases, the rudimentary IPA support was a hack of the existing math-editing code, so this represents a step forward.

Improved support for math typesetting is hardly a surprise; TeX was originally created by Donald Knuth to help him typeset The Art of Computer Programming, and TeX is used heavily by math journals. Nevertheless, there is always room for advancement. LyX 2.1 improves on its formula-and-equation support by adding a document-wide "math font" setting (which will not get overwritten if one changes the font of other body text), by adding a unicode-math package that supports math OpenType fonts (such as STIX or XITS), and by adding a new inline "equation editor" mode.

Several new languages are supported in LyX 2.1, if one activates the optional XeTeX output engine. XeTeX is best known for its support of OpenType, Apple Advanced Typography (AAT), and Graphite font systems, which enable typesetting many writing systems that are not supported (or are not easily supported) by pdfTeX, the default LyX output engine. XeTeX also supports several microtypographic features like hanging punctuation. It is also important to note that "language support" in LyX has a stronger meaning than it does in some other applications: switching the language setting of a document causes LyX to automatically make adjustments to features like the type of quotation marks used.

Speaking of typography, LyX 2.1 also adds support for several new TeX fonts. Unlike the WYSIWYG word-processor world, in which users can highlight any characters they want and put them in a different font via a drop-down menu, in the TeX world, font settings are often a document-centric decision. If the document class designer specifies one font for subheadings and another for body text, then that is simply how it goes, unless one adds document-specific overrides. LyX now ships with more built-in fonts available, and makes it easier for authors to add their own.

Finally, there are many small additions and enhancements in the new release, such as the ability to write multilingual captions, the ability to insert standard-issue "chemical risk and safety" statements, and a new dependency on libmagic to determine the file type of external resources (as opposed to built-in format detection). Nevertheless, there are also some limitations to make note of. Most importantly, LyX 2.1 is not yet compatible with Python 3; if it is the system default Python interpreter on the machine where LyX is installed, one should expect some trouble.

In all, LyX 2.1 is an incremental improvement over previous LyX releases—at least where everyday document editing is concerned—but there are still some significant enhancements that make a reexamination worthwhile for those who have found LyX too limiting in the past. There is still a learning curve, but the conceptual model of TeX is different enough from WYSIWYG word processing that some amount of retraining is inevitable. But if you think TeX is too difficult to learn, a few minutes with LyX is worth the investment.

[Those interested in TeX development should also see Knuth's TeX Tune-Up of 2014 [PDF] from TUGboat 35–1]

Comments (7 posted)