# Roadmap discussion for 2026 **URL:** \ **Category:** General\ **Created:** [December 22, 2025, 8:59pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246 "2025-12-22T20:59:42Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![nfeske](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/nfeske/32/6_2.png) [@nfeske](https://genode.discourse.group/u/nfeske)\ **Post date:** [December 22, 2025, 8:59pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/1 "2025-12-22T20:59:42Z")
We just kicked off our annual roadmap discussion over at our [mailing list](https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/thread/JMGMUML3KBFEXHJCEZBW5SQURNK7KRZI/). @jjkarcher suggested to cross-post here to make you aware of the discussion and possibly chime in. ---
**Author:** ![tickzip](https://avatars.discourse-cdn.com/v4/letter/t/848f3c/32.png) [@tickzip](https://genode.discourse.group/u/tickzip)\ **Post date:** [December 30, 2025, 9:24pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/2 "2025-12-30T21:24:56Z")
I thought I’d be the first to kick-start the conversation over here in the forums by talking about my own experiences with Genode in the past year. I first found out about Genode earlier this year after watching a [video](https://www.youtube.com/watch?v=Nr2h9eigpqA) of a presentation from @nfeske (which I found incredibly interesting and eye-opening btw). I had been interested in OS security for a while, and the idea of a system built out of a series of components was something familiar to me as a user of Qubes OS (although here it was taken a step further, and fully fleshed-out as part of a working system). Due to the similarities between the two systems, I turned to the Qubes OS forum and came across a [post](https://forum.qubes-os.org/t/qubes-os-based-on-the-genode-os-framework/11735) in which Genode had received great praise and admiration by the lead developer. Naturally, this furthered my intrigue, and led me to many whitepapers about microkernels and OS security in general. I was most certainly impressed when I tried out Sculpt OS for the first time on a USB! Who knew an Operating System could be this exciting? I plan to spend a great deal of time next year exploring the intricacies of Sculpt OS and seeing where it will take me. I also plan to attempt using Sculpt OS as my daily driver, as I am already used to using VMs as part of my usual workflow in Qubes. While I have never attempted any form of serious programming, I am interested in trying to port some software to Sculpt (or even write my own). It can’t be that hard, right? As a user of an IPv6-only (mostly) network, the continued focus on bringing IPv6 support to Genode would certainly expedite my arrival to Sculpt. I rely on IPv6 for managing my homelab infrastructure and it is something I would prefer to have natively supported by the OS. Additionally, @jschlatow’s mention of the use of Genode as a server had me quite excited as well, I certainly wouldn’t mind using it on my own servers, and the idea of Genode on desktop, mobile and server platforms would be quite impressive. In regards to the ‘building bridges’ focus for next year, I am particularly interested in the idea of a fusion or collaboration between Qubes and Genode. I am certain I am not alone in this regard, as I have seen many comments and posts from people that hope for the same. The topic has been in discussion for at least a decade (judging by some old mailing lists), but I assume the reason it has not yet come to fruition is that the work involved would perhaps be asking a little too much. Overall, I have been **very** pleased with my experience on Genode this year, and I am grateful for the hard work of the developers in making it happen. I hope that this year for the project will be the best one yet. 🥳 ---
**Author:** ![squizzler](https://avatars.discourse-cdn.com/v4/letter/s/fbc32d/32.png) [@squizzler](https://genode.discourse.group/u/squizzler)\ **Post date:** [December 31, 2025, 1:35pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/3 "2025-12-31T13:35:11Z")
I also fully endorse your mantra “building bridges”. As an armchair follower I especially enjoy it when Genode introduces us to obscure projects such as “Seed7” just featured on Genodians. The more esoteric the project or language you are able to find for our pleasure, the better! ---
**Author:** ![jjkarcher](https://avatars.discourse-cdn.com/v4/letter/j/a9adbd/32.png) [@jjkarcher](https://genode.discourse.group/u/jjkarcher)\ **Post date:** [January 2, 2026, 6:57pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/4 "2026-01-02T18:57:50Z")
> [@tickzip](#): > > I plan to spend a great deal of time next year exploring the intricacies of Sculpt OS and seeing where it will take me. I also plan to attempt using Sculpt OS as my daily driver, as I am already used to using VMs as part of my usual workflow in Qubes. Same here. (But just coming from regular Debian, not Qubes). Please share any tips; I will do likewise! > [@tickzip](#): > > While I have never attempted any form of serious programming, I am interested in trying to port some software to Sculpt (or even write my own). It can’t be that hard, right? Goa certainly makes it easier to port software! I’m finally going to try my hand at that also. On this topic, I don’t know what your preferred development environment is, but I am going to try to write a VSCodium extension to put an IDE front-end on Goa. I’m going to put a request for ideas / feature requests in another topic, so if that’s of interest, let me know. ---
**Author:** ![jjkarcher](https://avatars.discourse-cdn.com/v4/letter/j/a9adbd/32.png) [@jjkarcher](https://genode.discourse.group/u/jjkarcher)\ **Post date:** [January 5, 2026, 6:34pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/5 "2026-01-05T18:34:52Z")
From the ML - @skalk wrote: > 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. This is great news to me! My Framework 16 is in the mail, but I will obviously not be able to use it much with Genode without at least the USB Network driver, and preferably the USB Audio driver as well. (I would also love to use it on the ThinkPad Yoga, since I don’t have the silly dongle for the built-in ethernet port, so I have a different USB network adapter for that.) Needless to say, I will be eagerly awaiting whatever you are able to do on these. 🙂 Also, just curious, which model of Framework laptop do you have? P.S. Another positive effect of getting my Framework 16 is that my ThinkPad Yoga will immediately become a full-time Genode machine! 🥳 ---
**Author:** ![chelmuth](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/chelmuth/32/1_2.png) [@chelmuth](https://genode.discourse.group/u/chelmuth)\ **Post date:** [January 6, 2026, 5:21am UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/6 "2026-01-06T05:21:00Z")
So you may prepare `sudo lsusb -v` output for the devices you’re interested in. ---
**Author:** ![nfeske](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/nfeske/32/6_2.png) [@nfeske](https://genode.discourse.group/u/nfeske)\ **Post date:** [January 6, 2026, 11:11am UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/7 "2026-01-06T11:11:39Z")
Thank you @tickzip for having taken the time to explore Genode, and for sharing your story. Your feedback is highly encouraging. 😄 It is good to see that your interests are well aligned with the road-map topics that came up so far. Regardless of whether you decide to have a go at programming or porting components, your feedback on @chelmuth’s IPv6 work or @jschlatow’s headless scenario would be a welcome and motivating contribution for sure. > It can’t be that hard, right? I hope it’s not. The best starting point would be the step-by-step guides of the [Applications book](https://genode.org/documentation/genode-applications-25-04.pdf). Should the barrier of entry be too high, let’s try together to make it lower. > collaboration between Qubes and Genode […] has not yet come to fruition I see three major challenges. First, the “fusion” is not obvious. The architectures of both projects are different. So getting them into alignment needs research and experimentation. On that account, we had a splendid time at last year’s Hack’n’Hike where Marek and Marta joined us, played with Sculpt OS in very creative ways, exchanged ideas, and gave thoughtful feedback. We are seeing the beautiful peak of a mountain. The exact trail to walk on hasn’t been discovered yet. But we are looking out. Second, Qubes OS has a significant user base. With their distinct sense of responsibility, the Qubes developers won’t risk potential disruption of their users, which speaks very much in their favor. A joint approach will be feasible not before we discover a stepwise plan that keeps the risk for disrupting users really really low. This makes the scouting for a suitable trail even much harder. Third, both projects are not starved of ideas and working topics, which is quite well illustrated by the variety of topics already raised during our road-map discussion. Most of those topics are tangible and thereby actionable whereas the vision of fusing Qubes with Genode remains still vague. So when prioritizing work, the actionable topics usually win, unless economic incentives are at play. So far however, we have been solely talking on the grounds of curiosity, idealism, and friendship. There exists no funding or commercial incentive for such work on either side. By the way, there will be a joint stand of Qubes OS and Genode at [FOSDEM](https://fosdem.org/2026/) in just a few weeks. You can find us in the H building at stand location H-10. Thanks again for joining the discussion and welcome to the forum! ---
**Author:** ![skalk](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/skalk/32/23_2.png) [@skalk](https://genode.discourse.group/u/skalk)\ **Post date:** [January 6, 2026, 3:19pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/8 "2026-01-06T15:19:56Z")
> [@jjkarcher](#): > > This is great news to me! My Framework 16 is in the mail, but I will obviously not be able to use it much with Genode without at least the USB Network driver, and preferably the USB Audio driver as well. (I would also love to use it on the ThinkPad Yoga, since I don’t have the silly dongle for the built-in ethernet port, so I have a different USB network adapter for that.) Needless to say, I will be eagerly awaiting whatever you are able to do on these. 🙂 > > Also, just curious, which model of Framework laptop do you have? It’s an Intel Meteor Lake based Framework 13. Of course that doesn’t tell you much about the USB peripherals. The USB ethernet card of my USB-C docking station is a Realtek card (vendor\_id: 0xbda, product\_id: 0x8153). ---
**Author:** ![ttcoder](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/ttcoder/32/9_2.png) [@ttcoder](https://genode.discourse.group/u/ttcoder)\ **Post date:** [January 7, 2026, 5:08pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/9 "2026-01-07T17:08:06Z")
Just back from work and catching up on email, spotted this on the mailing-list, responding here instead: > The approach could potentially be applicable for RiscOS, or for Cedric’s > HoG project [2], The idea of running Be/Haiku in a virtual machine is something we toyed with a little in the past. During the discussion with my fellow TTS folks back at the time, which I think was about running Haiku in VirtualBox in Linux (instead of Genode as discussed here), we had not pursued it. The reason was, it did not solve the instability problems we had, it only helped alleviate them a bit with a faster reboot after a kernel crash (assuming VB reboots faster than real-hardware, and we could detect the Haiku crash and act on it). Edit : outside of our narrow use-case though, others might be attracted by this intriguing perspective ---
**Author:** ![nfeske](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/nfeske/32/6_2.png) [@nfeske](https://genode.discourse.group/u/nfeske)\ **Post date:** [January 8, 2026, 11:17am UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/10 "2026-01-08T11:17:52Z")
Nice seeing you picking up the topic. 🙂 The connection to HoG may have been far fetched but it is still an idea I found worth sharing. It was not my intention to merely replace HoG with Haiku running in a VM but to complement HoG and Haiku. To appreciate this picture, let’s recap to pros and cons of both Haiku and HoG (from my vaguely informed perspective): For Haiku, the _pros_ are the tasteful desktop, the management and interplay of applications, the user experience. The _cons_ are the stability troubles you mentioned (attributed to its monolithic structure) and its large risk surface regarding security (heritage of BeOS, which was not focused on security after all). For HoG, the _pros_ are the stability benefits of Genode’s architecture (e.g., pluggable drivers), and a vastly reduced surface for security risks (principle of least authority applied everywhere). The _cons_ are the lack of a desktop environment and the overly primitive user experience of Genode’s GUI stack. The pros and cons look strikingly complementary to me (while cowardly disregarding many other aspects like device-driver support, performance, available software). This makes me wonder, couldn’t both worlds be combined so that the strength of each project can shine? What if it was possible to use Haiku as a desktop shell (beautiful desktop) that allows for the spawning of HoG components that are executed besides Haiku, yet still displayed in Haiku windows? Technically this could be achieved by running Haiku in a VM hosted on Sculpt’s runtime, exposing Sculpt’s config and report file systems to Haiku (via VirtualBox’ shared-folder mechanism), and letting Haiku play the role of Genode’s window layouter and decorator. Using the config fs from within Haiku, one could install and start a HoG component by adding a `start` node to /genode/config/deploy (as usual on Sculpt). Sculpt would take care about downloading, verifying, installing, and starting the HoG component, which would ultimately try to open a window (by talking to Genode’s wm component). The new window with its initial size appears in the list of `/genode/report/window_list` that is visible by Haiku. A Haiku application observes the change, creates a new Haiku window with the appropriate size, and tracks the geometry of the window as managed by Haiku’s window manager. Whenever the window is repositioned, restacked, or resized, this application writes a file `/genode/config/gui_layout` telling Genode about the stacking order of Haiku windows, including the window of the HoG application. The gui\_layout, in turn, is consumed by a decorator that distinguishes Haiku windows from HoG windows and drives the composition of the respective nitpicker views (similar to like it’s done by Genode’s motif\_decorator). The approach resembles the [overlay window management](http://genode-labs.com/publications/overlaywm-tr-2004.pdf) idea. Well, the end result would be the following: A desktop where HoG applications appear as being part of the Haiku desktop and user experience but running independently. Haiku (and the virtualization overhead) is not involved in the execution of the HoG application. So even if Haiku crashes, the application remains unaffected. Upon restart of Haiku, the application window would just re-appear (from Genode’s perspective, the window decorator was merely restarted). Network-related security risks of Haiku can be reduced to zero by keeping Haiku disconnected from the network at all times and accessing the internet via Genode components only. In such a setting, Haiku asserts the role of a _trusted shell_ (or Dom0 in Xen speak) that has full control over Sculpt’s runtime. It is not intended for running untrusted software. But it can spawn new containers where software (untrusted or trusted) can be safely executed (including VMs of course). All this power is laid into the hands of Haiku by the access granted for /genode/config/. So Haiku is not subordinated. It is in charge of controlling Genode. ---
**Author:** ![ttcoder](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/ttcoder/32/9_2.png) [@ttcoder](https://genode.discourse.group/u/ttcoder)\ **Post date:** [January 8, 2026, 5:03pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/11 "2026-01-08T17:03:10Z")
> [@nfeske](#): > > For HoG, the _pros_ are the stability benefits of Genode’s architecture (e.g., pluggable drivers), and a vastly reduced surface for security risks (principle of least authority applied everywhere). The _cons_ are the lack of a desktop environment and the overly primitive user experience of Genode’s GUI stack Oh – now I see, you’re talking about something akin to “haiku-on-Sculpt OS” (almost tempted to call it “HoS” ^^), but going a step further, and using a _headless_ (not full-screen !) Virtualbox instance to pilot Sculpt OS, replacing the Sculpt UI logic and leitzentrale. Well assuming that [# 354](https://github.com/genodelabs/genode-world/issues/354) is adressed, and someone writes the Haiku/VB side code, and the Sculpt-side support is added, that could work. The latter part (Sculpt side support) would be used also for the other systems you mentionned, not just Haiku, so that one is easier to justify, clearly. Or maybe once #354 is adressed we’ll realize that it is good enough for most uses and no further work is required 😉 P.S. that ticket is part of the items listed in my “hired help wanted” post I’ve been meaning to post, assuming I solve my bitrot problems ; maybe in a few months EDIT: while I’m here, a quick detour to mention I’m doing a thorough tour of the [seed7.net](http://seed7.net) website ; the language appears to not have technical debt in the memory management area, unlike V-lang, I’m trying to determine a few things, e.g. whether it could interface/bridge with C++ etc ---
**Author:** ![nfeske](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/nfeske/32/6_2.png) [@nfeske](https://genode.discourse.group/u/nfeske)\ **Post date:** [January 9, 2026, 10:09am UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/12 "2026-01-09T10:09:54Z")
> [@ttcoder](#): > > Well assuming that [# 354](https://github.com/genodelabs/genode-world/issues/354) is adressed That’s certainly a key ingredient! Thanks for drawing this connection. Other questions/uncertainties would be: Support for vbox shared folders in Haiku? Support for watching files located in a shared folder (currently Genode’s libc and thereby Genode’s version of vbox lacks support for the watching of files). How to export and track Haiku’s window layout? How to export Haiku’s pointer shape? Uncertainties for sure, but I see no show stopper. 🙂 ---
**Author:** ![jjkarcher](https://avatars.discourse-cdn.com/v4/letter/j/a9adbd/32.png) [@jjkarcher](https://genode.discourse.group/u/jjkarcher)\ **Post date:** [January 9, 2026, 10:40pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/13 "2026-01-09T22:40:52Z")
> [@chelmuth](#): > > So you may prepare `sudo lsusb -v` output for the devices you’re interested in. Thanks! Most importantly are the devices that @Nos listed in the “Framework 16” topic. My USB network adapter/hub is just a cheap thing, and since Wi-Fi does work on the ThinkPad, it’s not really necessary. But in case it’s easy, here is what I hope is the relevant section: ```auto Bus 002 Device 004: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0b95 ASIX Electronics Corp. idProduct 0x1790 AX88179 Gigabit Ethernet bcdDevice 1.00 iManufacturer 1 ASIX Elec. iProduct 2 AX88179 iSerial 3 0000051BD346C4 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0039 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 8mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 4 Network_Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 11 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x0016 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 HIRD Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 1 micro seconds bU2DevExitLat 101 micro seconds Device Status: 0x000d Self Powered U1 Enabled U2 Enabled ``` Thanks again! ---
**Author:** ![nfeske](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/nfeske/32/6_2.png) [@nfeske](https://genode.discourse.group/u/nfeske)\ **Post date:** [January 27, 2026, 10:18am UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/14 "2026-01-27T10:18:54Z")
Thanks a lot to everyone who participated in the road-map brainstorming! Today, I’m happy to announce Genode’s official road map for this year: [Genode - Road Map](https://genode.org/about/road-map) ---
**Author:** ![G0retZ](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@G0retZ](https://genode.discourse.group/u/G0retZ)\ **Post date:** [January 28, 2026, 12:13am UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/15 "2026-01-28T00:13:54Z")
> [@nfeske](#): > > Thanks a lot to everyone who participated in the road-map brainstorming! > > Today, I’m happy to announce Genode’s official road map for this year: [Genode - Road Map](https://genode.org/about/road-map) Wow, this looks awesome! Really ambitious goals! 🤩 I’m very excited to see all this happening, this is one of those rare moments when I want to fast-forward time! Though I have 1 question, forgive me my ignorance if I’m missing something here. > GnuPG replaced by Sequoia What is the problem with GnuPG for Genode? 🤔 Isn’t old time-proofed code in this case more reliable and less vulnerable to possible attacks? 😅 ---
**Author:** ![jschlatow](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/jschlatow/32/12_2.png) [@jschlatow](https://genode.discourse.group/u/jschlatow)\ **Post date:** [January 28, 2026, 1:48pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/16 "2026-01-28T13:48:01Z")
> [@G0retZ](#): > > What is the problem with GnuPG for Genode? 🤔 There are multiple aspects that motivate us to replace GnuPG in our tooling: For instance, we like the library-first approach of Sequoia and the clarity in its CLI. GnuPG’s approach of using daemons such as gpg-agent and, more recently, keyboxd, has challenged and is still challenging us when executing it in a sandboxed environment (as Goa does). Moreover, with the goal of running Goa natively on Sculpt, we had to ask ourselves where to invest our porting efforts (we don’t have a complete port of GnuPG). ---
**Author:** ![G0retZ](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@G0retZ](https://genode.discourse.group/u/G0retZ)\ **Post date:** [January 28, 2026, 3:08pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/17 "2026-01-28T15:08:06Z")
> [@jschlatow](#): > > There are multiple aspects that motivate us to replace GnuPG in our tooling: For instance, we like the library-first approach of Sequoia and the clarity in its CLI. GnuPG’s approach of using daemons such as gpg-agent and, more recently, keyboxd, has challenged and is still challenging us when executing it in a sandboxed environment (as Goa does). Moreover, with the goal of running Goa natively on Sculpt, we had to ask ourselves where to invest our porting efforts (we don’t have a complete port of GnuPG). Oh, I see now, makes total sense! 🤔 Thank you! ---
**Author:** ![tickzip](https://avatars.discourse-cdn.com/v4/letter/t/848f3c/32.png) [@tickzip](https://genode.discourse.group/u/tickzip)\ **Post date:** [January 28, 2026, 3:32pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/18 "2026-01-28T15:32:54Z")
What is meant by > On-screen documentation Is this a tutorial-style documentation e.g. when you click on the `+` menu for the first time you get a little text prompt that guides you through installing a package. Or is it more like a help menu with information about each component and what it does e.g. you can click on any component in Leitzentrale and get an overview of what it does such as `nic_router` having a little description on Genode-specific networking. ---
**Author:** ![nfeske](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/nfeske/32/6_2.png) [@nfeske](https://genode.discourse.group/u/nfeske)\ **Post date:** [January 28, 2026, 5:31pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/19 "2026-01-28T17:31:38Z")
The details are not decided yet. Let me share the motivation: Following the getting-started steps of the Sculpt documentation is easy enough. But once when installing further components, users tend to hit a wall when confronted with the many decisions in the routing dialog. It would be nice to give software providers a way to briefly explain each of the requirements. So when the user opens one item in the routing dialog, a digestible piece of explanation is provided. Why is this resource needed, and what are typical decisions? So the user becomes able to follow the reasoning of the component provider. Software providers, in turn, will be rewarded by seeing their documentation on screen (rather than have it buried in a readme file). So the relationship between user and software provider becomes less distant. You know, building bridges. 😄 Another idea is to host the Sculpt documentation in a separate tab of the Leitzentrale. So the manual is always at hand without needing a web browser. ---
**Author:** ![tickzip](https://avatars.discourse-cdn.com/v4/letter/t/848f3c/32.png) [@tickzip](https://genode.discourse.group/u/tickzip)\ **Post date:** [January 28, 2026, 5:48pm UTC](https://genode.discourse.group/t/roadmap-discussion-for-2026/246/20 "2026-01-28T17:48:22Z")
> [@nfeske](#): > > Another idea is to host the Sculpt documentation in a separate tab of the Leitzentrale. I feel it would be useful to have documentation dedicated specifically for this purpose, such as a reference manual/guidebook that is not too dissimilar from what @G0retZ was talking about. [Next page](https://genode.discourse.group/t/roadmap-discussion-for-2026/246.md?page=2)