Bernhard Rosenkränzer

After approximately a year of work, Oniro - the Eclipse Foundation's embedded operating system - has been released to the public, and is open to bigger changes like rebasing to a newer Yocto branch and updating toolchains. Now we're seeing - and can share - what we did well and what we will have to do differently in the future.

After approximately a year of work, Oniro (https://oniroproject.org/) - the Eclipse Foundation's embedded operating system - has been released to the public, and is open to bigger changes like rebasing to a newer Yocto branch and updating toolchains. Now we're seeing - and can share - what we did well and what we will have to do differently in the future.

We updated a number of packages from dunfell - can this be avoided or done in a better way? What can we do about packages that don't have an LTS policy?

An important goal must be to make rebasing to newer upstream releases as quick and painless as possible - accumulating as little technical debt as we can.

Sometimes it is useful to share code across multiple kernels -- in projects like the Oniro door lock blueprint, for the typical use cases a Cortex-M CPU running Zephyr is more than sufficient, but using its functionality as part of a larger project makes using Linux on Cortex-A an interesting option. Can we find a way to maximize code reuse despite the very different GPIO APIs?

Sometimes it is useful to share code across multiple kernels -- we avoid doing the work twice. However, this might be complicated when one version is using Zephyr with a Cortex-M, and another Linux on a Cortex-A. We will explore this problem using an example of the door lock blueprint from the Eclipse Oniro project - an implementation of basic door lock functionality. For a typical use-case, a Cortex-M with Zephyr is more than sufficient, but we might also want to integrate the same application in a bigger one using Linux on a Cortex-A. Will we find a way to do so?

Oniro - the Eclipse Foundation's embedded operating system - is switching from libstdc++ to libc++ by default. This talk gives an overview of our experience daring to make the switch.

Oniro - the Eclipse Foundation's embedded operating system - is switching from libstdc++ to libc++ by default.

Binary compatibility is a holdup for libc++ adoption on Linux desktops and servers - but in the embedded world, we have more options.

This talk gives an overview of our experience daring to make the switch.

OpenMandriva and its predecessors have been in the desktop and server world since the 1990s - now OpenMandriva 4.3 can run on the PinePhone. What did we have to do to get there and what problems have to be solved before it can fully replace that Android phone in my pocket?

Porting to the ARM (64-bit) architecture was relatively easy (and needed for some other projects). Modifying the build system to handle bootloaders other than grub and distribution formats other than iso images and special per-device kernels? Easy to hack but not that easy if you want to do it right. We needed to do something that doesn't go quite as far as OpenEmbedded/Yocto, but still is powerful enough to handle many different devices. Making the hardware work? Largely solved by the upstream community. Finding or developing apps for base functionality, and making them work for the phone form factor? Mostly solved (with a few caveats). But how can we work with Android and/or iOS apps (currently required to e.g. log in to most bank accounts)? How can we make this appealing to a normal user?

Not too long ago, it was clear how to build a new toolchain -- build binutils, build a gcc bootstrap compiler, build glibc, build a full featured gcc, debug it with gdb. That is still a good option - but no longer the only one: These days, alternatives to each of those components are available. This talk examines the available options and gives recommendations of what components make sense for what use cases.

The talk looks at the traditional toolchain options as well as alternatives including LLVM/clang/lld, elfutils, TinyCC and OpenArk, musl, uClibc-ng, klibc, newlib, LLVM libc, bionic and dietlibc, libstdc++, libc++ and uClibc++, and shows which components go well together and which don't.

There are many Linux distributions out there - and almost as many different approaches to how they're built. Two distributions on nearly opposite ends of the spectrum include OpenMandriva (which uses binary packages, builds and updates each package individually, applications are part of the OS, ...) and OpenHarmony (which builds the OS from source in one go, is updated through OTA images, and treats applications as something separate, ...)

A developer involved in both projects explains how the 2 projects go about building their respective OSes, why both projects made the choices they made, how the approaches differ from a developer and user perspective, and what approach works better for what particular use case.

OpenMandriva Lx has switched its default compiler to clang.

This talk will be about our experiences with the switch, problems we've run into, and their solutions.

OpenMandriva Lx has switched its default compiler to clang.

This talk will be about our experiences with the switch, problems we've run into, and their solutions.