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.
http://mbeddr.com http://mbeddr.com/ 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 https://github.com/redox-os/redox or the newly announced https://robigalia.org https://robigalia.org/ 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.
Cheers Norman