This talk will be focused on the software engineering techniques that we are using or plan to use to bring the BIND 9 into 21 century to scale better, use less memory and overall have improved design to utilize the modern CPU architecture.

A few years ago, a musician friend of mine reached out, hoping to build a custom controller for a live act performance. Together, we decided on a USB-MIDI device, which soon became a hands-on learning journey into Zephyr, USB development, and the MIDI protocol.

MIDI (Musical Instrument Digital Interface) has been the leading standard for connecting digital instruments and controllers since the 1980s. Although USB includes MIDIStreaming (a subclass of the Audio device class), Zephyr had no support for it. So, I decided to build one.

In this talk, I’ll walk you through my adventures implementing (and eventually upstreaming) this new device class. We’ll start by revisiting the original MIDI 1 protocol from the eighties, the original USB-MIDI1.0 from the 2000s and the updated USB-MIDI2.0 specification from 2020. After a brief refresher on USB devices, I’ll introduce the USB MIDIStreaming interface and the various supported topologies. Finally, we’ll see how to bring it all together using Zephyr USB device_next, and how it is used from your application's code. In the end, we should be able to make any kind of MIDI speaking device using our favorite kite-stamped RTOS.

Alongside this technical content, I may relate my experience as an occasional hobbyist contributor since Zephyr 1.14, and how I navigated spec updates (Device tree changes, USB-MIDI 1.0 to 2.0, Zephyr USB device next).

This talk looks at the state of upstream U-Boot, Linux kernel, FreedesktopSDK, and Yocto Project for the powerful SpacemiT K1-based Banana Pi BPI-F3. Nothing has been merged yet, but I took the various pieces posted on mailing lists or available as merge requests and gave them a spin. As a reference for comparison, I also looked at the vendor downstream stuff available from Banana Pi Team/SpacemiT.

How much do you know about Free Software, Open Source, Developers, and European meetings?

We interrupt your regularly scheduled programming to bring you a lively TV-style quiz show featuring several rounds of questions deemed too geeky for TV - about kernels, software projects, and digital culture. (Some will offer mass audience participation!)

As a fun game it will separate the Red Hat's from the Red Star's, the Linus Torvalds from "some random person in Nebraska", and is a fantastic way to enjoy our community even more.

Artificial intelligence use has exploded, with much anticipation about its future. This talk explores many of the advances that has fueled this explosion, including multi-dimensional vectors, text embeddings, semantic/vector search, transformers, generative AI, and Retrieval-Augmented Generation (RAG). The talk includes semantic/vector search and rag examples. It finally covers how the valuable data stored in databases can be used to enhance AI usage.

Cyclic redundancy check (CRC) is a widely used error-detection mechanism that helps in the validation of data communication and storage in the digital world. While traditional bitwise implementations are slow and less efficient, alternative methods such as lookup tables, carry-less multiplication, and hardware CRC instructions offer significant performance improvements. In this talk, I will present a novel method for automatically identifying and replacing inefficient bitwise CRC implementations with optimized alternatives. The approach uses fast detection of candidate code fragments, symbolic execution for validation, and automatic replacement with more efficient implementations. The method is implemented in the GCC compiler as a separate pass and is open-source available. Experimental evaluation was performed for i386, AArch64, and RISC-V architectures, and the results demonstrated up to 91%, 98%, and 93% performance improvements respectively, highlighting the effectiveness of the proposed optimization.

The Hitchhiker's Guide to the Galaxy has following to say about benchmarking: avoid, if at all possible. One of the reasons is that it's hard and often counterintuitive, another -- it attracts Ravenous Bugblatter Beasts.

Despite all those dangers it's still an important and underappreciated topic, and in this talk I would like to discuss cases when unexpected results arise from benchmarking of BPF programs and why they could be important. Kernel selftest benchmarks would serve as an example, but we will vary the load generation to produce different arrival distributions, introduce contention on tracepoints, or simulate swarm of network connections in user space. To make it easier, we will use home-grown tool Berserker, which was created with an intent to exercise real world BPF applications.

