Hi Ben,
thanks for sharing your thoughts!
From my understanding, the fastest way to start a subsystem in the Sculpt scenario is to type the XML start node into one of the config files. If instead, I could just type something like "start vbox_linux" into bash, I would be much more inclined to put Sculpt on my laptop, like I did with Turmvilla.
The Sculpt scenario is meant as a starting point. Right now, the user has to edit files per hand or juggle copies of modified files. Of course, these actions could alternatively be done by a program that covers typical usage patterns like starting a program, connecting to wifi, adjusting mixer settings, etc. Technically, such a program is just automating the steps a user would manually take with Sculpt: It consumes the system state (by looking at reports) and generates XML configurations for components and dynamic subsystems.
Actually, this approach is already at play. The device-driver discovery is managed by the program gems/src/app/driver_manager. Another example is the forthcoming depot-download subsystem at my 'depot_download' branch. Here the so-called download manager dynamically orchestrates 'fetchurl', 'extract', and 'depot_query' components without doing any actual work by itself.
I envision the desktop environment to provide a set of management components along with a set of minions that do the dirty work. An example for the latter is the file-identifying component you just discussed. The manager component spawns, respawns, configures, and discards its minions via a dynamic subinit as needed.
Sculpt should not be understood as an alternative to a desktop environment but rather as a suitable underlying foundation. A desktop environment will be one scenario (out of potentially many) a user can select to run on top of Sculpt. At the end of 2018, this vision should hopefully become within close reach.
Also, improved hardware support would be very nice. I have run into various issues in the past, and I'll bring them back up if I still have problems getting Genode to work on my computers. But even if all of the bugs have been resolved, we still don't have an AMD framebuffer driver, or a NVIDIA driver for that matter. For people like me who have high or non-standard monitor resolutions, being stuck with the VESA driver is rather annoying. I'm not sure whether these display drivers should be ported in 2018 or some later year, but they should definitely be ported sometime in the next few years.
I have mixed feelings about this. With Intel-based systems, we got the most popular hardware covered now, which was quite a feat - in particular when looking at wifi and GPU topics. Supporting also hardware that is less wide spread implies tremendous additional work while benefiting not so many new users. But more importantly, it does not open up new use cases. So it is intellectually less rewarding compared to other topics. There must be a strong commercial incentive or an intensive community effort to make it happen.
We had porting a modern web browser on the roadmap back in 2015, but that never happened, AFAIK. This might be worth pursuing again.
That's true. But I see no one willing to pick it up right now. For the foreseeable future - at least for the next year - I see us using a commodity browser in a VM, or a simple custom Qt5-based browser for browsing the leaner sites of the web.
- We have started using a package manager (depot), but we need more
recipes, especially for ported libraries such as Qt 5.
- Many run scripts are outdated. Most still need to be updated to use
depot packages, and many don't work anymore due to recent changes such as cap quotas. We need to update the run scripts and verify that they all work.
(* = high priority)
I wholeheartedly agree!
Cheers Norman