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
-
Johannes Schlatow -
John J. Karcher -
Norman Feske