FOSDEM 2026: The Devroom Talks I Saw

FOSDEM 2026 ran on Saturday 31 January and Sunday 1 February at the ULB campus in Brussels. My FOSDEM 2026 overview covers the stands and the hallway track, and my interview with Monty Widenius covers MariaDB. This post is the companion piece: the talks I sat in on, rebuilt from the slides I photographed. I’ve only written up talks where my photos show a title or enough slides to say what was presented, and I’ve left out any detail I couldn’t read.

”State of the Arch: Fedora on RISC-V” (room H.2214)

On Saturday around midday I was in room H.2214, its number chalked on the board, for “State of the Arch: Fedora on RISC-V”. The title slide was dated 31 Jan 2026 and credited David Abdurachmanov and Kashyap Chamarthy. The room was full, and several people in the audience were filming the slides on their phones.

A full H.2214 for the state of Fedora on RISC-V.

• Prior art first. For boards from 2018 to 2024, the talk pointed to Emil Renner Berthing’s FOSDEM 2025 talk, “RISC-V hardware: where are we?”.
• Tenstorrent hardware. “Tenstorrent ‘Blackhole’ (2025)” was described as a RISC-V “AI accelerator” on a PCIe card (p100a and p150a) for LLM inference and training. Drew Fustini had posted patches to LKML, and it “can boot mainline kernel, with caveats”. “Upcoming: Tenstorrent ‘Atlantis’ (2026?)” showed the Ascalon CPU running on a Synopsys HAPS-100 FPGA: RVA23-compliant, with an ETA of about Q3 2026, an emulated board merged in QEMU 10.0.0 and Linux upstreaming started.
• Kernel builds today (F43). A diagram, credited to Jason Montleon, showed separate kernel trees for SpacemiT, ESWIN, “vf2”/“lpi4a”, RockOS and two DeepComputing boards (fml13v01 and fml13v03). Each tree was packaged as RPMs and fed into riscv-koji.
• RVA23 readiness. Fedora’s current baseline is RV64GC, and the project is waiting on a reference platform (“SpacemiT K3” or “Atlantis”?). RVA23 kernels “will (should)” support RV64GC userspace, and riscv_hwprobe() is the syscall that reliably detects RISC-V extensions. Another slide said most of the current hardware “is running under people’s desks”, and the plan is to rack datacenter-grade RVA23 systems “soon” with the Fedora Infra team.

Blackhole today, and the open RVA23 question.

My take: the kernel-builds diagram tells the real story. While every board needs its own kernel tree, a distro can’t treat the architecture as first class. RVA23 hardware in a proper datacenter, building packages under the same rules as everything else, is the step that would change that.

ClickHouse in the Databases devroom (room UB2.252A)

Later on Saturday afternoon I went to UB2.252A. The board had “DATABASES” and the FOSDEM code of conduct chalked on it, and the amphitheatre was close to full. I didn’t photograph a title slide, so I won’t guess the exact title. The slides carried the ClickHouse logo.

“Your (soon-to-be) favorite database!”

• What ClickHouse is. One slide summed it up in four columns: open source, column-oriented, distributed (replication, sharding, multi-master, cross-region) and an OLAP database (analytics use cases, aggregations, visualisations, mostly immutable data).
• Granules. “A granule represents the smallest indivisible data unit processed by the scan and index lookup operators in ClickHouse.” The rows of a part are divided into groups of 8192 records, called granules.
• Tokenizers. A slide took a single log line (timestamp, UUID and a <Debug> level) and showed how splitByNonAlpha, splitByString, ngrams(3) and array each break it into tokens.

My take: the tokenizer slide is the practical bit. If you push logs into ClickHouse, how you split them decides which searches an index can actually help with.

”Funding a FOSS Revolution in the Energy Sector” (room UD2.218)

The last stop on Saturday was room UD2.218, which had Sovereign Tech Agency and NLnet banners beside the stage. The title slide read “Funding a FOSS Revolution in the Energy Sector”, by Dr. Maximilian Parzen, 31 January 2026, with the Open Energy Transition (OET) logo. There were three people on stage.

Energy-sector open source, with the funders’ banners in the room.

• The imbalance. The “Impact” slide: “Grid planners pay $1B/a for proprietary software, $0.01B/a for FOSS software to decide $1000B/a infrastructure investments.”
• A tracker as evidence. The example was openmod-tracker.org, which lists “200+ OS tools for grid planning” and is described as an insight platform that guides decision-makers. The code is at github.com/open-energy-transition/openmod-tracker. The screenshot was titled “Open Energy Modelling Tools - Key Metrics”.
• Closing. The session ended on a “Thank You!” slide for Dr. Maximilian Parzen, Chief Executive Officer.

”An Enterprise Perspective on Open Source Funding” (SAP, room UD2.218)

The SAP talk was in the middle of the same session. The title slide read “An Enterprise Perspective on Open Source Funding”, by Fabian Palmer & Tobias Gabriel, SAP, 31st January 2026.

How does a company give money to an individual maintainer?

