Distributions

Building a GNOME-based automotive system

At GUADEC 2016 in Karlsruhe, Germany, Lukas Nack presented a look at Apertis, the open-source automotive in-vehicle infotainment (IVI) system developed by Bosch. Apertis makes use of a number of GNOME components for its application framework, in contrast to many IVI products built by car makers. But, as the audience questions at the end of the session revealed, there may still be some significant disconnects between the free-software community and automotive industry decision makers.

The car market

Nack began by outlining the increasingly computerized aspects of modern cars and how open source (namely Linux systems) is expected to play a significant role in the coming years. In the future, cars will come with computerized IVI head units in the dashboard, computerized instrument clusters, separate passenger entertainment systems, and likely several other software-driven panels (such as the climate-control system). Already, most new cars come with a seven-to-nine-inch screen in the IVI unit, which provides audio control, phone connectivity access, navigation, and other services.

These IVI head units are not chosen by the user, though; they are provided by the car maker as built-in equipment that the manufacturer puts through a multi-year test phase in order to meet safety and reliability requirements. The car industry, Nack said, is not quick to adopt new technology. The safety regulations are one reason why, but there are others, including the long maintenance period (product lifespans averaging ten years or more) and the difficultly of building systems that are robust in the automotive environment. For example, automotive computers must not crash even when the available voltage supply suddenly drops or the ignition is shut off without warning.

The result is that developing IVI software is more complicated than developing a typical desktop system, he said. Car makers want app-store like environments similar to what users have on their smartphones, but they also want a platform that they can customize to serve in a wide range of different vehicles. They are also quite concerned with safety issues, he said. They want to avoid the security vulnerabilities routinely demonstrated by researchers, and they are averse to using GPLv3 software primarily because they want to "Tivoize" their systems. That desire, he said, comes from their fear that people will modify the software in their car and people will die in an accident as a result.

Bosch is primarily a supplier to the auto industry (although it has several other industrial engineering interests), making components from braking systems to navigation and car stereo units for use by car makers. Apertis is Bosch's automotive Linux distribution, which it has developed to be used and adapted by car makers as well. Nack outlined its major features.

Apertis

The distribution is an Ubuntu derivative that ships a GENIVI-compliant middleware stack. On top of that, Bosch has built an application framework using GTK+ and GNOME. There are two reference hardware designs supported in the official release images: the MinnowBoard MAX for Intel systems and the i.MX6 SABRE Lite for ARM. The project also produces development tools that can be installed and run on the target system itself. The original code is released under the MPLv2.

For its application framework, Nack said, Apertis chose GNOME over Qt—largely because it found Qt to "be very closed." "It's hard to break out of," he said, whereas GNOME is totally different. "You can use whatever you want; there are lots of language bindings, and you can exchange any components you want to."

The Apertis framework distinguishes between built-in applications and "apps" that would come from a smartphone-like app store. These apps are installed from self-contained bundles (which include their dependencies) and are run in a sandboxed environment. The Apertis sandboxing system appears to have been developed entirely within Bosch, but it follows the same basic outlines as other application-sandboxing systems. AppArmor is used to enforce access control, control groups restrict access to system resources, and polkit is used as a second-level mechanism to limit access to the system.

Each app can read and write files in a private directory, and access to a shared storage directory must be authorized interactively by the user. An app-launcher process is responsible for installing apps, checking the permissions each app requests in its manifest file and whitelisting it with the necessary AppArmor policy. The launcher also handles app upgrades, starting and stopping apps, and uninstallation.

Apertis offers a set of APIs that track the automotive APIs defined by GENIVI and the World Wide Web Consortium. In addition, Apertis supports "agent" processes, which are essentially standard daemons. In addition to native GTK+ apps, HTML5 apps are supported (running on WebKit2GTK).

The developer community

At present, Apertis is not shipping in any cars and Nack did not disclose any such plans. The system is similar in most respects to the GENIVI-based products being developed elsewhere (including by car makers), though building the system on Ubuntu rather than with Yocto is a distinction, as is the choice of GNOME over Qt.

The GNOME developers and community members in the audience had quite a few questions, beginning with whether or not Bosch had seen any of the application-sandboxing work done in Flatpak. Nack replied that he was not familiar with it himself, but that the project had been asked about it. Flatpak developer Alex Larsson (who was moderating the question-and-answer session) noted that the Apertis sandbox design seemed "almost exactly the same" and suggested that Bosch explore Flatpak.

Several other audience members pushed back on various comments from the presentation about locking the system down. Bradley Kuhn asked whether or not an Apertis system would come with the necessary scripts for users to modify and install their own version; Nack replied that he did not know. Kuhn also objected to the notion that avoiding GPLv3 software would prevent fatalities. He pointed out that the Tesla self-driving car component was proprietary and it has killed someone and that Volkswagen's proprietary emissions-cheating software was, in a sense, killing lots of people slowly by contributing excess pollution.

