Roadmap 2020

[John J. Karcher]

Looking back at your summary of 2019, it has been a great year!  I don't 
know how you guys accomplish so much in so many different areas. 
Congratulations and thanks to everyone on the Genode team!

I think your plans are right on target, and have enjoyed reading 
everyone else's ideas also.  I'm afraid I don't have much to add, but 
I'll throw out a few thoughts.

My main goals for the year are:

1. Migrate to Genode as my primary desktop
2. Focus on developing native components

In the context of #1:

- I don't know if others feel the same way, but I would feel more 
comfortable with a journaling file system (e.g., ext4) for important 
data.  (I have no idea how big of a task this is)

- I'd like to echo Stephan's items about the window manager handling 
large numbers of windows; I'd be curious to hear what the ideas are on 
this (multiple "workspaces" is the first thing that comes to my mind)

- Borrowing from Stephan again, porting an e-mail client would seem like 
a good way to get rid of a needless VM; if anyone works on this, I will 
be happy to be a tester

Regarding #2:

- To state the obvious, I will be avidly following the continuing 
adventures of Goa and genodians.org

- Like TTCoder, I am also very interested in your ideas for extending 
the GUI stack; even if I can't contribute much code, I will be happy to 
be an early tester


And just for curiosity, can you share any info on your Sculpt UI ideas, 
especially "Replacing Unix/Vim-based interface of the Leitzentrale with 
a graphical user interface"?

  Thanks again!

   John J. Karcher
   devuser at alternateapproach.com


On 12/27/19 8:33 AM, Norman Feske wrote:
> Dear Genode community,
> 
> the year 2020 is approaching, which prompts me to kick off the
> discussion of our road map for the year to come. Before drafting plans,
> however, I'd like to share my personal reflections of the past 12 months.
> 
> For the road map 2019, we picked "bridging worlds" as our guiding theme:
> (1) Lowering the friction when combining existing software with Genode,
> (2) Fostering interoperability with widely used protocols and APIs, and
> (3) Making Genode easier to approach and generally more practical.
> 
> With respect to (1), we identified Genode's custom tooling (build
> system, run scripts, ports mechanism, depot tools) as a point of
> friction. They are arguably powerful and flexible but require a lot of
> up-front learning. This is certainly a burden unacceptable for a casual
> developer without a black belt in Make and Expect/Tcl. The new Goa tool
> rearranges the existing tools in a way that puts the concerns of casual
> developers into focus, allowing for the use of commodity build systems,
> eliminating Tcl syntax from the equation, running sub-second test
> cycles, and streamlining the packaging of software.
> 
> On account of (2), we switched to C++17 by default, fostered the use of
> Java, updated Qt5, and put POSIX compatibility into the spotlight. We
> were eventually able to dissolve the need for our custom Unix runtime
> (Noux) because all features of Noux are covered by our regular libc now.
> 
> Our biggest step towards (3) is the https://genodians.org website we
> started in winter 2019, which gives individual members of our community
> an easy way to present thoughts, projects, and experiences.
> Complementing Genode's formal documentation, it also conserves practical
> tips and tricks that were previously not covered in written form.
> 
> When speaking of "bridging worlds", I should not forget to mention the
> tremendous effort to bring Sculpt-OS-like workloads to the 64-bit ARM
> world. Thanks to the added support for multi-core AARCH64,
> hardware-based virtualization, and network/USB/graphics drivers for the
> i.MX8 SoC, the flexibility of Sculpt OS will eventually become available
> on PC hardware and ARM-based devices alike.
> 
> Over the course of 2019, we admittedly skipped a few topics originally
> mentioned on our road map. In particular, the user-visible side of
> Sculpt OS received less attention than originally envisioned. We also
> deferred several ideas we had in mind about reworking our GUI stack.
> Instead, we expanded our work in the areas of storage (block-level APIs,
> test infrastructure, block encryption) and input processing. This shift
> of focus is mostly attributed to the priorities of Genode Labs'
> customers who fund our work.
> 
> 
> Drafting plans for 2020
> -----------------------
> 
> Hereby, I'll just present my personal interests and invite you to do the
> same. When carving out Genode's official road map for 2020 until mid of
> January, I will then try to condense all the input into a tangible plan.
> 
> Personally, I think that after "bridging worlds", it's time for "use,
> consolidation, and optimization".
> 
> - It is certainly too early to call Goa a success. In order to find out
>    if we are on the right track, I want to expose Goa to as many problems
>    as possible, primarily by the means of porting software.
> 
> - I'd love to pick up our ideas about Genode's GUI stack, accommodating
>    headless scenarios, multi-head, screen capturing, color depth, and the
>    ability to restart drivers.
> 
> - I have a huge backlog of ideas about the user-visible side of Sculpt
>    OS, which would make Sculpt OS more pleasant to use and much more fun.
>    E.g.,
> 
>    - Replacing Unix/Vim-based interface of the Leitzentrale with a
>      graphical user interface
>    - Making the Leitzentrale's layout more logical
>    - Keyboard-based navigation
>    - Context-aware on-screen documentation
>    - Settings embedded in the graph nodes of the runtime view
> 
> - I see plenty of opportunities for optimization throughout the entire
>    software stack. With the rich C runtime in place now, it becomes
>    easier than ever to stress the system from various angles, which is
>    a great motivator for optimization work.
> 
> - Genode's binary compatibility across a variety of kernels is a key
>    feature of the framework. I'd like to push it even further by unifying
>    the capability-space management among all the kernel platforms.
>    Such a consolidation would make Genode less reliant on the subtle ways
>    how edge cases are handled by each kernel (in-kernel data structures,
>    capability re-identification), and reduce the amount of kernel-
>    specific code to maintain.
> 
> 
> This is merely my personal point of view. Now I'm very interested in
> learning about your's! Please don't hesitate to share your perspective
> on the project, your priorities and plans, and topics you would
> anticipate most.
> 
> Cheers
> Norman
>