crate</th>	notes</th>	Runtime</th>	transport</th></tr></thead>
async-stomp</td>	Has its own client and server types.</td>	Tokio</td>	TCP</td></tr>
stomp</td>	Callback API (not async)</td>	-</td>	TCP</td></tr>
wstomp</td>	Somehow uses both actix and Tokio...</td>	awc / actix</td>	WebSocket</td></tr>
stomp-parser</td>	"Just a parser"</td>	-</td>	-</td></tr>
iridium-stomp</td>	Has its own client type</td>	Tokio</td>	TCP</td></tr> </tbody></table> </div> There is a trend here: Almost every library except for `wstomp</code> and stomp-parser</code> use TCP transport, and I need to use WebSocket as the transport layer. The crate for WebSocket communication I want to use is tokio-tungstenite</a> but no existing STOMP library I found offers that.</p>` `Furthermore, every library except for stomp-parser</code> and stomp</code> are tied to a specific async runtime. At Spiideo we are building more and more cross-platform functionality in Rust that is supposed to work across iOS, Web, Desktop, Backend, and Android. Using Tokio or other async runtimes in the browser is not worth it in my experience; wasm-bindgen-futures</code> is enough if you design your software to be async without using runtime specific functionality.</p>` `Of the existing choices, none fit the bill.</p>` `It would be great to have a STOMP library that is pluggable. Since STOMP is such a simple protocol (it really is very simple), it should be possible to build a library that is more than a parser, but also doesn't go all the way to mandate a specific transport protocol.</p>` `Finding a fork</h1>`Out of the available choices, async-stomp</code> seems the best fit for what I want to do. async-stomp</code> was relicensed to use the EUPL</a> license in addition to the original MIT license. I'm very much not a license expert, but the EUPL seems like a reasonable license. I am actually a fan of the EU's work in this field, especially the DMA Enforcement Team</a>, so I'm not even going to try to do anything about the license.</p> Comically, async-stomp</code> is a fork of tokio-stomp-2</code>, which is a fork of tokio-stomp</code>. I don't think it is out of character to fork it once more.</p> If you don't know what you are doing, use the original tokio-stomp</p> Caveat Emptor: tokio-stomp-2</div> </div> Fun quote I found in the tokio-stomp-2</code> repository while researching 👆. At what point am I expected to know what I am doing?</p> How do we fork?</h1> There are some juicy parts that we are going to need and some parts that we are going to rip right out of async-stomp</code>. The main things to keep are the Frame</code> and Message</code> types, both of which represent a STOMP frame: A Message</code> is the high-level variety and Frame</code> contains the bytes received or to-be-sent. The throwing away part is easy: anything that has to do with TCP transport or Tokio.</p> The Message</code> type comes in two flavors: Message<FromServer></code> and Message<ToServer></code>. The nomenclature is client centric, but I don't think renaming Message<FromServer></code> to Message<ToClient></code> would help. Either way you are doing some sort of purpose inversion in your head when implementing either the client or server parts. Adding type aliases might help, but I don't think it would help much.</p> Designing an agnostic interface</h1> The two axes I want to design along are freedom to choose whatever transport you want and the madness to use whatever async runtime you want.</p> We are going to need two simple-to-implement traits for the transport layer, one for the client transport and one for the server transport. On top of that we are going to have handles for the client and server parts of STOMP.</p> The ClientTransport</code> and ServerTransport</code> traits are similar from a design point-of-view so there is no use exploring the design of more than one; for convenience we will look at the client side of things.</p> The implementation can be found at github.com/bes/stomp-agnostic</a>.</p> ClientTransport</h2> An important detail for the transport layer is going to be an escape hatch for dealing with protocol-specific communication. For example, a WebSocket connection has Ping and Pong messages, which are not part of STOMP but need to be handled if they come down the wire.</p> Here's the trait for ClientTransport</code>.</p> #</span>[</span>async_trait</span>]</span></span> </span>pub</span> trait</span> ClientTransport</span>: Send + Sync {</span> </span></span></span> ///</span> A side channel to shuffle arbitrary data that is not part of the STOMP communication, </span></span></span></span> ///</span> e.g. WebSocket Ping/Pong. </span></span></span></span> type</span> ProtocolSideChannel</span>;</span> </span></span></span> </span></span></span> async fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, message</span>:</span> Message<</span>ToServer></span></span></span>)</span></span></span></span> -></span> Result</span><</span>(</span>)</span>, WriteError></span></span></span></span>;</span> </span></span></span> async fn</span> </span>read</span></span>(</span>&</span>mut</span> self</span></span>)</span></span></span></span> -></span> Result</span><</span>ReadData<</span>Self</span>::</span></span></span>ProtocolSideChannel></span></span>, ReadError></span></span></span></span>;</span> </span></span></span></span>}</span></span></span> </span></code></pre> Reading is a matter of getting bytes from some source and then buffering until we have a full Message<FromServer></code>. Writing similarly is a matter of converting the given Message<ToServer></code> to bytes using the .into_bytes</code> method and sending them down the wire. Taking a Message<ToServer></code> instead of just raw bytes for .write</code> makes it impossible (or at least very hard) to misuse the transport trait.</p> ReadData</code> is a simple enum; either bytes (STOMP data) or some special type T</code> (Self::ProtocolSideChannel</code> in our case) that belongs to the transport protocol.</p> ///</span> Data coming down the line from the transport layer. When the transport layer is </span></span>///</span> e.g. WebSocket, custom data such as Ping/Pong can be handled separately from STOMP data </span></span>///</span> by using the `Custom` variant. </span></span>#</span>[</span>derive</span>(</span></span></span>Debug</span></span>)</span></span></span>]</span></span> </span>pub</span> enum</span> ReadData</span><T> {</span> </span></span></span> Binary(</span>Bytes</span>)</span></span>,</span> </span></span></span> Custom(</span>T</span>)</span></span>,</span> </span></span></span></span>}</span></span></span> </span></code></pre> The ProtocolSideChannel</code> can be as simple as ()</code> but for WebSocket it will need to be an enum for the special cases.</p> enum</span> WebsocketProto</span> {</span> </span></span></span> Ping(</span>Bytes</span>)</span></span>,</span> </span></span></span> Pong(</span>Bytes</span>)</span></span>,</span> </span></span></span></span>}</span></span></span> </span></code></pre> Notice that to keep the trait simplish, I decided not to be able to send ProtocolSideChannel</code> data through the ClientTransport</code> trait, only to receive it through read. This doesn't stop us from sending a WebSocket Ping though, since the design of the handle allows us to temporarily (or permanently) drop down to transport level and get a hold of the original type.</p> The magic, if you will, is in transport::client::BufferedTransport</code></p> pub</span>(</span>crate</span></span>)</span></span> struct</span> </span>BufferedTransport</span><</span>T></span></span></span></span> </span></span>where </span></span> T: ClientTransport, </span></span> T::ProtocolSideChannel: Debug, </span></span></span>{</span> </span></span></span> transport</span>:</span> T, </span></span></span> buffer</span>:</span> BytesMut, </span></span></span></span>}</span></span></span> </span></code></pre> BufferedTransport</code> holds on to an implementation of ClientTransport</code>. As we receive data from the transport, it's buffered in a BytesMut</code> until we can read a whole Frame</code>. When we are not waiting on a .read</code> or .write</code> we can get a hold of the underlying transport through BufferedTransport</code></p> pub</span>(</span>crate</span></span>)</span></span> fn</span> </span>into_transport</span></span>(</span>self</span></span>)</span></span></span></span> -></span> T</span> </span>{</span> </span></span></span> self</span>.</span>transport </span></span></span></span>}</span></span></span> </span> </span>pub</span>(</span>crate</span></span>)</span></span> fn</span> </span>as_mut_inner</span></span>(</span>&</span>mut</span> self</span></span>)</span></span></span></span> -></span> &</span>mut</span> T</span> </span>{</span> </span></span></span> &</span>mut</span> self</span>.</span>transport </span></span></span></span>}</span></span></span> </span></code></pre> Unfortunately BufferedTransport</code> is crate-private, but the methods are proxied through ClientStompHandle</code>.</p> ClientStompHandle</h2> The handle type is really just a very thin wrapper around the BufferedTransport</code>, but you can only get a ClientStompHandle</code> using the ClientStompHandle::connect</code> associated function, which makes sure to do a successful STOMP client handshake.</p> Once you have a ClientStompHandle</code> it's time to rock'n'roll</p> impl</span></span><</span>T></span></span></span> ClientStompHandle</span><</span>T></span></span> </span></span></span>where</span> </span></span> T:</span> ClientTransport, </span></span> T</span>::</span></span></span>ProtocolSideChannel:</span> Debug, </span></span></span>{</span> </span></span></span> ///</span> Send a STOMP message through the underlying transport </span></span></span></span> pub</span> async fn</span> </span>send_message</span></span>(</span>&</span>mut</span> self</span>, message</span>:</span> Message<</span>ToServer></span></span></span>)</span></span></span></span> -></span> Result</span><</span>(</span>)</span>, WriteError></span></span></span> </span>{</span> </span></span></span></span></span> self</span>.</span>transport.</span>send</span>(</span>message</span>)</span></span>.</span>await </span></span></span></span></span> </span>}</span></span></span> </span></span></span> </span></span></span> ///</span> Read a STOMP message from the underlying transport </span></span></span></span> pub</span> async fn</span> </span>read_response</span></span>(</span> </span></span></span></span></span> &</span>mut</span> self</span>, </span></span></span></span></span> </span>)</span></span></span></span> -></span> Result</span><</span>ServerResponse<</span>T</span>::</span></span></span>ProtocolSideChannel></span></span>, ReadError></span></span></span> </span>{</span> </span></span></span></span></span> self</span>.</span>transport.</span>next</span>(</span></span>)</span></span>.</span>await </span></span></span></span></span> </span>}</span></span></span> </span></span></span></code></pre> Implementing a WebSocket client transport</h1> There are simple and functional, but not fully fleshed out, examples in the stomp-agnostic repository</a>. The client example code uses tokio-tungstenite</code> to create a WebSocket client and the server example uses axum</code> to expose an endpoint that can be turned into a WebSocket connection.</p> Since there are only three server frames to consider, plus the underlying WebSocket protocol, it doesn't take much to implement the full ClientTransport</code></p> #</span>[</span>async_trait</span>]</span></span> </span>impl</span> </span>ClientTransport for</span></span> WsTransport</span> </span>{</span> </span></span></span> type</span> ProtocolSideChannel</span> =</span> WebsocketProto;</span> </span></span></span> </span></span></span> async fn</span> </span>write</span></span>(</span> </span></span></span></span></span> &</span>mut</span> self</span>, </span></span></span></span></span> message</span>:</span> stomp_agnostic::</span></span>Message<</span>ToServer></span></span>, </span></span></span></span></span> </span>)</span></span></span></span> -></span> Result</span><</span>(</span>)</span>, WriteError></span></span></span> </span>{</span> </span></span></span></span></span> let</span> bytes =</span> message.</span>into_bytes</span>(</span></span>)</span></span>;</span> </span></span></span></span></span> //</span> Check that bytes is valid UTF-8! </span></span></span></span></span></span> //</span> NOTE: This is part of the safety, do not remove! </span></span></span></span></span></span> let</span> _</span> =</span> str</span>::</span></span>from_utf8(</span>&</span>bytes</span>)</span></span>?</span>;</span> </span></span></span></span></span> let</span> ws_message =</span> Message::</span></span>Text(</span> </span></span></span></span></span></span> //</span> Safety: We checked that bytes are valid UTF-8 above </span></span></span></span></span></span></span> unsafe</span> {</span> Utf8Bytes::</span></span>from_bytes_unchecked(</span>bytes</span>)</span></span> </span>}</span></span>,</span> </span></span></span></span></span></span> </span>)</span></span>;</span> </span></span></span></span></span> self</span>.</span>ws_stream </span></span></span></span></span> .</span>send</span>(</span>ws_message</span>)</span></span> </span></span></span></span></span> .</span>await </span></span></span></span></span> .</span>map_err</span>(</span>\|</span></span></span>e</span>\|</span></span> </span>WriteError::</span></span>Other(</span>anyhow!</span>(</span>e</span>)</span></span></span>)</span></span></span></span>)</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span> </span></span></span> async fn</span> </span>read</span></span>(</span>&</span>mut</span> self</span></span>)</span></span></span></span> -></span> Result</span><</span>ReadData<</span>Self</span>::</span></span></span>ProtocolSideChannel></span></span>, ReadError></span></span></span> </span>{</span> </span></span></span></span></span> loop</span> {</span> </span></span></span></span></span></span> let</span> message =</span> self</span> </span></span></span></span></span></span> .</span>ws_stream </span></span></span></span></span></span> .</span>next</span>(</span></span>)</span></span> </span></span></span></span></span></span> .</span>await </span></span></span></span></span></span> .</span>transpose</span>(</span></span>)</span></span> </span></span></span></span></span></span> .</span>map_err</span>(</span>\|</span></span></span>e</span>\|</span></span> </span>ReadError::</span></span>Other(</span>anyhow!</span>(</span>e</span>)</span></span></span>)</span></span></span></span>)</span></span>?</span>;</span> </span></span></span></span></span></span> if</span> let</span> Some</span>(</span>message</span>)</span></span> =</span> message {</span> </span></span></span></span></span></span></span> match</span> message {</span> </span></span></span></span></span></span></span></span> Message::</span></span>Text(</span>utf8_bytes</span>)</span></span> =></span> {</span> </span></span></span></span></span></span></span></span></span> return</span> Ok</span>(</span>ReadData::</span></span>Binary(</span>Bytes::</span></span>copy_from_slice(</span> </span></span></span></span></span></span></span></span></span></span></span></span> utf8_bytes.</span>as_bytes</span>(</span></span>)</span></span>,</span> </span></span></span></span></span></span></span></span></span></span></span></span> </span>)</span></span></span>)</span></span></span>)</span></span>;</span> </span></span></span></span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span></span></span></span> Message::</span></span>Binary(</span>bytes</span>)</span></span> =></span> {</span> </span></span></span></span></span></span></span></span></span> return</span> Ok</span>(</span>ReadData::</span></span>Binary(</span>bytes</span>)</span></span></span>)</span></span>;</span> </span></span></span></span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span></span></span></span> Message::</span></span>Ping(</span>data</span>)</span></span> =></span> {</span> </span></span></span></span></span></span></span></span></span> return</span> Ok</span>(</span>ReadData::</span></span>Custom(</span>WebsocketProto::</span></span>Ping(</span>data</span>)</span></span></span>)</span></span></span>)</span></span>;</span> </span></span></span></span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span></span></span></span> Message::</span></span>Pong(</span>data</span>)</span></span> =></span> {</span> </span></span></span></span></span></span></span></span></span> return</span> Ok</span>(</span>ReadData::</span></span>Custom(</span>WebsocketProto::</span></span>Pong(</span>data</span>)</span></span></span>)</span></span></span>)</span></span>;</span> </span></span></span></span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span></span></span></span> Message::</span></span>Close(</span>_</span></span>)</span></span> =></span> {</span> </span></span></span></span></span></span></span></span></span> return</span> Err</span>(</span>ReadError::</span></span>ConnectionClosed</span>)</span></span>;</span> </span></span></span></span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span></span></span></span> Message::</span></span>Frame(</span>_</span></span>)</span></span> =></span> {</span> </span></span></span></span></span></span></span></span></span> return</span> Err</span>(</span>ReadError::</span></span>UnexpectedMessage</span>)</span></span>;</span> </span></span></span></span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span></code></pre> Fifty-seven lines, including a lot of curly braces.</p> A note on cancel safety</h2> Rust cancel safety can be tricky, so be sure to understand the details before implementing ClientTransport</code> or ServerTransport</code>. RFD-400 Dealing with cancel safety in async Rust</a> is fantastic and is a very good resource on the subject.</p> In short, If a function isn't cancel safe there is a risk of leaving the system (your program, your customer's program) in a broken state, a state where some property of the system has been violated.</p> Let's take a quick look at ClientTransport</code> as an example again:</p> async fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, message</span>:</span> Message<</span>ToServer></span></span></span>)</span></span></span></span> -></span> Result</span><</span>(</span>)</span>, WriteError></span></span></span></span>;</span> </span>async fn</span> </span>read</span></span>(</span>&</span>mut</span> self</span></span>)</span></span></span></span> -></span> Result</span><</span>ReadData<</span>Self</span>::</span></span></span>ProtocolSideChannel></span></span>, ReadError></span></span></span></span>;</span> </span></code></pre> The implementor's responsibility is to make sure that .write</code> and .read</code> are cancel safe. It's a matter of being careful: You are probably going to use some other library (I used tokio-tungstenite</code> and axum</code> in the example code in the repo) to implement the functions. It's your responsibility to figure out their cancel safety properties.</p> Sending and receiving messages</h1> The best part of stomp-agnostic</code> is how easy it is to use once the transport has been implemented.</p> I'm hand-waving a bit here, but it doesn't need to be more complicated than this to handle sending and receiving messages as a STOMP-over-WebSocket client</p> let</span> mut</span> stomp =</span> ClientStompHandle::</span></span>connect(</span> /</span> ... /</span></span></span>)</span></span>.</span>await?</span> </span>loop</span> {</span> </span></span> select!</span> {</span> </span></span></span> _</span> =</span> cancellation.</span>cancelled</span>(</span></span>)</span></span> =></span> {</span> </span></span></span></span> break</span>;</span> </span></span></span></span> </span>}</span></span>,</span> </span></span></span> message_to_send =</span> internal_message_channel.</span>recv</span>(</span></span>)</span></span> =></span> {</span> </span></span></span></span> match</span> message_to_send {</span> </span></span></span></span></span> Some</span>(</span>message</span>)</span></span> =></span> stomp.</span>send_message</span>(</span>message</span>)</span></span>.</span>await?</span>,</span> </span></span></span></span></span> None</span> =></span> break</span>,</span> </span></span></span></span></span> </span>}</span></span> </span></span></span></span> </span>}</span></span> </span></span></span> response_result =</span> stomp.</span>read_response</span>(</span></span>)</span></span> =></span> {</span> </span></span></span></span> let</span> response =</span> response_result?</span>;</span> </span></span></span></span> match</span> response {</span> </span></span></span></span></span> Response::</span></span>Message(</span>message</span>)</span></span> =></span> {</span> </span></span></span></span></span></span> match</span> message.</span>content {</span> </span></span></span></span></span></span></span> FromServer::</span></span>Message {</span> body,</span> ..</span> </span>}</span></span> =></span> {</span> </span></span></span></span></span></span></span></span> //</span> ... </span></span></span></span></span></span></span></span></span></code></pre> What now?</h1> Having this library enabled me to replace our very old iOS STOMP client library by writing a few glue functions using UniFFI. All the lovely Rust async cancellation, and a simple library that I am familiar with that can be reused for many other cases.</p> I'm currently also working on a desktop application for Spiideo that has a STOMP-over-WebSocket server, obviously powered by stomp-agnostic</code>. The magic of loop</code>, select!</code>, CancellationToken</code>, and channels makes it easy to build robust software that is easy to understand. Certainly a far cry from callback based concurrent programming. Rust manages to beat any other programming language I've tried, including async Swift and async TypeScript.</p> I'm hoping that stomp-agnostic</code> will not only be a tool for me to keep building a variety of Rust STOMP clients and servers, but also for others that have needs that stray from the available STOMP Rust libraries.</p> FOSDEM 2026 2026-01-31T00:00:00+00:00 I had the opportunity to go to FOSDEM 2026!</p> </span> Chaos on the rails</h1> 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.</p> 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.</p> In short, Germany tried to break me, but I am still here and more powerful than ever.</p> ULB Campus</h1> 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.</p> Smoke</p> </div> </a> Not a fire, that's just smoke from a lot</em> of fries.</p> </div> Day 1 - Saturday</h1> 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.</p> ROSA: Finding backdoors with fuzzing</h2> (Security) – event page</a> – Michaël Marcozzi and Dimitri Kokkonis.</p> A backdoor can mean many things to many people; weak server config, ML training data poisoning, or weaknesses in cryptographical algorithms.</p> "Backdoors can be anything".</p> 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.</p> 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.</p> Fuzzers are a class of software used to find memory errors, exploring errors by randomized testing in both source code and binaries.</p> 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.</p> The idea of ROSA</a>. 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.</p> 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.</p> 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.</p> Backdoor found!</p> The output from ROSA can now be inspected. We see the rosa-explain</code> command in action: ROSA explains "why this is a backdoor". We then run the application through strace</code> and after a little bit of scrolling we see a very strange system call that should not be there; an execv</code>.</p> If we now run the server program with just the right parameters we get ROOT. A very polite applause from the audience was heard.</p> 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.</p> Interoperability regulation in the EU: Opening iOS and Android for Free Software</h2> (Legacy & Policy) – event page</a> – Alexander Matern, Victor Le Pochat, Lori Roussey, Gabriel Kobus, and Lucas Lasota.</p> The exciting topic of the EU Digital Markets Act!</p> Interoperability is important because it gives people the opportunity to communicate between different pieces of hardware and software.</p> Interoperability regulation panel</p> </div> </a> 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.</p> </div> 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).</p> 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".</p> 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.</p> 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.</p> 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.</p> Something for the kids: Article 6-7 mentioned a few times; a few smiles seen in the panel.</p> 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.</p> 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.</p> 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).</p> 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).</p> 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).</p> Adversarial interoperability - Writing a Microsoft Bob application</h2> (Main track) – event page</a> – HP van Braam</p> "I am HP van Braam from the Godot Foundation, and I like old computers"</p> Braam</div> </div> 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!</p> 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".</p> </a> 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.</p> Bob has some slightly outdated skeumorphisms - full screen organizing desk, full screen folder organizer, and so on.</p> 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.</p> 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.</p> 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.</p> You can play with Microsoft Bob at https://bob.estate/</a>.</p> raylib: a 12-year adventure as a solo-maintainer</h2> (Main track) – event page</a> – Ramon (Ray) Santamaria</p> </a> 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.</p> The keyword is "enjoy". It was designed to be enjoyable to use.</p> The whole presentation today is built in raylib</a>.</p> 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).</p> 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.</p> 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".</p> 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".</p> Day 2 - Sunday</h1> WebAssembly on Constrained Devices</h2> (Rust) – event page</a> – Fedor Smirnov</p> Running WebAssembly on microcontrollers!</p> Why would you want to do it in the first place?</p> 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.</p> What does it mean for your code?</p> 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.</p> 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.</p> What are the tradeoffs for the runtime and integration?</p> 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!</p> Rust-boy: A Rust journey into Game Body dev</h2> (Rust) – event page</a> – Federico Bassini</p> 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!</p> "The daily developer loop can be kind of boring"</p> Federico</div> </div> 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...).</p> 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.</p> 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.</p> 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.</p> Can we develop a compiler for Rust to Game Boy? Rust-boy</a> 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</code> which emits assembly code for the Sharp LR35902 processor, gb_std</code> which is a "standard library" for building Game Boy games, and finally rust_boy</code> that exposes a bunch of higher-level APIs that makes it easier to start building a Game Boy game.</p> 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.</p> //</span> Main game loop </span></span> asm.</span>label</span>(</span>"</span>MainLoop"</span></span></span>)</span></span> </span> .</span>ld_bc</span>(</span>160</span></span>)</span></span> </span> .</span>call</span>(</span>"</span>WaitVBlank"</span></span></span>)</span></span> </span> .</span>jp</span>(</span>"</span>MainLoop"</span></span></span>)</span></span>;</span> </span> </span> //</span> VBlank function </span></span> asm.</span>chunk</span>(</span>Chunk::</span></span>Functions</span>)</span></span> </span> .</span>label</span>(</span>"</span>WaitVBlank"</span></span></span>)</span></span> </span> .</span>comment</span>(</span>"</span>Wait for vertical blank"</span></span></span>)</span></span> </span> .</span>ld_a_label</span>(</span>"</span>[$FF44]"</span></span></span>)</span></span> </span> .</span>cp_imm</span>(</span>144</span></span>)</span></span> </span> .</span>jr_cond</span>(</span>Condition::</span></span>NZ</span>,</span> "</span>WaitVBlank"</span></span></span>)</span></span> </span> .</span>ret</span>(</span></span>)</span></span>;</span> </span> </span> //</span> Generate assembly </span></span> println!</span>(</span></span>"</span>{}</span>"</span></span></span>,</span> asm.</span>to_asm</span>(</span></span>)</span></span>)</span></span>;</span> </span></code></pre> You still need to know a lot about the Game Boy to use it!</p> 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</code>.</p> GStreamer 1.28 and beyond</h2> (Audio Video & Graphics Creation) – event page</a> – Tim-Philipp Müller</p> GStreamer is an open source, cross-platform video framework. You can read, write, stream, mix, cut, edit, and do many other things with media.</p> Major release 1.28! Released just a couple of days ago. TPM will give us a high-level walk through today.</p> There are a bunch of new codec support</strong>: H.266, MPEG-H audio and some other changes. SMPTE 2038 ancillary data</strong> that can be used to add metadata to a stream like the game score of a football game.</p> Enhanced RTMP</strong> add support for modern video codecs like H.265 and AV1, also multiple audio and/or video tracks.</p> HLS stream authoring</strong>: I-frame only playlists, and single media file output for Video on Demand use cases.</p> Speech + Translations</strong> 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.</p> Analytics</strong> ONNX support, more tensor decoders, and a few other things.</p> Vulkan</strong> AV1 and VP9 decoding support, H.264 encoding support, H.265 decoder with 10-bit depth.</p> Wayland</strong> more support for a few different things for Linux desktop environments.</p> GNOME</strong> ShowTime replaces Totem media player, which uses all the "cool new stuff" that have been added in the last few years.</p> AMD HIP plugin</strong> AND GPU programming API for portable CUDA-like development on AMD or NVIDIA.</p> Bidnings</strong> New C++ bindings, new-ish Go bindings, Python bindings improvements, and Rust bindings improvements.</p> fallbacksrc</strong> multi-stream support via the Streams API, supports encoded output; not just raw audio/video.</p> Misc</strong> VMAF element (perceptual video assessment score), Webkit gets a new plugin for the "WPE Platform API".</p> Tracing and debugging</strong> enhanced dots-viewer, GstLogContext to fine-tune logging output to reduce log message spam.</p> Future stuff!</p> 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.</p> Clickhouse’s C++ and Rust journey</h2> (Rust) – event page</a> – Alexey Milovidov</p> "How to avoid a full rewrite".</p> ClickHouse is an open source project, mostly C++ codebase which is about 1.5MLoC.</p> "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.</p> 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.</p> 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".</p> 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.</p> ClickHouse added support for the Delta Lake format for Data Lakes, and it was integrated using an existing Rust library.</p> 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.</p> 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".</p> 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.</p> Takeaways: Rust is a great language. You can come and be ClickHouse contributor by adding features using Rust!</p> A word from our sponsor</h1> Now go watch this talk</a> where Bryan Cantrill references Swedish physician Torsten Thunberg's "Thermal Grill Illusion"</a> ( 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".</p> How two generations of internal indoor map apps created a new line of business at Sony 2025-07-18T00:00:00+00:00 In 2009, I was assigned to one of the Android teams at Sony Ericsson. To get up to speed I experimented with the different Android APIs. At this time I had been working at Sony Ericsson for 3 years already, and the massive footprint of the company in Lund required office landscapes the size of small towns. But also meeting rooms. Lots of meeting rooms.</p> </span> This is the story of how SEMCMap (SEMC being short for Sony Ericsson Mobile Communications) was created, how SonyMap spawned from a completely different project, how they were merged, how we managed to be the first project to be accepted by the brand-new Research and Incubation initiative at Sony Mobile, how it was the first project to "exit" Research and Incubation a few months before I left Sony Mobile for Spiideo, and finally how it became a completely new line of business1</a></sup> for Sony Europe.</p> </div> I need to give Magnus Persson a big Thank You for helping me remember details that would have otherwise been lost to time. You were invaluable. Thank You!</p> </div> Smartphone and application maturity in 2009</h1> In 2009, there were very few smartphones: The iPhone 3Gs had just been released, and Sony Ericsson was about to release the Xperia X102</a></sup>. There weren't many apps, and there definitely weren't any popular indoor-navigation apps.</p> Smartphone screens were tiny compared to the screens we have today, and the phones weren't exactly snappy, even if it maybe felt like they were then and there. The Xperia X102</a></sup> had a 4-inch screen and the iPhone 3Gs had a 3.5-inch screen. Today it's hard to find a smartphone with a screen that's smaller than 6 inches. Apps weren't very pretty, especially on Android, which honestly had a lot of catching up to do at the time.</p> SEMCMap</h1> The first indoor map application I worked on was SEMCMap. I created it while I was looking into the Android APIs. My first attempts were terrible: performance-wise, design-wise, you name it. No compass, no auto-rotate, and no indoor positioning.</p> It was rough being a user of SEMCMap, but it quickly gained in popularity, since it filled a niche that people needed help with — finding their way to the meeting room they were supposed to be in. If you've ever worked at a large company, or in a building with a lot of meeting rooms, you probably have some sense of how disorienting it can be when every floor looks the same and there are hundreds of meeting rooms.</p> The main use-case was basically just typing a meeting room name into the search box, selecting the meeting room and then trying to decipher where you were going based on where you thought you were and where the map told you the meeting room was.</p> A lot of people were using SEMCMap at the time</p> </div> </a> </div> SEMCMap had one redeeming feature though — the ability to send your position to someone else through the app. You could use your Google account to quickly sign in, and then use those credentials to send a message to another signed-in user along with the location. The feature was popular and well-used.</p> So far so good. I maintained the application myself for a few years, and a lot of people seemed to like it! Mostly I did other work: phone book, social media integrations, and so on. I worked through a lot of tasks and a lot of teams.</p> SEMCMap and Indoor Finder coexist for a while</h1> Magnus Persson3</a></sup> and I know each other from my early days at Sony Ericsson. He was working in some of the same teams that I did. A cool cat, and full of energy and great ideas. I think I met him the first time in 2006, I was 24 at the time feels like yesterday but almost 20 years have passed. Life comes at you fast.</p> While I had been working on SEMCMap on-and-off for a couple of years, Magnus was working in the Technology department. The Technology department was tasked with keeping track of new technologies and making sure those ended up in Sony Mobile's devices.</p> Around 2011, Magnus ran a project called Indoor Finder together with Ericsson Research, with Sony Mobile mainly contributing to the map interface and the positioning functionality. At the time, he wrote a blog post, which can still be found using The Internet Archive's wayback machine! I did a little archiving myself — have a look at the PDF</a>.</p> Left is SEMCMap, right is Indoor Finder</p> </div> </a> </div> At the end of 2011 Sony Ericsson was being transformed into Sony Mobile, after Sony bought out Ericsson to gain full ownership and control of the company.</p> SonyMap</h1> Ericsson Research lost interest in the joint research project Indoor Finder at some point, and Sony Mobile fully took over the project. Magnus and I both had a lot of ideas and Magnus talked me into joining him to work full-time on SonyMap. Roger Jansson4</a></sup>, was my manager's manager at the time, and he was happy to give the permission to go ahead, and we went ahead... full steam.</p> We both agreed that Indoor Finder was a better starting point than SEMCMap, but a lot of the code and ideas from the internals of SEMCMap made it over to the new SonyMap application. We brought on more people, and we were usually at least two, but usually three, or even four people working on it at this time. One of the good people got help from was Oskar Syrén5</a></sup> who implemented an improved fused indoor positioning engine that used a combination of GPS, Bluetooth Low Energy beacons, and Dead Reckoning.</p> Bluetooth Low-Energy Beacon</p> </div> </a> </div> Magnus dutifully ordered parts and assembled Franken-BTLE beacons and placed them in every single meeting room</em> — and there were a lot! Every BTLE beacon was attached to a standard Sony Mobile USB charger. You would think people would just leave them alone, but you'd be wrong.</p> Research and Incubation</h1> Around 2014 things were not going great for Sony Mobile. Actually, things had not been going great for a while. Samsung and Apple are currently the biggest smartphone manufacturers, and that was true in 2014 too. There was more competition for sure: LG, Motorola, even Nokia, but they were all small too.</p> Patrik Olsson6</a></sup> kicked off the Research and Incubation (R&I) department. Anyone that had an idea could apply, and SonyMap was the first project to get accepted. Magnus and I were very happy about that, since it showed that we had worked on something that was useful to people.</p> Getting accepted to R&I was great for us, but it also serves as an example of what happens when a project gets the spotlight on it in an organization starved for success. All of a sudden I wasn't spending my days planning concrete things to do with our application, or building cool features, I was in meetings with people wanting a piece of the cake.</p> On the other hand, we now got to staff our development team with amazing engineers and designers. It was a fun time, and the team built a lot of interesting stuff, most of which was actually usable and shippable. One of the engineers that joined at this time was Mattias Niklewski, who I consider to be a good friend, and one of the finest engineers I have worked with.</p> We weren't just the first project to get accepted to the R&I process. The goal for an R&I project was to "graduate" a real product, and we did that too, as the first graduate project from R&I no less.</p> Nimway</h1> But, I had done my time at Sony Mobile. I was ready for a new adventure. So after a little courting I accepted an offer to join Spiideo. Magnus tried to get me to stay on, but my mind was set on moving on.</p> Magnus stayed for another 8 years. Mattias, and Oskar are still there, and the team did a great job acquiring clients under the Nimway1</a></sup> moniker. A few years after I left, the project moved on from Sony Mobile and joined Sony Europe, and is still going strong from what I can gather!</p> It's satisfying to see how something with small beginnings was able to evolve and amalgamate, finally becoming a whole new business segment for a huge company like Sony. I'm proud to be one of the parents of SonyMap, now part of Nimway, and I'm glad to see that what started as our side project continues to employ people.</p> References</h1> ^1</sup>https://www.sonynetworkcom.com/nimway</a></p> </div> ^2</sup>https://en.wikipedia.org/wiki/Sony_Ericsson_Xperia_X10</a></p> </div> ^3</sup>https://www.linkedin.com/in/magnuspersson78/</a></p> </div> ^4</sup>https://www.linkedin.com/in/brjansson/</a></p> </div> ^5</sup>https://www.linkedin.com/in/oskar-syr%C3%A9n-79023857/</a></p> </div> ^6</sup>https://www.linkedin.com/in/polsson/</a></p> </div> I remade a 20-year-old game to learn Bevy ECS 2025-01-02T00:00:00+00:00 I got the fantastic idea to learn Bevy ECS</a> by recreating a game I developed with a friend a long time ago. The main goal is to remake the game, written in Java in the standard pointer soup programming style, using an Entity Component System—a kind of type system driven in-memory database geared towards game programming.</p> </span> In 2005 Stefan Li1</a></sup> and I did a game for Värnpliktsrådet2</a></sup>. Värnpliksrådet is a council for and by conscripts from the different branches of the Swedish Armed Forces. This year is the 20th anniversary of the game. Unrelated to that, I have a plan to use an Entity Component System3</a></sup> for our new rendering engine at work. Let's see if I can transform a 20-year-old Java Applet into a Rust WebAssembly game with a Bevy4</a></sup> ECS core.</p> /</span> Created on 2005-sep-07 /</span></span> </span></code></pre> Blog bless whoever came up with automatic headers with dates in new files.</p> Gameplay</h1>

