users January 2026

users@lists.genode.org

14 participants
5 discussions

Building the toolchain on nixos
by alice.domage＠gapfruit.com 02 Feb '26

02 Feb '26

Dear Genodians, Has anyone already built the toolchain for nixos? and happens to have a `flake.nix` or a `.nix` source file that can build it, I think those are called 'derivation'. I am currently down that rabbit hole, and have the following error: ``` $ ./tool/tool_chain x86 <...> The directory (BUILD_SYSTEM_HEADER_DIR) that should contain system headers does not exist: /usr/include ``` I haven't modified the `tool/tool_chain` tool or patched configure to adjusted standard paths, to point to their respective 'stores' yet. I only have adjusted the shebangs to `#!/usr/bin/env -S ...` where needed. Cheers, alice

3 3

Roadmap 2026
by Norman Feske 27 Jan '26

27 Jan '26

Hello everyone, I'm writing this email on a Sculpt OS image [1] running on Genode's custom kernel and using HID as the format for its textual user interface [2]. To me personally, a distant dream has just become real. What else happened this year, and where to go next? Let me kick off our annual roadmap discussion with sharing my perspective and ambitions. [1] https://genode.discourse.group/t/sculpt-25-10-with-hid-syntax-highlighting [2] https://genodians.org/nfeske/2024-12-20-moving-on-from-xml Reflection of 2025 ------------------ Our overarching theme for this year was "rigidity, clarity, performance" [3]. My main contributions towards these goals had been the replacement of C++ exceptions by sum types throughout the framework, and the move from XML to the lean syntax I envisioned 2,5 years ago and officially proposed in December last year [2]. [3] https://genode.org/about/road-map Both topics had ripple effects on the entire code base. The systematic change of the error handling to sum types forced me to reconsider the longest-standing system-wide abstractions such as the low-level allocator interfaces, to the welcome effect of becoming conscious of all possible error conditions, unveiling loose ends formerly obscured, and ultimately solving them. I'm extremely grateful to my team mates who joint the effort, e.g., Alexander applying the new error handling scheme to the seL4-specific portions of Genode, or Stefan for the tremendous curation of our custom kernel as well as Genode's virtualization interfaces. It has been a long way. But now we have the luxury of knowing that Genode's base system has left no error condition unconsidered. The replacement of XML with a human-friendly alternative had been largely my personal line of work. While being convinced of the goal, I was quite cautious of possible disruption. I tried hard to not distract my colleagues from their working topics by pursuing the migration path to the new syntax on my own account while upholding the framework's compatibility to XML. I was quite afraid to disrupt API users external to our team for a mere syntactic change. However, by combining the change with an API revision that addresses long-standing deficiencies of the former XML utilities, I could justify the disruption. We had to revise the XML processing anyway. The introduced 'Node' and 'Generator' APIs generally simplify the code, do not rely on exceptions, and improve memory safety. Even we kept XML, this repair would have been needed rather sooner than later. As the intended side effect, components using the new API became syntax-agnostic. Voila. In summer, I managed to start up Sculpt OS using the new syntax, and in October, I switched to this flavour full time, eating my own dog food with great delight. All the while working on these main topics, I witnessed wonderful things happening in Genode land: With the new scheduler and the added virtualization support for our custom kernel, the final puzzle pieces have fallen into place for using Sculpt as self-sufficient OS without depending on a 3rd-party kernel! The culmination of a seemingly eternal line of work, which started as a heretic idea "Couldn't roottask and the kernel be merged into one program?" I dared to utter in 2007 to the distress of the Dresden church of L4, then first explored by Martin Stein with Genode on the Xilinx Microblaze in 2011 [4], then moved to the realms of x86 by Adrian-Ken Rueegsegger and Reto Buerki in 2015 [5], then becoming our go-to kernel for using Genode on ARM for many years, later equipped with x86 virtualization support by Ben, and now finally made fit for general-purpose use with Sculpt OS by Stefan and Johannes. Given this long story, having the kernel now running on the laptop under my fingers is truly amazing. [4] https://genode.org/documentation/release-notes/11.02#Approaching_platform_s… [5] https://genode.org/documentation/release-notes/15.05#Principal_support_for_… Another super satisfying sight had been the coolness of Sebastian, Josef, and Alex while updating our arsenal of Linux-based drivers to Linux 6.12, reinforcing hardware support as one of Genode's most distinctive features in the world microkernel-based systems. The tool-chain update to GCC-14 went equally smooth, thanks to the careful preparation and execution by Christian Prochaska. Finally, I'm overly happy to see the proliferation of the Goa SDK as the central tool for the development of Genode software. I see Josef's re-organization of the Genode-world repository as a Goa-project tree as the begin of a new chapter. Ambitions for 2026 ------------------ What could that "new chapter" be about? I think it should be about building bridges. Bridges to other open-source projects. Bridges to a variety of programming languages. Bridges to new user demographies. Bridges for the interoperability of applications. Personally, I feel the urge to implement HID parsers to different programming languages while - at the same time - bringing those programming languages to Genode. So we gain new freedom for implementing components, and the HID syntax could potentially become useful elsewhere. Another interest of mine is the seamless interoperability of Genode components in a sort of capability-based desktop environment. As a preparatory step, I'm longing to make the VFS more flexible, in particular adding dynamic reconfiguration support. Closely related to the VFS, I'm dreaming of making the GUI session available as a VFS plugin. With the GUI session exposed as file-system interface, the porting of GUI toolkits will become easier because those toolkits no longer need to interface with Genode's C++ API. For Sculpt OS, I have a long list of topics in the back of mind. I hope that I will have the time to realize the on-screen documentation view and the interactive management of USB devices. I'd love to see HID becoming the default in Sculpt OS 26.04 and to drop the support for XML in version 26.10. How about you? -------------- I'm eager to learn about the perspectives and plans of you, users and developers alike. What is your retrospective on Genode in 2025? Which topics are of most interest to you? How do my plans resonate with you? What are your plans for 2026? Where do you see Genode by the end of 2026? Following the tradition of the previous years, I'll do my best to distill your input along with the plans of Genode Labs into the project's official road map by mid of January. Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

