Architecture

Background One of the main goals for Apertis is to provide teams the tools to support their products for long life cycles needed in many industries, from civil infrastructure to automotive. This document discusses some of the challenges related to long-term support and how Apertis addresses them, with particular interest in reliably reproducing builds over a long time span. Apertis addresses that need by providing stable release channels as a platform for products with a clear trade-off between leading-edge functionality and stability. [Read More]

It is important to properly version software to enable software changes and compatibility of components to be tracked, as well as to aid with bug tracking and the application of updates. To achieve this, it is important that we effectively version each source component, binary package and release. The approach to versioning depends on the entity being versioned and in the case of source code whether it is developed specifically for Apertis or an existing project used by Apertis. [Read More]

For both privacy and security reasons it is important for modern devices to ensure that the software running on the device hasn’t been tampered with. In particular any tampering with software early in the boot sequence will be hard to detect later while having a big amount of control over the system. To solve this issues various vendors and consortiums have created technologies to combat this, known under names as “secure boot”, “highly assured boot” (NXP), “verified boot” (Google Android/ChromeOS). [Read More]

This document provides the analysis and rationale for migrating to Debian as the projects upstream distribution. This change was completed in late-2018 and as such all releases since v2019 have been based on Debian. Why was Apertis based on the Debian/Ubuntu ecosystem At the beginning of Apertis, a few platforms were considered for the base of Apertis: MeeGo, Tizen, OpenEmbedded Core, Debian and Ubuntu. A choice of Debian/Ubuntu ecosystem was based on Debian being ‘one of the oldest and largest (most inclusive of OSS packages), and one of the first Linux distributions to feature an ARM port’, providing ‘a very solid distribution baseline’ and ‘a high degree of robustness against the involvement or not of individual contributing companies’, while Ubuntu bases on Debian but adds value important for Apertis (see below). [Read More]

Build infrastructure on Intel x86-64 Introduction The current Apertis infrastructure is largely made of hosts based on the Intel x86-64 architecture, often using virtualized machines. The only exceptions are: OBS workers used to build packages natively for the ARM 32 bit and ARM 64 bit architectures LAVA workers, which match the reference hardware platforms While LAVA workers are by nature meant to be hosted separately from the rest of the infrastructure and are handled via geographically distributed LAVA dispatchers, the constraint on the OBS workers is problematic for adopters that want to host downstream Apertis infrastructure. [Read More]

Sysroots and devroots are two development rootfs meant to provide an environment to build software for Apertis, targeting foreign architecture that don’t match the CPU architecture of the build host (for instance, building ARM64 binaries from a Intel-based host). They are meant to address different use cases with different trade-offs. Sysroot Sysroots are file system trees specifically meant for cross-compilation and remote debugging targeting a specific release image. They are meant to be read-only and target a specific release image, shipping all the development headers and debug symbols for the libraries in the release image. [Read More]

Apertis provides the GTK port of WebKit as its web engine. To ensure low maintenance effort, no changes are made to the downstream branch, any improvements should go to the upstream project. Security maintenance Like all other major browser engines, the GTK port does not provide long term support, so security maintenance comes down to staying up to date. The general approach Apertis takes is to follow whatever Debian provides. The project may also importing a new upstream release that has not been made available in Debian yet if an important fix is available. [Read More]

Summary Define API stability guarantees for your project. Ensure version numbers are changed as appropriate when API changes. API and ABI At a high level, an API – Application Programming Interface – is the boundary between two components when developing against them. It is closely related to an ABI – Application Binary Interface – which is the boundary at runtime. It defines the possible ways in which other components can interact with a component. [Read More]

Tracker is a desktop search engine, metadata indexing and storage service. It is the recommended way to search for user files and access metadata about them. A full introduction to Tracker is here. Summary Avoid SPARQL injection vulnerabilities by using prepared statements. Using Tracker Tracker is effectively a metadata store which applications can query using the SPARQL query language. SPARQL is similar to SQL, so all the same considerations about SQL injection apply when using it. [Read More]

Internationalization (commonly abbreviated i18n) is a topic which covers many areas: more than just translating UI strings, it involves changing settings and defaults to match the customs and conventions of the locale a program is being run in. For example, days of the week, human name formats, currencies, etc. Summary Design projects to be internationalized from the beginning. Use gettext (not intltool) for string translation. Remember that all strings are in UTF-8, and may contain multi-byte characters. [Read More]