John J. Karcher
devuser at alternateapproach.com
Sat Jan 4 02:25:00 CET 2020
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
- 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"?
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.
> - 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.
More information about the users