This talk will provide an overview of observability in server-side Swift, with a focus on Distributed Tracing. I’ll start off by talking about some of the design decisions that went into building the swift-distributed-tracing library, which I co-created as part of Google Summer of Code in 2020. The talk will not only compare it to other Swift observability libraries (swift-log, swift-metrics), but also highlight some of the differences between Distributed Tracing in Swift compared to other ecosystems. My personal highlight is the fact that we eliminated the need for support libraries such as “OTel instrumentation for this specific web framework” by implementing swift-distributed-tracing to be used by libraries directly. During the next part, I’ll cover what it means to build a tracer implementation for swift-distributed-tracing with plenty of examples from my OpenTelemetry client swift-otel. I’ll finish the talk with an end-to-end example of a server-side Swift application using the Hummingbird web framework, fully instrumented using Logging, Metrics, and Distributed Tracing, including context propagation and log correlation. This example exports logs, metrics, and spans via the OpenTelemetry Protocol (OTLP) to both a standalone OTel Collector instance and other observability backends that support OTLP natively.

Links: - GitHub: apple/swift-distributed-tracing - GitHub: slashmo/swift-otel - OpenTelemetry Website

Over the years, Delta Chat has matured to be an easy-to-use, secure, and even fast messenger for all platforms, based on the massive e-mail server network. We'll give an overview of the ways Delta Chat is used today and how it is developed by a dozen active contributors. This talk will highlight our recent introduction of realtime chat-shared apps that use e-mail OpenPGP-encrypted messaging to establish a private Peer-to-Peer network among chat group members. In this talk we will demonstrate how these apps work in real-time. We'll also report on several interesting situations where Delta Chat is used today in context of partial shutdowns or strict internet censorship.

Description:

In the beginning, Delta Chat was a fun little experiment, an experimental solution to the network effects problem: “nobody uses secure messengers! But everyone has E-Mail… 🤔" Since then it has come a long way. From a cross-platform set of messenger apps with freely chosen e-mail servers to using audited and well analyzed end-to-end encryption, our project is based on IETF and W3C approved protocols and specifications. We interoperate with the massively distributed SMTP e-mail routing network as well as other e-mail based apps or webmailers and socially are in collaborative relations with numerous other projects, including XMPP-based messengers and standardization specialists.

Delta Chat was among the first messengers to adopt Rust (2019) as its core implementation language and provide all-platform apps. Together with XMPP-projects like Cheogram and Monocles we are evolving a new paradigm and quasi-standard called "webxdc" that enables integration of web apps into chat groups, giving users full control over app distribution. Webxdcs provide a unique Peer-to-Peer model for deploying collaborative standards based software.

Mobilizon is a decentralized, privacy-focused platform for event management and group organization. In this talk, we will explore how Mobilizon empowers users to create and manage events without sacrificing their privacy or control over their data. We will discuss the importance of decentralization, provide a technical overview of the platform, and share insights into its growing community and future roadmap.

Much of the world's open source lives on GitHub, and uses GitHub Actions to provide tasks ranging from routine testing to critical build and release processes. As such, the security of GitHub Actions (and the workflows and actions that users develop and consume) is paramount to the security of the world's software.

But how secure is GitHub Actions, really? This talk will introduce GitHub Actions' internal building blocks and (mostly implicit) security model, and provide real world examples of security failures and surprising avenues of exploitation that recur in widely used actions and workflows. These examples will be motivated via zizmor, a Rust-based static analysis tool for GitHub Actions that can catch many of the most common (and severe) footguns that occur when writing workflows.

Attendees will leave knowing more about GitHub Actions security and best practices for writing secure workflows, as well as how to use zizmor both locally and in CI to detect potential security issues. No prior familiarity with GitHub Actions is necessary.

Java code that is ahead-of-time (AOT) compiled using GraalVM Community Edition native-image may run more slowly than code that is just-in-time (JIT) compiled with the HotSpot compiler. This is something I quickly discovered when I joined the GraalVM team at Red Hat.

Diagnosing performance issues in Java code can be done using Java Microbenchmark Harness (JMH), which helps developers build, run and analyse microbenchmarks written in Java. However, it only works with Java virtual machines using JIT compilation. For the past four years I’ve been wondering how to make JMH achieve the same objectives when that Java code runs as GraalVM native executables.

