Hello everyone,
like every year in December, I'd like to kick off the discussion of Genode's road map for the upcoming twelve months. It goes without saying that your feedback and suggestions are very welcome. Should you have any plans related to Genode, please do not hesitate to chime in!
Before I present my rough plans, let me take a minute to review the past year.
Review of 2017 --------------
As Johannes Schlatow's team put it so nicely in their Christmas card (thanks a lot!), the "Turmvilla" era lies behind us. So let the "Sculpt" era begin! Whereas Turmvilla allowed me to work on a Genode-based system since mid of 2015, the scenario was quite rigid and required significant manual labour for any customization. Although it was not really inviting for potential users, it illustrated well that all the basic building blocks - in particular the driver stacks - were in place. But it would have been be quite a stretch to call Turmvilla a general-purpose OS at that point.
The new Sculpt scenario that I started to put together this autumn leverages two key features of 2017 to ultimately enter the realms of general-purpose computing. Those features are the dynamic init and the package management. The combination of Genode's recursive architecture with the dynamic reconfigurability of the init component allows me to interactive shape the running Genode system including any subsystem or even configurations of individual components. The system structure is at my fingertips and I can change it instantly using my favorite text editor. This excites me to no end! :-) At the same time, the new package management greatly helps to keep the complexity at a manageable level. Whereas I rarely updated my Turmvilla installation out of hesitance to break my work environment, I routinely update Sculpt on a weekly basis. Not only do I but also all my team mates at Genode Labs! The switch of the entire Genode-Labs team to Genode full time was certainly our biggest milestone of the year.
At the technical level, the use of the gained cross-kernel binary compatibility or the VFS infrastructure have already become a second nature. Regarding the latter, remodelling this infrastructure to an asynchronous mode of operation was certainly a long and stony way. I am extremely grateful to Emery and Christian for having taken a big share of this labor-intensive work! Now, we can start to reap the fruits of this development.
How to proceed in 2018? -----------------------
Personally, I'm to eager to take Genode in two main directions. First, the Sculpt scenario will for sure spawn manifold developments to the benefit of end users. Those developments will include documentation to make Sculpt palatable to users, the further cultivation of Genode's package-management concept, the composition of new subsystems, and the optimization of daily work flows. The progress in this direction will be quite organic and primarily motivated to make our daily computing experience more effective and fun.
The second direction is the application of Genode for real-time graphics and sound processing - in a way reigniting my past passion of programming demo effects on the Atari Falcon. ;-) The path for this activity was paved this year by Josef and Sebastian who created our driver infrastructure for Intel GPUs. By actively using this infrastructure along with the audio stack, I am eager to push Genode towards low-latency multimedia performance. In order to do that, I will have to improve the tools for gathering runtime data (e.g., putting our tracing infrastructure to good use), gain a profound understanding of the behavior of complex scenarios, and optimize.
Aside these playful activities, I also want to focus on the quality and resilience of our software. The modernized framework API introduced last year is an important stepping stone. But there is much more we can (and should) do, I.e., learning from the high-integrity computing community (e.g., implementing critical components in SPARK), leveling-up the scope and intensity of our automated tests, facilitating static code analysis, and employing software-hardening techniques. Of course, this scope goes far beyond the time frame of one year. The immediate priorization of these topics will largely depend on the focus of commerical users funding the work.
The aspirations outlined above are my personal perspective. Please do not hesitate to share yours! Any comments and suggestions are appreciated. Maybe you even have tangible or less tangible Genode-related plans as well? I would be happy to learn about them!
The outcome of the discussion will eventually become the official road map for 2018, which I am going to announce in mid of January.
Cheers Norman
I definitely agree that we need to make the sculpt scenario more user-friendly. A desktop environment would help a lot, but isn't planned as part of the official Genode repository. I'm personally working on my own (see https://github.com/NobodyIII/genode-desktop-environment), and I'd be more than happy to accept contributions. That being said, I would suggest that we add an easy way to start Genode subsytems from inside noux. From my understanding, the fastest way to start a subsystem in the Sculpt scenario is to type the XML start node into one of the config files. If instead, I could just type something like "start vbox_linux" into bash, I would be much more inclined to put Sculpt on my laptop, like I did with Turmvilla.
Also, improved hardware support would be very nice. I have run into various issues in the past, and I'll bring them back up if I still have problems getting Genode to work on my computers. But even if all of the bugs have been resolved, we still don't have an AMD framebuffer driver, or a NVIDIA driver for that matter. For people like me who have high or non-standard monitor resolutions, being stuck with the VESA driver is rather annoying. I'm not sure whether these display drivers should be ported in 2018 or some later year, but they should definitely be ported sometime in the next few years.
We had porting a modern web browser on the roadmap back in 2015, but that never happened, AFAIK. This might be worth pursuing again.
* We have started using a package manager (depot), but we need more recipes, especially for ported libraries such as Qt 5.
* Many run scripts are outdated. Most still need to be updated to use depot packages, and many don't work anymore due to recent changes such as cap quotas. We need to update the run scripts and verify that they all work.
(* = high priority)
On Fri, Dec 22, 2017 at 2:47 PM, Norman Feske <norman.feske@...1...> wrote:
Hello everyone,
like every year in December, I'd like to kick off the discussion of Genode's road map for the upcoming twelve months. It goes without saying that your feedback and suggestions are very welcome. Should you have any plans related to Genode, please do not hesitate to chime in!
Before I present my rough plans, let me take a minute to review the past year.
Review of 2017
As Johannes Schlatow's team put it so nicely in their Christmas card (thanks a lot!), the "Turmvilla" era lies behind us. So let the "Sculpt" era begin! Whereas Turmvilla allowed me to work on a Genode-based system since mid of 2015, the scenario was quite rigid and required significant manual labour for any customization. Although it was not really inviting for potential users, it illustrated well that all the basic building blocks - in particular the driver stacks - were in place. But it would have been be quite a stretch to call Turmvilla a general-purpose OS at that point.
The new Sculpt scenario that I started to put together this autumn leverages two key features of 2017 to ultimately enter the realms of general-purpose computing. Those features are the dynamic init and the package management. The combination of Genode's recursive architecture with the dynamic reconfigurability of the init component allows me to interactive shape the running Genode system including any subsystem or even configurations of individual components. The system structure is at my fingertips and I can change it instantly using my favorite text editor. This excites me to no end! :-) At the same time, the new package management greatly helps to keep the complexity at a manageable level. Whereas I rarely updated my Turmvilla installation out of hesitance to break my work environment, I routinely update Sculpt on a weekly basis. Not only do I but also all my team mates at Genode Labs! The switch of the entire Genode-Labs team to Genode full time was certainly our biggest milestone of the year.
At the technical level, the use of the gained cross-kernel binary compatibility or the VFS infrastructure have already become a second nature. Regarding the latter, remodelling this infrastructure to an asynchronous mode of operation was certainly a long and stony way. I am extremely grateful to Emery and Christian for having taken a big share of this labor-intensive work! Now, we can start to reap the fruits of this development.
How to proceed in 2018?
Personally, I'm to eager to take Genode in two main directions. First, the Sculpt scenario will for sure spawn manifold developments to the benefit of end users. Those developments will include documentation to make Sculpt palatable to users, the further cultivation of Genode's package-management concept, the composition of new subsystems, and the optimization of daily work flows. The progress in this direction will be quite organic and primarily motivated to make our daily computing experience more effective and fun.
The second direction is the application of Genode for real-time graphics and sound processing - in a way reigniting my past passion of programming demo effects on the Atari Falcon. ;-) The path for this activity was paved this year by Josef and Sebastian who created our driver infrastructure for Intel GPUs. By actively using this infrastructure along with the audio stack, I am eager to push Genode towards low-latency multimedia performance. In order to do that, I will have to improve the tools for gathering runtime data (e.g., putting our tracing infrastructure to good use), gain a profound understanding of the behavior of complex scenarios, and optimize.
Aside these playful activities, I also want to focus on the quality and resilience of our software. The modernized framework API introduced last year is an important stepping stone. But there is much more we can (and should) do, I.e., learning from the high-integrity computing community (e.g., implementing critical components in SPARK), leveling-up the scope and intensity of our automated tests, facilitating static code analysis, and employing software-hardening techniques. Of course, this scope goes far beyond the time frame of one year. The immediate priorization of these topics will largely depend on the focus of commerical users funding the work.
The aspirations outlined above are my personal perspective. Please do not hesitate to share yours! Any comments and suggestions are appreciated. Maybe you even have tangible or less tangible Genode-related plans as well? I would be happy to learn about them!
The outcome of the discussion will eventually become the official road map for 2018, which I am going to announce in mid of January.
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
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Ben,
thanks for sharing your thoughts!
From my understanding, the fastest way to start a subsystem in the Sculpt scenario is to type the XML start node into one of the config files. If instead, I could just type something like "start vbox_linux" into bash, I would be much more inclined to put Sculpt on my laptop, like I did with Turmvilla.
The Sculpt scenario is meant as a starting point. Right now, the user has to edit files per hand or juggle copies of modified files. Of course, these actions could alternatively be done by a program that covers typical usage patterns like starting a program, connecting to wifi, adjusting mixer settings, etc. Technically, such a program is just automating the steps a user would manually take with Sculpt: It consumes the system state (by looking at reports) and generates XML configurations for components and dynamic subsystems.
Actually, this approach is already at play. The device-driver discovery is managed by the program gems/src/app/driver_manager. Another example is the forthcoming depot-download subsystem at my 'depot_download' branch. Here the so-called download manager dynamically orchestrates 'fetchurl', 'extract', and 'depot_query' components without doing any actual work by itself.
I envision the desktop environment to provide a set of management components along with a set of minions that do the dirty work. An example for the latter is the file-identifying component you just discussed. The manager component spawns, respawns, configures, and discards its minions via a dynamic subinit as needed.
Sculpt should not be understood as an alternative to a desktop environment but rather as a suitable underlying foundation. A desktop environment will be one scenario (out of potentially many) a user can select to run on top of Sculpt. At the end of 2018, this vision should hopefully become within close reach.
Also, improved hardware support would be very nice. I have run into various issues in the past, and I'll bring them back up if I still have problems getting Genode to work on my computers. But even if all of the bugs have been resolved, we still don't have an AMD framebuffer driver, or a NVIDIA driver for that matter. For people like me who have high or non-standard monitor resolutions, being stuck with the VESA driver is rather annoying. I'm not sure whether these display drivers should be ported in 2018 or some later year, but they should definitely be ported sometime in the next few years.
I have mixed feelings about this. With Intel-based systems, we got the most popular hardware covered now, which was quite a feat - in particular when looking at wifi and GPU topics. Supporting also hardware that is less wide spread implies tremendous additional work while benefiting not so many new users. But more importantly, it does not open up new use cases. So it is intellectually less rewarding compared to other topics. There must be a strong commercial incentive or an intensive community effort to make it happen.
We had porting a modern web browser on the roadmap back in 2015, but that never happened, AFAIK. This might be worth pursuing again.
That's true. But I see no one willing to pick it up right now. For the foreseeable future - at least for the next year - I see us using a commodity browser in a VM, or a simple custom Qt5-based browser for browsing the leaner sites of the web.
- We have started using a package manager (depot), but we need more
recipes, especially for ported libraries such as Qt 5.
- Many run scripts are outdated. Most still need to be updated to use
depot packages, and many don't work anymore due to recent changes such as cap quotas. We need to update the run scripts and verify that they all work.
(* = high priority)
I wholeheartedly agree!
Cheers Norman
Hello,
thanks Norman for making a start with the road-map discussion and also for the review of 2017. Personally, I'm quite excited that Sculpt enables me to work on Genode each day. This is pretty much different from what I felt one year ago with a rather static scenario that I used only once for a talk.
Looking at 2017 in hindsight, I did not invest much time into my personal plan, which was a Genode-native multi-component email workflow including IMAP, SMTP, local (maildir) storage, and mutt as MUA. Nevertheless, I'll extend the plan to 2018 as Sculpt promises less obstacles and features true dynamic Genode subsystems beside the traditional Linux VM. The first natural step is the use of multiple VMs tailored for dedicated purposes of daily work (speak development, email, web browsing). This is not my personal ambition but the first pieces were already put in place by others in the team. This scenario helps to understand and solve the task of sharing data when splitting the daily work into more fine-grained domains. Next, the email VM can be replaced by the Genode email subsystem developed in parallel.
Additionally, I'd like to explore more options for Genode as an OS for network equipment. We already have a collection of network-related components like NIC and WiFi drivers, nic_router, and the IP stacks. What's missing is a Sculpt-like scenario one may just install on a network/WiFi router. Initially, I'll address an easily available x86-based platform to avoid time-consuming platform enablement or porting of device drivers. Also for 2018, I anticipate that we'll invest a good share of our development time into x86 PC hardware.
Regards
On 12/27/2017 11:15 AM, Christian Helmuth wrote:
Hello,
thanks Norman for making a start with the road-map discussion and also for the review of 2017. Personally, I'm quite excited that Sculpt enables me to work on Genode each day. This is pretty much different from what I felt one year ago with a rather static scenario that I used only once for a talk.
Looking at 2017 in hindsight, I did not invest much time into my personal plan, which was a Genode-native multi-component email workflow including IMAP, SMTP, local (maildir) storage, and mutt as MUA. Nevertheless, I'll extend the plan to 2018 as Sculpt promises less obstacles and features true dynamic Genode subsystems beside the traditional Linux VM. The first natural step is the use of multiple VMs tailored for dedicated purposes of daily work (speak development, email, web browsing). This is not my personal ambition but the first pieces were already put in place by others in the team. This scenario helps to understand and solve the task of sharing data when splitting the daily work into more fine-grained domains. Next, the email VM can be replaced by the Genode email subsystem developed in parallel.
Chris, please keep us informed about your progress on the IMAP server scenario if you can. I am also gradually making my systems more modular using VMs (although not quite as granular as what you describe above), and I am currently running an little IMAP server in a *nix VM, which I would love to replace with a Genode "appliance" VM.
Everyone, since I'm already chiming in, I might as well throw in this idea as food for thought:
It might be possible to piggyback on the work of the "postmarketOS" project ( https://postmarketos.org/ ) to get Genode running on a variety of smartphones with only one porting effort. In a nutshell, they are isolating all the device-specific code into one file, in order to allow creating a single (highly customizable, Alpine Linux-based) OS image to run on all the supported devices. I wonder if it's possible to create a Genode-on-Linux (ARM) scenario on this foundation.
In any case, thanks for the amazing work, and Happy New Year to everyone!
Hello John,
On Fri, Dec 29, 2017 at 06:03:13PM -0500, John J. Karcher wrote:
Chris, please keep us informed about your progress on the IMAP server scenario if you can. I am also gradually making my systems more modular using VMs (although not quite as granular as what you describe above), and I am currently running an little IMAP server in a *nix VM, which I would love to replace with a Genode "appliance" VM.
It looks like I've to clarify that my project is all about the client side of email. What I'd like to achieve is a Genode-native multi-component replacement for running Thunderbird or the like in a Linux VM. I personally use Mutt, offlineimap, msmtp, and abook on Linux for my Genode Labs account for years and am quite satisfied by most of the components. For the Genode implementation I'm still addressing Mutt, msmtp, and abook, but like to replace offlineimap by isync/mbsync.
Nevertheless, it should be not that hard for you to start the initial port of a simple IMAP server to Genode (using the libc) and identify additional requirements (e.g., missing libraries) not available yet.
Greets
The network equipment use case is especially interesting here. Genode has tremendous potential for a wide range of embedded systems, enabling strong security features combined with memory efficiency--a combination that is difficult to obtain other ways.
While x86 support is good, the embedded landscape is dominated by ARM, and currently Genode seems to have weaker driver support for small modern ARM systems. The Wand Quad would be a good platform to develop in this regard (vs, say, Arndale). Rpi would be another. (We've had little luck getting Genode running on any recent model of rpi, but maybe it wouldn't take much to change this.)
// Steve Harp
On 12/27/2017 10:15 AM, Christian Helmuth wrote:
Additionally, I'd like to explore more options for Genode as an OS for network equipment. We already have a collection of network-related components like NIC and WiFi drivers, nic_router, and the IP stacks. What's missing is a Sculpt-like scenario one may just install on a network/WiFi router. Initially, I'll address an easily available x86-based platform to avoid time-consuming platform enablement or porting of device drivers. Also for 2018, I anticipate that we'll invest a good share of our development time into x86 PC hardware.
Regards
Hi Steven,
While x86 support is good, the embedded landscape is dominated by ARM, and currently Genode seems to have weaker driver support for small modern ARM systems. The Wand Quad would be a good platform to develop in this regard (vs, say, Arndale). Rpi would be another. (We've had little luck getting Genode running on any recent model of rpi, but maybe it wouldn't take much to change this.)
I agree that the Freescale i.MX SoC should receive some love from us in 2018. From my perspective, the most interesting features would be the addition of USB and networking support.
Are you planning to enable Genode on a more recent Raspberry Pi? This would be a very welcome contribution! ;-)
Cheers Norman
Hello everyone,
and a happy new year!
To me personally it seems 2018 will be the year of "sculpt", and although I much appreciate my daily work on a Genode base, I fear other activities will become orphaned - which is our own kernel and support of embedded platforms.
Therefore, I'd like to take up the cudgles for putting some effort into the further development of the hw kernel. Currently, it cannot serve as a base for something like the sculpt scenario, because of missing features like SMP support and virtualization extensions. On the other hand, it is the only kernel target, we fully understand and are able to control in a manageable time, e.g., if problems arise like meltdown or spectre.
In the moment, it often feels like doing a hobby project if I practice maintainance work regarding the kernel. To me it seems its time to leap in the dark and fill the gap to put real workload on top of it. I know it contradicts with the overall goal to put energy into missing pieces, because the kernel development is not part of that. Anyway, if we do not want to quit the hw development, nor waste energy into a longstanding experiment, it's time to complete it. I would like to fill the gap, together with other (x86 virtualization) experienced developers, by:
* revert kernel optimization to share the address space with other * components at least on top of x86, keyword: meltdown * enable SMP for x86 * implement IOMMU support * add x86 hypervisor functionality to hw
Apart from the kernel work, I really like a fully functional (UTF8) terminal, ssh client, and a more convenient window-manager in the near future. Here, I like to take part too.
Regards Stefan
Hi Stefan,
To me personally it seems 2018 will be the year of "sculpt", and although I much appreciate my daily work on a Genode base, I fear other activities will become orphaned - which is our own kernel and support of embedded platforms.
Let me try to dispel your fear. My line of thoughts is as follows:
1. NOVA cannot be Genode's long-term future.
We carry the burden of maintaining NOVA alone (where "we" is for the most part one person - hi Alex!). Note that I am speaking of maintaining, not developing. It is clear that we won't expand our engagement beyond the current level. Solving the remaining fundamental deficiencies of the kernel, in particular the kernel-resource management, is not on our agenda. This would be a different story if there was an active community around the kernel. But there is none to speak of.
Feature-wise, NOVA is complete. So it is definitely a suitable basis for today and the immediate future. But in the longer term, its limitations will become a burden that we must overcome.
2. Base-hw solves NOVA's architectural problems but lacks features.
The base-hw kernel facilitates Genode's architecture to solve problems that are extremely complicated to solve in other kernels (seL4 comes to mind) or unsolved (NOVA). But its feature set is incomplete.
Since we won't take NOVA to the level we need in the longer term, the conclusion can only be what you just suggested: adding the missing features to base-hw:
- revert kernel optimization to share the address space with other components at least on top of x86, keyword: meltdown
- enable SMP for x86
- implement IOMMU support
- add x86 hypervisor functionality to hw
So how about combining the overall theme "Sculpt" with this ambition? Should we set up the goal to run Sculpt on base-hw by the end of the year?
You may wonder about the role of seL4 in this discussion. In contrast to NOVA, it is actively developed and there is a welcoming community around it. It is also fairly feature complete. On the other hand, it is complicated and we cannot easily tailor it to our needs. This is not a critique but a just consequence from seL4's focus. In contrast to seL4, base-hw was co-designed with Genode. So it is simple and frictionless, and puts us in control over everything. Hence, I see seL4 and base-hw in complimentary roles. (A) In situations where seL4's formal-verification story is anticipated, Genode enables seL4 to carry highly dynamic workloads. (B) For Genode use cases that call for the highest-possible simplicity, or that benefit from our full control over the kernel, base-hw is attractive.
Even though I often hear that (A) is super interesting, Genode/seL4 has no commercial backing yet. I.e., there are no customers with the ambition to drive Genode's seL4 support via commissioned development projects. Naturally, as a Genode developer, my personal use case falls into category (B). So I wholeheartedly support your plan!
Cheers Norman
Along with adding features to the base-hw kernel, I would suggest an emphasis on improving its performance. I have tried my own Sculpt-like scenario on that kernel, and I found that the mouse was sluggish when I tried dragging a window around. I had no such problem on NOVA.
My particular example indicates that the base-hw kernel has performance issues that need to be resolved, beyond just its lack of SMP support. I would like to see it running much more smoothly later this year.
Aside from that, like Stefan, I would like to see window management improvements. In particular, I would like to see the buttons on the title bar actually working. This might just be an issue with current graphical apps, such as nit_fb, but wherever the issue is, it should be fixed this year.
On Thu, Jan 11, 2018 at 6:45 AM, Norman Feske <norman.feske@...1...> wrote:
Hi Stefan,
To me personally it seems 2018 will be the year of "sculpt", and although I much appreciate my daily work on a Genode base, I fear other activities will become orphaned - which is our own kernel and support of embedded platforms.
Let me try to dispel your fear. My line of thoughts is as follows:
- NOVA cannot be Genode's long-term future.
We carry the burden of maintaining NOVA alone (where "we" is for the most part one person - hi Alex!). Note that I am speaking of maintaining, not developing. It is clear that we won't expand our engagement beyond the current level. Solving the remaining fundamental deficiencies of the kernel, in particular the kernel-resource management, is not on our agenda. This would be a different story if there was an active community around the kernel. But there is none to speak of.
Feature-wise, NOVA is complete. So it is definitely a suitable basis for today and the immediate future. But in the longer term, its limitations will become a burden that we must overcome.
- Base-hw solves NOVA's architectural problems but lacks features.
The base-hw kernel facilitates Genode's architecture to solve problems that are extremely complicated to solve in other kernels (seL4 comes to mind) or unsolved (NOVA). But its feature set is incomplete.
Since we won't take NOVA to the level we need in the longer term, the conclusion can only be what you just suggested: adding the missing features to base-hw:
- revert kernel optimization to share the address space with other components at least on top of x86, keyword: meltdown
- enable SMP for x86
- implement IOMMU support
- add x86 hypervisor functionality to hw
So how about combining the overall theme "Sculpt" with this ambition? Should we set up the goal to run Sculpt on base-hw by the end of the year?
You may wonder about the role of seL4 in this discussion. In contrast to NOVA, it is actively developed and there is a welcoming community around it. It is also fairly feature complete. On the other hand, it is complicated and we cannot easily tailor it to our needs. This is not a critique but a just consequence from seL4's focus. In contrast to seL4, base-hw was co-designed with Genode. So it is simple and frictionless, and puts us in control over everything. Hence, I see seL4 and base-hw in complimentary roles. (A) In situations where seL4's formal-verification story is anticipated, Genode enables seL4 to carry highly dynamic workloads. (B) For Genode use cases that call for the highest-possible simplicity, or that benefit from our full control over the kernel, base-hw is attractive.
Even though I often hear that (A) is super interesting, Genode/seL4 has no commercial backing yet. I.e., there are no customers with the ambition to drive Genode's seL4 support via commissioned development projects. Naturally, as a Genode developer, my personal use case falls into category (B). So I wholeheartedly support your plan!
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
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Ben,
On 11.01.2018 20:12, Nobody III wrote:
Along with adding features to the base-hw kernel, I would suggest an emphasis on improving its performance. I have tried my own Sculpt-like scenario on that kernel, and I found that the mouse was sluggish when I tried dragging a window around. I had no such problem on NOVA.
My particular example indicates that the base-hw kernel has performance issues that need to be resolved, beyond just its lack of SMP support. I would like to see it running much more smoothly later this year.
I suspect that the perceived sluggishness is a configuration issue, not a kernel issue. In contrast to NOVA that implements traditional static priorities, base-hw combines priorities with a quota regime. Unless a CPU quota is explicitly defined for a component, the assigned priority remains without effect. Since we use interactive scenarios like Sculpt primarily on NOVA, the run scripts lack any CPU-quota definitions. With no priorities, however, interactive scenarios cannot run smoothly at all. If you disabled them on NOVA, it would look similarly poor.
However, I take your posting as another indicator that we should put emphasis on the interactive use of base-hw during 2018.
Cheers Norman
Hello list,
I apologize for my absence from the mailing list, I didn't realize my subscription had ended until I noticed a link to the spectre thread on the front page of Hacker News :-)
Two goals that I set at the begining of last year have turned out well, the Nim language works for reasonable and practical purposes and Libreto based games compile and work with little effort. Both topics suffer from poor integration into the build system, so to continue them into this year I would like to perhaps investigate using the package system to build components hosted outside Genode repositories against a "Genode API/ABI snapshot", if that makes sense.
I expect my primary goal this year will be an IPFS compatible content-addressed storage system that is orthogonal yet complimentary to the new package management system introduced this year. I have for a few years considered reimplementing some of IPFS (a mostly Go project) for Genode, but only made it a serious goal this autumn. Over the course of a few small projects and investigation I have decided that the time is right. The end goal is to create a general purpose storage system that is capable of replicating across networks, global or private.
I've managed so far to represent IPFS data structures as native file-systems with a constellation of native components connected to a networked daemon running in a VM. Perforance is poor, but just good enough for real-time decoding of FLAC files. My short term goal for FOSDEM is demonstrate using the system to loading media like music or text and then move on to using it as a medium for software packages.
Best wished for 2018, Emery
Hello,
On Thu, Jan 11, 2018 at 03:16:31PM -0600, Emery Hemingway wrote:
I apologize for my absence from the mailing list, I didn't realize my subscription had ended until I noticed a link to the spectre thread on the front page of Hacker News :-)
We're working on the migration of our mailing lists to our own servers because of repeating annoying incidents like this with Sourceforge's service. So, consider this as a definite roadmap item. In the future, we may even host them on a Genode instance transparently ;-)
Cheers
Hello all,
attached my ideas and plans.
Review 2017 -----------
In January of 2017 I was not able to boot Genode on my brand-new notebook side by side with other OSes installed in UEFI mode. To overcome the issue, I choose to change this as side project and managed to get the Genode framework, Genode's hw kernel, the seL4 kernel and the NOVA kernel ready for UEFI. Also thanks to the external contribution of Johannes Kliemann, we have graphical support in UEFI mode even beside Intel graphic cards.
seL4 was also a weak UEFI target, just to trigger _some_ community interaction. Fortunately, the experiment went well and the seL4 kernel changes got accepted after some re-work rounds. Notable, that the seL4 kernel developers are open for external contributions. Unfortunately, this is not given for all mircokernel projects we had to deal with.
The other bigger working field was to finish the Virtualbox 5 port for Genode/NOVA, paused in 2016. According to the signals from our customers and also from our "Sculpt" cook, the move from VirtualBox 4 to 5 was relatively smooth.
With the raising "Sculpt" at end of 2017, several items triggered to be solved, e.g. for me in the NOVA kernel and the platform driver.
2018 ---- 2018 will continue as 2017 ended - by work triggered by "Sculpt". I imagine topics like _working_ restarted driver (not all do) or ordered shutdown/restart of the system.
For my personal "Sculpt" setup I started and tend to continue to split up, as far as maintainable, my working environment in several (minimal) VMs (e.g browser, eMail, compiler, tftp VM and more). I hope to replace some of the VMs over the year by native Genode components as soon as the alternatives become available and/or performance become acceptable. Where possible, I also tend to use the Seoul VMM.
The other area I would like to tackle, is to move some of Genode/NOVA only features to other Genode/kernel combinations, e.g. virtualization leveraging our 3 x86 VMMs and IOMMU support. The harmonization of the Genode interface to the kernel interfaces will cause some headaches, especially when not just functionality&security but also performance matters.
As pointed out by Stefan, Genode's hw kernel will have to get some feature extensions - here I tend to participate.
Finally, I would like to see/to address some (fmpov to low prioritized) work in Genode's core. Beside some modernization - read only dataspace capabilities and removing physical address information from the Dataspace interface come to my mind.
Happy hacking,
Hello,
I'd like thank everyone who participated in the road-map discussion for 2018!
I just updated Genode's official road map and hope that it adequately captures the interests expressed during the discussion while staying realistic:
https://genode.org/about/road-map
Cheers Norman
I like it! However, I noticed a few things that could use some changes:
1. Java support is mentioned as planned to be at least usable by the end of 2018, but isn't mentioned in any of the quarterly milestones. Given how significant Java support is, it should probably be in one or more of the milestones.
2. With Qt5 packages planned for the same release as Sculpt for The Curious, we should include a graphical text editor. I have already written a simple text editor, and with a little improvement, it will be ready to be included in that release. I suspect that it will make Sculpt much more inviting to users who are unfamiliar with Vim.
On Jan 17, 2018 9:46 AM, "Norman Feske" <norman.feske@...1...> wrote:
Hello,
I'd like thank everyone who participated in the road-map discussion for 2018!
I just updated Genode's official road map and hope that it adequately captures the interests expressed during the discussion while staying realistic:
https://genode.org/about/road-map
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
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Ben,
- Java support is mentioned as planned to be at least usable by the end
of 2018, but isn't mentioned in any of the quarterly milestones. Given how significant Java support is, it should probably be in one or more of the milestones.
we are just getting our toes wet and don't want to promise too much. The risks and scope of the undertaking are too vague for a more definite planning.
- With Qt5 packages planned for the same release as Sculpt for The
Curious, we should include a graphical text editor. I have already written a simple text editor, and with a little improvement, it will be ready to be included in that release. I suspect that it will make Sculpt much more inviting to users who are unfamiliar with Vim.
I'd like to avoid including Qt into the base image because it would inflate the image (and the thereby increase the boot time) quite noticeably. However, acknowledging the inconvenience that Vim may represent for some users, we could at least strive to alleviate the need for Vim for tweaking typical settings (network, wifi, keyboard layout, mouse acceleration, screen resolution) in Sculpt for The Curious. I am thinking of simple interactive dialogs based on the menu-view component. So users won't need to use Vim for everyday tasks.
Of course, a graphical editor could be featured in the non-initial stage in the form of a package. I hope that this will provide you with a nice way to distribute and promote your desktop-environment work.
Cheers Norman
On 01/17/2018 11:45 AM, Norman Feske wrote:
Hello,
I'd like thank everyone who participated in the road-map discussion for 2018!
I just updated Genode's official road map and hope that it adequately captures the interests expressed during the discussion while staying realistic:
https://genode.org/about/road-map
Cheers Norman
As a hobbyist, I hesitate to be among the first to respond, but I have to say that I am very excited about "The Year Of Sculpt". I think it could be a real turning point when it comes to gaining a wider audience.
I can't wait to get my hands on Sculpt EA!
In the meantime, please be sure to let us know if you upload any materials and/or videos from the FOSDEM presentations.
Thanks!
Hi John,
As a hobbyist, I hesitate to be among the first to respond, but I have to say that I am very excited about "The Year Of Sculpt". I think it could be a real turning point when it comes to gaining a wider audience.
I can't wait to get my hands on Sculpt EA!
In the meantime, please be sure to let us know if you upload any materials and/or videos from the FOSDEM presentations.
thank you for the enthusiastic feedback. :-)
If everything goes well, there will be recordings of the talks.
Cheers Norman
If you don't want Qt in the base image, we should at least include Gnu Nano. Its UI is more intuitive for beginners, and it should be easy to port.
On Jan 19, 2018 1:20 PM, "Norman Feske" <norman.feske@...1...> wrote:
Hi John,
As a hobbyist, I hesitate to be among the first to respond, but I have to say that I am very excited about "The Year Of Sculpt". I think it could be a real turning point when it comes to gaining a wider audience.
I can't wait to get my hands on Sculpt EA!
In the meantime, please be sure to let us know if you upload any materials and/or videos from the FOSDEM presentations.
thank you for the enthusiastic feedback. :-)
If everything goes well, there will be recordings of the talks.
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
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Ben,
On 20.01.2018 02:32, Nobody III wrote:
If you don't want Qt in the base image, we should at least include Gnu Nano. Its UI is more intuitive for beginners, and it should be easy to port.
the use of Vim is a deliberate decision - not only on technical grounds but also to manage expectations.
Let's face it: modifying XML in a plain text editor is - to most computer users - an awkward way to operate a PC. Using the "Leitzentrale" on Sculpt (EA or TC) is like an open-heart surgery where a typo at the wrong place can freeze your desktop. For most people, this is unacceptable. But for a few of us, it opens up a new world. To truly appreciate it, one needs a certain level of imagination and sophistication. Performing a surgery with a butter knife instead of a scalpel wouldn't make it any easier. Sculpt TC is targeted for "the curious". If one's curiosity stops when confronted with a few Vim commands, its better to wait for Sculpt VC.
Please note that Sculpt uses the Unix command-line interface (with bash, coreutils and vim) merely as an interim solution. It should not be mistaken as an intrinsic part of Sculpt. In the mid term, it will stay there as a last resort for investigating and fixing problems but remain out of the user's view most of the time. In the longer term, it will eventually vanish from the initial boot image.
Cheers Norman
-
Alexander Boettcher -
Christian Helmuth -
Emery Hemingway -
John J. Karcher -
Nobody III -
Norman Feske -
Stefan Kalkowski -
Steven Harp