• The missing tool. Until then, sole maintainers and small projects “could only be supported through development contributions”, which “is not always the best way”.
• How to pay individuals. The slide asked “How do you give money to individuals as a company?” Its answers: an intermediary helps with the purchasing process, common ones are GitHub Sponsors and Open Collective (and GitHub Sponsors can route money to Open Collective), and recipients must not be related to the company or sanctioned. A fixed, meaningful amount is a good starting point, and a pilot budget lets you test the process end to end.
• Choosing projects. “Automated Selection: Data-Driven project selection”: metrics characterise projects, and funding decisions follow the current funding goal. The listed advantage was “no inherent bias towards well known projects”. The disadvantage was that it “is not a perfect science”, so manual filtering is still needed.

My take: the compliance line (no related parties, no sanctioned recipients) is what usually stalls this inside large companies. Putting it on a slide next to GitHub Sponsors and Open Collective makes it look solvable.

”How to: Buy Less, Create More” (FreeSewing)

On Sunday lunchtime I was in one of the large auditoriums for a FreeSewing talk. The title slide read “How to: Buy Less, Create More. And feel great about it”, and the slides carried a FreeSewing.eu footer. The speaker’s name wasn’t on any slide I photographed.

People were still coming in as the title slide went up.

• The origin story. “New Year’s resolution 2011: I will stop buying clothes and instead make everything myself” (with a footnote: “not everything”). A scan of The Tailor and Cutter from 1 February 1868, “158 years ago”, set the historical scene.
• Pre-FOSS. A timeline went from “started sewing” in December 2010, to registering makemypattern.com in February 2012, to launching it (“not FOSS”) in September 2012.
• Growth. A chart of user account registrations ran from January 2014 to August 2017, with “Early access becomes available”, “Early adopters” and “Launched FreeSewing.org (25 August 2017)” marked on it. A later version of the chart ran to January 2026 and ended in a spike labelled “Help!”. A yearly revenue chart (patrons and donations) covered 2015 to 2025.
• Under the hood. Settings sets go into draft() to build a pattern. A pattern has parts (points, paths, snippets) for each set, plus a pattern store and set stores. It is then rendered either with render() to SVG, or through getRenderProps() to React, Svelte, Vue or plain JS.

Settings in, pattern out, rendered to whatever front end you like.

My take: separating drafting from rendering is the same design choice that keeps infrastructure tools sane. Compute a model once, then hand it to whichever output layer needs it.

Linux power saving in room UA2.114

Mid-afternoon on Sunday I went to UA2.114 for a talk on cutting power use on Linux devices. The room was packed and a lot of people had laptops open. I didn’t photograph the title slide.

Measured savings, one subsystem at a time.

• CPU frequency governors. “Available CPUFREQ” listed ondemand, conservative, powersave, performance, userspace and schedutil, each with a one-line description.
• Connectivity. “Connectivity devices are very power consuming”. When you don’t need them, the advice was to disable them (via ifconfig, ip, nmcli). The slide claimed a 52% power saving from turning down Wi-Fi, Ethernet and the modem.
• USB. Dynamic power management “is disabled by default” and needs testing, because “some issues have been detected when reconnecting on some devices” (see Documentation/driver-api/usb/power-management.rst). Turning down a USB modem saved 56%.

”Upstreaming Before Silicon Available” (room UA2.114)

I stayed in UA2.114 for the next talk. Its slides used the Tokyo Linux Plumbers Conference template (Tokyo, Japan, Dec. 11–13, 2025) with a FOSDEM logo added. The main slide was headed “Upstreaming Before Silicon Available”. Earlier that day I’d seen a deck in the same template, titled “Solving Pre-silicon Kernel Upstream for RISC-V First Ever”, open on a laptop at one of the stands.

“How’s Progress, Any Surprises? Best ever progress!!!”

• Hard parts. Big and little, asymmetric cores: RVA23 vs non-RVA23 cores, RVV with different vector lengths, and an AI stack on an AI cluster. Also PCIe DMA zones (“not on 32bit DMA Zone”).
• Public matters. Moving from a private repository to a public one, to “avoid IP issues”.
• Breaking rules? An FPGA target was rejected as a “short-life target”. Testing was hard with “no hardware”, and the slide asked “Any reputation ruin? What happen bugs!”
• The SoC. The right-hand column, headed “RISC-V Profile”, called the power vs efficiency trade-off “problematic”, for example with the H extension. A diagram labelled “K3” showed performance cores and “efficient & AI” cores in separate clusters.

My take: upstreaming before silicon exists is the right instinct for RISC-V. When the board ships, a stock distro kernel boots on it, and the per-board kernel trees from Saturday’s Fedora talk become unnecessary.

Related

• FOSDEM 2026: Open Source, RISC-V & Community Energy
• FOSDEM 2026: Interview with MariaDB Creator Monty
• FOSDEM 2025 Brussels: The Devroom Talks I Saw
• Running Linux on RISC-V: Ubuntu, Fedora & Debian