Eventually I solved this problem creating an extension to JMH that allows Java developers to seamlessly run their existing JMH benchmarks as GraalVM native executables. In this talk I will demonstrate how to obtain benchmark results, gather performance statistics and inspect annotated assembly code. Finally I will compare how the GraalVM native-image AOT code differs from the JIT code of HotSpot.

As with many stages of the software development lifecycle, the release process needs to be constantly improved, iteration by iteration. This way, the software product gets delivered faster and more reliably to customers. This paper focuses on different techniques that have shortened the release cycle of the Kuiper Linux distribution. The new release process involves creating a stabilization branch from main which is dedicated to the new release. Previously, the software components were built and installed during the image creation. Now they are released independently as Debian packages which are uploaded on Analog Devices' Linux Package Repository. This is an easy, user-friendly method that facilitates the distribution and installation of ADI software packages. Each software component has its own release cycle so that one component's bugs won't affect the other components' release. The software components are tested both separately and integrated into the Kuiper image. The latter required creating a Kuiper Docker image. This ensures that each software component is compatible with the target system as early as possible in the development process.

As a project we have notoriously great documentation. The handbook and man pages make it easy to find out how to do anything you might want to on a FreeBSD system, whether it is setting up a network or debugging kernel locking.

Explaining the changes we make to improve FreeBSD? We are less good at communicating what we are up to.

For the last 6 months I have been writing regular status reports about changes in the FreeBSD network stack using a tool guided approach to automate finding and managing what to write about.

In this talk I’ll explain how I am trying to improve communication around FreeBSD development and how you can get involved in writing about FreeBSD.

This is the story of how Jitsi's AI evolved and expanded its features while keeping it all open source: from half-botched PoCs in a weekend to features our customers use in production on a daily basis. Razvan will walk you through some of the implementation details and gotchas of the near-real-time transcription system, while Tudor will guide you through all the other goodies which rely and expand on it.

In the era of distributed systems, many modern databases are designed to scale horizontally from the ground up. Yet, some of the most widely used databases, like MySQL and PostgreSQL, remain single-node by design, relying on third-party sharding solutions like Citus or Vitess for distribution. This raises a critical question: do we always need to go distributed, or can replicated single-node databases meet most use cases? In this talk, we’ll explore the trade-offs between distributed and non-distributed architectures, evaluate the limits of single-node databases, and discuss when it truly makes sense to embrace distribution. Join us as we navigate the complexities of modern database design and uncover what’s best for your applications.

In 2023 a small set of developers set out to work on a Rust-based framework for Arch Linux Package Management (ALPM) - see talks from FrOSCon 2023 and All Systems Go! 2023. After months spent on securing funding for the work ahead, in late 2024 the project has picked up work again in an extended capacity.

In this talk we will explore the technical challenges this project seeks to overcome and provide an overview of the work ahead. This will cover topics such as the writing of specifications for custom file types, dedicated metadata file parsers and writers, the design of libraries for package handling, the more generic verification of digital signatures for distribution artifacts and the integration with existing and upcoming package building and package management infrastructure.

Visual exploration of graph databases is a powerful method for spotting signals and patterns not immediately visible in raw data. However, most existing tools are either too complex or heavy for business users or locked behind proprietary platforms. In visual network analysis, this complexity overload is a significant issue; while graph abstraction is powerful, it can also harm user experience if not properly managed. In this context, developing custom visual graph exploration user interfaces can be key to providing business users with workable tools.

I will present how to use sigma.js, an open-source JavaScript library for web-based network visualization, to write a dedicated web interface to explore data from RICardo, an open-data research project mapping world trade in the 19th century.

Over 30 years ago, Neal Stephenson wrote about a pizza-delivering hacker who saved the digital world. Today, we're all facing our own L. Bob Rife – not through ancient Sumerian viruses, but through corporate consolidation and regulatory pressure threatening to end open source as we know it.

Our digital commons began as a frontier of freedom and innovation. Today giants are consolidating control over the infrastructure that shapes our digital world. The dark future seen in the franchise-owned streets of Snow Crash's America is coming. But Hiro showed us how to fight back: with skill, with allies, and with unwavering dedication to freedom.

We're facing our own daemon – not ancient Sumerian, but modern corporate and regulatory control. The question is: Will you remain a pizza delivery driver, or will you become a Hiro?

