Roadmap 2024

[Norman Feske]

Hi Cedric,

thanks for sharing your unique perspective. It's always a joy getting 
new insights into your experiences and ambitions. I'm grateful seeing 
that you hold our work in such high regard.

On 2023-12-22 12:03, ttcoder at netcourrier.com wrote:
> Howdy Norman, all,
> A little screenshot to warm up, then my perspectives of daily Genode usage.
> 
> Mail:
> Here's a little screenshot of a quick port of the (Be)Mail GUI.
> 	https://tts-genode.neocities.org/tts-img/2023-12_BeMail_nano3d_ftppositive.png
> This one specific app is probably not a most promising prospect for Genode/Sculpt, due
> to limited feature set compared to big names like ThunderBird and (more importantly)
> due to its requiring a custom version of Genode with xattr support,
> plus I didn't port its network back-end yet.
> But it could serve as inspiration for related projects, who knows. Doing that kind of small-to-medium
> size Be ports to Genode is quite easy now that most pieces of the Be puzzle are in place.

The screenshot nicely shows how far your work has come by now. Speaking 
of the porting of Be applications, I wonder how Goa could be applicable 
in these cases? Should we succeed to eventually bridge the gap between 
your customized version of Genode (xattr) and the regular Sculpt OS 
while fostering the use of Goa for such porting efforts, developers who 
enjoy casual porting work may become able to join the fun, building upon 
your H/o/G layer as a library.

> Heck,
> after learning about the new debug-monitor in 23.08(?) I had to resist the urge to slap this
> GUI on top of it: https://www.haiku-os.org/files/images/debugger_return_value.png
> It would probably be a couple orders of magnitude more work than porting (Be)Mail...
> But knowing myself, I'll probably port it eventually, though it will have to wait
> a year or three. I rarely use that debugger/GUI in Be and also on Genode I tend to
> resort to tracing analysis. But sometimes it can make a big difference to dump an
> app into a debugger, e.g. if some threads are deadlocked, you save yourself many
> iterations of refining tracing to find out which thread stops where and when.
> Anyway, as I port new stuff in the future new screenshots will appear (always better than the wall'o'text I tend to post! /grin)

It is so nice seeing you drawing connections between Haiku and our 
working topics, even for the debug monitor.

Once we have fully realized our vision of on-target debugging via GDB, 
you will hopefully be able to follow the lines of this working example. 
Now is too early. But as you cheerfully noted, we aren't in a hurry.

> Stations:
> This coming year 2024 will be pivotal for us at tunetracker and our stations.
> Nothing that's of direct concern to the genodian community, but will mention
> it for the curious. After the elapsed time and the promises we made to our stations
> of providing them with a platform that doesn't crash several times per day, one
> of twho things could happen : stations could tell us they're still interested in our
> software and want to try it out now that it's getting to alpha stage on a rock solid
> platform (Genode!), or they'll tell us they've moved on to other pastures (free-as-in-beer/speech
> radio software running on Linux etc is gaining market shares against commercial concerns like
> ours : why pay for software suite X if you can get Y for free and it's "good enough" ?).
> In the latter case that's fine, sort of. Genode will still have a lot of staying
> power in my computing life as a 'daily driver', which has huge significance to me.

I sense your mixed feelings from this paragraph, and I'm crossing fingers.

> Past years "push" versus future "daily driver":
> My take on this kind of mirrors Norman's remarks : those past years my feedback
> often revolved around 'wishes' (what I needed/wished from Genode, and progress I must make),
> now in my case it's (the beginning of) harvest time, very happy about that.
> Now that SculptOS-style depot packages are supported in H/on/Genode, including Falkon,
> I've started booting into H/Genode just to browse the news in Falkon, and will be
> striving to extend use-cases next year.
> For instance it might be possible to migrate my asciidoc writing to Genode, at least the
> part of asciidoc that depends on Python, if not the half that depends on Ruby. Will have to
> reboot for that one (or I could try out the Seoul and VirtualBox packages ? Sounds like a plan!).
> And I'll keep porting stuff from the Be world that I need to be productive in Genode too.
> This is all a 'sea change' for me, for years I've been growing increasingly
> confident about Genode's capabilities as I became more familiar with it,
> and now I'm in new territory, starting to actually do the stuff I wanted to do in Genode.
> One way to cut this pie is to look at my daily usage as 1) programming-related and 2) all the rest.
> Short term, this coming year I'll be curious to see if anything in set #2 resists my migration efforts.
> I'm not looking at #1 yet as that's a perspective for the future, being very demanding in terms of FS usage.
> But Genode currently looks like it could handle an awful lot of part #2 -- provided I port the necessary software of course.

