OSS + ELC EU 2026

Modern Linux based distributed systems generally rely on bespoke "agent" services on each node for introspecting their state or issuing operations.

In this talk I'd like to explain systemd's vision of improving and cleaning up this logic, with the ultimate goal of avoiding any local agents but nonetheless making the system nicely introspectable and accessible, with modern technologies.

For this, we'll talk about the Varlink IPC system, and the numerous Varlink APIs systemd provides these days. We'll also cover the HTTP Varlink proxy, which opens up these APIs in a web-native way, with modern authorization mechanisms. We'll also discuss systemd's metrics collection/report generation subsystem, it's cryptographic properties and remote access to it.

libiio is an open source C library developed by Analog Devices for interfacing with Industrial I/O (IIO) devices - ADCs, DACs, IMUs, RF transceivers, temperature sensors, and more. It underpins a broad ecosystem of host-side tools including Scopy, pyadi-iio, and MATLAB, all of which connect to targets over network, serial, or USB transports.

This talk walks through the architecture and practical mechanics of the port. We will cover how libiio's external backend integrates with Zephyr's device model, allowing any driver that implements the IIO device driver API to appear as a first-class IIO device. We will look at built-in bridge drivers that wrap any Zephyr ADC, DAC, or sensor device into an IIO device. We will also cover how the module integrates into the Zephyr build system using Kconfig, device tree, and snippets to enable libiio with minimal changes to an application.

We will demonstrate a Zephyr board being queried from Scopy and pyadi-iio, and close with a look at what is in progress - trigger support for deterministic sampling and streaming, and a USB transport as a complement to the existing UART and network transports.

This talk could prevent the next big data breach.

Building enterprise-ready AI poses challenges around data security, scalability, and integration, especially in compliance-regulated industries. We're already seeing security breaches with AI Agents in the news. This is a complex problem - Imagine having N users, M Agents and O actions. How do you design permissions around that?

This session will cover how modern permissions systems can ensure AI Agents have access only to authorized data. The talk will look at why the Google Zanzibar model of authorization which uses Relationship-Based Access Control (ReBAC) is well suited for fine-grained authorization at scale. The talk covers the nuts and bolts of how a Google Zanzibar system works under the hood, and how to apply it to AI Agents with techniques such as pre-filteration and post-filteration.

The talk will also include a live code demo implementing authorization for AI Agents + RAG using Open Source tools such as Weaviate, Langchain, and SpiceDB.

Linux was not developed around fault-containment properties expected of safety-certifiable software.

The linear map lets kernel code access memory across userspace ownership boundaries, so corruption can affect another process or container. Shared slab/page allocators and per-CPU caches compound this risk: corrupted state may remain latent and later affect unrelated subsystems. MMIO can cause external interference when a faulty driver accesses the wrong register or device because of corrupted state or an incorrect Device Tree or ACPI-derived base address.

Building on ELISA Linux Features WG (LFSCS) work, we use ks-nav call-tree artifacts to show that even narrow services depend on shared infrastructure across subsystems.

Reducing the configuration lowers function count but also usability; restoring functionality introduces transitive dependencies, so assessment cannot be limited to newly enabled code.

These findings challenge treating Linux as safe by default or relying on proven-in-use arguments alone. In a monolithic, shared-address-space kernel, fault containment and qualification scope must be demonstrated, not assumed.

Is it a multicopter? Is it a fixed-wing? Not quite: It is a quantum superposition of both, and only upon flipping the transition switch we can observe the VTOL state with certainty.

VTOL vehicles bridge the design space between either pure vehicle type and enable long, efficient flights combined with accurate and soft landings. However, they challenge our software engineering and architecture skills, and properly supporting all VTOL vehicles in PX4 is quite the balancing act.

In this talk, we will go over the architecture and implementation decisions that connect those two vehicle types within a running system. We will visit some VTOL specific features and see where they slot in, and finally we will conclude with possible paths for further improving VTOL support in PX4.

Autonomous VTOL aircraft require reliable, precision landing capabilities to enable real world applications from package delivery to infrastructure inspection. This session presents a complete open-source precision landing system built on ROS 2 and PX4, covering the full development lifecycle from high fidelity simulations to flight tested deployment.

We'll walk through how we developed, validated, and refined a multi-sensor perception and control stack that achieves centimeter-level landing accuracy using only commodity sensors and open-source tools. The system uses AprilTag fiducials for dock detection, fuses visible and infrared camera streams with a Kalman filter for robust pose estimation, and executes a phased descent state machine with real-time PID control.

The presentation covers:
Simulation first development: Building a Gazebo SITL environment with realistic sensor models
ROS 2 + PX4 integration: Bridging autopilot and perception via micro-XRCE-DDS,
Production deployment: Lessons learned scaling from lab prototype to field-tested hardware. Practical guidance on composing a production system from ROS packages, PX4 firmware, and community-contributed modules.

All active components require power. The device tree should properly describe these supplies so that the software can control power to the devices. On the other side of things, regulators also have their power inputs, and constraints on their power outputs. The device tree should also describe this. Nothing should be left to default.

This session will present how to fully describe the regulator tree of a system, how to identify missing bits, and how to properly describe regulator constraints.