Roadmap 2016

Norman Feske norman.feske at ...1...
Mon Jan 11 10:40:23 CET 2016

Hi Vladimir,

thanks for your participation in the discussion!

> Obviously the above is not an invitation to schedule more things into
> the Genode Labs diary about writing more tutorials, but rather to start
> a discussion about what people think needs to be done in this area and
> perhaps some volunteers can step up (I am certainly happy to write about
> my experiences with the USB Armory for example when I get the USB driver
> to finally work).

I very much appreciate your stance. We at Genode Labs will try to do our
share to provide such tutorial-like material. But to reach a wider
audience, we ultimately need a community effort by multiple independent
people publishing opinions, tutorials, and testimonials. For example,
right now, Genode is almost unknown to the HN crowd. If I posted
submissions about Genode (like release announcements), this would count
as shameless self-promotion. It would be different if such information
were spread by people outside the group of core developers.

> Some DSL for modelling larger state machines is definitely going to
> prove useful, though whether one should be adopted as part of Genode is
> debatable (will servers really be that huge?). I have seen state
> machines with 10s of states and many hundreds of transitions and it does
> become difficult to reason about them purely because you cannot keep
> them all in your head. I personally would prefer a custom textual DSL
> which is easy to see and edit in vim, but there are obviously many
> approaches out there.
> <> looks interesting as another idea
> of how to approach this problem (have not used it)

I 100% share your sentiment. Thanks for the pointer to mbeddr.

> ## A shell
> It would be really neat to have a small shell where you can change the
> system on the fly. I guess it would be similar to the graphical launcher
> in some respects, though I imagine some configuration could also be
> changed directly instead of having to fire up a text editor.

May the existing CLI monitor (os/src/app/cli_monitor) serve as a
starting point? This is what I am currently using in the Turmvilla scenario.

> Any
> scripting language would do, perhaps Python or Lua (so it would need a
> small binding and then creation of an API). Then it would be a good
> show-case of, say, configuring an IP address (and a new bit of hardware)
> in Genode vs. Linux. (Maybe, that's just the first idea that came to mind).

Since I switched to Turmvilla, my perspective on those kind of
management problems has changed a bit. I routinely carry out most
configuration tasks by merely editing (or copying) files, which is super
simple compared to the zoo of configuration interfaces (and the
corresponding tools) known from Linux. I don't think that it can get
much more convenient and flexible than that. If we meet at FOSDEM, I'll
show you what I mean. ;-)

In principle, thanks to Noux, it is possible to use any existing
text-processing solution for automating configuration tasks as long as
it can produce XML. In my opinion, a standardization or a new API is not
needed at that end.

We actually ported Lua and Python to Genode some years ago and intended
to use either of both for scripting / automated testing purposes. But so
far, these ports remained largely unused.

> In terms of software I would like to see ported:
>  * tor
>  * rust language
>  * pf (*sounds difficult)
>  * zeromq
>  * node
> (I would like to take on Rust, as projects like
> or the newly announced
> <> are surely going to get
> some following this year).

Great that you plan to look into Rust on Genode! Would you like to see
this point mentioned in the road map?

>  * Disk encryption would be very useful in actually having a
> production-like desktop example! (Is the rump based cgd still working fine?)

The rump-based CGD is still supposed to work but we don't use it in
practice. Personally, I think that the rump-based solution is overkill
for the simple task of encrypting blocks. Hence, I'd like to include a
low-complexity block-encryption component in the road map.


Dr.-Ing. Norman Feske
Genode Labs ·

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

More information about the users mailing list