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
A simple improvement that I would love to see in leitzentrale is the ability to create launchers from the GUI.
Aside from that, with the recent changes to libc, has QProcess been enabled in Qt5? Because that's perhaps the biggest remaining issue in porting existing Qt software, if the new SDK solves the qmake-related problems.
On Fri, Dec 27, 2019, 6:33 AM Norman Feske norman.feske@genode-labs.com 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
-- 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
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hey Ben,
On Sat, Dec 28, 2019 at 17:08:45 CET, Nobody III wrote:
Aside from that, with the recent changes to libc, has QProcess been enabled in Qt5? Because that's perhaps the biggest remaining issue in porting existing Qt software,
AFAIK nobody looked into this over the last year but as QProcess just depends on fork() the initial situation is much better now with native fork support. I'd say, just give it a spin and some debugging.
if the new SDK solves the qmake-related problems.
IMO this much depends on future efforts to separate Qt5 from the Genode sources and build Qt5 projects with the natural tools like Qmake and Cmake based on Goa.
Greets
Hello Genodians,
My 2020 project will be building a NixOS-like OS around Genode OS. Its something I tried a few years ago but never completed, but now I am resolved that it is the best way to scale up Genode.
I can't do it alone, so if such a project interests you, please contact me off-list. There is a lot of work to do but at least the following are complete: - An LLVM-8 based toolchain - A x86_64-genode Nixpkgs stdenv. It builds native Genode components and will evaluate most of Nixpkgs, but a strategy is missing for automatically patching projects that use GNU autotools. - Functions for building and testing bootable ISOs - An initial NixOS module for booting Genode subsystems as systemd services. - Pre-packaging of depot binary archives. - Dhall as an alternative configuration language
The current sources are held here: https://gitea.c3d2.de/ehmry/genodepkgs https://gitea.c3d2.de/ehmry/nixpkgs https://gitea.c3d2.de/ehmry/genode
Cheers, Emery
P.S.
There is a another project that packages Genode with Nix, but I haven't tried it yet: https://github.com/blitz/genode-nix
Hi Emery,
it's interesting to see the direction you are taking.
My 2020 project will be building a NixOS-like OS around Genode OS. Its something I tried a few years ago but never completed, but now I am resolved that it is the best way to scale up Genode.
Since I'm not a NixOS user, I admittedly struggle a bit to see the picture. From your posting, I take that the quality of Genode's POSIX support looks very important for your endeavor. This is very much in line with my goals. Apart from that, your direction seems to be rather complimentary to Genode's road map.
I can't do it alone, so if such a project interests you, please contact me off-list.
From my point of view, you are very welcome to use the list. The topic
is Genode-related after all. I think that the subscribers won't be bothered.
Cheers Norman
Hello & a happy new year to all of you,
my personal interests list to Genode's 2020 roadmap is:
* A more sophisticated window-manager incarnation for Sculpt
I use several virtual-machines aside, as well as noux shell, pdf-viewer, battery-applet, and top-view. At last, it became unmanageable to use all these windows overlapping each other, and without a feedback when switching in between.
* Performance optimization
As Norman already pointed out, now it is a good time to enhance overall performance for certain scenarios. Especially, I would like to use Genode for editing source-code and interact with git. The latter certainly needs some care to be usable with repositories of reasonable size. In a second step, compiling Genode components within Genode in comparable time would be nice as well.
* Mail client
We had this plan already in the past. I definitely would like to get rid at least of one virtual-machine currently used for mails. A good target to use the new Goa tool to port all necessary third-party tools.
* ARM platform driver for i.MX8
We now have a bunch of drivers available for i.MX* processors, but they have to be compiled for the corresponding board and configuration. Moreover, a dynamic form of power and clock settings for the corresponding devices is missing. Dynamic recovery of devices available via PCIe is missing too. Aligning the concept of the platform driver for x86 with the needs of modern ARM devices like the i.MX8 series would be nice. Especially, when using Genode in a mobile context.
* Sculpt OS on ARMv8
We already have a lot of features enabled to run a Sculpt OS scenario on ARMv8, but there are still some minor things missing like a Virtio block model in our new ARMv8 VMM to run Linux VMs inside. In the end, I would love to use Sculpt on a MNT Reform [1].
Those are my thoughts regarding the upcoming roadmap. I'm curious about the further discussion.
Best regards Stefan
On Fri, Dec 27, 2019 at 02:33:38PM +0100, 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
-- 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
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi, I'm just an outside observer with no skin in the game and no affiliation with any project or product, but I am a Linux user and I am looking at this window/file manager: http:eaglemode.sourceforge.net www.youtube.com/watch?v=G6yPKQt3mBA
Sent from Yahoo Mail on Android
On Wed, Jan 1, 2020 at 9:25 AM, Stefan Kalkowskistefan.kalkowski@genode-labs.com wrote: Hello & a happy new year to all of you,
my personal interests list to Genode's 2020 roadmap is:
* A more sophisticated window-manager incarnation for Sculpt
I use several virtual-machines aside, as well as noux shell, pdf-viewer, battery-applet, and top-view. At last, it became unmanageable to use all these windows overlapping each other, and without a feedback when switching in between.
* Performance optimization
As Norman already pointed out, now it is a good time to enhance overall performance for certain scenarios. Especially, I would like to use Genode for editing source-code and interact with git. The latter certainly needs some care to be usable with repositories of reasonable size. In a second step, compiling Genode components within Genode in comparable time would be nice as well.
* Mail client
We had this plan already in the past. I definitely would like to get rid at least of one virtual-machine currently used for mails. A good target to use the new Goa tool to port all necessary third-party tools.
* ARM platform driver for i.MX8
We now have a bunch of drivers available for i.MX* processors, but they have to be compiled for the corresponding board and configuration. Moreover, a dynamic form of power and clock settings for the corresponding devices is missing. Dynamic recovery of devices available via PCIe is missing too. Aligning the concept of the platform driver for x86 with the needs of modern ARM devices like the i.MX8 series would be nice. Especially, when using Genode in a mobile context.
* Sculpt OS on ARMv8
We already have a lot of features enabled to run a Sculpt OS scenario on ARMv8, but there are still some minor things missing like a Virtio block model in our new ARMv8 VMM to run Linux VMs inside. In the end, I would love to use Sculpt on a MNT Reform [1].
Those are my thoughts regarding the upcoming roadmap. I'm curious about the further discussion.
Best regards Stefan
On Fri, Dec 27, 2019 at 02:33:38PM +0100, 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
-- 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
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Correction: http://eaglemode.sourceforge.net/
Sent from Yahoo Mail on Android
On Wed, Jan 1, 2020 at 12:32 PM, Dave Springerdavid_springer_56@yahoo.com wrote: Hi, I'm just an outside observer with no skin in the game and no affiliation with any project or product, but I am a Linux user and I am looking at this window/file manager: http:eaglemode.sourceforge.net www.youtube.com/watch?v=G6yPKQt3mBA
Sent from Yahoo Mail on Android
On Wed, Jan 1, 2020 at 9:25 AM, Stefan Kalkowskistefan.kalkowski@genode-labs.com wrote: Hello & a happy new year to all of you,
my personal interests list to Genode's 2020 roadmap is:
* A more sophisticated window-manager incarnation for Sculpt
I use several virtual-machines aside, as well as noux shell, pdf-viewer, battery-applet, and top-view. At last, it became unmanageable to use all these windows overlapping each other, and without a feedback when switching in between.
* Performance optimization
As Norman already pointed out, now it is a good time to enhance overall performance for certain scenarios. Especially, I would like to use Genode for editing source-code and interact with git. The latter certainly needs some care to be usable with repositories of reasonable size. In a second step, compiling Genode components within Genode in comparable time would be nice as well.
* Mail client
We had this plan already in the past. I definitely would like to get rid at least of one virtual-machine currently used for mails. A good target to use the new Goa tool to port all necessary third-party tools.
* ARM platform driver for i.MX8
We now have a bunch of drivers available for i.MX* processors, but they have to be compiled for the corresponding board and configuration. Moreover, a dynamic form of power and clock settings for the corresponding devices is missing. Dynamic recovery of devices available via PCIe is missing too. Aligning the concept of the platform driver for x86 with the needs of modern ARM devices like the i.MX8 series would be nice. Especially, when using Genode in a mobile context.
* Sculpt OS on ARMv8
We already have a lot of features enabled to run a Sculpt OS scenario on ARMv8, but there are still some minor things missing like a Virtio block model in our new ARMv8 VMM to run Linux VMs inside. In the end, I would love to use Sculpt on a MNT Reform [1].
Those are my thoughts regarding the upcoming roadmap. I'm curious about the further discussion.
Best regards Stefan
On Fri, Dec 27, 2019 at 02:33:38PM +0100, 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
-- 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
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
---- Message d'origine ----
De : Stefan Kalkowski stefan.kalkowski@genode-labs.com
- A more sophisticated window-manager incarnation for Sculpt
I use several virtual-machines aside, as well as noux shell, pdf-viewer, battery-applet, and top-view. At last, it became unmanageable to use all these windows overlapping each other, and without a feedback when switching in between.
I'm tempted to add my 'vote' for implementing features addressing this, as a mid-term goal : In my daily use I just can't get anything done without a good implementation of "workspaces". There are more features used for organizing a desktop of course, like a "task bar" ..etc. But implementing multiple workspaces (virtual screens) has a surprisingly far reaching impact on applications, and thus might need careful planning.
E.g. here's the number of references in the API (just the header files alone) in the workspaces implementation I'm used to working with: /boot/system/develop/headers/os> grep -Ri workspace | wc -l 38 Those span classes related to windows, of course, but also application classes, deskbar/taskbar related classes ..etc.
And even that implementation, as hi-speed-low-drag as I find it, could still be considered incomplete. There are lots of behavioral questions to be adressed when implementing workspaces : what if an application is activated, yet its window is in a workspace /other/ than the one currently facing the user : should that other workspace come into focus, or to the contrary, should the application window's be "warped" into the current workspace? Or should that behavior be user configurable, rather than hardcoded ? Lots of questions like that.
Genode's philosophy seems to be "don't deny complexity, but organize it". So it would be an interesting challenge: would implementing workspaces entail big changes in nitpicker? in wm? How to reconcile the need for a low number of source- code lines, with the need for additional, complex features -- it might justify offering several w.m.'s (which I think is already the case), of varying degrees of complexity, so that users have a choice between high reliability (but somewhat restricted) wm's and more feature-rich wm's implementing workspaces, at the expense of possibly more bugs.
Cedric
Hi Cedrik,
Genode's philosophy seems to be "don't deny complexity, but organize it". So it would be an interesting challenge: would implementing workspaces entail big changes in nitpicker? in wm? How to reconcile the need for a low number of source- code lines, with the need for additional, complex features -- it might justify offering several w.m.'s (which I think is already the case), of varying degrees of complexity, so that users have a choice between high reliability (but somewhat restricted) wm's and more feature-rich wm's implementing workspaces, at the expense of possibly more bugs.
the design of the existing architecture (nitpicker + wm + layouter + decorator) already anticipates these concerns but the current version of Sculpt still hides this potential somewhat. I remained rather low-key about it because we had to nail down other (non-GUI) aspects of Sculpt first.
The current architecture already has the right hooks for implementing a rich feature set, including workspaces or a panel. It's just a matter of using (and possibly refining) those hooks. During 2020, I plan to put the GUI architecture more and more into the spotlight, possibly via a couple of Genodians articles.
The dual-head support is a different topic though. This one calls for non-trivial interface and architectural changes.
Cheers Norman
On 1/17/20 7:48 AM, Norman Feske wrote:
Hi Cedrik,
Genode's philosophy seems to be "don't deny complexity, but organize it". So it would be an interesting challenge: would implementing workspaces entail big changes in nitpicker? in wm? How to reconcile the need for a low number of source- code lines, with the need for additional, complex features -- it might justify offering several w.m.'s (which I think is already the case), of varying degrees of complexity, so that users have a choice between high reliability (but somewhat restricted) wm's and more feature-rich wm's implementing workspaces, at the expense of possibly more bugs.
the design of the existing architecture (nitpicker + wm + layouter + decorator) already anticipates these concerns but the current version of Sculpt still hides this potential somewhat. I remained rather low-key about it because we had to nail down other (non-GUI) aspects of Sculpt first.
The current architecture already has the right hooks for implementing a rich feature set, including workspaces or a panel. It's just a matter of using (and possibly refining) those hooks. During 2020, I plan to put the GUI architecture more and more into the spotlight, possibly via a couple of Genodians articles.
The dual-head support is a different topic though. This one calls for non-trivial interface and architectural changes.
Can you give a quick overview of what changes might be required for this?
Not having looked into the APIs, I would assume that having different workspaces on different displays would fit nicely with the hooks already present in Genode (as opposed to workspaces spanning multiple displays). To my mind, this would handle the vast majority of use cases for most users. Am I off-base here?
Thanks!
John J. Karcher devuser@alternateapproach.com
Hi Norman, I should start out by saying that my software skills are quite limited compared to yours. My laptop just broke so until I can get another up and running I'm limited to my phone. It difficult to type so please excuse the errors. I have been following this project because I think it has a bright future and I think that broadly speaking Linux is be becoming more like windows and leaving the Unix philosophy of simple components working together. Being a visual thinker I am drawn to the concept embodied in Eaglemode. I do not know how or how well the software is excecuted, but for me at least being able to to see the structure 'from above' is appealing. As far as being keyboard friendly I can't say, but the idea of having a window/file manager with these capabilities seems very useful. Just my two cents worth. Like I said I have no skin in the game.wish you and this project nothing but success and a bright future. Respectfully, Dave Springer
Sent from Yahoo Mail on Android
On Fri, Dec 27, 2019 at 8:34 AM, Norman Feskenorman.feske@genode-labs.com 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
Hi Dave,
Being a visual thinker I am drawn to the concept embodied in Eaglemode. I do not know how or how well the software is excecuted, but for me at least being able to to see the structure 'from above' is appealing. As far as being keyboard friendly I can't say, but the idea of having a window/file manager with these capabilities seems very useful. Just my two cents worth.
the Eaglemode ZUI looks like a lot of fun. Thanks for sharing the link.
With my work in the foreseeable future, I'll concentrate on Sculpt's administrative interface though. It will be as bare-bones as I can get away with. My main concern is to keep the code complexity at a level that is suitable for thorough analysis/evaluation/verification.
I have not studdied the Eaglemode project in detail. It surely looks like a tempting system to deploy on top of Sculpt. On the other hand, the listed requirements contain quite a few road blocks, i.e., Xlib.
Cheers Norman
Hello Genodians,
looking back at 2019, I see quite a few achievements, some matching our planned goals laid out on the road map and some more motivated by needs of Genode users and customers of Genode Labs. I'd like to thank all guys from Genode Labs and external contributors alike for an eventful and prolific Genode year. A particular highlight for me was the first Genode Community Summer event, which despite my initial scepticism was an entire success and makes a well-balanced Genode year towards FOSDEM and Hack'n'Hike in the first half. I'm definitely in for a renewal in August/September.
In retrospect (and like the years before), my personal objectives for 2019 drafted in January experienced mixed attention. This said, I contributed my share to Genodians.org but not as much as I liked. This is strongly linked to the fact that my planned work on Genode network appliances had to make room for various other important tasks.
Nonetheless, I'd like to put the Genode-based router and NAS vault on the agenda again this year as this topic holds huge potential to showcase Genode's strengths. Beside the scenarios themselves, challenges of this topic are:
- Performance and robustness of the network stack including drivers, protocol implementation and the NIC router as well as the LibC and VFS integration - Secured network protocols (SSL, SSH, wireguard) depending on the application - Configuration interface
Beyond this Steckenpferd, I expect a load of other opportunities to lend a hand from low-level debugging over tool-chain peculiarities and Goa-based software porting right up to the development of entire complex scenarios as in the years before. Therefore, I hesitate to commit to one or more of the following topics that are becoming more important now as we are "using and consolidating".
- Complete LibC thread safety - Improved STL support (e.g., threading and mutexes) - Continuous POSIX-compliance testing - Decoupling Qt5 from Genode sources with Goa
Regards
On 1/3/20 4:09 AM, Christian Helmuth wrote:
Hello Genodians,
looking back at 2019, I see quite a few achievements, some matching our planned goals laid out on the road map and some more motivated by needs of Genode users and customers of Genode Labs. I'd like to thank all guys from Genode Labs and external contributors alike for an eventful and prolific Genode year. A particular highlight for me was the first Genode Community Summer event, which despite my initial scepticism was an entire success and makes a well-balanced Genode year towards FOSDEM and Hack'n'Hike in the first half. I'm definitely in for a renewal in August/September.
I meant to ask about the Genode Community Summer at the time - I'm glad to hear that it was a success! Did anyone write anything about it (e.g., how many people participated, etc.)?
In retrospect (and like the years before), my personal objectives for 2019 drafted in January experienced mixed attention. This said, I contributed my share to Genodians.org but not as much as I liked. This is strongly linked to the fact that my planned work on Genode network appliances had to make room for various other important tasks.
Nonetheless, I'd like to put the Genode-based router and NAS vault on the agenda again this year as this topic holds huge potential to showcase Genode's strengths.
I could not agree more. In fact, I would love to put these into use in my SOHO environment.
FWIW,
John J. Karcher devuser@alternateapproach.com
Hey John,
El 4/1/20 a las 3:27, John J. Karcher escribió:
I meant to ask about the Genode Community Summer at the time - I'm glad to hear that it was a success! Did anyone write anything about it (e.g., how many people participated, etc.)?
AFAIK, no one wrote a resumé of the community summer but I share the feeling that it was a success. We had about 8 participants and a very diverse set of topics ranging from IMX/AMD GPU drivers over Java, networking optimization, lwext4, to robustness through redundant execution.
Cheers, Martin
Hello,
my biggest plan for 2020 is porting QtWebEngine and a more modern web browser to Genode, since both the Arora web browser and QtWebKit are outdated by now.
Christian
Hello Genodians,
looking back at 2019, I have quite mixed feelings about it. Starting with the x86 VM interface harmonization on Genode via several kernels in the beginning, the work switched straight into the world of ARMv8 virtualization through all levels together with Stefan Kalkowski. Technically, it was enlightened, a fun and successful virtualization trip. On the other hand, way to less time was left to tackle more points of the roadmap. Luckily, a year ends eventually and new plans can be made ;-)
For this year my personal interests are:
- Extended tooling for performance measurement (on-target) to spot actual optimization points. It started already as side project [1] last year and exposed several edges which needs optimization and ideas to be explored.
- Deterministic (not ad-hoc) workflow for screen capturing off-target and on-target by re-activating Martin's work [0], which I got running to some degree successfully at end of last year.
- Semi-automated/policy-guided load balancing and placing of components on several CPU cores.
- Shutdown protocol and restart-ability of services and drivers on Sculpt OS.
- Having an eye on improved AMD support and Seoul, whenever possible.
Those are my plans/ideas so far.
Cheers,
Alex.
[0] https://github.com/genodelabs/genode/issues/1806 [1] https://genodians.org/alex-ab/2019-12-23-top-view
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@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
Hi John,
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)
you are certainly not alone. I'm wary to put it on the road map though.
The topic is not merely a matter of porting some file-system code but it deserves to be addressed at a larger scale, combined with a performance study. E.g., we contemplated ideas to completely separate the caching from the file systems by the means of chained VFS plugins. This work - once tackled - should also consider the concerted and graceful wind-down of the file-system stack, which remains unaddressed as of today. Such a holistic undertaking, however, is quite a big project. Too big for a side project, in my opinion.
On the other hand, I personally don't feel the pressure. The rump-kernel-based file system that I'm using day to day has not failed me yet. Let me also note that none of our current customers has recently expressed interest in funding this direction either.
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"?
Good call. Please find my collection of thoughts here:
https://genodians.org/nfeske/2020-01-06-pending-sculpt-ui
Cheers Norman
On 1/6/20 10:36 AM, Norman Feske wrote:
Hi John,
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"?
Good call. Please find my collection of thoughts here:
That was quick!
This looks like a simple and elegant solution. Very nice!
Thanks,
John J. Karcher devuser@alternateapproach.com
Hey Norman,
Thanks for the annual poke!
For 2020 these are my interests:
* Provide a Genode kernel that is written entirely in Ada/SPARK, i.e., try to eliminate the use of base-hw code (C++) in the Spunky kernel that I started last year. Spunky currently aims only for the basic kernel features (e.g., no virtualization) and only for x86_64.
* Once, the Spunky design is independent from base-hw, try to find a way to modify the design in a way that SPARK-compliance can be reached. If successful, show absence of runtime errors via gnatprove.
* Try to find ways to let further core functionality of Genode benefit from Ada/SPARK. Especially the Core component and the base library are of interest for me. Building an Ada-only Core using Spunky would be a cool goal.
* Also, the NIC router has reached a state that makes me believe that a review of the internal design would be useful.
Cheers, Martin
El 27/12/19 a las 14:33, Norman Feske escribió:
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
Hey Martin,
On Mon, Jan 06, 2020 at 16:19:35 CET, Martin Stein wrote:
- Also, the NIC router has reached a state that makes me believe that a
review of the internal design would be useful.
This bullet point is quite aligned with my interests for the year, so I'd like to bump its priority. I understand it in a more broader scope of robustness of the solution and its autopilot test cases (remember my note during yesterday's meeting).
Greets
Hello everyone,
in 2019 I mostly focused on one project in particular and did not much else besides that. That lead to stalling on some of my pet projects. So for 2020 I plan on picking these up again (if time permits):
* Enabling USB Audio Class1/2 support (since having the dde_bsd sources up to date making uaudio.c work should just be a matter of porting™). * Revive my cmus port including the minimal OSSv4 VFS plugin used in as backend in cmus I did back in November 2018. * Revive the lynx port (now that the libc is up the task). * Porting Netsurf (I already started at last years hack'n hike but did not get far). * Finish writing a lwext4 VFS plugin.
I'm not sure how those fit into the overall roadmap but I'd already be happy enough if I manage to squeeze them into my personal time table.
Regards Josef
Hello Genodians,
2019 has again been a great year to work with, at and around this fabulous project and unique community. As always, we at gapfruit are impressed with the improvements: some expected and some unexpected but not less delightful.
I'd also like to share some ideas from our point of view. It may sound (and probably is) more like a wishlist than an agenda. But let me assure you that we'll contribute whenever possible and reasonable.
Software Enablement ===================
For us, this is probably the most volatile topic and priorities may change on a monthly basis. However improvements regarding feature completeness, performance, stability and production-readiness in the following areas is IMHO anyways well spent effort:
- libc: a lot has already been achieved in 2019 and with the number of use cases growing, we expect even more improvements in 2020.
- networking: network support is available but as the number of networking use-cases increases, we also need to spend more effort in networking. I.e. IPv6 will be required eventually as well. Also adding a reference board with several NICs to test and benchmark networking scenarios is desirable.
- filesystem: a native, production-ready filesystem will be required sooner or later. lwext4 is already supported by the Genode framework. Production-readiness in real life scenarios has yet to be proven. I guess networking and filesystem support is very much in line with Christians Genode-based router and NAS vault.
- Java: it's great to have Java support! Yet some work has to be done to make this support more generic. Namely some mechanism that allows to customize the "classes.tar" (which is currently managed in the port "jdk_generated" of genode-world) depending on the scenario.
- LLVM: Emery's proposal regarding the LLVM based toolchain is great. It will open up many new use cases and migration paths.
Hardware Enablement ===================
Genode Labs maintains some representative HW targets for different architectures which is good. However in our experience it's unlikely that a user will use exactly one of these targets. The only way I know to support a different target (like a new ARM board) is to add patches on top to the Genode repository. These patches will never be pushed upstream, which means that users actually have to maintain forks of the Genode repository. IMHO in the short, mid, or long-term it is desirable to add hardware support in dedicated repositories, similar like it is done for 3rd-party software with the genode-world repo. Imagine for example a "genode-nxp-arm" or "genode-marvell-arm" repo providing the hardware enablement for SOCs and boards. However, this can't easily be achieved and may require some kind of a common interface to "plug-in" such resources.
Tooling / SDK =============
It's great how well the depot and run tools can be used in the stages "extract", "build", "run" and "deploy" of our continuous integration pipeline! Since such a CI/CD infrastructure is most useful when it provides near instantaneous feedback on quality issues or regressions, optimization is key. Along the way of optimizations, we expect some effort on the following topics:
- Extract SDK from Genode repository that can be used in 3rd-party repositories: I think Emery has once done something in this direction. Together with the SDK, the information about current depot archive versions need to be passed along. This would allow to create system integration projects which *depend on* a specific version of the Genode framework, *instead of adding them* to the Genode framework.
- Add support to create, sign and share contrib archives (ports): Maybe the depot tools can be used as well for "preparation"/integration of 3rd-party code. If this is true, the port tools can probably be deprecated. Or more likely, they may become the plumbing with the depot-tooling as the new porcelain?
I didn't have the time to dive into the new Goa tool yet. Please bear with me if it already covers the above points ;)
Cheers, Roman
Hello Roman,
thank you for sharing your view and needs with us. I want to respond to some of the addressed points in the following.
On Tue, Jan 07, 2020 at 04:40:57PM +0100, Roman Iten wrote:
Hello Genodians,
2019 has again been a great year to work with, at and around this fabulous project and unique community. As always, we at gapfruit are impressed with the improvements: some expected and some unexpected but not less delightful.
I'd also like to share some ideas from our point of view. It may sound (and probably is) more like a wishlist than an agenda. But let me assure you that we'll contribute whenever possible and reasonable.
Software Enablement
For us, this is probably the most volatile topic and priorities may change on a monthly basis. However improvements regarding feature completeness, performance, stability and production-readiness in the following areas is IMHO anyways well spent effort:
- libc: a lot has already been achieved in 2019 and with the number of
use cases growing, we expect even more improvements in 2020.
- networking: network support is available but as the number of
networking use-cases increases, we also need to spend more effort in networking. I.e. IPv6 will be required eventually as well. Also adding a reference board with several NICs to test and benchmark networking scenarios is desirable.
There is an ARM-based board target called 'nit6_solox', which contains two NIC connectors that are both useable under Genode. Moreover, you are of course free to have more than one NIC card in x86-based PCs.
- filesystem: a native, production-ready filesystem will be required
sooner or later. lwext4 is already supported by the Genode framework. Production-readiness in real life scenarios has yet to be proven. I guess networking and filesystem support is very much in line with Christians Genode-based router and NAS vault.
- Java: it's great to have Java support! Yet some work has to be done to
make this support more generic. Namely some mechanism that allows to customize the "classes.tar" (which is currently managed in the port "jdk_generated" of genode-world) depending on the scenario.
- LLVM: Emery's proposal regarding the LLVM based toolchain is great. It
will open up many new use cases and migration paths.
Hardware Enablement
Genode Labs maintains some representative HW targets for different architectures which is good. However in our experience it's unlikely that a user will use exactly one of these targets. The only way I know to support a different target (like a new ARM board) is to add patches on top to the Genode repository. These patches will never be pushed upstream, which means that users actually have to maintain forks of the Genode repository. IMHO in the short, mid, or long-term it is desirable to add hardware support in dedicated repositories, similar like it is done for 3rd-party software with the genode-world repo. Imagine for example a "genode-nxp-arm" or "genode-marvell-arm" repo providing the hardware enablement for SOCs and boards. However, this can't easily be achieved and may require some kind of a common interface to "plug-in" such resources.
I definetly agree with this need. But I think that genode-world is for the time-being the right target for SoC/board-specific parts not maintained by Genode Labs directly. There are already examples for Zynq-centered boards running with base-hw in it. I also like to abondon several ARM boards not tested regularily in our test-farm to genode-world. Please, refer to issue 3168 in our issue tracker for details:
https://github.com/genodelabs/genode/issues/3168
Best regards Stefan
Tooling / SDK
It's great how well the depot and run tools can be used in the stages "extract", "build", "run" and "deploy" of our continuous integration pipeline! Since such a CI/CD infrastructure is most useful when it provides near instantaneous feedback on quality issues or regressions, optimization is key. Along the way of optimizations, we expect some effort on the following topics:
- Extract SDK from Genode repository that can be used in 3rd-party
repositories: I think Emery has once done something in this direction. Together with the SDK, the information about current depot archive versions need to be passed along. This would allow to create system integration projects which *depend on* a specific version of the Genode framework, *instead of adding them* to the Genode framework.
- Add support to create, sign and share contrib archives (ports): Maybe
the depot tools can be used as well for "preparation"/integration of 3rd-party code. If this is true, the port tools can probably be deprecated. Or more likely, they may become the plumbing with the depot-tooling as the new porcelain?
I didn't have the time to dive into the new Goa tool yet. Please bear with me if it already covers the above points ;)
Cheers, Roman
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
This is more of a curiosity question than a request, but what is the status of Sculpt running on base-hw? A few months ago I tried it, and it seemed to work, but ran very slowly.
Is this a near-term goal? (I thought it was on the roadmap in the past, but I can't find it.)
Thanks!
John J. Karcher devuser@alternateapproach.com
Hi John,
On Thu, Jan 09, 2020 at 03:55:52PM -0500, John J. Karcher wrote:
This is more of a curiosity question than a request, but what is the status of Sculpt running on base-hw? A few months ago I tried it, and it seemed to work, but ran very slowly.
Is this a near-term goal? (I thought it was on the roadmap in the past, but I can't find it.)
It certainly is! Unfortunately, there is no hardware-assisted virtualization available for hw/x86 yet, which is the biggest showstopper functionality-wise right now. But at least on ARM we will hopefully see something running quite soon.
Regarding the performance penalities: it might be just missing page attributes (write-combining) for the framebuffer memory, which leads to a poor interactive behaviour. Another point is that base-hw does not provide hard realtime priorities but implements as the only kernel Genode's concept of CPU quota. But in the current sculpt scenario there are no cpu quotas defined. Therefore, several latency-critical components, like the timer, are scheduled round-robin as all other components. We certainly have to investigate this.
Best regards Stefan
Thanks!
John J. Karcher devuser@alternateapproach.com
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello everyone,
I hesitated to write about my plans for 2020 as in the previous year I did not succeed with my goals regarding Genode and Raspberry Pi. It was mostly due to underestimating the amount of required work and maybe more important due to different personal issues that limited amount of spare time to the level that I was merely able to catch up with changes in official repository from time to time.
Now with the new year started I'm again full of optimism. After all the work done in base-hw (mostly by Stefan) it seems to be much easier and in a more natural way to introduce support for different hardware (rpi versions in my case) and I hope to be able to finish and cleanup my code enough to be incorporated to genode and genode-world repositories during this year. I believe that Sculpt like scenarios working on Raspberry Pi could arouse interest in Genode.
On a completely different territory I'd like to investigate possibilities to allow working with Genode code in some big programming environments - I'm thinking about Eclipse since I have some experience with it. I understand that everyone here knows organisation of code in Genode repository well enough to know where to look and finding proper places for modifications/improvements and I'm also getting used to it but I also remember how hard it was for me year ago to browse the code. Nowadays programmers are used to have code completion and integrated debugging in one environment and I think that such integration would lower the amount of time required to start coding for Genode and potentially attract new people.
Tomasz
On 1/13/20 7:24 PM, Tomasz Gajewski wrote:
Hello everyone,
I hesitated to write about my plans for 2020 as in the previous year I did not succeed with my goals regarding Genode and Raspberry Pi. It was mostly due to underestimating the amount of required work and maybe more important due to different personal issues that limited amount of spare time to the level that I was merely able to catch up with changes in official repository from time to time.
Now with the new year started I'm again full of optimism. After all the work done in base-hw (mostly by Stefan) it seems to be much easier and in a more natural way to introduce support for different hardware (rpi versions in my case) and I hope to be able to finish and cleanup my code enough to be incorporated to genode and genode-world repositories during this year. I believe that Sculpt like scenarios working on Raspberry Pi could arouse interest in Genode.
Yes, this would be great. I have a Pi 4, which I would love to experiment with Sculpt, as well as run as a simple Genode-based server.
On a completely different territory I'd like to investigate possibilities to allow working with Genode code in some big programming environments - I'm thinking about Eclipse since I have some experience with it. I understand that everyone here knows organisation of code in Genode repository well enough to know where to look and finding proper places for modifications/improvements and I'm also getting used to it but I also remember how hard it was for me year ago to browse the code. Nowadays programmers are used to have code completion and integrated debugging in one environment and I think that such integration would lower the amount of time required to start coding for Genode and potentially attract new people.
I also would love to have an IDE (whether Eclipse or a lighter alternative), and I agree that it could help attract more casual developers.
Keep us informed as you progress on these items (and if you want testers)!
Thanks,
John J. Karcher devuser@alternateapproach.com
I also would love to have an IDE (whether Eclipse or a lighter alternative), and I agree that it could help attract more casual developers.
I successfully use VSCode from Microsoft as ide for Genode build and debugging
I have 2 Parallels virtual machines on my Mac as a host where I use vscode One machine is a genode system to debug, another one is a Ubuntu server with build environment for genode (and gdb front end as well)
VSCode support remote work via ssh, so, I have a workspace running from inside build vm with Mac hosted VSCode and iTerm2
This allows me to handle code, compile (via remote make), git integration and even gdb UI for Nova kernel...
No very specific adjustment, just set of options for VSCode .
Debugging a bit more tricky - I have to compile exactly the same fronted 8.2.1 as used in genode 11.19 and place it inside build machine. Both vm connected via named pipe which allows remote debug of target genode vm from build vm with gdb using host (macOS) VSCode
Sincerely, Alexander
Hi Tomasz,
thank you for sharing your perspective on the project and your plans.
The Rpi topic is indeed a huge project. While following your conversations with Stefan on the issue tracker from the side lines, I admire your perseverance with dealing with this rabbit hole. Your vision to bring Sculpt to this broadly accessible and cheap platform is very exciting.
On a completely different territory I'd like to investigate possibilities to allow working with Genode code in some big programming environments - I'm thinking about Eclipse since I have some experience with it. I understand that everyone here knows organisation of code in Genode repository well enough to know where to look and finding proper places for modifications/improvements and I'm also getting used to it but I also remember how hard it was for me year ago to browse the code. Nowadays programmers are used to have code completion and integrated debugging in one environment and I think that such integration would lower the amount of time required to start coding for Genode and potentially attract new people.
I like this idea a lot!
In fact, the topic of an IDE for Genode development pops up again and again. But since everyone at Genode Labs uses plain Unix+Vim as development environment, we are unable to give a satisfactory answer. We wish there was a compelling solution but we have none, and - given that we are no IDE users - we are probably not right persons to develop one. Since you are used to IDEs, you are in a much better position.
Should you step forward with offering a solution, be it in the form of documentation about how to set up an IDE for Genode development or in the form of a customized IDE, this solution will surely meet a demand.
Maybe this line of work could go even hand in hand with Goa?
Cheers Norman
On 1/17/20 7:31 AM, Norman Feske wrote:
In fact, the topic of an IDE for Genode development pops up again and again. But since everyone at Genode Labs uses plain Unix+Vim as development environment, we are unable to give a satisfactory answer. We wish there was a compelling solution but we have none, and - given that we are no IDE users - we are probably not right persons to develop one.
I had a small thought related to this: Are there any XSD (XML schema) files for the configuration files?
This would make it easier to use a generic XML editor, not to mention custom tools or IDE plug-ins, to write these files. Considering how regular the formats are, the resulting XSD could be very clean.
Thanks!
John J. Karcher devuser@alternateapproach.com
Hi John,
A quick 'find . -name *.xsd*' reveals:
./base/xsd/base_types.xsd ./libports/src/app/sntp_client/config.xsd ./os/src/init/config.xsd ./os/src/server/nic_dump/config.xsd ./os/src/server/nic_router/config.xsd ./os/src/server/nic_bridge/config.xsd ./os/src/app/trace_logger/config.xsd ./os/src/app/ping/config.xsd ./os/src/test/nic_stress/config.xsd ./os/src/test/net_flood/config.xsd ./os/xsd/net_types.xsd ./os/xsd/timeout_types.xsd ./gems/src/app/depot_autopilot/config.xsd
We implemented support for automatic XSD checking in the run tool some time ago [1] but only a handful of components have an XSD by now.
Cheers, Martin
[1] https://genode.org/documentation/release-notes/18.02#Offline_validation_of_X...
El 22/1/20 a las 19:37, John J. Karcher escribió
I had a small thought related to this: Are there any XSD (XML schema) files for the configuration files?
This would make it easier to use a generic XML editor, not to mention custom tools or IDE plug-ins, to write these files. Considering how regular the formats are, the resulting XSD could be very clean.
Thanks!
John J. Karcher devuser@alternateapproach.com
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Dear Genode community,
today I have condensed our discussion into Genode's official road map for 2020:
https://genode.org/about/road-map
Thanks to everyone of you who participated. I hope that you find your ideas and concerns well reflected.
Cheers Norman
-
Alexander Boettcher -
Alexander Tormasov -
Christian Helmuth -
Christian Prochaska -
Dave Springer -
Emery Hemingway -
John J. Karcher -
Josef Söntgen -
Martin Stein -
Nobody III -
Norman Feske -
Roman Iten -
Stefan Kalkowski -
Tomasz Gajewski -
ttcoder＠netcourrier.com