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 -- 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 [email protected] https://lists.genode.org/listinfo/users
