My first thoughts on this are as follows: 1. I would love to use Genode as my primary OS, but I have been unable to make sufficient progress for any of my computers. The older ones don't have AHCI support, Genode's hardware support for my custom desktop computer is severely limited, and I don't even have any idea what's not working on my laptop because I haven't been able to get AMT to work. If you can add support for an alternative method of getting debugging output (or somehow support my desktop computer's motherboard) then I would happily try again to setup my own Turmvilla-like Genode system. 2. Cross-kernel binary compatibility would be great, especially since I find myself switching kernels for debugging purposes. 3. A Tails-like system would be awesome. According to Snowden, the NSA's main method of spying on Tor users is by compromising the Tor browser. 4. I would love graphical configuration utilities, but I would consider them a much lower priority than improved hardware support. I could make my own utilities, but I would need a lot of help getting Genode to support my hardware. On Dec 22, 2015 5:30 AM, "Norman Feske" <norman.feske@...1...> wrote:
Hello,
the end of the year 2015 is approaching. So it is time for planning our activities for the upcoming year. I plan to finalize the roadmap until mid of January. Hereby, I'd like to kick off the discussion. It goes without saying that everyone of you is invited to join in!
Before I come to my suggestions for 2016, let me briefly revisit the outcome of the roadmap for the past year. One year ago, I suggested three main topics to work on, namely the use of Genode as general-purpose OS, the advancement of our custom base-hw kernel platform, and the use of the seL4 kernel. In the discussions following my posting, many further points were raised, most prominently the need for through documentation, package management, and a sustainable quality of the base system in terms of stability and performance. In top of that, we received quite a few wishes of higher-level functionality such as a modern web browser or other typical desktop-computing features. Of course, we were not able to address all those topics but I am overly happy that we reached the point where a hand full of us (including me) are using Genode as their day-to-day OS. When I initially switched to using the Turmvilla scenario [1] at the end of May, the experience was admittedly a bit painful. But now, just a few months later, the beauty of the system becomes apparent as all the pieces come so nicely together. The performance, stability, and device-driver support have reached a level that leaves people impressed every time I have the chance to show off my system. Once people become interested, there is now the book available, which provides a smooth introduction into Genode. The feedback I receive about the book is overwhelmingly positive. So we did something right in 2015. :-)
After having passed the point where a few of us are able to use Genode as day-to-day OS, we should put the emphasis of the upcoming year on ways to make Genode accessible for a wider community. In a recent posting [2], I identified two possible ways to do that. The first way would be publishing a series of step-by-step guides that explain how to put Genode components together in order to create custom system scenarios. Those articles could be accompanied by screencasts or live-system images. Example scenarios could be the Turmvilla scenario, building a home-computer-like system for kids using the Raspberry Pi (like the Genode system my kids are using), building a network appliance like a data diode, tinkering with the USB Armory, etc. Those articles should be inviting to people who enjoy the building of systems. The second way would be to showcase a system with practical value to end users. I am thinking along the lines of a disposable OS like Tails that allows the user to browse the internet via the Tor network. But that is just an idea.
In this spirit, I propose the overall focus of 2016 to be: Let us make Genode accessible to the world outside the inner circle of us enthusiasts.
On a technical level, this motive implicates the following topics:
The deployment and management of Genode systems, i.e., by bringing forward Emery's work on the Nix package manager. This direction also reinforces the need to achieve binary compatibility between the various base platforms to make the distribution of binary packages, reproduceable builds, and continues test-and-integration scalable.
Supplementing Genode with user-friendly means to configure the system (e.g., wireless network, audio, display settings). Right now, I use Vim as configuration front end, which is cool, but also intimidating to less technical-minded users.
Accommodation of common desktop use cases like plugging in a USB stick to work with the files stored on it. Also disk encryption comes into mind.
Optimization of Genode for the use on a laptop, e.g., addressing fan control, power management, suspend/resume, and similar features.
There are also other possible avenues to support the stated goal:
Identifying ways of how Genode could play a role in related projects like Qubes OS. For example, we could promote the use of Genode as a tool for building App VMs as Qubes subsystems. Granted, this scenario leaves the architectural benefits of Genode with respect to its small TCB complexity unused as Qubes still relies on Xen, and Linux as Dom0. But Genode would still (possibly) provide value to the Qubes project. Maybe, there would be the prospect to replace Dom0 with Genode in the longer term? However, to drive this direction of work, we would certainly need someone who is actually using Qubes and has the natural incentive to work on such an integration.
Making Genode-based systems easily deployable on Amazon's EC2. Similar to the previous point, it would be beneficial to have someone working on this topic who is naturally interested in cloud computing.
Foster the cross-pollination of the seL4 and Genode communities. I got enthusiastic responses about my seL4-related work. There is definitely a strong interest in this kernel and a growing anticipation for formally verified software. Today, seL4 lacks a scalable user-level architecture. This would be the perfect place where Genode could step in. Genode would ultimately allow the seL4 community to move beyond static system scenarios.
Assuming that we succeed in drawing the attention of a broader audience to our project, we should make sure that Genode's API won't undergo major changes soon after this point. Today, I still see a number of deficiencies in the current API. In the past year, we successively moved to a new model of the API (dubbed server API) that promotes the construction of components as state machines rather than procedural programs. All recent components are designed in this style to the great benefit of their robustness. We should finally promote this style towards the base API and get rid of some mistakes we made in the past, in particular the reliance on side effects by using the globally visible Genode::env. I think that we should finalize this API renovation until the mid of 2016. This will also be right the time for updating the Genode book.
These are my thoughts about the upcoming year. Now I am curious about yours! :-)
Cheers Norman
[1] https://github.com/genodelabs/genode/issues/1552 [2] https://github.com/genodelabs/genode/issues/1000#issuecomment-161260312
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main