Wow! The stars seem to be aligning. :-) With that I mean that my 
personal ambition to streamline the use of Sculpt OS on the desktop will 
hopefully benefit your ambition. Since you have integrated Genode's 
depot/deploy mechanism now, you can finally draw on the full potential 
of our community (given the increasing arsenal of delightful packages 
maintained by individuals). Vice versa, I'd be thrilled to be able to 
fetch an index of nice Be applications from your depot one day.

> - if Goa is increasingly used to add new ports to genode-world or to other decentralized repos, I probably
>    won't be the only one looking forward to it and downloading packages to try them out!
>    Packages need to be "advertised" one way or another though : when a a new package is mentionned
>    in Genodians I take notes, when it goes through the GitHub genode-world timeline I takes notes,
>    but if in neither of these, I'm not going to be aware of its existence, so something to keep in mind.

The discoverability remains unaddressed. The existing "components 
overview" [1] does not do justice to the current (and emerging) 
situation where more and more Genode software resides outside our 
central repository. Maybe a community-managed plain list of links to 
projects (be it in the form of Goa projects or components hosted at the 
world repository or in other forms) would be good start? Still, someone 
would need to assert the responsibility to host and curate such a list.

[1] https://genode.org/documentation/components

> - re drag'n'drop, curious to see what the Genode approoach would be. It might save me
>    the need to roll my own ad-hoc implementation in H/Ge.

I was indeed thinking of you when I mentioned drag'n'drop.

> - same thing with (if I understand correctly) creating a "nitpicker_primitives.lib.so"
>    that can be re-used by other components : color me curious and interested.

The foundational work is already done and found its way into the 23.11 
release [2] but I deliberately don't overly advertise it to avoid wrong 
expectations. However, if you are curious about the use of this 
approach, you may risk a look at gems/src/app/sculpt_manager/ and the 
view/ sub directory in particular. Over the next year, I plan to 
successively complement the API with the features needed for more 
general use. One key feature will be the ability to integrate existing 
nitpicker clients into applications (similar to xembed), thereby 
clearing the path to augment existing full-screen applications (think of 
mupdf or avplay or VMMs) with UI controls. I think that this idea will 
fit Genode's capability-based component architecture like a glove.

[2] 
https://genode.org/documentation/release-notes/23.11#Dialog_API_for_low-complexity_interactive_applications

> FS optims:
> Maybe the one immediate item remaining on my Genode wish-list will be vfs related:
> Even if I'm in "reaping the fruits of past work" mode, there might still be one type
> of ticket I might file on github yet, related to FS xattr performance. Reading attributes
> in H/o-g is quite slow, maybe a couple dozen reads per sec. It's too soon to tell where the
> optimization potential is located though. Given the nature of the current xattr implementation
> (lots of back-and-forth between fs client and vfs server to process ad-hoc/virtual paths
> like /Station/Music/.PinkFloyd/.attributes etc) it comes to mind as a primary suspect, but
> gotta be careful to pinpoint accurately which part of which component is too slow and in need
> of optimization (on my side or on Genode's). It's easy enough to get lost in the weeds even
> for skilled devs, even more so for me 8-). My trip down that rabbit hole will probably
> begin in a few weeks or months, once the other ToDos are reasonably complete.

I'm with you on that. You already helped weeding out one performance 
issue [3] in the past, for which I'm grateful. We will surely get to the 
bottom of this one together as well.

[3] https://github.com/genodelabs/genode/issues/4603

Thank you again for the captivating write-up.

All the best!

Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth