Roadmap 2018

[Norman Feske]

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

-- 
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