Hi Christian,
given that we talk in person almost every day, the topics you
highlighted for 2026 are not surprising for me. :) I concur with
everything you wrote.
Let me only take the opportunity to continue the line of thoughts about
the bridges.
On 2025-12-29 14:18, Christian Helmuth wrote:
Regarding 2026, I'm impressed by the image of bridges connecting
Genode/Sculpt to worlds in the multiple dimensions Norman laid out.
Developing the capability-based desktop as paragon for enabling users of
all kinds to employ the core advantages of our technology is
electrifying.
I'm really glad that this image resonates so well. The longer I think
about it, the more enthusiastic I become because the topic gives room
for playful little projects like my recent exploration of Seed7. In the
back of my mind, I'm presently thinking of new ways how Genode could
augment existing projects.
For example, wouldn't it be fun to boot directly into an existing OS
(running in an emulator) with the config and report file systems exposed
to the guest OS? Not unlike a Dom0 in a traditional hypervisor
architecture, the existing OS could take over the role of Sculpt's
Leitzentrale. So Genode components besides the emulator could be managed
in a way that feels native to the existing OS. To the existing OS it
would bring two benefits: (1} support for all the hardware supported by
Sculpt OS, and (2) the use of arbitrary Genode components as a kind of
"plugin" for the existing OS. But the character of the existing OS is
fully retained.
One hypothetical example close to my heart would be booting directly
into TOS (or better, MagiC [1]). So one could turn any PC into an Atari
clone that boots directly into GEM in just a few seconds like in the
olden days. With Sculpt's config and report file systems accessible from
within TOS, a graphical GEM application (e.g. in the form of an
accessory) could allow the user to administer the Genode runtime by
merely monitoring the files in the report fs and writing the files in
the config fs. One could even go as far as letting this accessory play
the role of the window layouter of Genode components. So the user could
install the Falkon web browser that runs as native Genode component but
is hosted in a GEM window.
[1] https://forum.atari-home.de/index.php/topic,18379.0.html
The approach could potentially be applicable for RiscOS, or for Cedric's
HoG project [2], or SerenityOS [3], or SymbOS [4], or a hypothetical
Seed7 OS where all command-line tools run in the s7 interpreter, or for
or as a gateway for connecting QubesOS with Genode.
[2] https://chiselapp.com/user/ttcoder/repository/genode-haiku/home
[3] https://serenityos.org/
[4] http://symbos.de/symbosvm.htm
Well, I'm just sharing those thoughts as vague ideas. They are not
directly intended for the road map. However, the underpinnings needed
for unlocking those scenarios would be worth planning for:
* Splitting the *Sculpt manager into multiple components* so that
Sculpt's driver management and software management can be used
independently from the Leitzentrale.
* The VFS plugin for the GUI session I mentioned earlier would empower
any existing OS (given that it features a form of host-guest file-
system integration) to play the role the window decorator for Genode
components running besides the guest OS. That's certainly an
entertaining additional use case for the *GUI VFS plugin*.
* By consistently using HID syntax, custom tools running inside the
existing OS could control the underlying Genode system with plain
printf-like functionality (in any programming language) because the
format is so simple. Only for parsing HID, a library is needed.
To attain the broadest reach possible, a *HID parser written in C*
would be most valuable.
* By making the *VFS dynamically reconfigurable*, the existing OS could
be used to access files on, let's say, a USB stick when plugged in
without needing support for USB nor support for the file system used
on the USB stick. Those technicalities would be conveniently covered
by Genode.
I think these are four tangible items that deserve being part of the
road map.
Regarding the framing of our minds, our work with 3rd-party software has
been mostly motivated by extending the feature set of Genode for the
benefit of our users. Of course, this motive prevails, e.g. in the form
of Christian Prochaska's work with porting all tools of Genode's SDK.
Additionally to this motivation, however, I think it is worth asking how
Genode could contribute positively to existing projects by augmenting them.
Given the bridge metaphor with Genode at the one side and a peer project
at the other side, let's try looking at the bridge from the position of
the peer project.
Cheers
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
_______________________________________________
users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Archived at
https://lists.genode.org/mailman3/hyperkitty/list/[email protected]/message/W6C4D36MDBDKAMB6BK7FUADKGMNTRHII/
