Roadmap 2024

[ttcoder at netcourrier.com]

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. 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)

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.

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.

Future/miscellaneous/"stream of consciousness":
- now that things are calming down at my end I'm going to resume my DFS (depth first search)
  'walk' of the Genode source tree started a few years ago, and interrupted much too quickly/early ^^.
  I want to create a mental map of it, pick up things of interest. This also ties in
  with my wish to migrate my computing to Genode. If it's a given that Genode has 'all the right stuff'
  then it'd be a matter of transferring all my use-cases to Genode one by one, working on
  each case when I hit bumps. And that'll be easier if the required features/hooks/APIs
  inside Genode present themselves to me sequentially ("for each Genode bit: how can I use it ?"),
  rather than go the other way around ("foreach thing I need: try to hunt for it in the
  documentation or in the source code").
  You guys are super diligent and ruthless in removing "dead wood" from the tree (oooh the mixed metaphor),
  so "walking the (christmas *g*) source tree" always had lots of appeal to me.
- 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.
- 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.
- 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.

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.

So to sum up,
december was a solid start for my personal "daily driver" goal, the moment of truth's
coming for my commercial stuff as we're going to probe/survey customers,
and I might start a ticket or discussion re. fs optimization but I can't
say yet what the specifics will be.

Here's to a productive new year to all genodians,

Cedric