Welcome session.
Robot Vacuums are a pretty common item in many households around the world. They've also become a fairly standard item for robot hobbyists to hack on and use as cheap, open platforms for experiments in mobile bases. The classic "Turtlebot" platform has seen many incarnations, as the iRobot Create series, the Kobuki base, the Neato BotVac and now lives on in the "Hackerbot" from HackerBot Industries(https://www.hackerbot.co/). It has an open command set, options for an arm, animated head and SDK to support the development of character-like human-robot interactions. It does autonomous mapping of whatever space it was in at the push of a button. Unfortunately, the map is stored in an internal proprietary format, accessible through an app you download onto your phone.
I have a number of robots at home and in my lab, all of which run ROS. Surely there must be some way to hack out the map and convert it into a ROS-compatible format that my other robots could use! My talk would be discussing the steps I took to make this happen, the FOSS packages I used and the resulting tool.
This is not my first excursion into hacking robot mapping and sensors, so I'll also present some tips and tricks I've learned over the years to make seemingly proprietary robot subsystems more open and generally usable.
Mapping tool GitHub: https://github.com/jetdillo/hackerbot-maptools
Hackerbot Base: https://www.hackerbot.co/
My robot consulting business: https://www.familiarrobotics.com
When building a robot you want to make sure your set up is perfect. This means good calibration for your sensors, good configurations for your sensors, good synchronization between sensors, good data logging practices and much much more!
In this talk Roland and Sam will talk about their experiences with poorly configured robots, the importance of visualisation and the (open source) tools they use to solve their problems.
As robotics systems grow more complex, bringing together all types of specialties from algorithm/ML developers, control engineers, to safety engineers, has become increasingly painful, especially when working with large, brittle stacks like C++ and ROS.
This talk shares the journey of building Copper-rs, a Rust first robot runtime to make robotics development simpler, safer, and more predictable. Rust’s mix of performance, memory safety, and fearless concurrency offers a foundation for systems that don’t collapse under their own complexity.
Built entirely in the open, Copper-rs has grown out of the Rust for Robotics community and explores how we can take the openness and collaboration that made ROS successful and bring those values into a new generation of deterministic, Rust-based robotics systems.
The copper-rs project is an Apache v2 project available at https://github.com/copper-project/copper-rs
ROS 2 is tied to specific Ubuntu versions, which limits platform choice and can introduce additional configuration complexity. In this talk, I will explain how to run ROS 2 on non-standard platforms using Apptainer, a practical alternative to Docker. I explain why Apptainer works well for robotics: it enables easy access to USB and serial devices, supports GPUs, and runs GUI programs like rviz without configuration. The talk ends with a short look at when the package manager Pixi might even let you avoid containers altogether. Being less tied to a specific Ubuntu release makes robot development more flexible.
Just1 is an open-source robotics platform built for learning and rapid experimentation. It supports manual and autonomous navigation, path following, and obstacle avoidance. With a bill of materials around $250, it offers an affordable way to explore robotics, ROS 2, and autonomous behaviors.
The hardware includes a Raspberry Pi 4, mecanum wheels, TT motors, a 2D LiDAR, Raspberry Pi camera, and an IMU. The software stack is based on ROS 2 Jazzy, with RTAB-Map for SLAM, Nav2, and Foxglove integration.
I created Just1 as a simple, low-cost platform to experiment and to share with the community. Upcoming work focuses on simulation support (Gazebo / NVIDIA Isaac).
The learning curve for ROS2 can be steep, often requiring the installation and resolution of diverse software dependencies across operating systems, sensors, network configurations and robotic platforms. By combining virtual machines (VMs), with their off-the-shelf, ready-to-use environments resources and modern container registry workflows, we can reduce this complexity and enables learners to focus more directly on developing ROS2 skills. This approach also offers a smoother onboarding process for participants with varying levels of technical experience. In this talk, we share hands-on insights from our hackathon, which explored a distributed setup involving two servers located in different University College London (UCL) departments --Advanced Research Computing (ARC) and Civil, Environmental and Geomatic Engineering (CEGE)-- connected via a Zero Overhead Network Protocol (Zenoh) router with 10 GbE connectivity. One server from CEGE was connected to physical sensors --laser scanners, Inertial Measurement Units, and cameras-- with data streamed through the ROSBridge suite and Zenoh. On the ARC server and platforms (unified-AI and condenser), participants worked with off-the-shelf VMs and within containerised environments running ROS 2 Humble on Ubuntu 22.04. Five to ten participants accessed live sensor data via the ROSBridge Suite to visualise streams, perform object recognition and segmentation, and analyse outputs. They experimented with network constraints by varying sample rates, data types, and file sizes, and explored the trade-off between CPU usage for core ROS 2 packages and GPU demands for intensive tasks. Lessons on containerisation for virtual machines, managing dependencies, understanding latency and bandwidth, balancing resources, and cost considerations were shared, alongside next steps and a call for collaboration to advance ROS 2 skills and infrastructure in academia.
Building localization and navigation systems requires a lot of time, effort and statistical analysis over multiple scenarios. There are multiple sparse tools out there to create specific KPIs around datasets but almost none that provide end to end integration test scenarios, KPIs and automatic report generation for localization systems. Last year, at FOSDEM, we presented beluga - https://github.com/Ekumen-OS/beluga - a Monte Carlo Localization Framework for robotics. This year, we would like to present one of the tools we built for this project, Lambkin, the Localization and Mapping BenchmarKINg system that allows to orchestrate test runs of your code, data, KPIs and report generation all in one platform. You can find the code here: https://github.com/Ekumen-OS/lambkin
ROS2’s interface generation can be a major bottleneck in the build process, especially for large projects. The rosidl toolchain, while reliable, is slow due to its Python-based code generation and inefficient use of CPU resources. rosidlcpp (https://github.com/TonyWelte/rosidlcpp) tackles these challenges by reimplementing the rosidl generators in C++. However, switching to C++ is only one of the ways rosidlcpp achieves faster builds. This talk will walk through the optimization journey behind rosidlcpp. We’ll cover how the build inefficiencies were diagnosed and the techniques used to address them.
More than two decades have passed since the first steps of the Gazebo simulator, one of the early attempts to provide a fully-featured 3D environment for robotics simulation. Rewritten into modular libraries, the new Gazebo preserved most of the internals from the previous era even if new features have been added continuously.
Meantime, especially in the last 5 years, the field of robotics simulation has experienced a rapid transformation. A new generation of simulators has emerged (Isaac Sim, O3DE, Carla, etc.) showing powerful rendering capabilities and advanced physics engines, supported by GPU acceleration to enhance realism and performance. These developments have not only changed the landscape of simulation, but have also created new opportunities for integrating AI, machine learning, and robotics in more complex and scalable virtual environments.
Are there any plans to push Gazebo into the modern features? The talk will provide information directly from one of the members of the Gazebo core team about existing roadmaps, funded projects, proof of concepts and any internal discussions on what could come for Gazebo in the future.
Rust offers many advantages for robotics. One key benefit is its memory safety, which helps prevent critical bugs in complex systems. Additionally, its high performance is essential for real-time applications, while safe concurrency allows for efficient parallel processing, crucial for multi-core robotic systems.
This talk will present rclrs (https://github.com/ros2-rust/ros2_rust), the Rust client library for ROS 2, and its accompanying tooling. rclrs is being developed in the open by a community of Rust and ROS enthusiasts. Support for Rust is now part of ROS 2 rolling and will be shipped in the next ROS 2 releases.
In this talk, we will discuss the open hardware and open-source software available today for creating open-source robots, taking the Upkie wheeled bipeds as our working example:
On the software side, we will go through the core robotics libraries used by the robots: Gymnasium, moteus, and PyBullet, as well as libraries for developing robot behaviors, such as Stable-Baselines3 for reinforcement learning and qpmpc for model predictive control. We will compare model-based and AI-driven approaches to implement new behaviors on Upkies, discussing what has worked and not worked so far, as well as future plans for the project like integrating vision for perceptive locomotion.
On the hardware side, we will describe how Upkies use mjbots actuators and PCB cards, which are fully open source (down to motor-driver firmware and KiCad electronics files!). Upkies can be built from off-the-shelf components for around $3,000, making experimentation with bipedal robots more accessible to hobbyists and educators. We will finally conclude by releasing version 2 of the robot hardware with an on-stage demonstration.
Building robots, whether industrial arms or autonomous vehicles, often comes with middleware pain that drains valuable engineering time. Issues like communication delays, execution inconsistencies, poor scalability, and nondeterministic behavior are common and frustrating. Most developers want to focus on their application, not on becoming middleware experts.
This talk introduces iceoryx2, the next generation of the widely used zero-copy middleware Eclipse iceoryx. It is written in Rust, with additional bindings for C, C++, Python, and C#, and runs on a variety of operating systems. iceoryx2 is already used in robotics, automotive, medical, finance, and other domains where high-throughput and low-latency communication are critical.
We will walk through common middleware pain points in robotic systems and show how iceoryx2’s architecture and feature set help eliminate or significantly reduce them.
Many ROS developers know PX4 exists but never get the chance to actually poke at it. This talk gives you that chance. We walk through a complete precision landing pipeline using PX4, ROS 2, OpenCV, Aruco markers, and Gazebo, built the same way we teach it in our hands on workshops.
We start with the pieces of the PX4 architecture that matter to you as a ROS developer, then show how the PX4 ROS 2 interface works, including the PX4 ROS 2 Library by Auterion that makes message handling feel familiar instead of foreign. From there we jump into simulation with Gazebo, run OpenCV based Aruco detection, and wire it all into a precision landing controller.
The heart of the session is practical. We take the tag pose produced by OpenCV in the camera optical frame, transform it into the body frame and world frame, and use it to run an approach phase with PI velocity control. We cover the spiral search pattern for when the tag is not visible, and the land detection feedback that lets the system finish the job safely.
To make it easy to try everything at home, we will provide a Docker container and an open repository with all the source code and configuration you need to reproduce the pipeline on your own machine.
If you have ever thought about connecting your ROS and OpenCV skills to PX4 but did not know where to start, this talk will get you there with a smile and a working example you can take home.
Have you ever wanted to build your own robot but felt overwhelmed by the complexity of dependencies, compilers, and unstable C++ code? Then why not use Rust? In this talk, we aim to convince you that ROS 2-Rust allows the creation of a state-of-the-art stack that is simple, safe, robust, memory-safe, and highly-performant, drastically reducing the time spent debugging runtime crashes. We will also show how to take advantage of Cargo, the Rust package manager, to ease dependency management.
In order to demonstrate our postulate, we have open-sourced a repository that allows everyone to create a minimal, teleoperable rover from scratch. This shows how ROS 2-Rust can further reduce the barrier to entry in the world of robotics.
This project also displays how we used Pixi to simplify the entire development workflow, allowing any developer to clone our open-source repository and achieve a fully working, cross-platform ROS 2 and Rust environment with just a single Pixi install command.
Join us to see how this modern toolchain transforms complex robotics projects into an accessible and enjoyable open-source experience. We aim to inspire you to start your own rover project and show that building your first robot is now as simple as that.
Simulation has evolved to be a key part of robotics development. Nevertheless, existing simulators such as Gazebo and O3DE tend to be time consuming to set up, computationally heavy and out of the box often simulate systems too idealistically, leading to systems that work in simulation but fail in the real world.
The new ROS 2 package vehicle_dynamics_sim aims to resolve this situation for the specific case of mobile platforms by providing an easy to configure and lightweight vehicle dynamics simulator focused on realistic actuator dynamics. It by default simulates real world imperfections such as dead time and acceleration limits, comes with six vehicle types (four bicycle/Ackermann + differential + omni/mecanum) and is fully configured through a minimum of ROS parameters. The two main use cases are trajectory following controller development and automated validation (CI).
ROS is a popular and widely used middleware, ecosystem, and environment for robotics development. It's become quite popular in research environments and for early prototyping, but it's not as common to see it in production environments. Why is that?
In this talk, I'll go over my experience productionising ROS in professional settings, what gaps ROS has, and how you all can avoid the pitfalls, issues, and hellholes I've dug myself into multiple times through my career. This will include ROS message serialisation and how to mesh it with other serialisation formats, how you can leverage Bazel to generate real ROS build artifacts with rules_ros2, and how to integrate all the above into a real robot in production with OTA updates.
You can find the examples for this talk at https://github.com/rdelfin/ros2_bazel_examples
ArduPilot is a trusted, versatile, and open source autopilot system supporting many vehicle types: multi-copters, traditional helicopters, fixed wing aircraft, boats, submarines, rovers and more. The source code is developed by a large community of professionals and enthusiasts. https://ardupilot.org/
ArduPilot is a well known autopilot for drones but it is often associated to only hobby or academic work. This talk will showcase some advanced features and integration of ArduPilot. The talk will present for each type of vehicle some interesting less known features and provide focused explanation on dual autopilot (or more) and advanced video feed usage with BlueOS (https://bluerobotics.com/what-is-blueos/).
This should give idea how far people can integrate and what crazy idea are possible with ArduPilot from hobbyist to industrial grade, all staying FOSS and documented, of course !
I won't speak about rockets nor GPS denied things. If time permits FROST quantum interoperability will be detailed.
What if you could build an autonomous, outdoor collaborative robot using free, open-source tools and community-driven software? That’s exactly what we did at Botronics. In this talk, we will take you behind the scenes of iXi, our autonomous golf trolley, showing how we use open-source technologies, from high level behaviors and control to simulation, fleet management, monitoring, and user interfaces, to build a real-world robotic system deployed outdoors.
You’ll see how tools like ROS 2, Gazebo, Nav2, BalenaOS, Docker, Telegraf, Grafana, Rviz2, and React/React Native come together into a production stack to deploy one of the first outdoor collaborative robots. More than just engineering talk, the objective is to provide a return of experience and lessons learned about what open-source robotics can enable outside the lab: reproducible development, remote deployment, full observability, and real user-facing applications.
If you are interested in taking robotics beyond prototypes, building autonomous systems that work in the real world, this session will show you what’s possible using open source stacks from end to end.
ROS 2 was designed to be independent of its underlying communication middleware — a powerful architectural feature, but one that introduces complexity and overhead.
While working on rmw_zenoh, we kept wondering: What if we streamlined the ROS 2 layers and built a Rust-native stack from Zenoh up to the RCL API? Could it improve performance? Would it be easier to extend? And could we still support existing RCL-C/C++/Python packages through C bindings?
This led us to develop ROS-Z, a Rust/Zenoh-native RCL stack, fully interoperable with ROS 2 via rmw_zenoh. In this talk, we’ll explore our design choices, share performance insights, and highlight the some of the unique features we’ve added to push innovation even further.
EasyNav is a fully open-source navigation framework for robots, designed to be lightweight, modular, and suitable for real-time execution. The project is motivated by the limitations of existing systems, which are tightly coupled to a single environment representation and often introduce unnecessary computational overhead. EasyNav decouples navigation from the underlying map structure, enabling costmaps, gridmaps, NavMap, or other models to be used interchangeably. Its architecture is built around a minimal core and open, extensible stacks that group controllers, planners, localizers, and map managers. The framework is designed to be easy to inspect, modify, and extend through its clear plugin interfaces. This talk will present the motivation, architecture, main features, and evaluation results in simulation and real robots, showing how an open-source approach improves flexibility, transparency, and performance in complex scenarios.
Links: - https://easynavigation.github.io - https://github.com/EasyNavigation/
AutoAPMS is a heavily extensible development framework for behavior-based ROS 2 applications. It provides a highly modular integration of behavior trees. In this talk, I'm explaining the core concepts while walking through the development workflow using an applied example. This should give you a good idea of whether AutoAPMS is for you or not.
The intention of this project is to make it significantly more user-friendly and less error prone to develop autonomous robotics with behavior trees. The core packages are written in C++ and a supplementary Python API exposes high-level features for scripting.
The framework relies on the popular BehaviorTree.CPP library under the hood and offers a Nav2-agnostic approach for using it within the ROS 2 ecosystem. It was inspired by BehaviorTree.ROS2 and can be considered a spiritual successor. AutoAPMS took the core ideas of the behavior tree paradigm and supercharged it with the following features:
ament_cmake and ament_indexros2 behavior command extending the ROS 2 CLIPlotJuggler is an open source QT/C++ application that allow developers to visuale and analyze timeseries from logs, that it is very popular in the robotics and drones community.
It supports both static files and real-time streaming.
Its plugin-based architecture makes it easy to extend; this allowed people to add more and more formats, in terms of streaming transport (Websocked, MQTT, ZeroMQ, UDP, ROS2, etc.), serialization protocols (DDS, Protobuf, JSON, Proprietary) and file formats (rosbags, PX4 logs, CSV, Arrow Parquet, etc).
Furthermore, it includes a Lua-based data editor that allows the user to manipulate and transform data, effectively replacing the need for those "short-lived" Python scripts that people in this community would create to quickly analyze their data.
Its Github repository (https://github.com/facontidavide/PlotJuggler) is approaching its 10th anniversary, with 5.5K stars, 2500+ commits and 120+ contributors.
Welcome to the FOSDEM 2026 edition of the Distributions DevRoom! Meet the organizers of this year's Distribution DevRoom, learn a little bit about the history of our DevRoom, and go over some ground rules for the day.
The systemd project and some others have been adopting the Varlink IPC system recently, in places traditionally reserved for D-Bus. In this talk I'd like to explain why Varlink matters, and is a major step forward from D-Bus for almost all areas of Linux OSes. I'll talk about patterns, lifecyles, tracing, parallelism, security, and a lot more.
For decades, building a Linux distribution has been considered a highly specialized craft. To participate, one had to master complex toolchains—building package files, navigating the intricacies of dependency resolution, and operating hard-to-grok build systems like OBS or Koji & Pungi & ImageBuilder. While extremely powerful, this entire stack presents a massive barrier to entry. The result is a demographic crisis: the average age of package maintainers is rising, and new contributors are not motivated to learn these legacy tools.
In this talk, we argue that the solution lies in the commoditization of the build process. By adopting docker and podman as a build tool and OCI (Open Container Initiative) images as the native artifact, we bridge the gap between "distro builders" and the millions of developers who already know how to write a Dockerfile.
We will explore current successes like Universal Blue and Fedora Atomic, but we will also go further. What if we built the individual packages themselves from Dockerfiles?
Join us to explore how OCI-based workflows don't just solve technical problems—they solve a growing social problem. By making the tools of creation accessible to a larger base, we can foster the next generation of contributors!
eBPF introduces new challenges for Linux distributions: programs depend on kernel, CO-RE relocations, pinning behavior, and version-aligned bpftool or libbpf tooling. This session looks at what it really takes to package eBPF programs as RPMs and explores specific, real world usecases in Fedora. We’ll explore issues such as pinned maps, privilege models, reproducible builds, SELinux implications, kernel-user ABI considerations, and managing kernel updates without breaking packaged eBPF assets. The talk presents practical solutions, best practices, and tooling ideas to make eBPF a first-class citizen in mainstream distributions.
How do you ensure code works across distributions before it reaches users? The Packaging and Testing Experience (PTE) project is an open-source approach to solving the upstream-to-downstream testing challenge.
The traditional model fragments testing: upstream tests their code, distribution maintainers test packages, and users discover the gaps. PTE bridges this by creating a continuous testing pipeline where upstream changes are automatically built, tested in realistic distribution environments, and validated before integration.
Our approach consists of three open-source components working together:
But this isn't just about specific tools - it's about the philosophy: making tests portable, infrastructure on-demand, and integration automated. tmt works with any distribution. Testing Farm's architecture could inform similar services. The integration patterns apply broadly.
In this talk, we'll share:
The software supply chain for Linux distributions is under growing pressure. Several distributions have recently suffered from infected packages caused by compromised or malicious upstream sources, including core libraries, leading to significant security implications.
These incidents prompted Arch Linux to reflect on the way we handle our package sources. With the objective of bringing greater transparency to our packaging process, we revisited historical decisions and established updated guidelines and best practices for selecting trustworthy sources for our packages, in order to prevent (or at least mitigate) such potential security threats in the future.
This talk will share an overview of the specifications and guidelines we established during this reflection.
TL;DR: Write a Containerfile, use image-builder to convert it to an ISO with a live environment.
bootc revolutionized how we build and consume image-based systems: just build an OCI container in your preferred git forge, publish it in a registry, and voilà, anyone can come and rebase their bootc-based system to it. A great example is Bazzite: one of the most popular gaming-oriented distributions today.
However, the first-day experience is still lacking: the installers don’t run in a live environment, and their building process is a nightmare and far from container-friendly.
The team behind the osbuild/image-builder project recently started experimenting with introducing a way to build an ISO with a live environment directly from an OCI container image. All techniques you know from building bootc systems can be applied here, so the build pipelines can be shared. Additionally, if you want such an ISO to be a bootc installer, the resulting artifact will be surprisingly small due to the high level of deduplication.
Come to this talk to learn how to build your own ISO using just a bunch of podman commands!
https://github.com/osbuild/image-builder-cli https://osbuild.org/docs/developer-guide/projects/image-builder/usage/#bootc
Over the last several years, the Kairos project has built image-based, immutable systems on top of multiple Linux distributions like Ubuntu, Debian, Alpine and others. This experience has revealed a recurring set of engineering constraints shared across traditional distros: assumptions about package managers, filesystem layout, dependency chains, downstream patches, boot tooling, or init system behavior that work well for classic installations, but create friction in image-based, cloud-native and edge-focused environments.
This talk presents the design principles that emerged from this work: minimal bases, upstream-first components, predictable boot paths, trusted boot chains, reproducibility, and clear separation between the immutable system image and extensible runtime layers. We will discuss both the technical challenges and the architectural conclusions that followed.
These lessons ultimately led us to build Hadron, a new minimal Linux distribution developed by the Kairos team: musl-based, systemd-powered, upstream-aligned, and designed specifically for image-based systems. Hadron is not intended to replace any existing distribution; rather, it is a small, focused reference implementation of what an OS optimized for this model can look like.
The goal of this talk is to share practical insights with the wider distribution community and contribute to the ongoing evolution of image-based Linux.
https://github.com/kairos-io/hadron https://github.com/kairos-io/kairos https://kairos.io/
You all used to know Gentoo Linux as a source-based Linux distribution, where compiling things on your own machine was both pleasure and pain, right? Well, some time ago we announced that we now also offer binary packages for download. And while of course a few purists protested, overall this initiative was a resounding success. Now you can mix and match between binary and source based installation, and find your own balance between convenience and tuning.
A lot of LEGO blocks had to come together (and occasionally be stepped on) to make this happen. From quality control and automated rebuilds on the source installation side, to a new package format and support for GPG signing, to package delivery and designated build hosts, extended support in the package manager, ... Let us tell you the story of an experiment that worked out great, and discuss further possible future improvements.
CentOS is the Community Enterprise Operating System, a Linux distribution built by the CentOS Project. For over two decades, CentOS has powered servers and workstations around the world. During this time it has accumulated its fair share of myths, tall tales, and urban legends. Many of these stem from the transition from the legacy CentOS Linux variant to the modern CentOS Stream variant.
In this session, we won't just tell the myths, we'll put them to the test. In the spirit of the TV show MythBusters, we'll use observable data, historical events, and project insights to rate each myth as BUSTED, PLAUSIBLE, or CONFIRMED. Attendees will gain a better understanding of the advantages of CentOS and the state of the CentOS Project, which they can use to make informed choices for their own deployments.
This talk gives an overview of how Rust libraries ("crates") and applications are packaged as RPMs for Fedora Linux, and how this distribution mechanism addresses multiple shortcomings of the limited functionality of the distribution mechanism built-in to cargo, the Rust package manager:
Packaging Rust crates as individual RPM packages also simplifies package maintainer responsibilities, despite increased up-front work:
Does your distribution need to care about attacks by quantum computers, and if yes, where? Which parts of Fedora already support post-quantum cryptography (PQC), and what still needs to be done? And what does the European Union have to do with any of this?
Answers for these questions, and more, will be provided in this talk. You'll leave with a rough idea whether the risk is relevant for you and why the risk is no longer the only thing driving a migration. Don't expect hyped statements, we'll stick to the technical details and facts. You may learn how to make your OpenPGP key quantum-safe.
Attend if: - you're vaguely aware of what PQC is, but want to learn what it means for your project - you've always wanted to ask that one question about post-quantum cryptography, but haven't found the right person to ask - you are running a distribution's package signing infrastructure, or maintain a package that implements a network protocol
openSUSE MicroOS is a snapshot-based, immutable operating system that features automatic updates and recovery.
health-checker is the system tool responsible for handling automatic recovery and rollbacks, and it comes installed by default. It was recently rewritten to support both systemd-boot and grub2-bls, utilizing systemd-bless-boot and Automatic Boot Assessment.
In this talk, we will provide a brief explanation of the Boot Loader Specification (BLS), which is supported by both systemd-boot and grub2-bls. Next, we will explain Automatic Boot Assessment, describe how it is used by health-checker, and show how it can be used to check the system status at boot and act accordingly.
How to successfully brew a Linux immutable image, with bells and whistles
Creating a (truly!) immutable distribution with a strong security posture and a chain of trust that starts in the hardware and ends in userspace is no longer a job that requires an entire team and starting from first principles. With the power of tooling and infrastructure provided by the systemd project, anyone can customize, build and deploy at scale and securely starting from your preferred traditional package-based distribution.
This talk will go over all the tooling and infrastructure available to achieve this, from systemd to mkosi, from UEFI Secure Boot and dm-verity to the Integrity Policy Enforcement LSM, from OBS to systemd-sysupdate, from systemd-repart to systemd-firstboot, and show a working example and how to reproduce and customize it.
Fedora Project is undergoing significant infrastructure changes that affect everyone from distribution users to individual contributors - that is migrating from Pagure to Forgejo as its primary Git forge for both source code and package sources. Our talk chronicles the journey from the early days of collective debating between GitLab and Forgejo with Fedora Council, through the ongoing migration of thousands of repositories with Fedora Infrastructure.
While the initiative began due to the need to move away from Pagure, it gradually evolved into one that also aimed at fixing the long-standing pain points faced with workflows. We got the opportunity to streamline the processes that made sense about a decade back and have since then, slowly started getting in the way of contribution. This also allowed us to contribute back to the Forgejo upstream with the features that would end up benefitting all.
Our findings serve as a blueprint for other distribution maintainers facing similar infrastructure decisions with maintaining their collaborative applications and services. They can take advantage of Fedora Project's learnings on building compatibility bridges, CI/CD workflow modernization, granular permission models, existing toolchain integration and comprehensive documentation - to ensure a sustainable approach to their significant infrastructure changes.
In August 2025, Debian turned 32 — or, for those who prefer other bases, 0b100000 in binary, or 0x20 in hexadecimal. An impressive age for a community-driven distribution that continues to power much of the Free Software world.
By the time of FOSDEM, I will have served nearly two years as Debian Project Leader. In this talk, I’ll share insights from that experience: how Debian works as a do-ocracy, what helps it thrive, and where collaboration sometimes meets friction.
I’ll reflect on what I set out to achieve, what we managed to accomplish, and the challenges of coordinating a large, globally distributed project run entirely by volunteers. The talk will also explore how Debian adapts to change — in technology, community dynamics, and expectations — while staying true to its core values.
https://www.debian.org