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