The future of open source depends on your answer.

Research software projects often are initially funded by a grant that supports development of the software. But when the grant ends, the projects have to shift to another model to support the required software maintenance, if the software is going to continue being used. This talk will look at the Parsl project and its effort to become sustainable, across a set of project phases. It will also look at the different kinds of RSE work that have taken place during the project. These activities, phases, and developer types appear to be useful concepts for planning or studying other research software projects, or research software as a whole.

Container images sometimes take tens to hundreds of megabytes in size and require many network resources to be transferred. Especially in low-bandwidth network environments like edge computing, frequent image updating will be difficult and increase the network cost. In this talk, I will present "D4C", a software that provides faster and lighter image updating with delta encodings. Delta encodings reduce data size, but generating and applying deltas is a time-consuming operation. D4C utilizes some techniques to reduce them including merge-based delta management and applying deltas lazily. D4C reduces the data size to update images by up to 95% and provides about 10x faster updating in low-bandwidth networks than the state-of-the-art approach. Benchmarks with PostgreSQL and PyTorch showed that their performance degradation caused by D4C is negligible.

We started building CMSes before the days of Wordpress, and we’ve built new CMS every five years or so since. In 2020, hunkered in my covid quarters, I wanted to devise the next version that had a hosted version, a self-hosted, more customizable version, and an open source version.

Kentico’s Petr Palas wrote a treatise in 2017 on why we shouldn’t build a new CMS. His essay basically considers custom CMSes a way to lock in clients, and suggests cloud-first headless CMSes were the future. I, as well, have built multiple versions of custom CMSes, but I see it quite the opposite – even 8 years later, now is exactly the time to create a new CMS.

In this talk I’m going to show the process, roadmap, dangers and successes of creating a content management system from the ground up. I’m going to talk through each of the parts, including errors and notification systems, issues and help systems, user and permissions systems, etc. I’m going to cover the many “required” layers of development that we just didn’t need that saved us thousands of hours and acquired a fraction of the technical debt.

Mobian is a Debian derivative targeting mobile devices, and a significant actor in the Mobile Linux community. Its developers try to closely follow the Debian development cycle and expect to release the next Mobian stable version, codenamed "Trixie", around mid-2025.

However, packaging software and releasing disk images is merely the tip of the iceberg, with the most important work happening behind the scenes: testing, identifying and (hopefully) fixing bugs, contributing to upstream projects...

This talk will discuss the latest developments in Mobian, using it as a pretext to dive into the philosophy underlying its development, and how it shapes not only the technical aspects of the distribution, but also our interactions with the wider Mobile Linux community.

Redox is a community-developed Unix-like operating system written in Rust, with the long term goal of being a microkernel-based alternative to its monolithic counterparts. To achieve this, Redox has been pursuing a "userspaceification" strategy of the POSIX-enabling logic in the kernel, into a runtime library. The most recent example of this is the ongoing POSIX Signals project, funded by NLnet.

This presentation will provide an overview of the Redox operating system and architecture. It will describe the technical details of the userspace signals implementation, challenges, and which parts that were kept in the kernel and why.

As a DNS proxy with extensive support for DNS encryption protocols, DNSdist seemed like a very good choice to support DoT, DoH and DoQ on embedded devices running OpenWrt. This is the story of how we completely underestimated the challenges of the embedded world, and managed in the end to make DNSdist's footprint small enough to provide end-to-end, encrypted DNS service to your home.

OpenStack Swift is the object storage component of OpenStack, unique in its ability to be deployed independently for object storage services.

In this session, I will share valuable insights and experiences gained from operating OpenStack Swift as a public cloud service over the past eight years. Compared to other projects like Ceph, OpenStack Swift has fewer documented use cases. This presentation aims to provide practical knowledge for those looking to build and manage object storage solutions using Swift.

The discussion will cover: • Key components of OpenStack Swift • Architecture design for public cloud services • Operational scenarios for scaling nodes and handling failures • Monitoring strategies for effective operating

Project Repo : https://github.com/openstack/swift

