We just kicked off our annual roadmap discussion over at our mailing list. @jjkarcher suggested to cross-post here to make you aware of the discussion and possibly chime in.
6 Likes
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 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 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. 
5 Likes
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!
2 Likes
Same here. (But just coming from regular Debian, not Qubes). Please share any tips; I will do likewise!
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.
1 Like
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!
3 Likes
So you may prepare sudo lsusb -v output for the devices youāre interested in.
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. 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 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!
2 Likes
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).
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
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 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.
1 Like
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 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 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
1 Like
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.
1 Like
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:
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!
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
3 Likes
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? 
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).
1 Like
Oh, I see now, makes total sense!
Thank you!
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.
1 Like
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.
5 Likes
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.
1 Like