FOSDEM 2026
I had the opportunity to go to FOSDEM 2026!
Chaos on the rails
The trip to Brussels by train was a bit of a disappointment since all the departures between Hamburg and Köln were canceled while I was on the train, making it hard to reschedule (even though I had bought cancellable tickets!). I had to take a detour through Münster where I had to spend 1.5 hours because my train there was delayed, which made me miss my connection, and the following trains kept getting canceled.
I finally made it to Köln, but by that time my Eurostar to Brussels had departed and I had to spend the night in Köln. I finally made it to Brussels on Saturday morning and made it to the campus an hour before lunch.
In short, Germany tried to break me, but I am still here and more powerful than ever.
ULB Campus
The ULB campus where FOSDEM takes place is filled to the brim with people! The atmosphere is very chill and there are talks, dev rooms, food trucks, and a lot of energy everywhere.
Day 1 - Saturday
Note - the rest of the sections were written while I was listening to the talks and are not edited. They may contain factual errors and other horrors.
ROSA: Finding backdoors with fuzzing
(Security) – event page – Michaël Marcozzi and Dimitri Kokkonis.
A backdoor can mean many things to many people; weak server config, ML training data poisoning, or weaknesses in cryptographical algorithms.
"Backdoors can be anything".
This talk focused on code-level backdoors, code embedded in your software that gives an attacker access to a computer. They call this "hidden access", and it is not an exclusively academic problem: xz-utils, php, and proprietary firmware are just some examples where real-world backdoors were founds.
xz-utils was a supply chain attack, because it was a piece of software that many linux systems relied on, and if the attack were to be successful it could have caused a lot of problems.
Fuzzers are a class of software used to find memory errors, exploring errors by randomized testing in both source code and binaries.
The goal of the project is to prevent backdoors in CI for open-source projects. After investigating what options existed for finding backdoors, it was mainly based on manual engineering efforts. The idea is to automate parts of the reverse engineering process. A hurdle was that there was not a large corpus of examples for software backdoors available. Fuzzers are good at finding crashes, but are not really good at finding backdoors.
The idea of ROSA. is to take an out-of-the box Graybox Fuzzer and add a "novel metamorphic oracle" to find backdoor triggering inputs that cause diverging behavior. The team created ROSARUM which is a standardized backdoor benchmark with 17 examples of backdoors to benchmark against.
ROSA can be used to find a backdoor in Boa HTTP server found in some Belkin devices. Phase 1 for the fuzzer is to find representative input and spends some time doing that. Phase 2 is to "intensively explore the input space". ROSA then monitors the syscall interface to see if some inputs trigger diverging system calls. The divergent system calls can then be manually vetted.
Demonstration! Disclaimer: The fuzzer has been biased for the demo not to take 4 hours. The demonstration begins by showing some decompiled PHP server code, which contains a backdoor; "but we don't know that yet". ROSA then starts to run; ROSA is written in Rust and the CLI/TUI is Ratatui a popular Rust TUI framework.
Backdoor found!
The output from ROSA can now be inspected. We see the rosa-explain command in
action: ROSA explains "why this is a backdoor". We then run the application
through strace and after a little bit of scrolling we see a very strange
system call that should not be there; an execv.
If we now run the server program with just the right parameters we get ROOT. A very polite applause from the audience was heard.
Fuzzing is not deterministic! It takes 1.5 hours for a run, and it has a 87% success rate. ROSA is the first fuzzer-based generic backdoor detector and ROSARUM is the first standardized backdoor benchmark.
Interoperability regulation in the EU: Opening iOS and Android for Free Software
(Legacy & Policy) – event page – Alexander Matern, Victor Le Pochat, Lori Roussey, Gabriel Kobus, and Lucas Lasota.
The exciting topic of the EU Digital Markets Act!
Interoperability is important because it gives people the opportunity to communicate between different pieces of hardware and software.
Interoperability regulation panel
Alexander Matern, European Commission's DMA enforcement team. Victor Le Pochat, European Commission's DMA enforcement team. Lori Roussey, Data Rights. Gabriel Kobus, European Commission's DMA enforcement team. Panel moderation: Lucas Lasota, Legal Researcher and Lecturer at the Halle-Wittenberg University.
The biggest companies on the planet do not want to interoperate. Less than 1% of the room uses a mobile phone that does not run iOS or Android (I saw one hand raised).
The DMA puts an obligation on the biggest companies on the planet: it gives open software access to the largest markets on the planet. We have members of the EU DMA enforcement team on stage, and they are fighting "an uphill battle".
It is a simple law: You shall get interoperability by design. Google, Apple, and Microsoft do what they can to avoid providing interoperability. As developers we can go these companies' portals to request interoperability which will add more pressure on them to do the right thing.
Vendors use Security and Integrity as ways to argue that their users will be at risk if their systems were more open. The security of a system may be that when I put a password in place to protect a certain piece of data, and the integrity of the operating system is what makes sure those protections can not be circumvented. The DMA requires that the integrity of a system is not diminished when interoperability is provided, and vendors use that to argue that they can not make their systems more interoperable. Some things that were possible in the past have been cut by way of app stores, even if it did not make the systems inherently more secure.
Apple has always had an adversarial role in the interoperability world, making the relationship with the open source community very simple: we know where they stand. Google on the other hand has a more nuanced relationship; recently the Android OS has taken steps to make it more difficult to run third party app stores. Android devices are relatively easy to modify and run custom operating systems, but recently some changes has made that harder as well. In short, Google's approach to Android governance has changed over the last few years.
Something for the kids: Article 6-7 mentioned a few times; a few smiles seen in the panel.
Data interoperability and portability: Portability is different from interoperability in that portability generally means data flowing one-way where interoperability is defined as (at least) two-way.
The DMA is designed to prevent Gatekeeping: Data access through APIs, documentation for accessing data, and a lot of other things are now required to be provided free of charge and in machine-readable formats.
A small joke from the moderator: In the modern world we are not allowed to do sideloading, but we are expected to do "side-listening" (playing Spotify but not paying attention), and "side-thinking" (using AI to write for us).
The DMA enforcement team have weekly and monthly interactions with the large companies: the enforcement team listen to our complaints w.r.t interoperability and they first ask the vendors nicely, and often they comply, but they also have other regulatory tools in their toolbox (including, ultimately, fines).
A few examples of what has been achieved by the DMA: On iOS you can now set default applications other than Apple's own and iOS now supports alternative app stores, and browser vendors can distribute their own engines for their browsers (at least in the EU).
Adversarial interoperability - Writing a Microsoft Bob application
(Main track) – event page – HP van Braam
"I am HP van Braam from the Godot Foundation, and I like old computers"
Bob – A project from Microsoft from 1994 that not many people have heard about. Is there anything we can learn from this project? Braam came across a forum post claiming that someone had a friend using a computer for only one thing: Writing letters using Microsoft Bob (Letter writer). Her friends had lost her files, oh no!
Bob is a workplace program manager. Basically your desktop, but at that time you did everything from there, a replacement for the Windows 3.1 desktop. "There is an irresistible earnestness to it".
Bob does things that computers simply do not do anymore. You get a birthday present on your birthday (if you enter your birthday in the Bob calendar). There are flowers on your desktop. You can move them around. Scalable vector graphics. Wonderful.
Bob has some slightly outdated skeumorphisms - full screen organizing desk, full screen folder organizer, and so on.
Despite its quirky look, it was built with modern APIs (for the time) - COM, MAPI, and MS JET (whatever that is). Some of those are still used in some form today.
Braam was able to use a combination of a partial dump of the SDK found on the internet, as well as Ghidra decompilation how to figure out how to program for Microsoft Bob.
Back to Jean. Jean was able to get some files on a floppy, but was not able to figure out how to get the letters back. This is because there are no files, everything was saved in a single database (file). This is how the modern world works: every SaaS company saves user data in a huge database.
You can play with Microsoft Bob at https://bob.estate/.
raylib: a 12-year adventure as a solo-maintainer
(Main track) – event page – Ramon (Ray) Santamaria
The basis is a simple and easy to use library to put graphics on the screen, born from a need to teach beginner programmers / students to do graphics programming.
The keyword is "enjoy". It was designed to be enjoyable to use.
The whole presentation today is built in raylib.
With around 100 lines of code you can get a full 2D or 3D application, you can load shaders, and you can also deploy raylib to embedded systems, such as UIs in cars (e.g. openpilot).
A small library to teach graphics or video games programming has evolved over 12 years and just kept growing. In 2019 the library got a Google Open Source Award and at that time it got a lot of attention. In 2020 Ray quit his job and worked full-time on raylib for a while.
The three M's: Maintenance, Motivation, Money – three hard things when working as a solo developer. Asking yourself "How long am I willing to work on my project?". Best advice - Keep it simple! Raylib is "only 50k lines of code".
How long can motivation last? Your primary motivation must be that you enjoy what you do. If you stop to enjoy what you do, it will be difficult to stay with it. Ray stayed motivated by engaging with the community and working on side project related to raylib. Receiving recognition for his work was highly motivating. The last thing is self-care: "no-screen hobbies".
Day 2 - Sunday
WebAssembly on Constrained Devices
(Rust) – event page – Fedor Smirnov
Running WebAssembly on microcontrollers!
Why would you want to do it in the first place?
At Myrmic they build a common middleware layer that manages application code across devices. WASM is a good choice for OS-grade devices, because of strong sandboxing and target-independent deployment. On microcontrollers it isn't as obvious. The things you get is that you can update device behavior without reflashing, it isolates application logic from the firmware and it reduces the risk of bricking; if the application crashes you don't lose access to the device.
What does it mean for your code?
There are a number of build targets for wasm on device; wasi targets which assume things about the runtime and the unknown target that assumes almost nothing. The downside of unknown is that you need to provide the functionality you need yourself, but on the other hand you can avoid some bloat that might not fit into your hardware of choice.
The wasm interface is constrained to integers and floats, but since the host can access the wasm sandbox's memory, you can communicate addresses to the host and the host can then read the memory directly. To make nice interfaces you can wrap all of this low-level stuff in safe Rust interfaces, mostly through macros that implement the functionality for you.
What are the tradeoffs for the runtime and integration?
When you want to run your wasm program on embedded, you need to select a runtime. Unfortunately the Rust runtimes are (currently) quite expensive size-wise, i.e. they require much more memory than the smallest C runtime: Almost 10 times more expensive ~60KiB (wamr) vs ~600KiB (wasmtime). There is also a tradeoff around speed: interpreted mode vs AoT (Ahead-of-Time compiled), the Rust runtimes run in interpreted mode, which is 10 times slower than AoT, which is what wamr uses. There is certainly room for the Rust runtimes to improve!
Rust-boy: A Rust journey into Game Body dev
(Rust) – event page – Federico Bassini
Federico says "The daily developer loop can be kind of boring". But last year Federico discovered something at FOSDEM: A passion for making retro games in Rust!
"The daily developer loop can be kind of boring"
The first part of the talk is a walk-through of the Game Boy and Game Boy Color hardware architecture: Surprisingly similar but with some differences for color management (obviously...).
To make a game you need to be able to write code and compile it in the right format! There are a bunch of tools and documentation online. There are also some tools like GB Studio which is a no-code tool to make Game Boy games.
But Rust can't be compiled directly to the original Game Boy hardware! But Game Boy Advance has an ARM cpu; and there are few Rust projects to support it.
But there is a workaround for Rust on Game Boy! "Rust-GB". It is a way to compile to LLVM-IR and from there convert it to C and finally you can get machine code for The Game Boy.
Can we develop a compiler for Rust to Game
Boy? Rust-boy is a library that tries to go
all the way from Rust to assembly code that is compatible with the Game Boy
hardware. It is a modular codebase that contains gb_asm which emits assembly
code for the Sharp LR35902 processor, gb_std which is a "standard library"
for building Game Boy games, and finally rust_boy that exposes a bunch of
higher-level APIs that makes it easier to start building a Game Boy game.
This library isn't about "writing arbitrary Rust code" and running it on the Game Boy, it is more of an abstraction layer for the assembly code that needs to be generated, so it is still low level.
// Main game loop
asm.label
.ld_bc
.call
.jp;
// VBlank function
asm.chunk
.label
.comment
.ld_a_label
.cp_imm
.jr_cond
.ret;
// Generate assembly
println!;
You still need to know a lot about the Game Boy to use it!
Something Federico sees in the future is a Rust parser which would make it
possible to write actual Rust code and it would be automatically translated to
use gb_std.
GStreamer 1.28 and beyond
(Audio Video & Graphics Creation) – event page – Tim-Philipp Müller
GStreamer is an open source, cross-platform video framework. You can read, write, stream, mix, cut, edit, and do many other things with media.
Major release 1.28! Released just a couple of days ago. TPM will give us a high-level walk through today.
There are a bunch of new codec support: H.266, MPEG-H audio and some other changes. SMPTE 2038 ancillary data that can be used to add metadata to a stream like the game score of a football game.
Enhanced RTMP add support for modern video codecs like H.265 and AV1, also multiple audio and/or video tracks.
HLS stream authoring: I-frame only playlists, and single media file output for Video on Demand use cases.
Speech + Translations support for Speech-to-Text, voice cloning, deepgram speech-to-text transcription, output compression for translated audio to "catch up" if there is a delay in the automatic translation.
Analytics ONNX support, more tensor decoders, and a few other things.
Vulkan AV1 and VP9 decoding support, H.264 encoding support, H.265 decoder with 10-bit depth.
Wayland more support for a few different things for Linux desktop environments.
GNOME ShowTime replaces Totem media player, which uses all the "cool new stuff" that have been added in the last few years.
AMD HIP plugin AND GPU programming API for portable CUDA-like development on AMD or NVIDIA.
Bidnings New C++ bindings, new-ish Go bindings, Python bindings improvements, and Rust bindings improvements.
fallbacksrc multi-stream support via the Streams API, supports encoded output; not just raw audio/video.
Misc VMAF element (perceptual video assessment score), Webkit gets a new plugin for the "WPE Platform API".
Tracing and debugging enhanced dots-viewer, GstLogContext to fine-tune logging output to reduce log message spam.
Future stuff!
GStreamer will be adding more Rust, "that is where the cool stuff happens". Media over QUIC: a simpler replacement for WebRTC. WebRTC stack is going to be converted to Rust, which will improve scalability. MPEG-TS will be converted to Rust, complete rewrite which will give us more reliability and it will get a more robust time domain. More speech & translation features; already support cloud translation but new focus will be local translation e.g. Whisper. More formats like AV2.
Clickhouse’s C++ and Rust journey
(Rust) – event page – Alexey Milovidov
"How to avoid a full rewrite".
ClickHouse is an open source project, mostly C++ codebase which is about 1.5MLoC.
"C++ is not the nicest language", but it was a good choice in 2009 and it is prominent in many domains like games development and database management systems.
If we started today would we write ClickHouse in Rust? The pain of C++ is " soothed" by running a lot of tests and santizers (ASan, TSan, UBSan, and so on) in CI. Lots and lots of tests: 10-30 million test invocations per day. They also run Jepsen tests on their database.
Arguments against Rust: Full rewrite would take years. Combining two languauges is sometimes worse than using just one or the other. "Throwing away accumulated knowledge".
ClickHouse's approach: Iterative Development. Take a non-essential library that can easily be turned off, and use it as an example; added a new function to SQL for BLAKE3 hashing. The second thing they did was to improve their command line application; the result of this was "Rust was worth it". Next they added a new language dialect, PRQL, that existed as a Rust library.
ClickHouse added support for the Delta Lake format for Data Lakes, and it was integrated using an existing Rust library.
What is wrong with Rust? To combine C++ with Rust you need to take some extra care. To get reproducible builds you need to take care of a few things: all dependencies must be pinned to to avoid supply-chain attacks, and dependencies must be built from source.
When writing wrapper libraries for C++, you have to take extra care to make sure the interface is safe to use and correct. C++ and Rust error handling works a bit differently; C++ uses exceptions, and Rust libraries typically pass errors upwards on the stack, or the code panics. You don't want a third party library with an internal panic to bring down your server or application. "ClickHouse CI found bugs (causing panics) in every Rust library we used".
When it comes to sanitizers, for C++ all code must be checked with sanitizers. For (safe) Rust you might think that sanitizers are not needed, but when combining it with C++ it must be possible to run the sanitizers on the combined code.
Takeaways: Rust is a great language. You can come and be ClickHouse contributor by adding features using Rust!
A word from our sponsor
Now go watch this talk where Bryan Cantrill references Swedish physician Torsten Thunberg's "Thermal Grill Illusion" ( two pipes, one slightly warm and the other slightly cool, are twisted together, and when touched cause a strong reaction to want to pull your hand away as a metaphor for Marc Andreesen's writing on "Software is eating the world".