Today, eBPF is used for software-defined networking, observability, monitoring tools, and more. Previously, creating these was labor-intensive and had a high barrier to entry. With the new scheduler extensions, we can now add custom schedulers to this list. Sched_ext allows us to write schedulers with custom policies directly in eBPF. In this talk, we’ll develop a basic FIFO (First-In-First-Out) scheduler in C to show you how to get started with writing your own. If you’re interested in diving deeper into eBPF, join us for a quick hands-on intro to custom scheduling!

In today's hyper-connected world, organizations demand database solutions that transcend traditional infrastructure limitations. This talk explores how distributed SQL databases (such as the open source based YugabyteDB) enable unprecedented global resilience and scalability. We'll dive into practical strategies for building fault-tolerant, geo-distributed systems that can withstand regional failures while maintaining data consistency and high performance.

Key insights include: * Architectural principles of cloud-native distributed databases * Multi-region deployment strategies * Automatic failover and self-healing mechanisms * Real-world implementation patterns

Open Source project that is being used in this talk: YugabyteDB

Tracking down performance issues can be tough, especially when you're not quite sure how to fix them and need to reach out to someone on your team for help. In this talk, we’ll explore how the Firefox Profiler not only helps identify performance bottlenecks but also makes it easy to collaborate with your team to find solutions faster.

We’ll show how to collect and analyze profiling data, spot key issues, and share your findings, so everyone can work together more effectively. We’ll go through real-world examples of how using the Firefox Profiler can streamline your debugging process and improve teamwork.

An introduction and exploration of how to separate debug information from C/C++ build artifacts in order to save space and time when building large codebases. Is it possible to have fast builds without stripping away debug symbols altogether? How would you integrate this into a larger build system?

After a quick introduction to debug symbols, we dive into various compiler and linker options to make an executable smaller without stripping away its debug capabilities. We compare multiple approaches for splitting debug symbols from executables, and demonstrate their pros and cons.

After looking at the details, we take a step back and show how to integrate these techniques into larger build systems like CMake and Bazel, where the effect of split debug symbols is much more noticeable.

Nowadays, most services provide APIs with their own formats, and sometimes multiple versions, which may change over time. But there is a universal API, with an excellent track record of stability and backward compatibility: XMPP!

In this talk, I'll show how XMPP can be more than just an Instant Messaging protocol, and how it can be an extremely powerful tool to access almost anything, from third-party networks (IM, microblogging, etc.) to file sharing, automation (IoT), and more.

I'll briefly explain how the XSF (XMPP Standards Foundation) is organized, how specifications are created, and why having a large number of XEPs (we are now in the 500 series) is not a bad thing—quite the opposite.

Next, I'll discuss some mechanisms of XMPP and demonstrate how they can be applied to a wide range of use cases.

I'll also show that you can use XMPP without having to deal with XML—you can use JSON from your software or other layers.

XMPP is a fantastic toolbox that can help you do almost anything. Let's dive into it and explore how it can help you achieve things simply, efficiently, and quickly.

Swift Distributed Actors offers an exciting way for building reliable and scalable apps in Swift. In this talk, we’ll start with a quick introduction to Distributed Actors itself, and Cluster System—peer-to-peer cluster actor system implementation. I’ll share my journey of implementing a simple event-sourcing and Virtual Actors plugin for this system, demonstrating how these patterns simplify state management and enhance fault tolerance. We’ll explore a small example and will see how it scales and manages different failures.

In late 2023, the Libre Space Foundation asked my company to develop an Open Source photometer—a device designed to help astronomers measure and understand sky quality. The goal was to create a community-friendly tool accessible to enthusiasts and professionals alike, with an ambitious vision of building a global, crowdsourced network of photometers. While the network is a story for another time, this talk focuses on the journey of designing and deploying the device itself.

After writing down the requirements, we realized that the architecture—comprising I2C sensors, a microcontroller, and WiFi connectivity—was relatively straightforward. This simplicity gave us the opportunity to explore new technologies. In particular, could we use Rust to build a robust, unattended, battery-powered device?

Fast forward to today: we have manufactured several hundred units and are collaborating with the Instituto de Astrofísica de Canarias, a leading research institute, to rigorously test the devices under challenging conditions. In this session, we’ll share the lessons learned during development, the hurdles we overcame, and how Rust has since become an integral part of our workflow.

