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