14 28

Re: Roadmap 2026
by Michael Müller 16 Jan '26

16 Jan '26

Hi Norman, > But lacking personal relations with cloud infrastructure > providers, this world remains distant and intangible to me. This is something where Gapfruit may come into play, as they have partners in the realms of IoT clouds, and seem to be interested in my work. But, I also may to broker some contacts using my University and PhD supervisor’s contacts, if needed. > I wonder, do you see any actionable steps that would lead us towards this alien world? I actually already have planned steps towards this world. So first, I would start with, as stated in my first e-mail, improving the networking stack to be able to support high volume traffic (which to be honest not even the Out-of-the box Linux stack can currently handle, which is why third-party user-space stacks based on DPKD are so popular in this domain). During that I’d also start to port some typical server applications to Genode for use for evaluation of the network stack and as a poster child. And, if this works out and I have a practically proven prototype for a cloud-flavor of Genode including the features I developed for my PhD thesis, I would like to present it with a demonstrator and evaluation at fitting conferences (e.g. the corresponding dev-rooms at FOSDEM, SOSP, NSDI etc). This way, I may be able to draw some attention and interest into these kinds of applications of the Genode framework. I know that this sounds ambitious, but somehow that’s why I find it so motivating. Cheers Michael ............................................................................................................................................... Michael Müller Wissenschaftlicher Mitarbeiter (DFG-Projekt MxKernel) AG Eingebettete Systeme — Institut für Informatik Raum 50/613a Telefon: +49 541 969 3891 E-Mail: michael.mueller(a)uos.de <mailto:michael.mueller@uos.de> Homepage: ess.cs.uos.de/team/mml <https://ess.cs.uos.de/team/mml>

2 1

Re: Roadmap 2026
by J03 14 Jan '26

14 Jan '26

Hey, in 2025 we had a wonderful time at the Hack-and-Hike :)I learned a lot and in the end I had a laptop with a satisfying SculptOS setup and the feeling that it’s achievable to use Genode as a hypervisor for my every day use cases.The following weeks I enjoyed configuring a declarative setup for systems with Genode + NixOS:https://github.com/johannesloetzsch/nixos-genode-hybridIn the future, I would be happy to build native apps using Goa. For now (the transition), I’m happy about using declarative builds of VMs running the software I’m familiar with. The Ambition for 2026 to build bridges to other open-source projects and new demographies really resonates with me :)I plan to improve my existing setup and would like to provide reusable modules to allow future users a smoother path to a usable setup.I'm thankfull about the hours of amazing support I received from core-developers during the last year :) However to make the potential in Genode available to a much broader community than now, the simple availability of common open source software should increase. I would love to have an community maintained distribution of a setup similar to Qubes OS, but based on Genode… This is a dream for a larger time period, but I would be happy to exchange thoughts and do some prototyping in 2026… It's so nice, to have other Genode users at our hackerspace, inspiring each other. They plan to start a „user group“ with regular meetups in 2026 :) Which topic is most interesting to me?To use Genode on my devices without relevant security regressions, I require secure boot.For now my setup allows booting the kernel via TrustedGRUB / Lanzaboote. However till now, the sculpt-iso-image and the configurations (from GENODE*-partition) are not signed. I have ideas how this could be implemented, but I would prefer a clean solution, applicable to everyone interested.In the end I want protect to the integrity up to starting VMs (with a static MBR + boot partition). Cheers, Johannes