In the eyes of a site editor or administrator, web content management systems haven’t really changed much in 20 years. They all seem so similar to each other and cover the same distance as to be wholly generic. If there’s innovation in CMSes, it seems to be more about architecture, marketing, SEO and templates and less about customizations, new ideas and administrator delight. The players haven’t changed much over the years, and the newer players seem mostly focused on monetization through scale and commerce.

What can we do as a community to rethink the humble web CMS and open new pathways and ideas that could make a web CMS exciting again? This talk hopes to open more questions than answers, drawing on my 25 years of experience working with and building CMSes, and will cover some potential ways to move the industry forward through collaboration, CMS data interoperability and collective innovation.

Mattermost is an open-source collaboration platform that uses PostgreSQL for its database. As a developer heavily involved with Mattermost, I constantly explore new technologies. Recently, I came across YugabyteDB and decided to test it as a replacement for PostgreSQL. In this tech talk, I will share my previous experience with another distributed database and how it compares with my experience with YugabyteDB. Also, I will share the results of running load tests on Yugabyte and how it compares to regular Postgres.

GraalVM Native Image is a popular tool for building standalone executables from Java applications. It is able to generate executables with fast startup time and low memory footprint through the use of a closed world assumption, constraints on dynamism, and many traditional compiler optimizations.

Unfortunately, Native Image's many advanced features can make its build process inscrutable to an inexperienced developer. It is hard to decipher how its many internal components (e.g. analysis, compiler phases, plugins, intrinsics, features, singletons, substitutions, etc.) work in concert and what assumptions must not be violated.

In this talk I will attempt to help make sense of the Native Image build process. I will first describe what components exist and how they interact with each other. Next, I will walk through a native image build and highlight key phases of the process. Finally, I will provide some practical tips to follow when trying to learn more about specific functionality within Native Image.

A short story about why & how Omniconvert migrated from MongoDB to TiDB, with no downtime, for an application serving 15-20k requests per minute. We will discuss the challenges that prompted the migration, why we chose TiDB, overview stress testing & performance evaluation of the application running on TiDB, as well as walk through the steps of the migration. And of course, highlight some lessons learned and the end-user perceived improvements.

The object-capability security paradigm (ocaps) is a conceptually simple, efficient model for collaboration in mutually-suspicious contexts. Spritely is exploring concepts and building solutions in this space to solve real-world problems while encouraging the wider adoption of ocaps, including by working alongside other ocaps organizations and projects to define a standard protocol for intercommunication between ocaps systems. This talk will explain what ocaps is and why you should use it.

Our current model of collaboration is broken. Rather than basing our systems on granting consent, we base them on revoking authority. Ocaps inverts this model with its "if you don't have it, you can't use it" approach, facilitated by restricted means of exchanging authority. Meanwhile, the Object Capability Network protocol (OCapN) abstracts away transport mechanisms between objects while creating a security barrier with minimal overhead. Altogether, this ocaps ecosystem enables secure collaboration in mutually-suspicious contexts by emphasizing and enforcing a consent-based approach to information and authority exchange. Spritely is pioneering new tooling for ocaps with its Goblins library, which also serves as a model for other implementations; and has plans for solutions to problems like distributed storage, identity management, and even social networking.

Social and Solidarity Economy (SSE) refers to a wide range of economic activities that aim to prioritize social profitability instead of purely financial profits. SSE organizations act guided by values ​​such as equity, solidarity, sustainability, participation, inclusion and commitment to the community, and are also promoters of social change.

There is a great diversity of entities in the Social and Solidarity Economy. Different types of activity, different sizes of the entity, different maturity of the IT teams, different quantity and quality of data, medium budgets, low budgets, etc. The SSE, like the rest of the companies, must also make decisions based on data.

Normally the budget of the entities of the SSE is reduced, for this reason, we must facilitate intercooperation to minimize costs without reducing functionalities. The architecture must also be adaptable to future changes within the same entity, without having to make major migrations or lose the work already done. And, of course, Social and Solidarity Economy 💓 Feee Software

We will set up a Business Intelligence architecture by exploring free software tools such as PostgresSQL, DBT, Airflow, Zulip, Superset, etc. to adapt to the needs of the SSE, and Ansible to facilitate replicability and inter-cooperation.