Roadmap 2020

[ttcoder at netcourrier.com]

Responding in terms of "use cases", I would list the following two, as use-cases of interest to me:

1) making my radio station software cross-platform, to also run on a Genode-based system (not necessarily a full fledged 
OS, just framebuffer + nit picker + audio_drv to start with)

2) transferring a bit of my day-to-day computer use, from Haiku to a Genode-based operating system. That OS would 
be(come) as full fledged as possible over time; and would mix Sculpt-OS's no-holds-barred safety and use of Genode's 
security features, whilst still providing the great productivity I'm used to.

Regarding the former, I'm happy to have reached a stage where we have a "vertical slice" of CC6 running on Genode. And 
since early Q3 2019 it is now in "maintenance" mode, i.e. whenever I make changes to CC6 in Haiku, I also compile it in 
Genode+haiku.lib.so to check that it builds and runs as before (and if not, I add implementation or at least stubs for the 
missing symbols). Once we go public with CC6 (Any Day Now (tm)) and reveal what it looks like in the Haiku world there'll be 
more info about the state of its Genode counterpart as well.

Future plans include looking into the AHCI driver (it locks up on our production AMD F2A systems, so I can only work on a 
thinkpad for now) and bringing the haiku.lib.so library to parity with its "big brother", to have more than a proof of 
concept/vertical slice.

Regarding the latter,
That one is still on the drawing board. Future plans include a full-fledged desktop similar to the one I use daily, and maybe 
also an hpkg-like packagefs that allows to mount/unmount packages (packagefs is like BFS -- once you get the virus you 
can  never go back :-). It would have to settle on a preferred file system, I'm leaning on NTFS (via ntfs-3g) as the one that 
seems to provide the features needed for a modern desktop OS and is provided by seemingly mature OSS code base. Later 
in Q1 and Q2 2020, after crunch time has passed, I'll take baby steps resuming work on this, starting with cleaning up and 
commiting more files to the public repository on ChiselApp.

 ***

Now to put back the spotlight where it belongs, on Genode Labs :

Congrats on folding "noux" into libc; following (some of) the action on github it's been clear it was a lot of hard work!

It's exciting reading the "Goa" article series. Definitely keeping it as a reference. In fact, I don't know if Norman realizes how 
many benefits it brings beyond just presenting the Goa tool : for people who live and breathe Genode daily it's probably all 
old news, but for devs like me it's great that is revisits the functioning of Genode system, Genode's packaging, a lot of 
System Integration aspects (the "config" file ..etc) in a way that is different from the previously available documentation. 
Lots of aspects that need to be hammered home. Those articles are all very welcome... and bookmarked. They seem to 
strike the perfect balance in detailing what must be, and yet remain super readable. And once armed by a better 
understanding, one may then revisit the other Genodians articles, and "get" more from them, than initially understood 
during the first read!

> - It is certainly too early to call Goa a success. In order to find out
>   if we are on the right track, I want to expose Goa to as many problems
>   as possible, primarily by the means of porting software.

Having a rich set of ported software is very attractive, it has a lot going for it.
Of course one has to strike a balance between porting a lot and then adding what could be perceived as "dead weight" and 
being too conservative, porting too few programs... But if there are no big down sides I'd say go for it.

> - I'd love to pick up our ideas about Genode's GUI stack, accommodating
>   headless scenarios, multi-head, screen capturing, color depth, and the
>   ability to restart drivers.

The latter is intriguing ; that would go a long way toward demonstrating yet again the technological superiority of a micro-
kernel component-based OS -- I can think of a couple drivers/FSes I'd be glad to see "ruggedized" by that feature.

The GUI stack aspect is of course something I would monitor closely, hoping to contribute both ideas and code in one 
shape or another.

Cedric