Table of Contents

OpenBSD Hackathon Canada 2026
#

EuroBSDCon 2026
#

This year’s EuroBSDCon took place in Brussels, Belgium, from 9 to 13 September 2026. Going to EuroBSDCon was a lucky decision, and at first it had nothing to do with the OpenBSD hackathon. I think it was sometime in winter 2025/2026. I was walking around the Wöhrder See in Nuremberg with Alvar, as we often do, talking about open source, the tech bubble and OpenBSD philosophy. Somehow we started talking about EuroBSDCon and found out that neither of us had ever been there, but we both always wanted to go and see what it is like. So we agreed to make the trip to Brussels together.

During 2026 it became clear that there would be a hackathon in September, planned so that EuroBSDCon attendees could join too. Brussels has an international airport, so it was easy to find a flight to Edmonton on the Monday after the conference. By the beginning of the year, the plan was complete.

Now, about EuroBSDCon. It is still hard for me to reflect on it, because my impressions cover a range as wide as the spectrum of light.

The first thing I noticed was how many people already knew each other compared to how many were new. I can’t judge this objectively. But the opening was a good hint: “Welcome family” – henning@. I would say 90% of the attendees are repeat offenders, and as Henning said, the event sees itself as a family reunion.

On one hand, this is really nice. On the other hand, it shows that BSD is a mature community that has probably seen its peak. I joined long after that peak, and I’m very happy to be part of it, so I hope I’m allowed to ask: is BSD is Dying, the title of Jason Dixon’s talk at NYCBSDCon 2007, true? If you only look at growth numbers and compare them with other technologies in IT, then yes. But growth was never the point of BSD (Or maybe it was a different time after all). We don’t scale to infinity, we just keep going. And in the end, everything that has lived will die anyway. So instead of “dying”, I would give BSD this label: “resilient”.

Open communication is the key to every conference, and I have to say I have never been to a better conference than EuroBSDCon. Almost everywhere I looked, I saw people sitting together at round tables and talking. I only had open and respectful conversations with lots of people. In the end, this even led to httpd: add header block/drop rules for request filtering, and at least two more ideas are in the pipeline.

The talks had a bit of everything: from “wow, I didn’t know that” to interesting views and ideas to “WTF was that?” (which is fine, too). In general I would have liked OpenBSD talks in every slot, but this way I also looked beyond the OpenBSD world. FreeBSD can keep their ZFS, good for them. Sadly, I didn’t notice anything from NetBSD. Nothing at all. It’s a bit of a shame, but it was down to how I’d organised my time. I would have liked to have seen something interesting that people could get involved in on Open. In the end, we are all very different.

I didn’t really want to go to the talk GEFS: The File Shredder of the Future. In the end, a few people did manage to convince me. (hype) The talk left me with mixed feelings. I find Ori Bernstein’s work very exciting, and the part about B-epsilon trees, plus the reference to an old talk about them, was super interesting. But the demo was on Plan 9, and I was missing the OpenBSD part. A file system lives in the kernel, so if the goal is to bring it to OpenBSD, I think it needs close contact with OpenBSD developers early on. I didn’t see that. In my opinion, when you start a project like this, you should work closely with the upstream community and try to build a community around your idea. Otherwise it is in danger of staying an academic project.

My personal highlight was bluhm@’s talk From Report to Patch, the OpenBSD Errata Process. Not only because I learned something, but also because of the mix of fun and information.

I can also recommend henning@’s talk OpenNTPD - 20 years and a few milliseconds later to everyone.

And last but not least, Kristaps Dzonsons’ talk Unix Manpages, Then and Now. It was keynote speaker level.

A big thank you also goes to the nice lady I briefly talked to because she had such a cool device. It turned out to be a Pomera DM250. A really nice device for taking notes, I think. Thanks for the nice chat!

To sum up: this was not my last EuroBSDCon. Next time I should be brave enough to submit a talk, and I should definitely sign up for the social event. And I hope that a different location will have a hackroom ;)

w2k26: hackathon
#

After EuroBSDCon, well rested, I flew from Brussels via Toronto to Edmonton for the w2k26 hackathon. The flight to Toronto took almost 9 hours, which is tough. But for about 300 euros I could upgrade from economy to premium economy. That gave me enough space (I’m not the smallest person) to open my laptop. I looked at the diffs from Purple Rain and decided to re-implement them in a generic way. I had recently implemented the header syntax, so I knew exactly which path to follow.

So when I landed, the very first version was basically done. I finished the rest of the trip in jet-lag zombie mode.

On Tuesday in the hackroom in Edmonton I was well rested and started working on things I had not really planned.

I started by testing the httpd header block/drop diff, and after half a day I was quite happy with the result. During the hackathon I also had an LLM generate a shell script that tests all combinations of the new block/drop syntax. After fixing two edge cases, that was clean too.

I had already finished all KDE ports before the hackathon, and they were fully up to date, so there was nothing to do there. I’m happy that we will once again ship OpenBSD 8.0 with a current KDE stack:

KDE Gear 26.08.1
KDE Frameworks 6.30.0
KDE Plasma 6.7.5, bugfix release for September

In the first days I updated a few ports here and there, but nothing worth mentioning. Just the usual noise in the ports tree. (We already passed 10,000 commits in the ports tree during the hackathon.)