Being STOMP Agnostic

2026-03-13T00:00:00+00:00

I needed a STOMP library, and my search for one written in Rust ended up with a fork and a library that I'm happy with!

In this blog post I will try to do the following things

Introduce you to STOMP</li>
Go through the current landscape of Rust STOMP libraries and explain why none of them scratch my itch</li>
Find a suitable library to fork, so that we may stand on the shoulders of others</li>

Propose a runtime and transport agnostic design for a STOMP library and implement it as stomp-agnostic</a></li> </ul>

What is STOMP</h1>

STOMP stands for Simple Text Oriented Messaging Protocol. If you have a need for sending and receiving text messages in real time using a client-server model, and you don't have fancy needs, this is the protocol for you. STOMP has been around for a long time; the latest version, STOMP 1.2</a>, was published in 2012.

The protocol itself is simple and easy-to-understand, and is usually used together with the WebSocket communication protocol in browsers, but can be used over TCP or any other protocol as the transport layer. STOMP is supported by a lot of software: RabbitMQ, Spring Framework, and is also commonly used to support real-time updates in web applications.

Transport layer is used a bit lax in the previous section; in the OSI model, TCP is at the Transport layer (layer 4), while HTTP and WebSocket are at the Application layer (layer 7), the same as STOMP. However, when we are in a browser we don't have direct access to TCP/layer 4, so we transport the STOMP data using a WebSocket connection.

