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_su... [5] https://genode.org/documentation/release-notes/15.05#Principal_support_for_t...
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
Hi Norman,
thank you for initiating the roadmap discussion. I'll happily join in and share my reflections and plans...
Reflection of 2025 ------------------
One of my highlights of 2025 was bringing the new kernel scheduling to life. What started as a conversation with Stefan at FOSDEM 2024 about the limitations of the former base-hw scheduler has finally been implemented. It was a fun endeavour evaluating and refining the implementation and even more joyful to see that it actually delivers to our expectations. I'm also looking forward to present the details of this journey in the scope of the microkernel devroom at FOSDEM 2026.
On the other end of the spectrum, the Goa SDK further evolved. Along with mainlining the rigorous sandboxing of 3rd-party tools and build systems, the SDK has received various usability improvements over the year such as support for a wildcard depot user and archive-version look-up from depot indexes.
Another topic that kept me occupied once in a while was the support for touch input in Sculpt OS. After I was able to port the touch driver from Linux a few loose ends w.r.t. touch-event support became apparent. In particular, the intermix of pointer and touch events turned out to be quite challenging. In the end, the orchestration between nitpicker, window manager, decorator and layouter had to be streamlined w.r.t. this new use case. Extending the event-filter component for touchscreen gesture detection was actually pretty fun. By writing this mail, I am currently distracting myself from putting everything together in order to actually use Sculpt on my StarLite for browsing and mailing.
Ambitions for 2026 ------------------
The theme "building bridges" actually match my ambitions for 2026 quite well. There are two bridges I'd like to start constructing in 2026:
One topic that has been lingering in my mind for years is the use of Genode as a headless VM host to replace my home server. I would love to spend some time in 2026 for customizing Sculpt for this use case, particularly simplifying the deployment and management of VMs, and making the Sculpt UI and VMs accessible via VNC. Moreover, a mechanism for creating data backups and restore VM state from these backups would be essential for productive use. Maybe there is time for exploring software RAID solutions in Genode.
The other one is file management in Sculpt. There are quite a few 3rd-party file browser apps already waiting to be ported to Sculpt. Even more with the prospect of a VFS plugin for the GUI session. I'd like to pick one of them, port it to Genode and start exploring how file interactions, such as opening a PDF with a PDF viewer, could be orchestrated by Sculpt. I expect that the insights gained thereby are going to contribute to Norman's vision of a capability-based desktop environment.
There are also a few pending topics in the realm of the Goa SDK such as the use of sequoia as a replacement for gnupg, which has been living on an (outdated) topic branch for a while now and is waiting to be mainlined.
Cheers Johannes
On 12/17/25 4:39 PM, Norman Feske wrote:
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_support_for_Xilinx_MicroBlaze [5] https://genode.org/documentation/release- notes/15.05#Principal_support_for_the_64-bit_x86_architecture
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
Hello Johannes,
thanks for presenting your perspective so promptly!
On the other end of the spectrum, the Goa SDK further evolved. Along with mainlining the rigorous sandboxing of 3rd-party tools and build systems, the SDK has received various usability improvements over the year such as support for a wildcard depot user and archive-version look-up from depot indexes.
Your work on Goa never fails to put a smile on my face because you are not only open to suggestions, but often take them much further on your own. The moment I tried 'goa info nfeske/pkg/a8-sdk' from inside my goa-projects repository felt super rewarding.
Just yesternight, my oldest Son and me spent quality time together with using the Goa SDK to bring his custom chess engine over to the PinePhone, using the Goa testbed all the time. He hasn't even the Genode source tree installed on this machine. Just Goa and the Genode toolchain and he was ready to rock. Goa has come such a long and good way.
One topic that has been lingering in my mind for years is the use of Genode as a headless VM host to replace my home server. I would love to spend some time in 2026 for customizing Sculpt for this use case, particularly simplifying the deployment and management of VMs, and making the Sculpt UI and VMs accessible via VNC. Moreover, a mechanism for creating data backups and restore VM state from these backups would be essential for productive use. Maybe there is time for exploring software RAID solutions in Genode.
These would be valuable features, both on a headless system and on a desktop.
The other one is file management in Sculpt. There are quite a few 3rd-party file browser apps already waiting to be ported to Sculpt. Even more with the prospect of a VFS plugin for the GUI session. I'd like to pick one of them, port it to Genode and start exploring how file interactions, such as opening a PDF with a PDF viewer, could be orchestrated by Sculpt. I expect that the insights gained thereby are going to contribute to Norman's vision of a capability-based desktop environment.
There are also a few pending topics in the realm of the Goa SDK such as the use of sequoia as a replacement for gnupg, which has been living on an (outdated) topic branch for a while now and is waiting to be mainlined.
Good to know that my VFS-related plans will fall on fertile ground. I'm very much looking forward to pick up the ideas on the inter-application data exchange we brainstormed together. If you have concrete application scenarios in mind, that's all the better.
Cheers Norman
Hello Fellow Genodians!
Thank you Norman for continuing this enjoyable and enlightening tradition! Could you post this over on Discourse as well, since there might be different people there, and we can be chattier without disturbing the S/N ratio here?
Reflection of 2025 ------------------
It's been another exciting year, for all the reasons you mentioned! Here are a few of the things that resonated with me personally:
- Goa / Genode-World The advances in Goa make everything so much easier, and the Genode-World reorganization around Goa makes a lot of sense. Can't wait to play with it! (See "Ambitions" section below.)
- 25.10 Multi-Kernel Image I absolutely love the multi-kernel boot image! It is really interesting to be able to run the same configuration on different kernels so easily. Please make these for every release!
- Great API Hardening / Eliminating Exceptions Anything that moves errors from run-time to compile-time is near and dear to my heart! I wasn't aware of this pattern before, but I'm looking forward to using it in practice.
- Multi-Monitor / Display Rotation These are both useful and fun! I haven't been taking much advantage of either so far, but I plan to make the most of both going forward.
- HID This is an interesting development, that grows on me the more I look at it. (More in "Ambitions" below.)
Ambitions for 2026 ------------------
I am "all in" on the concept of "Building Bridges". Even though I've had a couple of disappointing years, I really hope to work on the following in 2026, most of which fit this theme:
- VSCodium Extension This one may be useful to others also, and it has the advantage of being pretty simple. My vision is a couple of extensions, one for the traditional build system and one for Goa. I am still gathering ideas of exactly what these would provide, but I will definitely try my hand at HID syntax highlighting. I will create a topic on Discourse to share my thoughts and get ideas from others also.
- Daily Driver / Framework 16 After several false starts, I am going to seriously try to make Sculpt my "daily driver", and gradually move functionality out of Linux VMs and into native Genode apps. I plan on getting a Framework 16 any day now, so I will try to be helpful on getting the most out of that hardware as well.
- PinePhone PDA / Games I often miss the simplicity of PDAs, like the Palm Pilot or Newton (with stylus, not finger, but that's another question for another time). To this end, I would really like to use Goa to port (or write!) some simple apps to the PinePhone, to recreate this experience. Wish me luck! :^)
Questions ---------
Could you elaborate a little bit about the following items from your "Ambitions" section?
- "Capability-based desktop environment" - what would this entail?
- "GUI session VFS plugin" - what sort of information would you be exposing through the VFS?
Thanks again for sharing this with all of us!
Happy Sculpting!
John J. Karcher devuser@alternateapproach.com
Hi John,
thanks a lot for your ongoing enthusiasm and for joining the conversation!
Thank you Norman for continuing this enjoyable and enlightening tradition! Could you post this over on Discourse as well, since there might be different people there, and we can be chattier without disturbing the S/N ratio here?
Sure. I just created a new thread at the forum:
https://genode.discourse.group/t/roadmap-discussion-for-2026/246
Given your reflections, I'm happy that your perception is so well in line with mine.
Ambitions for 2026
I am "all in" on the concept of "Building Bridges". Even though I've had a couple of disappointing years, I really hope to work on the following in 2026, most of which fit this theme:
- VSCodium Extension
This one may be useful to others also, and it has the advantage of being pretty simple. My vision is a couple of extensions, one for the traditional build system and one for Goa. I am still gathering ideas of exactly what these would provide, but I will definitely try my hand at HID syntax highlighting. I will create a topic on Discourse to share my thoughts and get ideas from others also.
I'm looking forward to your ideas. Very cool that you are considering HID-syntax highlighting. On that account, I've recently crafted an LR-grammar for this syntax, which will hopefully contribute to your effort.
- PinePhone PDA / Games
I often miss the simplicity of PDAs, like the Palm Pilot or Newton (with stylus, not finger, but that's another question for another time). To this end, I would really like to use Goa to port (or write!) some simple apps to the PinePhone, to recreate this experience. Wish me luck! :^)
That sounds indeed well aligned with the "Bridges" theme.
Questions
Could you elaborate a little bit about the following items from your "Ambitions" section?
- "Capability-based desktop environment" - what would this entail?
Think of delegating a capability using drag and drop. Or allowing the user to easily take data from one application to another, without both applications even knowing each other. So work flows like opening a PDF downloaded via the web browser, which are currently poorly supported on Sculpt OS, would become seamless but remain under strict arbitration by the user.
- "GUI session VFS plugin" - what sort of information would you be
exposing through the VFS?
I want to expose the entire interface of the GUI session as a file-system structure, in a Plan9-like way.
Pixel buffers are files. The composition of views would described in another file. Input events can be obtained from yet another file. And vsync signaling can be obtained by reading from a pipe-like file. Multiple GUI sessions used by a single application (like a Qt app hosting each window and menu at a distinct GUI session) would form a file hierarchy. This way, even for multi-window applications, plain file system calls would suffice for interacting with Genode's native GUI stack. Think of opening a new window via mkdir.
All languages supporting the traditional notion of files could then interact with the GUI. E.g., a Genode backend for toolkits like GTK could then be written in C using plain file I/O instead of jumping though C++ hoops. But a tool kit written in a higher-level language could use file I/O just as well.
Cheers Norman
Hello Genodians,
before the turn of the year I'd also like to chime in with a review of 2025 and my personal view of challenges for 2026.
In retrospect, I see 2025 as a year of great achievements mixed with the usual delayed ambitions. The multi-monitor GUI improvements as well as Goa attaining its well-deserved place in our daily work flow for the genode-world repository are two achievements I'm quite glad about. While not yet installed on my work machine, the development of base-hw as Sculpt PC platform seems like a dream come true to me. On the other hand, the ambitions for Pre-boot ACPI discovery and IPv6 support did not evolve as desired over the past year. In case of IPv6, the thorough research of protocols and practical aspects was complemented by initial steps of a new router implementation and preparations of our Linux-based IP stack only.
Regarding 2026, I'm impressed by the image of bridges connecting Genode/Sculpt to worlds in the multiple dimensions Norman laid out. Developing the capability-based desktop as paragon for enabling users of all kinds to employ the core advantages of our technology is electrifying. Therefore, I'm more than ready to lend helping hands for the inevitable VFS and libc renovation. Beyond that, the IPv6 developments are going to gain momentum and will evolve into a dual-stack NIC router replacement with support for virtual machines and native components. Further, I aspire robust support for Intel Arrow Lake notebooks incl. BE2xx wifi and Xe-LPG+ graphics based on the promising experiences during the last DDE Linux updates.
Have a good New Year!
Best regards
Hi Christian,
given that we talk in person almost every day, the topics you highlighted for 2026 are not surprising for me. :) I concur with everything you wrote.
Let me only take the opportunity to continue the line of thoughts about the bridges.
On 2025-12-29 14:18, Christian Helmuth wrote:
Regarding 2026, I'm impressed by the image of bridges connecting Genode/Sculpt to worlds in the multiple dimensions Norman laid out. Developing the capability-based desktop as paragon for enabling users of all kinds to employ the core advantages of our technology is electrifying.
I'm really glad that this image resonates so well. The longer I think about it, the more enthusiastic I become because the topic gives room for playful little projects like my recent exploration of Seed7. In the back of my mind, I'm presently thinking of new ways how Genode could augment existing projects.
For example, wouldn't it be fun to boot directly into an existing OS (running in an emulator) with the config and report file systems exposed to the guest OS? Not unlike a Dom0 in a traditional hypervisor architecture, the existing OS could take over the role of Sculpt's Leitzentrale. So Genode components besides the emulator could be managed in a way that feels native to the existing OS. To the existing OS it would bring two benefits: (1} support for all the hardware supported by Sculpt OS, and (2) the use of arbitrary Genode components as a kind of "plugin" for the existing OS. But the character of the existing OS is fully retained.
One hypothetical example close to my heart would be booting directly into TOS (or better, MagiC [1]). So one could turn any PC into an Atari clone that boots directly into GEM in just a few seconds like in the olden days. With Sculpt's config and report file systems accessible from within TOS, a graphical GEM application (e.g. in the form of an accessory) could allow the user to administer the Genode runtime by merely monitoring the files in the report fs and writing the files in the config fs. One could even go as far as letting this accessory play the role of the window layouter of Genode components. So the user could install the Falkon web browser that runs as native Genode component but is hosted in a GEM window.
[1] https://forum.atari-home.de/index.php/topic,18379.0.html
The approach could potentially be applicable for RiscOS, or for Cedric's HoG project [2], or SerenityOS [3], or SymbOS [4], or a hypothetical Seed7 OS where all command-line tools run in the s7 interpreter, or for or as a gateway for connecting QubesOS with Genode.
[2] https://chiselapp.com/user/ttcoder/repository/genode-haiku/home [3] https://serenityos.org/ [4] http://symbos.de/symbosvm.htm
Well, I'm just sharing those thoughts as vague ideas. They are not directly intended for the road map. However, the underpinnings needed for unlocking those scenarios would be worth planning for:
* Splitting the *Sculpt manager into multiple components* so that Sculpt's driver management and software management can be used independently from the Leitzentrale.
* The VFS plugin for the GUI session I mentioned earlier would empower any existing OS (given that it features a form of host-guest file- system integration) to play the role the window decorator for Genode components running besides the guest OS. That's certainly an entertaining additional use case for the *GUI VFS plugin*.
* By consistently using HID syntax, custom tools running inside the existing OS could control the underlying Genode system with plain printf-like functionality (in any programming language) because the format is so simple. Only for parsing HID, a library is needed. To attain the broadest reach possible, a *HID parser written in C* would be most valuable.
* By making the *VFS dynamically reconfigurable*, the existing OS could be used to access files on, let's say, a USB stick when plugged in without needing support for USB nor support for the file system used on the USB stick. Those technicalities would be conveniently covered by Genode.
I think these are four tangible items that deserve being part of the road map.
Regarding the framing of our minds, our work with 3rd-party software has been mostly motivated by extending the feature set of Genode for the benefit of our users. Of course, this motive prevails, e.g. in the form of Christian Prochaska's work with porting all tools of Genode's SDK. Additionally to this motivation, however, I think it is worth asking how Genode could contribute positively to existing projects by augmenting them.
Given the bridge metaphor with Genode at the one side and a peer project at the other side, let's try looking at the bridge from the position of the peer project.
Cheers Norman
Hi all,
Reflection of 2025 ------------------
Next to many other things I have reached my two main goals for 2025. First, I had the time to add improved Meson support to Goa which made it possible to build more complex projects, like glib, using slightly modified Meson build files. With this feature in place I then entered the home stretch of this whole endeavor by transforming our port of Mesa (24.0.8) into a Goa project. Because there are quite a few files generated by the Mesa 3D library, we can now take full advantage of the Meson build-system as used by the project as well as Mesa's internal configuration options without maintaining file lists and generated files [1] within Genode's build system. This line of work will greatly ease the tedious process of updating the Mesa project for Genode. The initial Mesa-Goa project can be found at [2] with the goal of bringing it to the Genode-world repository soon.
Second, I unified the VFS plugins for both lwIP and lxip. Both IP stacks now implement the Socket C-API interface and both VFS plugins share 99% of the source code relieving us of the burden of maintaining two very different code bases. With a look in the direction of IPv6 and ongoing improvements within libc, this unification makes the IP-stacks behave more consistent and new features easier to implement.
Ambitions for 2026 ------------------
With the ongoing re-organization of the Genode-world repository as a Goa-project there are still questions to be answered and problems to be solved and I hope that by the end of the year we will have established new workflows where everybody is happy with.
Since IPv6 will also be addressed 2026, I hope there will be time to participate.
[1] https://github.com/ssumpf/mesa_generated.git [2] https://github.com/ssumpf/goa-projects/tree/master/mesa
Let's start,
Sebastian
Hi Sebastian,
Second, I unified the VFS plugins for both lwIP and lxip. Both IP stacks now implement the Socket C-API interface and both VFS plugins share 99% of the source code relieving us of the burden of maintaining two very different code bases.
I missed thanking you in person for that, but I benefited greatly from this work while adapting our code base to API changes over the course of the past year. From a maintainer's perspective, the situation has become so much better. :)
With the ongoing re-organization of the Genode-world repository as a Goa-project there are still questions to be answered and problems to be solved and I hope that by the end of the year we will have established new workflows where everybody is happy with.
Given your success with Meson and the many fruitful joint efforts on improving Goa we had this year, I'm very positive about it.
Cheers Norman
Hi,
in 2025 I finished the update of QtWebEngine and the Falkon web browser to Qt 6 and worked on the tool chain update and then I started to explore the topic of building Genode (using the Genode build system) and Genode applications (using the Goa SDK) on Genode instead of Linux. I started with setting up a FreeBSD system and building all the needed tools and libraries from source for a chroot environment to get an overview about what needs to be ported to Genode (about 50 tools and libraries so far) and how it needs to be patched and configured to work with the FreeBSD libc which is used on Genode. This process already led to the discovery that our ported versions of 'bash' and 'make' could not build some parts of Genode without errors and needed to be updated. Then I started to port missing tools and libraries to Genode which are needed to use the Goa SDK on Genode, like tcl, expect and git, which is what I'm working on right now and would like to continue in 2026 so we can hopefully build many Genode parts and applications without depending on a Linux VM by the end of the year.
Christian
Hi Christian,
thanks for your response. Your persistence while dealing with highly complex software stacks is truly remarkable. The step-wise methodology you mentioned (testing the waters with chroot on FreeBSD first) seems to be key. It goes without saying that your agenda is completely in line with mine. I love the prospect of developing Genode on Genode without cheating (aka using a Linux VM).
If everything goes according to your plan of covering those 50 tools and libraries, we gain - as a welcome side effect - plenty for real-world porting examples in Genode world, which in turn will make further porting activities easier and easier over time.
Apart from this main theme, do you think it's realistic to update the Chromium engine sometime this year as well? I think it would be really nice to have genode.discourse.group well supported with our native browser.
Cheers Norman
Hi Norman,
On 09.01.26 13:56, Norman Feske wrote:
Apart from this main theme, do you think it's realistic to update the Chromium engine sometime this year as well? I think it would be really nice to have genode.discourse.group well supported with our native browser.
Yes, I would then update the other Qt6 libraries to the same version as well.
Christian
Hello,
all in all 2025 had a similar vibe to the years before. Spending time on reworking parts of the block I/O stack, while also working on different topics throughout the year, was nice.
Attending FOSDEM as well as FrOSCon was especially fulfilling as familiarizing someone with Genode leads to interesting and fruitful discussions most of the time.
Although I planned spending time on certain things, e.g. retiring VBox for my personal usage, I was hard pressed for motivation, which resulted in little progress.
With that in mind I am going to treat 2026 like a blank canvas and see where it goes (w/o any ulterior plan).
Best regards Josef
Hi Josef,
thank for chiming in.
On 2026-01-05 14:25, Josef Söntgen wrote:> all in all 2025 had a similar vibe to the years before. Spending
time on reworking parts of the block I/O stack, while also working on different topics throughout the year, was nice.
I sense that the gradual continuation of your storage line-of-work is only natural. Now that you curated the low-level block layer so well, we can slowly move up the stack, e.g., looking together at a revision of the file-system session, or expanding the set of supported file systems. This ties in pretty well with the VFS-related activity I advertised.
Attending FOSDEM as well as FrOSCon was especially fulfilling as familiarizing someone with Genode leads to interesting and fruitful discussions most of the time.
Good vibes indeed. Let's keep them up. :) I particularly enjoyed the C3D2 events as well, like the Sculpt-OS session in December we visited together. This calls for repeating.
Cheers Norman
Hi,
here are my thoughts regarding the roadmap discussion.
Reflection of 2025 ------------------
The past year to me meant a lot of long standing improvements at the very ground of the framework to actually become reality. Especially the re-design and implementation of our custom kernel's scheduler algorithm, elimination of exceptions within core, and kernel (base-hw), modern x86 hardware support for base-hw, accurate page-table memory accounting, and some more. Moreover, I was involved in enabling new hardware like the armStone i.MX 8MP SoC including a demonstrator for the embedded world exhibition, USB stabilization work, and some more maintainance work items. The coronation of these attempts surely was the switch to our custom kernel and the new HID configuration language on top of my relatively recent (Meteorlake) x86 hardware just 2-3 weeks ago :-).
On the downside I didn't accomplish to introduce a new USB API and server that acts as a multiplexer for either USB peripheral drivers, as well as USB host controller drivers, see roadmap 2025, for which I felt responsible. This is what I plan for the very beginning of this year.
Topics for 2026 ---------------
Beside the re-organization of the USB API (to have explicit host controller driver clients), I'd like to have support for USB Audio. Not only, but also as a practical example to stress-test the ability to have distinct drivers of different USB interfaces of one and the same USB device (AUDIO + HID of a headset). Moreover, my framework laptop has no internal ethernet card, but one that is bound via USB. Unfortunately, our USB network driver does not support it resp. doesn't work correctly here. I would like to strengthen the USB network support therefore.
Beside making the USB multiplexer more robust, the platform driver needs some internal reworks too, like removing exceptions, explicit DMA sessions to account DMA memory for distinct clients in separate, and interrupt session adaptions to support MSI and MSI-x better (more than one interrupt per device).
Now that our custom kernel is used on a daily base by ourselves, I see the necessity of more maintainance work in 2026 here, like building it without C++ exception support compiler-wise (minor issue now), strengthen its robustness in general, do some x86-related and generic optimizations, e.g. rethink system calls to combine signals and ipc in one call.
I'm hesitant to bring up new features or applications here, because I see myself confronted with the maintainance of some important components on several hardware platforms already, and of course we'll have to do driver updates and support of new modern hardware this year too. Therefore, I don't see myself porting additional native applications (e-mail client), or enabling non-functional features (like full-disk encryption) although I would be very happy about it.
Happy new Year!
Best regards Stefan
Hi Stefan,
The past year to me meant a lot of long standing improvements at the very ground of the framework to actually become reality. Especially the re-design and implementation of our custom kernel's scheduler algorithm, elimination of exceptions within core, and kernel (base-hw), modern x86 hardware support for base-hw, accurate page-table memory accounting, and some more. Moreover, I was involved in enabling new hardware like the armStone i.MX 8MP SoC including a demonstrator for the embedded world exhibition, USB stabilization work, and some more maintainance work items.
I really cannot put into words the gratitude I feel for your sense of responsibility for base-hw that you have put on display in 2025. The scope of this work was at times surprising to both of us. Your desire for quality and the removal of remaining uncertainties was beautiful to witness. Your priorization of this important kernel curation work over your original USB plans was only natural in my opinion. No regrets!
Beside the re-organization of the USB API (to have explicit host controller driver clients), I'd like to have support for USB Audio. Not only, but also as a practical example to stress-test the ability to have distinct drivers of different USB interfaces of one and the same USB device (AUDIO + HID of a headset). Moreover, my framework laptop has no internal ethernet card, but one that is bound via USB. Unfortunately, our USB network driver does not support it resp. doesn't work correctly here. I would like to strengthen the USB network support therefore.
Beside making the USB multiplexer more robust, the platform driver needs some internal reworks too, like removing exceptions, explicit DMA sessions to account DMA memory for distinct clients in separate, and interrupt session adaptions to support MSI and MSI-x better (more than one interrupt per device).
Now that our custom kernel is used on a daily base by ourselves, I see the necessity of more maintainance work in 2026 here, like building it without C++ exception support compiler-wise (minor issue now), strengthen its robustness in general, do some x86-related and generic optimizations, e.g. rethink system calls to combine signals and ipc in one call.
This is a perfectly sensible plan worth pursuing.
I'm hesitant to bring up new features or applications here, because I see myself confronted with the maintainance of some important components on several hardware platforms already, and of course we'll have to do driver updates and support of new modern hardware this year too. Therefore, I don't see myself porting additional native applications (e-mail client), or enabling non-functional features (like full-disk encryption) although I would be very happy about it.
I agree.
Each year, our road map tends to be unrealistically optimistic at some points. When missing a few of the goals, there might be a slight feel of defeat. But it shouldn't. In contrast to a contractual obligation like commissioned project, our road map is just a casual plan after all, a guiding rail for us developers, but no definite guarantee.
Yet, I recognize your call for staying realistic. ;-)
Cheers Norman
Hi all,
2025 was a quite strange but interesting year for me. Making the Genode support fit to run (on official unsupported) Sculpt OS variations occupied quite some time, but was fun and I learned a lot, about the kernels and (yes, also) Genode. Presenting the results live on a running Sculpt@kernel image at meetings and at conferences (Dresden Systems Meetup, FOSDEM, seL4 summit), in front of, partially non Genode faced, communities was also very special, but I don't want to miss the experience actually. It finally settled in the release of a combined multi-kernel Sculpt OS 25.10 image [0] for NOVA, hw, NOVAe, seL4 and Fiasco.OC, which triggered (surprisingly to me) quite good attention.
Other working topics had been adding/enabling ARMv8 support to Genode/seL4 and Genode/NOVAe, building a working prototype to run Win11 as VM on Genode@NOVA, investigation of the Intel TotalMemoryEncryption feature with multi-key support and building a working prototype for Genode@NOVA, and an early working prototype to be able to hot plug also display drivers during runtime. My second year of running my VMs daily, just powered by the Seoul VMM, went quite well without hick-ups. Just the feature work on shared-folder support for Seoul, received too less attention to have something to share yet.
For 2026 I expect quite some amount of contract work and backlog work from the 2025 roadmap, so I will see where it goes.
Cheers,
Alex.
[0] https://genodians.org/alex-ab/2025-11-02-sculpt-multi-kernel
Hi Alex,
thank you for your reflections and perspective.
On 2026-01-08 09:58, Alexander Boettcher wrote:
2025 was a quite strange but interesting year for me. Making the Genode support fit to run (on official unsupported) Sculpt OS variations occupied quite some time, but was fun and I learned a lot, about the kernels and (yes, also) Genode. Presenting the results live on a running Sculpt@kernel image at meetings and at conferences (Dresden Systems Meetup, FOSDEM, seL4 summit), in front of, partially non Genode faced, communities was also very special, but I don't want to miss the experience actually. It finally settled in the release of a combined multi-kernel Sculpt OS 25.10 image [0] for NOVA, hw, NOVAe, seL4 and Fiasco.OC, which triggered (surprisingly to me) quite good attention.
It is very laudable that you took the motto of your FOSDEM'25 talk "microkernel diversity" to your heart and - in the form of the multi-kernel system image - to its impressive logical conclusion. I greatly appreciated that you took the topic right into the home of seL4 community in the form of your presentation at the seL4 summit, creating awareness that Genode is no joke. :)
Other working topics had been adding/enabling ARMv8 support to Genode/seL4 and Genode/NOVAe, building a working prototype to run Win11 as VM on Genode@NOVA, investigation of the Intel TotalMemoryEncryption feature with multi-key support and building a working prototype for Genode@NOVA, and an early working prototype to be able to hot plug also display drivers during runtime. My second year of running my VMs daily, just powered by the Seoul VMM, went quite well without hick-ups. Just the feature work on shared-folder support for Seoul, received too less attention to have something to share yet.
For 2026 I expect quite some amount of contract work and backlog work from the 2025 roadmap, so I will see where it goes.
Given Johannes' posting of today, I sense that your investigation of x86-security features comes just at the right time. With "backlog work", I guess you are referring the pre-boot topic. This would indeed fit very well with the overall theme of system integrity protection and boot-time security. Let's see where it takes us.
Cheers Norman
Hi everyone,
I'm eager to learn about the perspectives and plans of you, users and developers alike.
What is your retrospective on Genode in 2025?
I haven't finished any of my goals for 2025 ;-(
My plan to port Nova to the Power9 architecture got stuck behind my port of the OS-in-1000-lines tutorial to the P9: It's easy to work in the hypervisor mode on that chip, getting to user mode with paging is a little more complex.... I'll get to it some day.
My second wish, to build a router/firewall on Genode got postponed due to lack of IPv6 in Genode. I had a 4 port router in the past based on run/tcp-terminal, it worked quite well but it was V4 only. When V6 comes available I'll volunteer as alpha/beta tester in my homelab.
My third plan: Moving my workflow from Linux to Sculpt and Linux VMs. As I don't trust my data to single disks on laptops without ECC-ram, I tried NFS and 9p, but these were too slow to compile Sculpt on the laptop. Especially when compared to cross compiling on the P9.
What I need is a shared file system between my P9, Sculpt and its VMs so I can work in the VM while my data lives safely on my ZFS-server with snapshots and backups. So I decided to create my own filesystem. How hard can it be?
I expect to get it working in Linux/FUSE soon. With that I can slowly migrate some workflows from Linux to Sculpt VMs while starting to port that FS to Genode's VFS. And that's my goal for this year.
On the other hand, reading about Michael's server platform and CLI-Leitzentrale makes me dream about running a mail and DNS server in Genode. So many good ideas, so little time.
Cheers,
Guido Witmond.
PS. Hope to meet at FOSDEM.
Hi Guido,
even though your verdict of the past year is not quite happy, I'm glad that it does not spoil your interest in Genode. The addition of a new CPU architecture to NOVA+Genode as a single person may have been too ambitious.
Your idea to focus in a file-system implementation that is fit for your needs (scratching one's own itch) sounds much better manageable, in scope as well in depth. From community perspective, it might actually be more rewarding than the engagement with the PowerPC architecture because such a component could become useful for users of Sculpt OS of any flavor.
On the other hand, reading about Michael's server platform and CLI-Leitzentrale makes me dream about running a mail and DNS server in Genode. So many good ideas, so little time.
That's really good to read. The uncovering of such shared interests is certainly a wished-for outcome of publicly discussing our road map.
See you at FOSDEM! :)
Norman
Hello,
Last year, the Hack&Hike was my highlight. Not only was I able to install SculptOS on my convertible notebook, but I also figured out how to set up the touchscreen. Many thanks to everyone for their support. To make it helpful for others, I wrote an article about it in the Genode forum [1]. The Hack&Hike was rounded off by a varied supporting program that allowed participants to get to know each other better. The event was topped off with a small LAN party, which of course took place on SculptOS in proper style. With the release of the experimental multi-kernel Sculpt 25.10 PC image, I tried SculptOS on my second computer and wrote about it again in the forum [2]. While I was thinking about tooling to better cope with the XML used in SculptOS, the new HID/ HRD syntax came in handy. I now find the configuration and reports from SculptOS much easier to read.
I really like the metaphor for building bridges. It also fits very well with the idea of a Genode/ SculptOS user group. There, I could team up with others and learn Goa. I am also interested in the idea of a capability-based desktop environment that uses VFS plugins and is thus somewhat similar to the file-based approach of Plan9. This file-based approach also seems to me to be helpful for good accessibility or a simple headless system. I am also interested in good 3D support for (linux-)VMs. I am also interested in a help system or at least better accessibility of documentation in the Leitzentrale and for components (on-screen documentation) as well as better usability for updates. With regard to notebooks such as [2], where virtually all connections consist of USB modules, an expansion of the USB stack would also be quite helpful.
For the coming year, I would like to get involved in a user group, be able to use Goa on Linux and Genode, and, if possible, help with usability improvements.
[1]: https://genode.discourse.group/t/evaluation-of-hardwaresupport-for-thinkpad-...
[2]: https://genode.discourse.group/t/evaluation-of-hardwaresupport-for-the-frame...
Cheers, Nos
-- Translated with DeepL.com (free version)
Hello Nos,
I'm grateful for you joining our discussion and sharing your perspective on the project. It is particularly rewarding that the Hack'n'Hike gets so much appreciation from you. As I responded to Johannes, the interplay of the C3D2 with our team as it emerged over the past year means a lot to me. Your engagement and enthusiasm - both at the events we joint together as well as on the forum - has played a big role in that.
XML used in SculptOS, the new HID/ HRD syntax came in handy. I now find the configuration and reports from SculptOS much easier to read.
So happy!
That's exactly what I was after: Increasing the joy while using Genode.
I really like the metaphor for building bridges. It also fits very well with the idea of a Genode/ SculptOS user group. There, I could team up with others and learn Goa. I am also interested in the idea of a capability-based desktop environment that uses VFS plugins and is thus somewhat similar to the file-based approach of Plan9. This file-based approach also seems to me to be helpful for good accessibility or a simple headless system. I am also interested in good 3D support for (linux-)VMs. I am also interested in a help system or at least better accessibility of documentation in the Leitzentrale and for components (on-screen documentation) as well as better usability for updates. With regard to notebooks such as [2], where virtually all connections consist of USB modules, an expansion of the USB stack would also be quite helpful.
Most of these interests are perfectly in line with mine. It's motivating to know that you are anticipating features like the on-screen documentation. So it sounds worth prioritizing it over some of the under-the-hood technical topics that occupy me most of the time. Looking very much forward to present the fruits of this labor at C3D2 or the new user group! :-)
For the coming year, I would like to get involved in a user group, be able to use Goa on Linux and Genode, and, if possible, help with usability improvements.
Fantastic!
Cheers Norman
What is your retrospective on Genode in 2025?
I feel like it has been 9-12 months since I even touched Genode but started poking around again when the roadmap discussion started, inspired by all the productive talk. I do not dislike XML to the degree others might, but the new HID syntax is great! Impressed with the progress.
Which topics are of most interest to you?
Personally, I crave novelty. Unique systems and programming languages and ideas.
Professionally, security has become a huge talking point in my job search, mostly around supply chain and attestation. "Can we trust this hardware platform/vm platform? Is our software supply chain for this system secure?". I'm no security specialist, my role is mostly automation/observability/etc. I do not see Genode fitting into this (yet) but my knowledge is limited.
How do my plans resonate with you?
When I hear "printf-like functionality" I'm reminded of the Benno Rice talk "What Unix Cost Us", where he laments the amount of snprint required to use the USB Linux APIs/usb_f_fs api. It's not necessarily my opinion but more like "Benno Rice's opinion".
- Splitting the *Sculpt manager into multiple components* so that
Sculpt's driver management and software management can be used independently from the Leitzentrale.
What little I've learned about Sculpt so far, I really like this. I noticed if I want to change something in Sculpt that is in the codebase, it's a full recompile of that component. Learning the Sculpt codebase itself, on top of learning the rest of Genode, looks like a large task.
What are your plans for 2026?
Part one of my plan is accomplished: get Sculpt on a bare-metal system. I would like to build and publish a package that I can fetch within a Sculpt system. Get a full write-up of how to do it, publish to a blog, then keep working from there.
I've been doing lots of "Modern C++" (C++23, linux io_uring + coroutines) and seeing about building from-scratch Wayland bindings for it. I've thought about putting this peanut butter in the Genode chocolate, get some form of Wayland compositor proxy that can talk to nitpicker. I can not estimate how much work that would be, whether I could even accomplish it.
Hi boin,
nice to see you here! Thanks for joining the discussion.
I do not dislike XML to the degree others might, but the new HID syntax is great! Impressed with the progress.
Overall, the feedback is much more positive than I expected. It's reassuring to see that this change is perceived as an improvement, not as a mere whim of mine. ;-)
Is our software supply chain for this system secure?". I'm no security specialist, my role is mostly automation/observability/etc. I do not see Genode fitting into this (yet) but my knowledge is limited.
The discussion touched topics like trusted/authenticated boot and assured system integrity already, e.g., the postings of Alexander and Johannes (J03). I definitely want to see the use cases of Johannes covered in 2026.
Regarding (software) supply-chain security, I think that Genode's ports and depot tools provide a solid starting point for a systematic assessment. E.g., I think a tool for creating the "bill of material" for a given pkg archive (a list of all 3rd-party software downloads that go into the pkg) would not be difficult to implement. But as I don't see that as urgent, I wouldn't put the topic on the road map of this year.
When I hear "printf-like functionality" I'm reminded of the Benno Rice talk "What Unix Cost Us", where he laments the amount of snprint required to use the USB Linux APIs/usb_f_fs api. It's not necessarily my opinion but more like "Benno Rice's opinion".
Hah! Mea culpa. This was just a clumsy attempt to express that HID is easy to generate. I'm indeed not a friend of format strings myself, which is the reason we removed them from the Genode framework 10 years ago.
[1] https://genode.org/documentation/release-notes/16.08#Cultivation_of_the_new_...
What little I've learned about Sculpt so far, I really like this. I noticed if I want to change something in Sculpt that is in the codebase, it's a full recompile of that component. Learning the Sculpt codebase itself, on top of learning the rest of Genode, looks like a large task.
I agree. Good that your are reinforcing this point.
What are your plans for 2026?
Part one of my plan is accomplished: get Sculpt on a bare-metal system. I would like to build and publish a package that I can fetch within a Sculpt system. Get a full write-up of how to do it, publish to a blog, then keep working from there.
You are probably aware, but let me drop the link to the "Applications" book [2], which wants to be your guide along the way.
[2] https://genode.org/documentation/genode-applications-25-04.pdf
I've been doing lots of "Modern C++" (C++23, linux io_uring + coroutines) and seeing about building from-scratch Wayland bindings for it. I've thought about putting this peanut butter in the Genode chocolate, get some form of Wayland compositor proxy that can talk to nitpicker. I can not estimate how much work that would be, whether I could even accomplish it.
Interesting! I sense that this undertaking would potentially benefit from the VFS-GUI line of work I mentioned earlier.
Cheers Norman
Hi everyone,
I've been watching closely for years but unfortunately I couldn't do much in 2025 (have other responsibilities...). In 2026 I plan to do what I've been always planning to do: a more user-friendly Genode-based distro, maybe by basing off Sculpt OS, maybe by directly building upon the Genode framework. Genode is an interesting project, I wish more people would start learning and building upon it... HID is also very interesting and I would like to do some related work (if needed) too.
Best Regards,
Z Lin
On 12/18/25 00:39, Norman Feske wrote:
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_su... [5] https://genode.org/documentation/release-notes/15.05#Principal_support_for_t...
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
What is your retrospective on Genode in 2025?
I haven't done much coding during 2025 and that is true for Genode , but also other projects.
Which topics are of most interest to you?
Base-hw kernel.
How do my plans resonate with you?
To be honest , I don't know :-)
What are your plans for 2026?
If I manage to do anything .. I will look into if I can do something about SVC handling. I have started a bare metal aarch32 emulator for aarch64. It won't be bare metal in a Genode context, but it is very small. In the emulator 32bit SWI are directly mapped to aarch64 SVC. It uses the immediate value after SWI and not a register. So the plan is to handle that in the most system friendly way as possible.
Where do you see Genode by the end of 2026?
I hope that the framework will survive Sculpt.
Kind regards, Michael Grunditz
Hi Michael,
thank you for the response.
Where do you see Genode by the end of 2026?
I hope that the framework will survive Sculpt.
No need to worry. You make Sculpt sound like an infection. But as indicated by the other postings, if anything, the aspired decomposition of Sculpt's feature set into independent components will make Genode more flexible and versatile, not less. I sincerely hope that you'll benefit from that.
Cheers Norman
Hi Z Lin,
thanks for sharing your interests.
I've been always planning to do: a more user-friendly Genode-based distro, maybe by basing off Sculpt OS, maybe by directly building upon the Genode framework.
This seems to fit perfectly with the ambition to make Sculpt OS more modular.
Potential users are sometimes scared away by the Leitzentrale UI of Sculpt OS. A more welcoming alternative - one that is still interoperable with Sculpt and Goa at the package level - could be a real win. Along these lines, the discussion already touched on possible synergies with QubesOS, which already addresses many end-user concerns (like the interactive management of USB devices) in a carefully designed user-friendly way.
Cheers Norman
Hello everyone,
thanks to everyone who participated in the brainstorming! I'm happy that the theme of building bridges resonated so well with many of you. Over the past few weeks - and thanks to your thoughtful replies - this vague picture has evolved into a tangible plan:
https://genode.org/about/road-map
For me, the thrill of anticipation is stronger than ever. :)
Cheers Norman
-
Alexander Boettcher -
boin -
Christian Helmuth -
Christian Prochaska -
Guido -
Johannes Schlatow -
John J. Karcher -
Josef Söntgen -
Michael Grunditz -
Norman Feske -
Nos -
Sebastian Sumpf -
Stefan Kalkowski -
Zetian Lin