2 1

Re: Roadmap 2026
by Michael Müller 14 Jan '26

14 Jan '26

Hi all, For those who don’t know me yet: I am a PhD student working on Genode as foundation for researching novel concepts and architectural designs for data-center system software and gave a talk about Genode on FOSDEM three years ago. At the beginning of last year, I started porting the extension I made to Genode, namely NUMA support and dynamic resource allocation for components to Genode 25.02. As, Genode had diverged quite a lot since I started my modifications in 2022, I used the opportunity to completely redesign the handling of NUMA topology information and resource allocation. The reasoning behind this was, to make all my modifications available as an additional micro-kernel with its own specialized version of Genode’s “core” service. Thus, I hope, future upstream changes in Genode’s Core API can be more easily integrated into my fork of Genode. Furthermore, the redesign of my extensions allowed me to greatly improve the stability of the dynamic resource allocation for components while also improving its performance. This has also has been the year, where I finally implemented my plans for a NUMA-aware scalable hoard allocator that could replace Genode’s heap in scenarios with many parallel memory allocations as for example in database workloads, where not just scalability is needed but also the ability to allocate memory from specific NUMA regions in advance to improve NUMA-locality for future memory accesses. I have evaluated the performance of my new memory allocator with the “Larson” memory benchmark which is commonly used to evaluate the performance and scalability of memory allocations in server applications. The evaluation showed significant improvements for my allocator over Genode’s default allocator. Currently, I use my allocator even as a replacement for libC’s heap on Genode to test its performance and stability in real world applications. There might come up a pull requests, once, I have cleaned up the code and made it platform-agnostic. After I attended last year’s Hack’n’Hike where Norman explained to me how SculptOS implements the dynamic creation of components, I could finally implement my own CLI-based remote shell for Genode (think of it as the CLI version of Leitzentrale). Now, my colleagues and I can run various evaluation campaigns on Genode on our servers without manually having to compile a new Genode image and restart our servers for each change in a scenario, as we had to before, because Leitzentrale did not work on our servers (for some it did not start at all and for another server it started but keyboard and mouse didn’t work) and we didn’t need a GUI but scriptable manager instead. In the meanwhile, as kind of a side quest, I analyzed and experimented with Genode’s network stack, as using it for data-center workloads revealed some bottlenecks. In conclusion, 2025 was finally the year I got not just a first prototype of my envisioned data-center OS but also one that can new be used by others. As I will be on search for a new job in 2026, as my contract at the university comes to an end in February, I am not sure whether my plans for 2026 work out as intended. Nonetheless, I’d like to present some of the work I’d like to do in 2026. First and foremost, I’d like to use 2026 to improve the scalability and performance of Genode’s network stack which would benefit running server applications on Genode as well as network-bound desktop applications. In this regard, I like the idea to build bridges to other projects and applications for Genode. I imagine one could also build bridges into server and cloud applications, too. For example, I think of porting a set of typical server applications (such as memcached and a DBMS) to Genode. Which together with lighttpd (or even a port of apache or nginx) would enable Genode to host dynamic websites such as content-management systems, blogs such as Wordpress, or even instances of the fediverse. Above all, I am more than ever convinced that Genode’s architecture combined with the concept of microkernels provides a better foundation for today’s cloud infrastructure than Linux or Windows can provide, as I will discuss in my upcoming talk at FOSDEM 2026. I really like the idea of building bridges and hope to see more applications of Genode in the future. Cheers, Michael ............................................................................................................................................... Michael Müller Wissenschaftlicher Mitarbeiter (DFG-Projekt MxKernel) AG Eingebettete Systeme — Institut für Informatik Raum 50/613a Telefon: +49 541 969 3891 E-Mail: michael.mueller(a)uos.de <mailto:michael.mueller@uos.de> Homepage: ess.cs.uos.de/team/mml <https://ess.cs.uos.de/team/mml>

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users January 2026