Communicating using STOMP is done using Frames. A frame is a verb plus some data; similar to HTTP verbs, but with a broader vocabulary. There are two connection frames: CONNECT</code> and CONNECTED</code>, nine standard client frames: SEND</code>, SUBSCRIBE</code>, UNSUBSCRIBE</code>, ACK</code>, NACK</code>, BEGIN</code>, COMMIT</code>, ABORT</code> and DISCONNECT</code>, and three standard server frames: MESSAGE</code>, RECEIPT</code>, and ERROR</code>.

Three Rings for the Elven-kings under the sky, Seven for the Dwarf-lords in their halls of stone, Nine for Mortal Men doomed to die(sorry)</div> </div> Using the client and server frames, it's possible to build a robust communication channel between a client and a server. A simple conversation would go something like this: Client Server │ CONNECT (accept-version=1.1,1.2, host:stomp.zkc.se, ...) │ ├───────────────────────────────────────────────────────────────►│ │ CONNECTED (version=1.2, session=xyz, ... ) │ │◄───────────────────────────────────────────────────────────────┤ | | | ... | | | | | │ SUBSCRIBE (id=sub-0, destination=/dest, ...) │ ├───────────────────────────────────────────────────────────────►│ | | | ... | | | | | │ MESSAGE (subscription=sub-0, message-id=0, destination=/dest, │ │ data=JSON {...}) │ │◄───────────────────────────────────────────────────────────────┤ │ MESSAGE (subscription=sub-0, message-id=1, destination=/dest, │ │ data=JSON {...}) │ │◄───────────────────────────────────────────────────────────────┤ | | | ... | │ │ </code></pre> Since the protocol is so simple and each frame type typically only requires a few pieces of data (e.g. SUBSCRIBE only needs an id and a destination) it's very easy to wrap your head around the whole thing in a very short time. Just click the link above and start reading. It's not harder than that, really. The search for a Rust STOMP crate that fits the bill</h1> What I need: A library, written in Rust, that I can use to implement several clients using WebSocket as the transport layer, but with wildly different platforms: Desktop & Mobile applications have access to real operating systems and have good support for Tokio, but I also need support for Web/WASM that has a hard time running Tokio. Web browsers have their own APIs for opening WebSockets. I also need to implement at least one server that uses WebSocket as the transport layer. A quick survey of the STOMP landscape in Rust shows that there are plenty of STOMP libraries, around 20 on lib.rs</a> at the time of writing. I had a quick look at many of them, but they all have something that make them not a great fit for what I need. crate</th> notes</th> Runtime</th> transport</th></tr></thead> async-stomp</td> Has its own client and server types.</td> Tokio</td> TCP</td></tr> stomp</td> Callback API (not async)</td> -</td> TCP</td></tr> wstomp</td> Somehow uses both actix and Tokio...</td> awc / actix</td> WebSocket</td></tr> stomp-parser</td> "Just a parser"</td> -</td> -</td></tr> iridium-stomp</td> Has its own client type</td> Tokio</td> TCP</td></tr> </tbody></table> </div> There is a trend here: Almost every library except for wstomp</code> and stomp-parser</code> use TCP transport, and I need to use WebSocket as the transport layer. The crate for WebSocket communication I want to use is tokio-tungstenite</a> but no existing STOMP library I found offers that. Furthermore, every library except for stomp-parser</code> and stomp</code> are tied to a specific async runtime. At Spiideo we are building more and more cross-platform functionality in Rust that is supposed to work across iOS, Web, Desktop, Backend, and Android. Using Tokio or other async runtimes in the browser is not worth it in my experience; wasm-bindgen-futures</code> is enough if you design your software to be async without using runtime specific functionality. Of the existing choices, none fit the bill. It would be great to have a STOMP library that is pluggable. Since STOMP is such a simple protocol (it really is very simple), it should be possible to build a library that is more than a parser, but also doesn't go all the way to mandate a specific transport protocol. Finding a fork</h1> Out of the available choices, async-stomp</code> seems the best fit for what I want to do. async-stomp</code> was relicensed to use the EUPL</a> license in addition to the original MIT license. I'm very much not a license expert, but the EUPL seems like a reasonable license. I am actually a fan of the EU's work in this field, especially the DMA Enforcement Team</a>, so I'm not even going to try to do anything about the license. Comically, async-stomp</code> is a fork of tokio-stomp-2</code>, which is a fork of tokio-stomp</code>. I don't think it is out of character to fork it once more. If you don't know what you are doing, use the original tokio-stomp Caveat Emptor: tokio-stomp-2</div> </div> Fun quote I found in the tokio-stomp-2</code> repository while researching 👆. At what point am I expected to know what I am doing? How do we fork?</h1> There are some juicy parts that we are going to need and some parts that we are going to rip right out of async-stomp</code>. The main things to keep are the Frame</code> and Message</code> types, both of which represent a STOMP frame: A Message</code> is the high-level variety and Frame</code> contains the bytes received or to-be-sent. The throwing away part is easy: anything that has to do with TCP transport or Tokio. The Message</code> type comes in two flavors: Message<FromServer></code> and Message<ToServer></code>. The nomenclature is client centric, but I don't think renaming Message<FromServer></code> to Message<ToClient></code> would help. Either way you are doing some sort of purpose inversion in your head when implementing either the client or server parts. Adding type aliases might help, but I don't think it would help much. Designing an agnostic interface</h1> The two axes I want to design along are freedom to choose whatever transport you want and the madness to use whatever async runtime you want. We are going to need two simple-to-implement traits for the transport layer, one for the client transport and one for the server transport. On top of that we are going to have handles for the client and server parts of STOMP. The ClientTransport</code> and ServerTransport</code> traits are similar from a design point-of-view so there is no use exploring the design of more than one; for convenience we will look at the client side of things. The implementation can be found at github.com/bes/stomp-agnostic</a>. ClientTransport</h2> An important detail for the transport layer is going to be an escape hatch for dealing with protocol-specific communication. For example, a WebSocket connection has Ping and Pong messages, which are not part of STOMP but need to be handled if they come down the wire. Here's the trait for ClientTransport</code>. #[async_trait] pub trait ClientTransport: Send + Sync { /// A side channel to shuffle arbitrary data that is not part of the STOMP communication, /// e.g. WebSocket Ping/Pong. type ProtocolSideChannel; async fn write(&mut self, message: Message<ToServer>) -> Result<(), WriteError>; async fn read(&mut self) -> Result<ReadData<Self::ProtocolSideChannel>, ReadError>; } </code></pre> Reading is a matter of getting bytes from some source and then buffering until we have a full Message<FromServer></code>. Writing similarly is a matter of converting the given Message<ToServer></code> to bytes using the .into_bytes</code> method and sending them down the wire. Taking a Message<ToServer></code> instead of just raw bytes for .write</code> makes it impossible (or at least very hard) to misuse the transport trait. ReadData</code> is a simple enum; either bytes (STOMP data) or some special type T</code> (Self::ProtocolSideChannel</code> in our case) that belongs to the transport protocol. /// Data coming down the line from the transport layer. When the transport layer is /// e.g. WebSocket, custom data such as Ping/Pong can be handled separately from STOMP data /// by using the `Custom` variant. #[derive(Debug)] pub enum ReadData<T> { Binary(Bytes), Custom(T), } </code></pre> The ProtocolSideChannel</code> can be as simple as ()</code> but for WebSocket it will need to be an enum for the special cases. enum WebsocketProto { Ping(Bytes), Pong(Bytes), } </code></pre> Notice that to keep the trait simplish, I decided not to be able to send ProtocolSideChannel</code> data through the ClientTransport</code> trait, only to receive it through read. This doesn't stop us from sending a WebSocket Ping though, since the design of the handle allows us to temporarily (or permanently) drop down to transport level and get a hold of the original type. The magic, if you will, is in transport::client::BufferedTransport</code> pub(crate) struct BufferedTransport<T> where T: ClientTransport, T::ProtocolSideChannel: Debug, { transport: T, buffer: BytesMut, } </code></pre> BufferedTransport</code> holds on to an implementation of ClientTransport</code>. As we receive data from the transport, it's buffered in a BytesMut</code> until we can read a whole Frame</code>. When we are not waiting on a .read</code> or .write</code> we can get a hold of the underlying transport through BufferedTransport</code> pub(crate) fn into_transport(self) -> T { self.transport } pub(crate) fn as_mut_inner(&mut self) -> &mut T { &mut self.transport } </code></pre> Unfortunately BufferedTransport</code> is crate-private, but the methods are proxied through ClientStompHandle</code>. ClientStompHandle</h2> The handle type is really just a very thin wrapper around the BufferedTransport</code>, but you can only get a ClientStompHandle</code> using the ClientStompHandle::connect</code> associated function, which makes sure to do a successful STOMP client handshake. Once you have a ClientStompHandle</code> it's time to rock'n'roll impl<T> ClientStompHandle<T> where T: ClientTransport, T::ProtocolSideChannel: Debug, { /// Send a STOMP message through the underlying transport pub async fn send_message(&mut self, message: Message<ToServer>) -> Result<(), WriteError> { self.transport.send(message).await } /// Read a STOMP message from the underlying transport pub async fn read_response( &mut self, ) -> Result<ServerResponse<T::ProtocolSideChannel>, ReadError> { self.transport.next().await } </code></pre> Implementing a WebSocket client transport</h1> There are simple and functional, but not fully fleshed out, examples in the stomp-agnostic repository</a>. The client example code uses tokio-tungstenite</code> to create a WebSocket client and the server example uses axum</code> to expose an endpoint that can be turned into a WebSocket connection. Since there are only three server frames to consider, plus the underlying WebSocket protocol, it doesn't take much to implement the full ClientTransport</code> #[async_trait] impl ClientTransport for WsTransport { type ProtocolSideChannel = WebsocketProto; async fn write( &mut self, message: stomp_agnostic::Message<ToServer>, ) -> Result<(), WriteError> { let bytes = message.into_bytes(); // Check that bytes is valid UTF-8! // NOTE: This is part of the safety, do not remove! let _ = str::from_utf8(&bytes)?; let ws_message = Message::Text( // Safety: We checked that bytes are valid UTF-8 above unsafe { Utf8Bytes::from_bytes_unchecked(bytes) }, ); self.ws_stream .send(ws_message) .await .map_err(|e| WriteError::Other(anyhow!(e))) } async fn read(&mut self) -> Result<ReadData<Self::ProtocolSideChannel>, ReadError> { loop { let message = self .ws_stream .next() .await .transpose() .map_err(|e| ReadError::Other(anyhow!(e)))?; if let Some(message) = message { match message { Message::Text(utf8_bytes) => { return Ok(ReadData::Binary(Bytes::copy_from_slice( utf8_bytes.as_bytes(), ))); } Message::Binary(bytes) => { return Ok(ReadData::Binary(bytes)); } Message::Ping(data) => { return Ok(ReadData::Custom(WebsocketProto::Ping(data))); } Message::Pong(data) => { return Ok(ReadData::Custom(WebsocketProto::Pong(data))); } Message::Close(_) => { return Err(ReadError::ConnectionClosed); } Message::Frame(_) => { return Err(ReadError::UnexpectedMessage); } } } } } } </code></pre> Fifty-seven lines, including a lot of curly braces. A note on cancel safety</h2> Rust cancel safety can be tricky, so be sure to understand the details before implementing ClientTransport</code> or ServerTransport</code>. RFD-400 Dealing with cancel safety in async Rust</a> is fantastic and is a very good resource on the subject. In short, If a function isn't cancel safe there is a risk of leaving the system (your program, your customer's program) in a broken state, a state where some property of the system has been violated. Let's take a quick look at ClientTransport</code> as an example again: async fn write(&mut self, message: Message<ToServer>) -> Result<(), WriteError>; async fn read(&mut self) -> Result<ReadData<Self::ProtocolSideChannel>, ReadError>; </code></pre> The implementor's responsibility is to make sure that .write</code> and .read</code> are cancel safe. It's a matter of being careful: You are probably going to use some other library (I used tokio-tungstenite</code> and axum</code> in the example code in the repo) to implement the functions. It's your responsibility to figure out their cancel safety properties. Sending and receiving messages</h1> The best part of stomp-agnostic</code> is how easy it is to use once the transport has been implemented. I'm hand-waving a bit here, but it doesn't need to be more complicated than this to handle sending and receiving messages as a STOMP-over-WebSocket client let mut stomp = ClientStompHandle::connect( /* ... */).await? loop { select! { _ = cancellation.cancelled() => { break; }, message_to_send = internal_message_channel.recv() => { match message_to_send { Some(message) => stomp.send_message(message).await?, None => break, } } response_result = stomp.read_response() => { let response = response_result?; match response { Response::Message(message) => { match message.content { FromServer::Message { body, .. } => { // ... </code></pre> What now?</h1> Having this library enabled me to replace our very old iOS STOMP client library by writing a few glue functions using UniFFI. All the lovely Rust async cancellation, and a simple library that I am familiar with that can be reused for many other cases. I'm currently also working on a desktop application for Spiideo that has a STOMP-over-WebSocket server, obviously powered by stomp-agnostic</code>. The magic of loop</code>, select!</code>, CancellationToken</code>, and channels makes it easy to build robust software that is easy to understand. Certainly a far cry from callback based concurrent programming. Rust manages to beat any other programming language I've tried, including async Swift and async TypeScript. I'm hoping that stomp-agnostic</code> will not only be a tool for me to keep building a variety of Rust STOMP clients and servers, but also for others that have needs that stray from the available STOMP Rust libraries. FOSDEM 2026 2026-01-31T00:00:00+00:00 I had the opportunity to go to FOSDEM 2026! Chaos on the rails</h1> 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</h1> 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. Smoke </div> </a> Not a fire, that's just smoke from a lot of fries. </div> Day 1 - Saturday</h1> 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</h2> (Security) – event page</a> – 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</a>. 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</code> command in action: ROSA explains "why this is a backdoor". We then run the application through strace</code> and after a little bit of scrolling we see a very strange system call that should not be there; an execv</code>. 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</h2> (Legacy & Policy) – event page</a> – 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 </div> </a> 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. </div> 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</h2> (Main track) – event page</a> – HP van Braam "I am HP van Braam from the Godot Foundation, and I like old computers" Braam</div> </div> 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". </a> 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/</a>. raylib: a 12-year adventure as a solo-maintainer</h2> (Main track) – event page</a> – Ramon (Ray) Santamaria </a> 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</a>. 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</h1> WebAssembly on Constrained Devices</h2> (Rust) – event page</a> – 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</h2> (Rust) – event page</a> – 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" Federico</div> </div> 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</a> 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</code> which emits assembly code for the Sharp LR35902 processor, gb_std</code> which is a "standard library" for building Game Boy games, and finally rust_boy</code> 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("MainLoop") .ld_bc(160) .call("WaitVBlank") .jp("MainLoop"); // VBlank function asm.chunk(Chunk::Functions) .label("WaitVBlank") .comment("Wait for vertical blank") .ld_a_label("[$FF44]") .cp_imm(144) .jr_cond(Condition::NZ, "WaitVBlank") .ret(); // Generate assembly println!("{}", asm.to_asm()); </code></pre> 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</code>. GStreamer 1.28 and beyond</h2> (Audio Video & Graphics Creation) – event page</a> – 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</h2> (Rust) – event page</a> – 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</h1> Now go watch this talk</a> where Bryan Cantrill references Swedish physician Torsten Thunberg's "Thermal Grill Illusion"</a> ( 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". How two generations of internal indoor map apps created a new line of business at Sony 2025-07-18T00:00:00+00:00 In 2009, I was assigned to one of the Android teams at Sony Ericsson. To get up to speed I experimented with the different Android APIs. At this time I had been working at Sony Ericsson for 3 years already, and the massive footprint of the company in Lund required office landscapes the size of small towns. But also meeting rooms. Lots of meeting rooms. This is the story of how SEMCMap (SEMC being short for Sony Ericsson Mobile Communications) was created, how SonyMap spawned from a completely different project, how they were merged, how we managed to be the first project to be accepted by the brand-new Research and Incubation initiative at Sony Mobile, how it was the first project to "exit" Research and Incubation a few months before I left Sony Mobile for Spiideo, and finally how it became a completely new line of business1</a> for Sony Europe. </div> I need to give Magnus Persson a big Thank You for helping me remember details that would have otherwise been lost to time. You were invaluable. Thank You! </div> Smartphone and application maturity in 2009</h1> In 2009, there were very few smartphones: The iPhone 3Gs had just been released, and Sony Ericsson was about to release the Xperia X102</a>. There weren't many apps, and there definitely weren't any popular indoor-navigation apps. Smartphone screens were tiny compared to the screens we have today, and the phones weren't exactly snappy, even if it maybe felt like they were then and there. The Xperia X102</a> had a 4-inch screen and the iPhone 3Gs had a 3.5-inch screen. Today it's hard to find a smartphone with a screen that's smaller than 6 inches. Apps weren't very pretty, especially on Android, which honestly had a lot of catching up to do at the time. SEMCMap</h1> The first indoor map application I worked on was SEMCMap. I created it while I was looking into the Android APIs. My first attempts were terrible: performance-wise, design-wise, you name it. No compass, no auto-rotate, and no indoor positioning. It was rough being a user of SEMCMap, but it quickly gained in popularity, since it filled a niche that people needed help with — finding their way to the meeting room they were supposed to be in. If you've ever worked at a large company, or in a building with a lot of meeting rooms, you probably have some sense of how disorienting it can be when every floor looks the same and there are hundreds of meeting rooms. The main use-case was basically just typing a meeting room name into the search box, selecting the meeting room and then trying to decipher where you were going based on where you thought you were and where the map told you the meeting room was. A lot of people were using SEMCMap at the time </div> </a> </div> SEMCMap had one redeeming feature though — the ability to send your position to someone else through the app. You could use your Google account to quickly sign in, and then use those credentials to send a message to another signed-in user along with the location. The feature was popular and well-used. So far so good. I maintained the application myself for a few years, and a lot of people seemed to like it! Mostly I did other work: phone book, social media integrations, and so on. I worked through a lot of tasks and a lot of teams. SEMCMap and Indoor Finder coexist for a while</h1> Magnus Persson3</a> and I know each other from my early days at Sony Ericsson. He was working in some of the same teams that I did. A cool cat, and full of energy and great ideas. I think I met him the first time in 2006, I was 24 at the time feels like yesterday but almost 20 years have passed. Life comes at you fast. While I had been working on SEMCMap on-and-off for a couple of years, Magnus was working in the Technology department. The Technology department was tasked with keeping track of new technologies and making sure those ended up in Sony Mobile's devices. Around 2011, Magnus ran a project called Indoor Finder together with Ericsson Research, with Sony Mobile mainly contributing to the map interface and the positioning functionality. At the time, he wrote a blog post, which can still be found using The Internet Archive's wayback machine! I did a little archiving myself — have a look at the PDF</a>. Left is SEMCMap, right is Indoor Finder </div> </a> </div> At the end of 2011 Sony Ericsson was being transformed into Sony Mobile, after Sony bought out Ericsson to gain full ownership and control of the company. SonyMap</h1> Ericsson Research lost interest in the joint research project Indoor Finder at some point, and Sony Mobile fully took over the project. Magnus and I both had a lot of ideas and Magnus talked me into joining him to work full-time on SonyMap. Roger Jansson4</a>, was my manager's manager at the time, and he was happy to give the permission to go ahead, and we went ahead... full steam. We both agreed that Indoor Finder was a better starting point than SEMCMap, but a lot of the code and ideas from the internals of SEMCMap made it over to the new SonyMap application. We brought on more people, and we were usually at least two, but usually three, or even four people working on it at this time. One of the good people got help from was Oskar Syrén5</a> who implemented an improved fused indoor positioning engine that used a combination of GPS, Bluetooth Low Energy beacons, and Dead Reckoning. Bluetooth Low-Energy Beacon </div> </a> </div> Magnus dutifully ordered parts and assembled Franken-BTLE beacons and placed them in every single meeting room — and there were a lot! Every BTLE beacon was attached to a standard Sony Mobile USB charger. You would think people would just leave them alone, but you'd be wrong. Research and Incubation</h1> Around 2014 things were not going great for Sony Mobile. Actually, things had not been going great for a while. Samsung and Apple are currently the biggest smartphone manufacturers, and that was true in 2014 too. There was more competition for sure: LG, Motorola, even Nokia, but they were all small too. Patrik Olsson6</a> kicked off the Research and Incubation (R&I) department. Anyone that had an idea could apply, and SonyMap was the first project to get accepted. Magnus and I were very happy about that, since it showed that we had worked on something that was useful to people. Getting accepted to R&I was great for us, but it also serves as an example of what happens when a project gets the spotlight on it in an organization starved for success. All of a sudden I wasn't spending my days planning concrete things to do with our application, or building cool features, I was in meetings with people wanting a piece of the cake. On the other hand, we now got to staff our development team with amazing engineers and designers. It was a fun time, and the team built a lot of interesting stuff, most of which was actually usable and shippable. One of the engineers that joined at this time was Mattias Niklewski, who I consider to be a good friend, and one of the finest engineers I have worked with. We weren't just the first project to get accepted to the R&I process. The goal for an R&I project was to "graduate" a real product, and we did that too, as the first graduate project from R&I no less. Nimway</h1> But, I had done my time at Sony Mobile. I was ready for a new adventure. So after a little courting I accepted an offer to join Spiideo. Magnus tried to get me to stay on, but my mind was set on moving on. Magnus stayed for another 8 years. Mattias, and Oskar are still there, and the team did a great job acquiring clients under the Nimway1</a> moniker. A few years after I left, the project moved on from Sony Mobile and joined Sony Europe, and is still going strong from what I can gather! It's satisfying to see how something with small beginnings was able to evolve and amalgamate, finally becoming a whole new business segment for a huge company like Sony. I'm proud to be one of the parents of SonyMap, now part of Nimway, and I'm glad to see that what started as our side project continues to employ people. References</h1> ^1https://www.sonynetworkcom.com/nimway</a> </div> ^2https://en.wikipedia.org/wiki/Sony_Ericsson_Xperia_X10</a> </div> ^3https://www.linkedin.com/in/magnuspersson78/</a> </div> ^4https://www.linkedin.com/in/brjansson/</a> </div> ^5https://www.linkedin.com/in/oskar-syr%C3%A9n-79023857/</a> </div> ^6https://www.linkedin.com/in/polsson/</a> </div> I remade a 20-year-old game to learn Bevy ECS 2025-01-02T00:00:00+00:00 I got the fantastic idea to learn Bevy ECS</a> by recreating a game I developed with a friend a long time ago. The main goal is to remake the game, written in Java in the standard pointer soup programming style, using an Entity Component System—a kind of type system driven in-memory database geared towards game programming. In 2005 Stefan Li1</a> and I did a game for Värnpliktsrådet2</a>. Värnpliksrådet is a council for and by conscripts from the different branches of the Swedish Armed Forces. This year is the 20th anniversary of the game. Unrelated to that, I have a plan to use an Entity Component System3</a> for our new rendering engine at work. Let's see if I can transform a 20-year-old Java Applet into a Rust WebAssembly game with a Bevy4</a> ECS core. /* Created on 2005-sep-07 */ </code></pre> Blog bless whoever came up with automatic headers with dates in new files. Gameplay</h1>

Domain Specific Language

Being STOMP Agnostic

FOSDEM 2026

ULB Campus</h1> 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.</p>

How two generations of internal indoor map apps created a new line of business at Sony

I remade a 20-year-old game to learn Bevy ECS