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
_______________________________________________
users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Archived at
https://lists.genode.org/mailman3/hyperkitty/list/[email protected]/message/M2ANJ5TEAO7K6PUTVK66C7DCJDPFW2EE/
