Hi Emery,
As for concrete goals for next year, I have one laptop that I use exclusively with Sculpt, but I also have a NixOS VPS that I use as my always-on OS. Therefore I would like a headless Sculpt that I can use remotely. For this to happen I would imagine a nested sculpt_manager so that I could share the same machine with friends, a Curses-like implementation of menu_view, and some secure networking tunneling.
headless Sculpt is a tempting idea. AFAIK, Christian and Sebastian already took steps into the same direction. I'm looking forward to see what you will come up with.
Its my perception that the greatest impedement to new users and contributers is the singular C++ system API. Perhaps additional Sculpt shells could be implemented in interpreted languages such as Python or Lisp. I've known a few "power-users" that would appreciate booting into their favorite language intepreter, but couldn't care less about how to use Bash. Python seems the surest choice, the digital artists I know work with Python and there was a time when I used IPython daily.
Support for languages other than C++ seems to be crucial for a wider adoption. This was the primary motivation behind the added JAVA support. Also, Johannes' port of Python3 could be leveraged. Language-wise, I sense interest in Go and Javascript (V8) from potential Genode users.
As another idea, with GDC having just become official part of GCC, D could be supported quite easily with the next update of Genode's tool chain. Since I sympathize with D for a long time, I would really like that. It would give me a good excuse to pick up this language more. ;-)
[1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=265573
With the goal of Genode adoption, I think the most sensible approach would be supporting such languages on top of Genode's POSIX layer. This way, we could satisfy most use cases without the need for bindings to Genode's native API (which would be a lot of work, for each language).
When speaking of functional languages, you mentioned lisp. But given your work on MirageOS, wouldn't OCAML be a more obvious choice?
As for my personal roadmap, in the past few weeks I've begun work on a distributed non-hierarchal storage layer. The intention is to support a subset of the de facto file-system semantics with quick composition using the formalism of set logic. This is a pivot of my roadmap from a year ago and reuses code and ideas from another storage project of mine, so progress is swift. The use-case is distributed and redundant storage for things like my permanent music collection as well as the package depot.
Is this a topic you'd like to see reflected on the official road map?
Thanks Emery for the fantastic year of sculpting we had together!
Cheers Norman