Roadmap 2019

[Norman Feske]

Hi Guido,

thank you for the elaborate and insightful response.

I'm very sorry to hear the fate of your eccentric-authentication project
as I still vividly remember your enthusiasm about it. Hopefully, it's
not buried but only temporarily suspended.

> Now about your goals and questions:
> 
>> 1) Widening the audience of Sculpt OS
>> Consequently, we should improve its ease of use.
> 
> For me a 1000 times this.
> 
> To me, the learning curve of Genode is steep. The learning curve of
> (changing) Sculpt is steep too. Although I know most of the concepts of
> the platform, I find it still hard to develop in. Lately I went deep
> into changing the configuration of Virtualbox in Sculpt. What should be
> a few hours took me more than a week. And the result was still hacky :-(

Hats off for trying! You certainly went outside the designated (and
documented) scope of the current version, which is impressive. Your
feedback is valuable for planning the upcoming improvements of Sculpt.

> Although there are many examples, I'd like to see them listed from
> simple to complex, each explaining a concept of Genode, builing on top
> of the previous ones. It could grow into a Genode for Dummies.

This raises an interesting question: Should we prioritize documenting
the use of Sculpt or the use of Genode?

The former would look only at the building blocks (but not inside them).
Such documentation can be in the form of light-hearted and practical
use-case anecdotes, which are fun to read and immediately applicable by
Sculpt users without any programming. It also takes a few complicated
topics like the build system or the run scripts out of view.

The latter would come down to a review and description of existing
run-script scenarios, which is probably less rewarding but more valuable
for people who want to go deeper below the surface of Sculpt.

Intuitively, for capturing a larger audience, I'd first put the focus on
use cases based on Sculpt.

> Other wish: please describe how I can enable all kinds of debugging
> modes. For example, when I make a XML syntax error in an init.config,
> the app doesn't start but the log remains quiet.
> 
> Other example, at one point I added printf-logging to init-components to
> trace the routing decisions so I could check that my config was correct.
> It would be great if there was a config option for that.

That's an interesting information because it does not overlap much with
my personal experience. Making init (optionally) more verbose would be
no problem at all. I just need to know which kind of verbosity is
actually helpful. So your experience can guide us here.

>> 2) Fostering the community spirit around our project
> 
> I think you have a nice (but small) community already, with your team
> ready to answer any question quicky. Just keep doing that.
> 
> You've seen my recent write-up on adding a raw partition to virtualbox
> in Sculpt. I thought of making it a blog so others can learn from it
> too. (I'm not sure if that example makes a nice showcase of the ease of
> Sculpt :-).

The blogging topic popped up also in the other responses. So let me
prematurely leak some information about a concrete idea in this respect:

We plan to start a kind of federated microblogging platform around
Genode called "genodians.org", which enables everyone interested in
Genode to publish posts. The content will be hosted at individual git
repositories and remains completely under control and ownership of each
individual author. The site merely aggregates the content from a list of
authors and takes care of the layout and style. This will give Genode
developers and users an easy way to share insights and experiences. For
discussion, each posting will be equipped with a reddit-submission link.

It goes without saying that the site will be hosted on Genode.

If you like, you can already have a peek here:

  https://github.com/genodelabs/genodians.org

Would you find the participation in such a federated publishing platform
attractive?

>> * Which areas of Genode would you like to see improved?
>>    How would you possibly contribute to these improvements?
> 
> Documentation. (I'll tell you my struggles, you improve the docs).

:-)

>> * If you imagine a Genode-based system one year in the future,
>>    how would it look like?
> 
> My long term dream is Genode on a Desktop.
> 
> It has a desktop UI interface, double clicking opens an application in a
> sandbox. The application has only access to its dependencies and
> resources like fonts, etc.
> 
> However, the application does not have access to the user's files,
> email, etc., not even network access. It the user wants to open a file,
> the sandbox detects the application opening a file-browser and an
> attempt to read /home/<user> and opens a Powerbox. The powerbox is a
> trusted part of the OS that lets the user select one or more files. Only
> these are the files that the application can read. (The powerbox is
> described in HP-Labs paper [1] and other capability security papers on
> the net).

The desktop is a recurring topic, also highlighted by Ben and Cedric.

I'm probably too opinionated about user interfaces to be very helpful
here. So it might take multiple people with different ideas to find a
solution that is attractive to actual end users.

As an example for my opinionated view, I remain unconvinced about the
powerbox paradigm. Since the file selector (aka powerbox) is triggered
by the application, I'm afraid that the user ends up with the mental
model that the file selector is part of the application. From the user's
subjective view, the application seems to see all the files. In my
opinion, the concept is similarly flawed as the UAC mechanism in Windows
OS where the software - not the user - decides when an authentication
popup dialog is smashed into the user's face. I would much prefer a
user-interaction model where the user - not the application - takes the
active role. E.g., delegating capabilities via drag-and-drop or your
example with spawning a view for a clicked-on file supports the mental
model I'm after.

As another indicator for my unfitness for creating a desktop
environment, whereas I very much appreciated desktops of old lore like
Jinnee (on Atari), BeOS, and RiscOS, for some reason, I tend to avoid
interactive desktop applications of today. I spend almost all my time on
the command line.

Regarding technicalities like the choice of the toolkit, I
wholeheartedly share Cedric's sentiment. Qt is established and powerful.
But it's also huge and conservative. With the menu-view approach that I
use in Sculpt's Leitzentrale, I enjoy exploring a very different idea.
So for my own work, I'd love to follow this unconventional direction.
But for building a desktop for Genode, my spleens might just stand in
the way.

To sum it up, for pursuing a desktop for Genode in the foreseeable
future (the upcoming year), someone other than me should better take the
lead.

>> * Do you have further ideas that would help making Genode relevant
>>    at a larger scale than today?
> 
> Since you ask about my Santa list :-)
> 
> Make it easy (both in documenting) and code support to port exisiting
> Linux or Windows software to Genode. It could be a preconfigured Noux
> instance that provides just enough to start the application. It needs
> /usr, a bit of /etc, a private var and a powerbox to /home/<user>. It
> needs a NIC environment with a configurable ingress and egress firewall.
> 
> Make it easy for an end-user to create separate of these sandboxes for a
> single application, so the user can create separate mail-readers for
> private mail, office mail, etc.
> 
> It should be easy to port and effortless to upgrade. Upgrades should be
> build automatically by a build server so a small number of people can
> manage a large set of programs. I'm thinking user application such as
> libreoffice, gimp, photo, video, audio, bookkeeping. Software that
> doesn't need linux kernel access, drivers or distribution packaging
> specific things.
> 
> I love to run a mail-stack consisting of server programs such as
> postfix, dovecot, spamassissin, DNS-servers, DNSSEC signers, etc on Genode.

This is a very sensible wish list. Most items come down to removing the
friction of porting existing software to Genode. This supports the
importance of our SDK. I also agree that the application management you
mention is very important.

Regarding the creation of a central build infrastructure, I'm afraid
that we won't be able to accommodate you in 2019. I'd rather prefer
distributing the responsibility of packages among individual contributors.

Thank you again for the very thoughtful and thought-provoking posting!

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