Hi Ben,
I very much appreciate your plans and suggestions. Thanks for chiming in!
On 24.12.18 20:22, Nobody III wrote:
*Desktop Environment*
I also see having a desktop environment as priority, and I have already made some progress in that direction. I have my plans along those lines, and if anyone wants to discuss details, I'd be happy to do so in another thread on this mailing list. However, I have run into some hurdles that I could use some help with. In particular, to enable easy IPC with libc-based applications, a named pipe (FIFO) VFS plugin would be extremely useful. I wrote one myself, only to discover that the VFS and File_system interfaces do not adequately support partial writes, as needed by such a plugin. With those interfaces reworked, I would happily modify and provide my VFS FIFO plugin code, as well as my Libc pipe plugin that uses it as the backend.
These are no fundamental show stoppers and I'm very hopeful that we can remove these limitations soon.
My other main technical hurdle for creating a desktop environment has been converting the init component into a library to allow for easy customization beyond what is possible through configuration files alone. The current method of writing a monitor component to read init's state and modify its configuration works fine for simple cases, but it has performance penalties that can range from mild to severe. The configuration parsing overhead grows with the number of child components, which isn't ideal, but the real show-stopper that I see is dynamic quota management. Each quota upgrade has to wait for a new report, and reports happen at regular intervals, usually every second. Thus multiple quota upgrades, e.g. from opening one or more new web browser windows/tabs can take several seconds. With an init library, such upgrades could be handled very quickly. I can handle this particular issue myself as soon as it becomes a high enough priority.
This is extremely interesting for me because I reached a similar conclusion while creating the user interface for the sculpt manager. In fact, I almost started working on the "librarization" of init in summer. I ultimately decided to defer this work to give it appropriate attention instead of rushing it.
Thanks for encouraging me. I will definitely put the "librarization" of init on the road map!
*Hardware Support*
Aside from a desktop environment, hardware support is another likely show-stopper for new users. I've been working on this myself, and hope to be able to make Genode/Sculpt usable on my new desktop computer in 2019. I accept that support for my hardware is mostly my issue, but improvements in debugging tools and documentation would help a lot with this.
I wonder, would any of these improvements be roadmap-worthy?
*Debugging*
As for debugging tools, I suggest building both remote (serial and/or (W)LAN) and on-screen GDB component debugging scenarios. This would help with many other goals, and might also help make Genode more attractive to developers.
This problem can probably be addressed in two stages. At the first stage, we should do a better job with documenting our existing time-tested debugging and development workflows that are used within Genode Labs. At the second stage, it may be cool to find a way of integrating our GDB monitor easily in Sculpt.
*Package Management*
I'd like to second and add to what ttcoder said about package management. It would be very helpful to provide a way for Sculpt users to discover and add depots. This would increase usability, and would encourage developers outside Genode Labs to write and port more software for Genode.
Currently, depots don't provide package or launcher lists. Ideally, I would like to see Sculpt have an option to fetch the latest launchers from the repositories selected by the user, allowing them to easily discover components. This would also fix the issue I've seen with Sculpt launchers expecting package versions only available locally on the build machine. Currently, when I modify a component used by Sculpt and update its recipe version, Sculpt expects my new version to be available from depot.genode.org. If a launcher list is fetched from the Genode Labs depot (possibly with a correct default launcher list provided in the Sculpt image), this problem will be solved.
These are all very good points. I definitely plan to improve Sculpt in this respect. It is not as simple as importing pre-defined launchers along with (potentially untrusted) depot content though. The launchers should always remain under conscious control by the user. Imagine a malicious depot provider that tricks the user into adding its depot along with a launcher that hands out the user's config fs to a package provided by the malicious depot provider. This could take over the whole system.
I think we can get a convenient experience with a graphical user interface that allows the user to select a package from a given depot provider and then interactively construct a launcher. I'll try this out in the next version of Sculpt. Let's see how you'll like it. ;-)
*Performance*
All current Genode scenarios (AFAIK), including Sculpt, run almost everything on a single hardware thread. An SMP balancing component would dramatically increase performance (and likely responsiveness) on modern multi-core CPUs. If nobody else gets around to it first, I'll probably write such a component, but if anyone else here more familiar with Genode's scheduling mechanisms is interested enough, they can probably write a much better implementation than I would.
That is certainly an interesting topic. For Sculpt, a good first step would be making init's affinity-managing feature available to the deploy configuration. This would give the user an easy way to explicitly assign workload to CPUs. Even though I see the balancing as a subsequent step, you may already start experimenting.
*Summary*
In short, I'd like to see the following things on the 2019 roadmap:
- Rework VFS and File_system interfaces to support partial writes, as
needed by FIFOs 2. Interactive local and remote GDB debugging scenarios for real hardware 3. Depot and Launcher discovery for Sculpt 4. SMP balancing component 5. Improved documentation
That's a very good and realistic list. Thank you for breaking down your requirements to these tangible goals.
We don't all see eye-to-eye on how a desktop environment should operate, so I'm particularly interested in getting help with (1) so I can make more progress on writing my own, and with (3) so I can make it easily available so others can try it out and give me feedback.
I wholeheartedly agree and look forward to this phase of experimentation.
Cheers Norman