Christian Hergert, who described himself as "a recovering car guy" noted that it currently takes a lot of reverse engineering to decode the proprietary diagnostic codes emitted by Bosch head units, and asked whether Apertis, with access to a nice seven-inch monitor, could save everyone a lot of trouble by displaying human-readable error messages instead. He also asked whether the opaque settings Bosch head units currently stored in 32-bit flag fields would become something more convenient like GSettings keys. Nack replied that he was not sure, but that he suspected Apertis would typically be deployed as a guest OS running on top of a separate real-time OS, and that the low-level messages and codes would probably be handled by the real-time component. As to displaying human-readable messages, he replied that he thought Bosch probably does not want anyone to reverse engineer its systems, so it was unlikely to make the job easy for them.

That point prompted a number of audience members to comment on the drawbacks and problems of locking out developers and car owners. Bastien Nocera pointed out that some components, notably WebKit, are guaranteed to have security bugs discovered over a car's ten-year lifespan. If developers cannot fix those packages, drivers are being placed at greater risk. Other points include the possibility that a car maker will go out of business, leaving users locked out and with no chance of even a vendor-provided update, and the fact that locking down the system imposes a long-term maintenance burden on the manufacturer.

To a degree, Nack seemed taken by surprise at how many questions the audience had on the topic of lock-down. He generally tried to abstain from making pronouncements on what Bosch's position (or any Apertis-using car maker's opinion) would be, noting that the automotive industry, in general, is not particularly open toward aftermarket development. "I think car manufacturers need to change their thinking about this," he said, "but I don't see that happening in the near future."

Given their alignment on technologies, in theory Apertis could become a project that works closely with GNOME, to the benefit of both camps. But there are clearly obstacles to that taking place, if the higher levels at Bosch or car makers are, indeed, averse to engaging with free-software developers like they would the supplier of any other component. That said, one should surely not extrapolate too much from a single Q&A session; as GENIVI and other automotive Linux projects have found, it is possible to shift the thinking of automotive industry players.

But it will likely take a lot more engagement between the two communities before the interests of automotive manufacturers are fully in line with the interests and needs of the free-software development community. Hopefully engaging with GNOME will increase the chances of that alignment happening soon.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2016.]

Comments (2 posted)

Distribution quotes of the week

-- Ian Jackson

-- Pavel Machek

Comments (8 posted)

OpenBSD 6.0

OpenBSD 6.0 has been released. An EFI bootloader has been added to the armv7 platform along with other improvements for that platform. Also in this release, new and improved hardware support, IEEE 802.11 wireless stack improvements, generic network stack improvements, installer improvements, routing daemons and other userland network improvements, security improvements, and more. The announcement also contains information about OpenSMTPD 6.0.0, OpenSSH 7.3, OpenNTPD 6.0, and LibreSSL 2.4.2.

Comments (6 posted)

Reminder - Debian Bug Squashing Party in Salzburg, Austria

There will be a BSP September 23-25 in Salzburg, Austria. "The BSP will be held in the office of conova communications GmbH [CONOVA], located close to Salzburg Airport W.A. Mozart. Team meetings/sprints during the BSP are welcome, just let me know in advance so we can organize appropriate rooms."

Full Story (comments: none)

Fedorahosted.org sunset

Fedora Infrastructure currently maintains two sites for general open source code hosting: fedorahosted.org and pagure.io. The Infrastructure team would like to retire fedorahosted.org in favor of pagure.io, which is in active development. The shutdown is currently planned for February 28, 2017. "Fedorahosted.org was established in late 2007 using Trac for issues and wiki pages, Fedora Account System groups for access control and source uploads, and offering a variety of Source Control Management tools (git, svn, hg, bzr). With the rise of new workflows and source repositories fedorahosted.org has ceased to grow, adding just one new project this year and a handful the year before. Pagure.io was established in 2015, and is a modern Flask/Python based application. It is under rapid development and supports git repos for source code, docs, and tickets. The pull request model is used for changes along with many options for projects. Access control is standalone. New projects are self service and added all the time."

Full Story (comments: 11)

Distribution newsletters

• DistroWatch Weekly, Issue 677 (September 5)
• Lunar Linux weekly news (September 2)
• openSUSE news (September 2)
• openSUSE news (September 7)
• openSUSE Tumbleweed – Review of the Week (September 4)
• Ubuntu Kernel Team newsletter (August 30)
• Ubuntu Weekly Newsletter, Issue 480 (September 4)

Comments (none posted)