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, ttco...@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
_______________________________________________
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users