I was lucky to sit next to bluhm@, so I used the chance to extend and fix the relayd regression tests. That way I could ask stupid questions at any time, because for me Perl looks like assembly code.

I also kept working on the relayd pattern matching syntax. You can find the idea here: https://rsadowski.de/posts/2026/update-relayd-and-httpd/#whats-next-in-pattern-patching-syntax-world The implementation is mostly done, except for some bugs. That is also why I needed the tests: I want to avoid breaking changes.

I also had an interesting discussion about relayd with robert@. The idea is to have backups for redirects. Example:

table <galera> { 127.0.0.1, 127.0.0.2, 127.0.0.3 }

table <g1> { 127.0.0.1 }
table <g2> { 127.0.0.2 }
table <g3> { 127.0.0.3 }

interval 2

redirect mariadb {
	listen on 127.0.0.4 port 3306
	match pftag RELAYD
	forward to <galera> port 3306 check tcp mode least-states
}

redirect mariadb-write {
	listen on 127.0.0.5 port 3306
	match pftag RELAYD
	forward to <g1> port 3306 check tcp
	forward to <g2> port 3306 check tcp
	forward to <g3> port 3306 check tcp
}

This is the part I mean. If g1 is down, g2 should take over as a fallback, and so on.

	forward to <g1> port 3306 check tcp
	forward to <g2> port 3306 check tcp
	forward to <g3> port 3306 check tcp

I’m thinking about a syntax like this:

	forward to prio 1 <galera> port 3306 check tcp mode failover

But before we decide on a syntax, we should look at the semantics, because the real problems are in the failback. When g1 comes back, relayd today switches back right away, while the existing pf states still point to g2. Suddenly two nodes are writing at the same time, which is exactly what mariadb-write is supposed to prevent. An option like no preempt or a hold-down time is where new syntax would really help. Also, check tcp is not enough for Galera: a node in joiner or donor state accepts TCP connections but is not ready for writes. A check script that looks at wsrep_ready would be a better choice. And with interval 2 and no retry, even a short hiccup can trigger a failover followed by an immediate failback. Finally, we should make sure that multiple forward to lines mean the same thing in redirect and in relay, so that relayd stays consistent.

Fresh ideas and suggestions are always welcome. I think relayd can and should do so many things better. Times and use cases have changed, relayd has not.

Besides the topics above, I searched my OpenBSD machine for things I had started but never finished, and I found x11/sddm: a login manager written in Qt/QML. KDE Plasma no longer uses it as its default login manager, because KDE now has its own fork, KDE/plasma-login-manager. Its README.md says: “Deeper Plasma integration including”. In other words: deeper vendor lock-in. And by vendor lock-in I mean nothing less than Linux/systemd. I tried to port it, but unlike in SDDM, systemd is no longer optional there. It is a hard dependency.

We all know where this is going: KDE is dying (on !systemd).

The good news at the end: I managed to get SDDM working, and I’m using it a lot right now. One positive thing for KDE Plasma on OpenBSD: KDE Plasma starts much faster with SDDM.

I think this is because SDDM starts all the PAM stuff properly, while otherwise the KDE Plasma startup waits a few seconds for it before it gives up.

You can find the new port "x11/sddm" on ports@. Feedback welcome. happy #OpenBSD #Desktop pic.twitter.com/5yEL5igxGB
— Rafael Sadowski (@sizeofvoid) September 20, 2026

Since the hackathon was held in Canada, the home of OpenBSD, I had the opportunity to meet new OpenBSD developers whom I hadn’t had the chance to meet before. It was a pleasure, and w2k26 definitely ranks among the top 3 hackathons!

The future of KDE Plasma Desktop on OpenBSD
#

Several people asked me about this at the hackathon and at EuroBSDCon. KDE announced that Plasma 6.8 will be Wayland-only and will no longer ship the X11 session. Looking at the commits, this has happened. X11 is dying. What does this mean for OpenBSD?

The short answer: we will stay on version 6.7 as long as we can. In the medium term, this means we will keep updating KDE Frameworks until breaking changes come in and we can no longer build KDE Plasma. That in turn means KDE Gear updates will stop too. These three stacks usually go hand in hand, and at some point the gap becomes too big to keep following upstream.

The solution I see is to make KDE Plasma on OpenBSD ready for Wayland. The first building block is in place: with SDDM we have a login manager that can, in theory, do Wayland and can therefore start KDE on Wayland.

At w2k26 I at least managed to get KWin running on Wayland without crashing. There were still problems with libinput handling, but I’m sure I can fix them.

But don’t celebrate too early. Even when we reach this milestone and have a working KDE Plasma on Wayland, we still won’t have hardware acceleration through libGL, because our libGL from Xenocara currently comes without Wayland support. And software rendering in KDE Plasma? You can do it, but it sucks.

The list of challenges is surely longer. These are just the ones I can see right now.

For now, it stays a balancing act for me between src/usr.sbin/{relayd,httpd} and ports/x11/kde-plasma. If only I had more free time.

Rocky Mountains
#

After the hackathon, my wife and I spent a week hiking in the Rocky Mountains: 2 days in Jasper and 3 days in Banff. What a beautiful place on earth (if you get hiking tips from locals and can avoid the mass tourism, thanks deraadt@). But why am I telling you this? A picture is worth a thousand words: