Hello everyone,
the end of the year is approaching. So it is the right time to make up our minds for the upcoming year.
Review of the past year -----------------------
When reviewing the roadmap for 2016, it is quite clear that our initial goals moved a bit out of focus throughout the year. Our overall theme was to make Genode more easily available outside the inner circle of developers. Topics like system configuration, package management, and tutorials spring to mind. However, the four releases of 2016 were mostly concerned with base technologies rather than end-user facing features. Just to name a few topic:
* RISC-V architecture * Hosting Genode on top of the Muen separation kernel * Using Genode with the seL4 kernel * Fundamental revision of the framework API * Huge device-driver improvements (like wifi, graphics, USB, ACPI) * Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies (like RISC-V, seL4, Muen) is very exciting from a developer's perspective and creates new opportunities for collaboration. On that account, I am particularly happy about the relationships that we now enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users should be prioritized over extending the user base. The existing users are primarily interested in API stability and maturity. So personally, I made it my priority to free Genode from legacies and known architectural limitations. Over the year, we introduced and cultivated the new framework API that is designed for safety, achieved cross-kernel binary compatibility, and revised the framework's most fundamental protocols. This was quite a feat! Now, knowing that the time of sweeping architectural changes lies behind us, I feel much more confident that users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very satisfied with the outcome of the past year. After all, the roadmap is a plan. Plans can be changed.
My goals for 2017 -----------------
There are still two low-level construction sites left that I want to wrap up, which is the introduction of application binary interfaces (ABI) and ability to dynamically configure the init component. The ABIs largely decouple library implementations from their users and thereby will greatly ease the creation of a scalable package-management system on top of Genode. The dynamic init will potentially cover the use cases of most of today's custom-implemented Genode runtime environments (like launchpad, cli_monitor) by one versatile solution that scales well. This, in turn, will facilitate the creation of more sophisticated and dynamic Genode systems. In contrast to the "Turmvilla" scenario that I am currently using, such systems could be defined and reshaped not only at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on stressing the framework, both in terms of using it much more intensively and by creating artificial stress. By the time of the release of version 17.05, Genode should - in principle - be well suited for the the maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two principle limitations. First, the system is hard to set up. Installing it on a new machine is quite a burden. (i.e., I have shiny new x260 on my desk that gathers dust because I don't find the time to install Genode on it) This needs to be fixed! Second, the system does not stay up to date automatically. I would love to always use the components of the latest master branch so that I can detect and correct regressions that slip through our automated tests. Consequently, I need to craft a solution that allows me to update Genode on the fly and - if anything goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official roadmap by mid of January.
Cheers Norman
I would like to see Genode being compiled on Genode. I know that a run script exists for that, but it doesn't really work, especially given Genode's (build) dependence on tools that haven't been ported yet (e.g. expect, tclsh, autotools). Once all of Genode, including the ports of 3rd-party software, will build properly on Genode, testing and debugging will be faster and easier.
On Wed, Dec 21, 2016 at 5:04 AM, Norman Feske <norman.feske@...1...> wrote:
Hello everyone,
the end of the year is approaching. So it is the right time to make up our minds for the upcoming year.
Review of the past year
When reviewing the roadmap for 2016, it is quite clear that our initial goals moved a bit out of focus throughout the year. Our overall theme was to make Genode more easily available outside the inner circle of developers. Topics like system configuration, package management, and tutorials spring to mind. However, the four releases of 2016 were mostly concerned with base technologies rather than end-user facing features. Just to name a few topic:
- RISC-V architecture
- Hosting Genode on top of the Muen separation kernel
- Using Genode with the seL4 kernel
- Fundamental revision of the framework API
- Huge device-driver improvements (like wifi, graphics, USB, ACPI)
- Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies (like RISC-V, seL4, Muen) is very exciting from a developer's perspective and creates new opportunities for collaboration. On that account, I am particularly happy about the relationships that we now enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users should be prioritized over extending the user base. The existing users are primarily interested in API stability and maturity. So personally, I made it my priority to free Genode from legacies and known architectural limitations. Over the year, we introduced and cultivated the new framework API that is designed for safety, achieved cross-kernel binary compatibility, and revised the framework's most fundamental protocols. This was quite a feat! Now, knowing that the time of sweeping architectural changes lies behind us, I feel much more confident that users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very satisfied with the outcome of the past year. After all, the roadmap is a plan. Plans can be changed.
My goals for 2017
There are still two low-level construction sites left that I want to wrap up, which is the introduction of application binary interfaces (ABI) and ability to dynamically configure the init component. The ABIs largely decouple library implementations from their users and thereby will greatly ease the creation of a scalable package-management system on top of Genode. The dynamic init will potentially cover the use cases of most of today's custom-implemented Genode runtime environments (like launchpad, cli_monitor) by one versatile solution that scales well. This, in turn, will facilitate the creation of more sophisticated and dynamic Genode systems. In contrast to the "Turmvilla" scenario that I am currently using, such systems could be defined and reshaped not only at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on stressing the framework, both in terms of using it much more intensively and by creating artificial stress. By the time of the release of version 17.05, Genode should - in principle - be well suited for the the maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two principle limitations. First, the system is hard to set up. Installing it on a new machine is quite a burden. (i.e., I have shiny new x260 on my desk that gathers dust because I don't find the time to install Genode on it) This needs to be fixed! Second, the system does not stay up to date automatically. I would love to always use the components of the latest master branch so that I can detect and correct regressions that slip through our automated tests. Consequently, I need to craft a solution that allows me to update Genode on the fly and - if anything goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official roadmap by mid of January.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Ben,
I would like to see Genode being compiled on Genode. I know that a run script exists for that, but it doesn't really work, especially given Genode's (build) dependence on tools that haven't been ported yet (e.g. expect, tclsh, autotools). Once all of Genode, including the ports of 3rd-party software, will build properly on Genode, testing and debugging will be faster and easier.
this topic fits nicely into my ambition to stress Genode. I agree that hosting the entire build infrastructure and implementing the development workflow directly on Genode sounds intriguing.
The key to achieve that is to get noux up to speed, and to revisit some of its inner workings. I have some ideas in this respect that I'd like to try out. But before it is worthwhile to start with that, we should address a few limitations of its underpinnings, in particular the VFS.
Another day-to-day scenario that is much easier to realize - compared to the full development worklow - would be a multi-component email application where multiple noux instances are used for dedicated tasks like fetching email, browsing local folders, composing an email, or sending email. Each noux instance could be tailored to its purpose. E.g., the one for browsing the local folders wouldn't have network access. So emails stored locally cannot leak to the network. This scenario is less demanding than the development scenario and would possibly reach more users. So we might better first go for this one?
Cheers Norman
On Fri, Dec 23, 2016 at 09:17:09AM +0100, Norman Feske wrote:
The key to achieve that is to get noux up to speed, and to revisit some of its inner workings. I have some ideas in this respect that I'd like to try out. But before it is worthwhile to start with that, we should address a few limitations of its underpinnings, in particular the VFS.
Another day-to-day scenario that is much easier to realize - compared to the full development worklow - would be a multi-component email application where multiple noux instances are used for dedicated tasks like fetching email, browsing local folders, composing an email, or sending email. Each noux instance could be tailored to its purpose. E.g., the one for browsing the local folders wouldn't have network access. So emails stored locally cannot leak to the network. This scenario is less demanding than the development scenario and would possibly reach more users. So we might better first go for this one?
Cheers Norman
Interesting you'd mention this!
I have developed a GNU Bash-based application that does something like this on my system in conjunction with mutt, mbsync and msmtp. There's no reason it couldn't be ported to run in different Noux instances, or other clients/fetchers/senders as long as they're okay with handling Maildir systems.
It'd be interesting to get some use out of it since it's reached the peak point of '90% done' with most of the current system finished (including documentation), but without a non-programmer tutorial or support for more use cases than just mine. If you're interested I'll throw some code up on GitLab or GitHub with it.
Jookia.
Hi Norman-
Thanks for sharing your reflections of Genode development over the past and upcoming year... I like what I'm seeing, as well as the direction Genode development seems to be going in... That said, Yes getting Genode to run on your "shiny new Lenovo x260" would be a good thing!... here, basic leading edge platform support seem critical if the Genode community is to attract (and keep) more capable developers. I recently invested in a DELL XPS 15.. as the x250 suggested at the time only came with 16Gig of ram.. so if there is a Laptop hardware list that supports Genode development, I will help make it happen, but it would be great if supporting the DELL XPS 13, 15 were on the Genode development ToDo: list.
I find encouragement that Genode already supports the Zynq_7000 SOC. Then it might be good to support at least one of the most common ARMv8_64 bit targets... most likely the Raspberry Pi 3..
Yes package management will prove key for the longer run maintenance of the Genode OS... then, it would be realy nice if there were at least some level of cross compatibility with package management systems that are cumming into common use with other operating systems. Snappy and Docker are the two package management systems that come to mind here, but others may be able to bring more insight as to what might be best for the long term health of the Genode ecosystem..
Hope this helps, -Peter
On Wed, Dec 21, 2016 at 4:04 AM, Norman Feske <norman.feske@...1...> wrote:
Hello everyone,
the end of the year is approaching. So it is the right time to make up our minds for the upcoming year.
Review of the past year
When reviewing the roadmap for 2016, it is quite clear that our initial goals moved a bit out of focus throughout the year. Our overall theme was to make Genode more easily available outside the inner circle of developers. Topics like system configuration, package management, and tutorials spring to mind. However, the four releases of 2016 were mostly concerned with base technologies rather than end-user facing features. Just to name a few topic:
- RISC-V architecture
- Hosting Genode on top of the Muen separation kernel
- Using Genode with the seL4 kernel
- Fundamental revision of the framework API
- Huge device-driver improvements (like wifi, graphics, USB, ACPI)
- Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies (like RISC-V, seL4, Muen) is very exciting from a developer's perspective and creates new opportunities for collaboration. On that account, I am particularly happy about the relationships that we now enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users should be prioritized over extending the user base. The existing users are primarily interested in API stability and maturity. So personally, I made it my priority to free Genode from legacies and known architectural limitations. Over the year, we introduced and cultivated the new framework API that is designed for safety, achieved cross-kernel binary compatibility, and revised the framework's most fundamental protocols. This was quite a feat! Now, knowing that the time of sweeping architectural changes lies behind us, I feel much more confident that users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very satisfied with the outcome of the past year. After all, the roadmap is a plan. Plans can be changed.
My goals for 2017
There are still two low-level construction sites left that I want to wrap up, which is the introduction of application binary interfaces (ABI) and ability to dynamically configure the init component. The ABIs largely decouple library implementations from their users and thereby will greatly ease the creation of a scalable package-management system on top of Genode. The dynamic init will potentially cover the use cases of most of today's custom-implemented Genode runtime environments (like launchpad, cli_monitor) by one versatile solution that scales well. This, in turn, will facilitate the creation of more sophisticated and dynamic Genode systems. In contrast to the "Turmvilla" scenario that I am currently using, such systems could be defined and reshaped not only at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on stressing the framework, both in terms of using it much more intensively and by creating artificial stress. By the time of the release of version 17.05, Genode should - in principle - be well suited for the the maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two principle limitations. First, the system is hard to set up. Installing it on a new machine is quite a burden. (i.e., I have shiny new x260 on my desk that gathers dust because I don't find the time to install Genode on it) This needs to be fixed! Second, the system does not stay up to date automatically. I would love to always use the components of the latest master branch so that I can detect and correct regressions that slip through our automated tests. Consequently, I need to craft a solution that allows me to update Genode on the fly and - if anything goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official roadmap by mid of January.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Peter,
On Thu, Dec 22, 2016 at 03:29:53PM -0800, Peter Lindener wrote:
Yes getting Genode to run on your "shiny new Lenovo x260" would be a good thing!... here, basic leading edge platform support seem critical if the Genode community is to attract (and keep) more capable developers. I recently invested in a DELL XPS 15.. as the x250 suggested at the time only came with 16Gig of ram.. so if there is a Laptop hardware list that supports Genode development, I will help make it happen, but it would be great if supporting the DELL XPS 13, 15 were on the Genode development ToDo: list.
There is an unofficial hardware-compatibility list maintained by Josef Söntgen at http://usr.sysret.de/jws/genode/hcl.html that gathers what we, Genode Labs team, tested and also other Genode users reported. This said, hardware compatibility is already a kind of community effort and I doubt the Genode team in Dresden will be able to extend their efforts to enable specific x86 devices considerably more. If you like to help to enable the XPS 13/15, you are very welcome to post detailed hardware specifications, report which devices work currently and which don't as well as provide more information to help others to support you.
I find encouragement that Genode already supports the Zynq_7000 SOC. Then it might be good to support at least one of the most common ARMv8_64 bit targets... most likely the Raspberry Pi 3..
The Raspberry Pi 3 is fairly appealing platform and we also discussed to add support to Genode during some coffee breaks. For me the topic has two main questions: 1) What could be the main motivation to support the RPi 3 (or any other ARMv8 device)? 2) If we add support, to which extend (regarding peripherals) should we support the platform and can we avoid regressions in the future.
Both questions have much room for personal opinions, but for me the main motivation (1) can only be that I myself (or any other active participant of the Genode community) likes to use the device in a reasonable application scenario. Then regarding (2), the required support for peripherals is also defined and the user of the platform will naturally test the device, which uncovers regressions. Do you have an application scenario in mind?
Regards
Hi everyone,
for 2017 my goal is to get Intel graphics hardware support into Genode. By now I have the intel_fb driver running on Broadwell, featuring OpenGL and libDRM, all in one component. The future task is to separate the driver from libDRM and define some sort of GPU session so multiple clients can make use of the GPU.
Sebastian
On 12/21/2016 01:04 PM, Norman Feske wrote:
Hello everyone,
the end of the year is approaching. So it is the right time to make up our minds for the upcoming year.
Review of the past year
When reviewing the roadmap for 2016, it is quite clear that our initial goals moved a bit out of focus throughout the year. Our overall theme was to make Genode more easily available outside the inner circle of developers. Topics like system configuration, package management, and tutorials spring to mind. However, the four releases of 2016 were mostly concerned with base technologies rather than end-user facing features. Just to name a few topic:
- RISC-V architecture
- Hosting Genode on top of the Muen separation kernel
- Using Genode with the seL4 kernel
- Fundamental revision of the framework API
- Huge device-driver improvements (like wifi, graphics, USB, ACPI)
- Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies (like RISC-V, seL4, Muen) is very exciting from a developer's perspective and creates new opportunities for collaboration. On that account, I am particularly happy about the relationships that we now enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users should be prioritized over extending the user base. The existing users are primarily interested in API stability and maturity. So personally, I made it my priority to free Genode from legacies and known architectural limitations. Over the year, we introduced and cultivated the new framework API that is designed for safety, achieved cross-kernel binary compatibility, and revised the framework's most fundamental protocols. This was quite a feat! Now, knowing that the time of sweeping architectural changes lies behind us, I feel much more confident that users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very satisfied with the outcome of the past year. After all, the roadmap is a plan. Plans can be changed.
My goals for 2017
There are still two low-level construction sites left that I want to wrap up, which is the introduction of application binary interfaces (ABI) and ability to dynamically configure the init component. The ABIs largely decouple library implementations from their users and thereby will greatly ease the creation of a scalable package-management system on top of Genode. The dynamic init will potentially cover the use cases of most of today's custom-implemented Genode runtime environments (like launchpad, cli_monitor) by one versatile solution that scales well. This, in turn, will facilitate the creation of more sophisticated and dynamic Genode systems. In contrast to the "Turmvilla" scenario that I am currently using, such systems could be defined and reshaped not only at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on stressing the framework, both in terms of using it much more intensively and by creating artificial stress. By the time of the release of version 17.05, Genode should - in principle - be well suited for the the maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two principle limitations. First, the system is hard to set up. Installing it on a new machine is quite a burden. (i.e., I have shiny new x260 on my desk that gathers dust because I don't find the time to install Genode on it) This needs to be fixed! Second, the system does not stay up to date automatically. I would love to always use the components of the latest master branch so that I can detect and correct regressions that slip through our automated tests. Consequently, I need to craft a solution that allows me to update Genode on the fly and - if anything goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official roadmap by mid of January.
Cheers Norman
Hello,
On Wed, Dec 21, 2016 at 01:04:50PM +0100, Norman Feske wrote:
the end of the year is approaching. So it is the right time to make up our minds for the upcoming year.
Thanks Norman for keeping up the good tradition and igniting the discussion of the steps for 2017 in the "reflective" Christmas time ;-)
Review of the past year
I personally did not manage to setup my x250 for day-to-day work on Genode and that's a shame. But I had time to prepare a demonstration of the current features for talk I held in fall. During this time I identified some shortcomings beside the fact that switching to Genode is not just installation. However, the experience of using Genode and seeing how capable the OS already is ensures me that we're on the right track and that I myself have to _use_ the system to stay on that track.
Norman's goals for 2017
With the ABI and dynamic init in place, I'd like to concentrate on stressing the framework, both in terms of using it much more intensively and by creating artificial stress. By the time of the release of version 17.05, Genode should - in principle - be well suited for the the maintenance of a long-term supported version.
I will definitely help in this regard as much as possible, on the one hand for the reason I mentioned above and on the other hand to get more users to make their own hands-on experiences with Genode (and hopefully get infected). I'm convinced the rolling-update feature will be the pivotal point in this plan.
Now I am interested in your plans and goals for 2017! ;-)
My plan to work on Genode also includes to move reasonable workloads out of my beloved Linux working environment into native components on Genode. The major motivation is security resp. confidentiality of the manifold shapes of sensitive data. Therefore, I pursue the plan to implement my email workflow as a component-based Genode application. The ingredients are components for protocols (IMAP/SMTP), handling local mailboxes (currently I use mutt), editing mails (vim), and PGP support (gnupg).
I already see some additional obstacles on the path to communicate via email solely on Genode and my x250. First, the x250 has only a 13" screen but a FullHD resolution, so I need support for resizeable terminals with configurable/alternative font sizes. Also, I'm pretty clumsy when it comes to use the mouse on the desktop, so I'd like to keep my fingers on the keyboard as much as possible. Therefore, I'd like to revive the idea of a tiled window manager for Genode with support for virtual desktops. The icing on the cake (but not a real plan) is to support multiple monitors beyond the current mirror mode.
In addition to this plan, I see two less ambitious but nevertheless appealing improvements. First, I have been using SD cards as simple in-the-background backup solution for years. So, I'd like to enhance Genode's support for SD-card readers by PCI-SDHCI on x86 and a port of the rdiff-backup tool. I also learned that our Qt5 port is getting pretty dusty though represents our only available rich widget toolkit on Genode. So, we should update our port to version 5.7 of the Qt framework in 2017 and thereby benefit not only from the improvements and fixes feature-wise but also from enhancements in the Qt Platform Abstraction induced by Wayland etc.
Greets and Merry Christmas
Thanks, Norman, for sharing and starting the 'discussion'. Here are a few comments from my perspective:
1) I like the idea of the multi-component email application. Let me be a bit more visionary and extend this to a post-2017 scope: I am running my own mailserver (Kolab) for quite some years now. The reason once was (and still is) to protect my privacy. Sure, end-to-end encryption would also be a solution but has quite some drawbacks on the usability side. It appeals to me that running a multi-component mailserver on a Genode system could improve the security of those systems quite a bit. I believe Genode's component-based architecture already reflects the way emails are processed on current 'legacy' systems but provides better isolation and separation. Of course this would be a huge undertaking but I'd like to keep this in the back of my mind for the future beyond 2017.
2) @Christian: Thumbs up for the tiling window manager ;-)
3) About my goals: a) There will (hopefully) be some improvements for the Zynq-7000 (HDMI support, NIC performance issues). b) In addition, as you might know, we are investigating model-based methods for auto-configuration in a far wider scope that the typical Genode applications. However, I'd like to extract the essential mechanisms to make this usable for general-purpose Genode systems. The benefit of this would be that new users don't need to care about how to setup the config, e.g., for the Turmvilla scenario. This would also address an issue that pops up with the ABI, namely (in)compatibility between different versions of component binaries. c) I also plan to make extensive use of the tracing framework.
Cheers and happy holidays! Johannes
Hi Johannes,
- About my goals:
a) There will (hopefully) be some improvements for the Zynq-7000 (HDMI support, NIC performance issues).
Nice! I have already seen a glimpse of it in your world repository. ;-)
b) In addition, as you might know, we are investigating model-based methods for auto-configuration in a far wider scope that the typical Genode applications. However, I'd like to extract the essential mechanisms to make this usable for general-purpose Genode systems. The benefit of this would be that new users don't need to care about how to setup the config, e.g., for the Turmvilla scenario. This would also address an issue that pops up with the ABI, namely (in)compatibility between different versions of component binaries.
I really look forward to see how my current line of work regarding packaging/ABI/deployment aligns with your ideas.
c) I also plan to make extensive use of the tracing framework.
That's interesting to hear. In my opinion, the tracing framework is a really distinctive and under-appreciated feature of Genode. Literally each time we used it, it provided invaluable insights into the behavior of the system at almost no performance overhead. It's a pity that it is so rarely used. I'm afraid that this won't change unless we greatly improve the tooling around it. Right now, one has to manually craft a trace monitor for each scenario under test. In many cases, this is too much of a burden to start using it. It would be great if your work can contribute to make the tracing more accessible for everyone.
Cheers Norman
Hello list,
My plans for the next year:
Libc ----
This next release will hopefully feature a more asynchronous VFS library which can move a number of improvements at libc forward. When the internals of libc settle and stabilize, I hope to make performance improvements to libc for the sake of my next topic...
Package management ------------------
I had big hopes when I worked to port the Nix package manager to Genode, but in reality sourced-based package management was not economical when compared to native POSIX counterparts. However, a fixed ABI across kernels is a game-changer. I would like to combine this with asynchronous session requests and again experiment with alternative package management flows.
Nim ---
This year I successfully compiled and executed Nim language code for Genode, but next year I would like to take time to make proper C++ glue between the Nim standard library and Genode. My motivation is to port or build network applications written in a modern langauge rather than rely on the BSD sockets API.
Gaming ------
For me, gaming was the gateway drug to general purpose computing. I would like to see Genode able to play the same role for the next generation as DOS played for me. As a low priority task I hope to work towards making a gaming console like system using the "lego" composition technique. So a modular menuing system and maybe integrating some package management. Now that I have the Libretro API/ABI nearly supported, getting more games to run has been more or less trivial.
Best wishes for 2017, Emery
Hello,
My personal roadmap was written on a sleepless night before 33C3, not a great idea as I expected that I would probably would have alterations after congress, so here is an ammendment.
I still haven't made it through my list of talks to watch at home but the talk of most immediate interest to me was 'Bootstraping a slightly more secure laptop' - https://trmm.net/Heads_33c3
The TL;DR is that if coreboot can execute Linux from flash and bypass the BIOS, MBR, and UEFI, then the TCB of the boot process shrinks. The boot process can also be measured with and verified with a TPM.
My though of course was that the same could be done with Genode, so another project I would like to work on this year is to replace some of the legacy bootstrapping stages on my laptop. This will be a piecemeal path, replacing GRUB, interoptibilty with coreboot, and maybe some TPM support. I plan to work cautiously and no more than one step ahead of what I can actually boot with.
Cheers, Emery
Hello,
The TL;DR is that if coreboot can execute Linux from flash and bypass the BIOS, MBR, and UEFI, then the TCB of the boot process shrinks. The boot process can also be measured with and verified with a TPM.
this is certainly an interesting direction to explore! I agree that we have to eventually overcome our current dependency from the legacy multi-boot method. Your ambition is one extreme end of the spectrum. Another topic would be the support for UEFI boot.
As a further addition to our road map with respect to my goal for a long-term supportable version 17.05, I would like to add a tool-chain update. It is sensible to update it before this point so the longer-term maintenance will be based on the same tool chain as used by the ongoing development for about 18-24 months (which is our typical interval for tool-chain updates).
From the updated tool chain, I hope to get the following benefits:
* Support for C++14, C++17 * Better support for reproducible builds * The uniform definition of 'size_t' as 'unsigned long' to harmonize the ABIs of C++ libraries like Qt5 across 32/64-bit architectures (this will be specific to Genode's tool chain) * Tighter integration of the tool chain with Genode's ports mechanism and build system. (right now, we use a separate tool-chain creation script, which does not ensure that the used tool chain matches the Genode version)
Cheers Norman
Thanks for sharing,
About the package management on the road map: It would be nice if Genode was the first system that really protects you from hostile programs. And not in the Apple way (trust us).
End point security is really important these days. I think it's important you can install packages you don't trust that much while maintaining as much security as possible.
Greetings, Frank
Op 21-12-2016 om 13:04 schreef Norman Feske:
Hello everyone,
the end of the year is approaching. So it is the right time to make up our minds for the upcoming year.
Review of the past year
When reviewing the roadmap for 2016, it is quite clear that our initial goals moved a bit out of focus throughout the year. Our overall theme was to make Genode more easily available outside the inner circle of developers. Topics like system configuration, package management, and tutorials spring to mind. However, the four releases of 2016 were mostly concerned with base technologies rather than end-user facing features. Just to name a few topic:
- RISC-V architecture
- Hosting Genode on top of the Muen separation kernel
- Using Genode with the seL4 kernel
- Fundamental revision of the framework API
- Huge device-driver improvements (like wifi, graphics, USB, ACPI)
- Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies (like RISC-V, seL4, Muen) is very exciting from a developer's perspective and creates new opportunities for collaboration. On that account, I am particularly happy about the relationships that we now enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users should be prioritized over extending the user base. The existing users are primarily interested in API stability and maturity. So personally, I made it my priority to free Genode from legacies and known architectural limitations. Over the year, we introduced and cultivated the new framework API that is designed for safety, achieved cross-kernel binary compatibility, and revised the framework's most fundamental protocols. This was quite a feat! Now, knowing that the time of sweeping architectural changes lies behind us, I feel much more confident that users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very satisfied with the outcome of the past year. After all, the roadmap is a plan. Plans can be changed.
My goals for 2017
There are still two low-level construction sites left that I want to wrap up, which is the introduction of application binary interfaces (ABI) and ability to dynamically configure the init component. The ABIs largely decouple library implementations from their users and thereby will greatly ease the creation of a scalable package-management system on top of Genode. The dynamic init will potentially cover the use cases of most of today's custom-implemented Genode runtime environments (like launchpad, cli_monitor) by one versatile solution that scales well. This, in turn, will facilitate the creation of more sophisticated and dynamic Genode systems. In contrast to the "Turmvilla" scenario that I am currently using, such systems could be defined and reshaped not only at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on stressing the framework, both in terms of using it much more intensively and by creating artificial stress. By the time of the release of version 17.05, Genode should - in principle - be well suited for the the maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two principle limitations. First, the system is hard to set up. Installing it on a new machine is quite a burden. (i.e., I have shiny new x260 on my desk that gathers dust because I don't find the time to install Genode on it) This needs to be fixed! Second, the system does not stay up to date automatically. I would love to always use the components of the latest master branch so that I can detect and correct regressions that slip through our automated tests. Consequently, I need to craft a solution that allows me to update Genode on the fly and - if anything goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official roadmap by mid of January.
Cheers Norman
Reiterating on Frank's reflection as for the need for truly secure package management systems (A real reason to use the Genode OS)..
a voter's keyword rule based issue by issue proxy delegation agent(s) (liquid democracy) will often be implemented by other's, on occasion less trusted... with news swirling in the press about election hacking... providing a truly secure OS that can host a collection of less than fully trusted agent's who's activity's can be fully monitored... seems like a real win as a foundation upon which tomorrow's more properly functioning democracy's might be built..
Genode running on 2nd gen LowRisc seems like the ticket here... lets bring it ON!
-Peter
On Thu, Jan 5, 2017 at 7:23 AM, Frank <frank87@...411...> wrote:
Thanks for sharing,
About the package management on the road map: It would be nice if Genode was the first system that really protects you from hostile programs. And not in the Apple way (trust us).
End point security is really important these days. I think it's important you can install packages you don't trust that much while maintaining as much security as possible.
Greetings, Frank
Op 21-12-2016 om 13:04 schreef Norman Feske:
Hello everyone,
the end of the year is approaching. So it is the right time to make up our minds for the upcoming year.
Review of the past year
When reviewing the roadmap for 2016, it is quite clear that our initial goals moved a bit out of focus throughout the year. Our overall theme was to make Genode more easily available outside the inner circle of developers. Topics like system configuration, package management, and tutorials spring to mind. However, the four releases of 2016 were mostly concerned with base technologies rather than end-user facing features. Just to name a few topic:
- RISC-V architecture
- Hosting Genode on top of the Muen separation kernel
- Using Genode with the seL4 kernel
- Fundamental revision of the framework API
- Huge device-driver improvements (like wifi, graphics, USB, ACPI)
- Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies (like RISC-V, seL4, Muen) is very exciting from a developer's perspective and creates new opportunities for collaboration. On that account, I am particularly happy about the relationships that we now enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users should be prioritized over extending the user base. The existing users are primarily interested in API stability and maturity. So personally, I made it my priority to free Genode from legacies and known architectural limitations. Over the year, we introduced and cultivated the new framework API that is designed for safety, achieved cross-kernel binary compatibility, and revised the framework's most fundamental protocols. This was quite a feat! Now, knowing that the time of sweeping architectural changes lies behind us, I feel much more confident that users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very satisfied with the outcome of the past year. After all, the roadmap is a plan. Plans can be changed.
My goals for 2017
There are still two low-level construction sites left that I want to wrap up, which is the introduction of application binary interfaces (ABI) and ability to dynamically configure the init component. The ABIs largely decouple library implementations from their users and thereby will greatly ease the creation of a scalable package-management system on top of Genode. The dynamic init will potentially cover the use cases of most of today's custom-implemented Genode runtime environments (like launchpad, cli_monitor) by one versatile solution that scales well. This, in turn, will facilitate the creation of more sophisticated and dynamic Genode systems. In contrast to the "Turmvilla" scenario that I am currently using, such systems could be defined and reshaped not only at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on stressing the framework, both in terms of using it much more intensively and by creating artificial stress. By the time of the release of version 17.05, Genode should - in principle - be well suited for the the maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two principle limitations. First, the system is hard to set up. Installing it on a new machine is quite a burden. (i.e., I have shiny new x260 on my desk that gathers dust because I don't find the time to install Genode on it) This needs to be fixed! Second, the system does not stay up to date automatically. I would love to always use the components of the latest master branch so that I can detect and correct regressions that slip through our automated tests. Consequently, I need to craft a solution that allows me to update Genode on the fly and - if anything goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official roadmap by mid of January.
Cheers Norman
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
Electronic voting is a step further: you have to trust computers you don't control yourself.
But it would be nice if hackers can't use a game to install a keylogger, and intercept all your encrypted communication. People want to play downloaded games on the same computer they use to do banking. Tor, PGP, and https, are useless when your computer is owned by some hacker (government or criminal)
Greetings, Frank
Op 5-1-2017 om 21:35 schreef Peter Lindener:
Reiterating on Frank's reflection as for the need for truly secure package management systems (A real reason to use the Genode OS)..
a voter's keyword rule based issue by issue proxy delegation agent(s) (liquid democracy) will often be implemented by other's, on occasion less trusted... with news swirling in the press about election hacking... providing a truly secure OS that can host a collection of less than fully trusted agent's who's activity's can be fully monitored... seems like a real win as a foundation upon which tomorrow's more properly functioning democracy's might be built..
Genode running on 2nd gen LowRisc seems like the ticket here... lets bring it ON!
-PeterOn Thu, Jan 5, 2017 at 7:23 AM, Frank <frank87@...411... mailto:frank87@...411...> wrote:
Thanks for sharing, About the package management on the road map: It would be nice if Genode was the first system that really protects you from hostile programs. And not in the Apple way (trust us). End point security is really important these days. I think it's important you can install packages you don't trust that much while maintaining as much security as possible. Greetings, Frank Op 21-12-2016 om 13:04 schreef Norman Feske: > Hello everyone, > > the end of the year is approaching. So it is the right time to make up > our minds for the upcoming year. > > > Review of the past year > ----------------------- > > When reviewing the roadmap for 2016, it is quite clear that our initial > goals moved a bit out of focus throughout the year. Our overall theme > was to make Genode more easily available outside the inner circle of > developers. Topics like system configuration, package management, and > tutorials spring to mind. However, the four releases of 2016 were mostly > concerned with base technologies rather than end-user facing features. > Just to name a few topic: > > * RISC-V architecture > * Hosting Genode on top of the Muen separation kernel > * Using Genode with the seL4 kernel > * Fundamental revision of the framework API > * Huge device-driver improvements (like wifi, graphics, USB, ACPI) > * Features like VirtualBox 5, virtual networking, TOR, Rust, ... > > There were two reasons behind this shift. > > First, exploring new ways to combine Genode with other technologies > (like RISC-V, seL4, Muen) is very exciting from a developer's > perspective and creates new opportunities for collaboration. On that > account, I am particularly happy about the relationships that we now > enjoy with the Muen and seL4 developers. > > Second, we realized that the concerns of the existing Genode users > should be prioritized over extending the user base. The existing users > are primarily interested in API stability and maturity. So personally, I > made it my priority to free Genode from legacies and known architectural > limitations. Over the year, we introduced and cultivated the new > framework API that is designed for safety, achieved cross-kernel binary > compatibility, and revised the framework's most fundamental protocols. > This was quite a feat! Now, knowing that the time of sweeping > architectural changes lies behind us, I feel much more confident that > users of Genode will enjoy it. > > Even though we largely deviated from our original plan, I am very > satisfied with the outcome of the past year. After all, the roadmap is a > plan. Plans can be changed. > > > My goals for 2017 > ----------------- > > There are still two low-level construction sites left that I want to > wrap up, which is the introduction of application binary interfaces > (ABI) and ability to dynamically configure the init component. The ABIs > largely decouple library implementations from their users and thereby > will greatly ease the creation of a scalable package-management system > on top of Genode. The dynamic init will potentially cover the use cases > of most of today's custom-implemented Genode runtime environments (like > launchpad, cli_monitor) by one versatile solution that scales well. > This, in turn, will facilitate the creation of more sophisticated and > dynamic Genode systems. In contrast to the "Turmvilla" scenario that I > am currently using, such systems could be defined and reshaped not only > at their build time but during runtime. > > With the ABI and dynamic init in place, I'd like to concentrate on > stressing the framework, both in terms of using it much more intensively > and by creating artificial stress. By the time of the release of version > 17.05, Genode should - in principle - be well suited for the the > maintenance of a long-term supported version. > > When looking at my use of the Turmvilla scenario on my laptop, I see two > principle limitations. First, the system is hard to set up. Installing > it on a new machine is quite a burden. (i.e., I have shiny new x260 on > my desk that gathers dust because I don't find the time to install > Genode on it) This needs to be fixed! Second, the system does not stay > up to date automatically. I would love to always use the components of > the latest master branch so that I can detect and correct regressions > that slip through our automated tests. Consequently, I need to craft a > solution that allows me to update Genode on the fly and - if anything > goes wrong = allows me to roll back to the previous version. > > There are many other ideas on the back of my head. But the topics > outlined above are the most important ones for me. > > Now I am interested in your plans and goals for 2017! ;-) > > As every year, I will to consolidate the discussion into the official > roadmap by mid of January. > > Cheers > Norman > ------------------------------------------------------------------------------ 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 <mailto:genode-main@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/genode-main <https://lists.sourceforge.net/lists/listinfo/genode-main>
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
Franks observation : "*you have to trust computers you don't control yourself*." is true up to the point where many computer's run by independent organizations are configured to automatically cross audit each other.. As I see it Genode could help with secure hosting of this kind of error monitored distributed computation service (Grove-Clarke Mechanism based strategic approval voting game equilibrium solver)...
then, none of this seems viable without the kind of more rigorous security that Genode's hierarchical structure promises to provide.. the rise of Genode can not come soon enough to address the current disarray in cyber space.
-Peter
On Thu, Jan 5, 2017 at 3:02 PM, Frank <frank87@...411...> wrote:
Electronic voting is a step further: you have to trust computers you don't control yourself.
But it would be nice if hackers can't use a game to install a keylogger, and intercept all your encrypted communication. People want to play downloaded games on the same computer they use to do banking. Tor, PGP, and https, are useless when your computer is owned by some hacker (government or criminal)
Greetings, Frank
Op 5-1-2017 om 21:35 schreef Peter Lindener:
Reiterating on Frank's reflection as for the need for truly secure package management systems (A real reason to use the Genode OS)..
a voter's keyword rule based issue by issue proxy delegation agent(s) (liquid democracy) will often be implemented by other's, on occasion less trusted... with news swirling in the press about election hacking... providing a truly secure OS that can host a collection of less than fully trusted agent's who's activity's can be fully monitored... seems like a real win as a foundation upon which tomorrow's more properly functioning democracy's might be built..
Genode running on 2nd gen LowRisc seems like the ticket here... lets bring it ON!
-PeterOn Thu, Jan 5, 2017 at 7:23 AM, Frank <frank87@...411... mailto:frank87@...411...> wrote:
Thanks for sharing, About the package management on the road map: It would be nice if Genode was the first system that really protects you from hostile programs. And not in the Apple way (trust us). End point security is really important these days. I think it's important you can install packages you don't trust that much while maintaining as much security as possible. Greetings, Frank Op 21-12-2016 om 13:04 schreef Norman Feske: > Hello everyone, > > the end of the year is approaching. So it is the right time to make up > our minds for the upcoming year. > > > Review of the past year > ----------------------- > > When reviewing the roadmap for 2016, it is quite clear that our initial > goals moved a bit out of focus throughout the year. Our overall theme > was to make Genode more easily available outside the inner circleof
> developers. Topics like system configuration, package management, and > tutorials spring to mind. However, the four releases of 2016 were mostly > concerned with base technologies rather than end-user facing features. > Just to name a few topic: > > * RISC-V architecture > * Hosting Genode on top of the Muen separation kernel > * Using Genode with the seL4 kernel > * Fundamental revision of the framework API > * Huge device-driver improvements (like wifi, graphics, USB, ACPI) > * Features like VirtualBox 5, virtual networking, TOR, Rust, ... > > There were two reasons behind this shift. > > First, exploring new ways to combine Genode with other technologies > (like RISC-V, seL4, Muen) is very exciting from a developer's > perspective and creates new opportunities for collaboration. Onthat
> account, I am particularly happy about the relationships that wenow
> enjoy with the Muen and seL4 developers. > > Second, we realized that the concerns of the existing Genode users > should be prioritized over extending the user base. The existing users > are primarily interested in API stability and maturity. So personally, I > made it my priority to free Genode from legacies and known architectural > limitations. Over the year, we introduced and cultivated the new > framework API that is designed for safety, achieved cross-kernel binary > compatibility, and revised the framework's most fundamental protocols. > This was quite a feat! Now, knowing that the time of sweeping > architectural changes lies behind us, I feel much more confident that > users of Genode will enjoy it. > > Even though we largely deviated from our original plan, I am very > satisfied with the outcome of the past year. After all, the roadmap is a > plan. Plans can be changed. > > > My goals for 2017 > ----------------- > > There are still two low-level construction sites left that I wantto
> wrap up, which is the introduction of application binary interfaces > (ABI) and ability to dynamically configure the init component. The ABIs > largely decouple library implementations from their users and thereby > will greatly ease the creation of a scalable package-management system > on top of Genode. The dynamic init will potentially cover the use cases > of most of today's custom-implemented Genode runtime environments (like > launchpad, cli_monitor) by one versatile solution that scales well. > This, in turn, will facilitate the creation of more sophisticated and > dynamic Genode systems. In contrast to the "Turmvilla" scenario that I > am currently using, such systems could be defined and reshaped not only > at their build time but during runtime. > > With the ABI and dynamic init in place, I'd like to concentrate on > stressing the framework, both in terms of using it much more intensively > and by creating artificial stress. By the time of the release of version > 17.05, Genode should - in principle - be well suited for the the > maintenance of a long-term supported version. > > When looking at my use of the Turmvilla scenario on my laptop, I see two > principle limitations. First, the system is hard to set up. Installing > it on a new machine is quite a burden. (i.e., I have shiny new x260 on > my desk that gathers dust because I don't find the time to install > Genode on it) This needs to be fixed! Second, the system does not stay > up to date automatically. I would love to always use the components of > the latest master branch so that I can detect and correct regressions > that slip through our automated tests. Consequently, I need to craft a > solution that allows me to update Genode on the fly and - if anything > goes wrong = allows me to roll back to the previous version. > > There are many other ideas on the back of my head. But the topics > outlined above are the most important ones for me. > > Now I am interested in your plans and goals for 2017! ;-) > > As every year, I will to consolidate the discussion into the official > roadmap by mid of January. > > Cheers > Norman > ------------------------------------------------------------
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 <mailto:genode-main@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/genode-main <https://lists.sourceforge.net/lists/listinfo/genode-main>
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
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
I am actually designing a voting machine right now ! We are looking at Genode but the Indian voting machine in its current incarnation is fairly simple, so a full OS seems an overkill. A small rtos that can be formally verified seems more appropriate.
HW platform is tentatively i.MX7 or I.MX8, so trustzone with high assurance boot and tamper is available. i.MX8 variants also provide hw isolation and dram encryption. So a pretty good HW base for a secure platform.
On Fri, Jan 6, 2017 at 2:05 AM, Peter Lindener <lindener.peter@...9...> wrote:
Reiterating on Frank's reflection as for the need for truly secure package management systems (A real reason to use the Genode OS)..
a voter's keyword rule based issue by issue proxy delegation agent(s) (liquid democracy) will often be implemented by other's, on occasion less trusted... with news swirling in the press about election hacking... providing a truly secure OS that can host a collection of less than fully trusted agent's who's activity's can be fully monitored... seems like a real win as a foundation upon which tomorrow's more properly functioning democracy's might be built..
Genode running on 2nd gen LowRisc seems like the ticket here... lets bring it ON!
-PeterOn Thu, Jan 5, 2017 at 7:23 AM, Frank <frank87@...411...> wrote:
Thanks for sharing,
About the package management on the road map: It would be nice if Genode was the first system that really protects you from hostile programs. And not in the Apple way (trust us).
End point security is really important these days. I think it's important you can install packages you don't trust that much while maintaining as much security as possible.
Greetings, Frank
Op 21-12-2016 om 13:04 schreef Norman Feske:
Hello everyone,
the end of the year is approaching. So it is the right time to make up our minds for the upcoming year.
Review of the past year
When reviewing the roadmap for 2016, it is quite clear that our initial goals moved a bit out of focus throughout the year. Our overall theme was to make Genode more easily available outside the inner circle of developers. Topics like system configuration, package management, and tutorials spring to mind. However, the four releases of 2016 were mostly concerned with base technologies rather than end-user facing features. Just to name a few topic:
- RISC-V architecture
- Hosting Genode on top of the Muen separation kernel
- Using Genode with the seL4 kernel
- Fundamental revision of the framework API
- Huge device-driver improvements (like wifi, graphics, USB, ACPI)
- Features like VirtualBox 5, virtual networking, TOR, Rust, ...
There were two reasons behind this shift.
First, exploring new ways to combine Genode with other technologies (like RISC-V, seL4, Muen) is very exciting from a developer's perspective and creates new opportunities for collaboration. On that account, I am particularly happy about the relationships that we now enjoy with the Muen and seL4 developers.
Second, we realized that the concerns of the existing Genode users should be prioritized over extending the user base. The existing users are primarily interested in API stability and maturity. So personally, I made it my priority to free Genode from legacies and known architectural limitations. Over the year, we introduced and cultivated the new framework API that is designed for safety, achieved cross-kernel binary compatibility, and revised the framework's most fundamental protocols. This was quite a feat! Now, knowing that the time of sweeping architectural changes lies behind us, I feel much more confident that users of Genode will enjoy it.
Even though we largely deviated from our original plan, I am very satisfied with the outcome of the past year. After all, the roadmap is a plan. Plans can be changed.
My goals for 2017
There are still two low-level construction sites left that I want to wrap up, which is the introduction of application binary interfaces (ABI) and ability to dynamically configure the init component. The ABIs largely decouple library implementations from their users and thereby will greatly ease the creation of a scalable package-management system on top of Genode. The dynamic init will potentially cover the use cases of most of today's custom-implemented Genode runtime environments (like launchpad, cli_monitor) by one versatile solution that scales well. This, in turn, will facilitate the creation of more sophisticated and dynamic Genode systems. In contrast to the "Turmvilla" scenario that I am currently using, such systems could be defined and reshaped not only at their build time but during runtime.
With the ABI and dynamic init in place, I'd like to concentrate on stressing the framework, both in terms of using it much more intensively and by creating artificial stress. By the time of the release of version 17.05, Genode should - in principle - be well suited for the the maintenance of a long-term supported version.
When looking at my use of the Turmvilla scenario on my laptop, I see two principle limitations. First, the system is hard to set up. Installing it on a new machine is quite a burden. (i.e., I have shiny new x260 on my desk that gathers dust because I don't find the time to install Genode on it) This needs to be fixed! Second, the system does not stay up to date automatically. I would love to always use the components of the latest master branch so that I can detect and correct regressions that slip through our automated tests. Consequently, I need to craft a solution that allows me to update Genode on the fly and - if anything goes wrong = allows me to roll back to the previous version.
There are many other ideas on the back of my head. But the topics outlined above are the most important ones for me.
Now I am interested in your plans and goals for 2017! ;-)
As every year, I will to consolidate the discussion into the official roadmap by mid of January.
Cheers Norman
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
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
Hello everyone,
looking back at the the roadmap of 2016 it is clear that we missed some items; nevertheless, I think all in all the year went well. Norman already noted some observations, namely prioritizing the existing user base over the future one. Looking back at this week's clean-up efforts I believe that spending more time on refining the base APIs was indeed the right decision. Using the new interface or switching the used kernel seamlessly while testing components feels so natural now and with the ABI mechanism provides a great foundation for building the infrastructure for package/deployment management.
That being said, one thing I missed from last year's roadmap discussion (although I am not sure if that was actually discussed on the ML or only at a coffee break) is the intention of making more information about Genode available to and by the community, i.e. in the form of writing how-tos for specific tasks or just by writing informally about interesting things that happend while working on Genode. Since parts of the APIs were or are still in flux I understand that it is difficult to write detailed articles that are valid for the years to come and probably one of the reason why one hesitates to spend time on that. That merely leaves the more informal part. Judging by the huge amount of out-dated information for <insert your favourite topic here> in all the weblogs on the internet I am not sure if spending time on that is a good idea either. Than again, were is the harm in documenting the process of writing a new component or porting existing software [1] to Genode? After all it should be fine if the focus is more on the process or the methodology. So, that is a goal of mine for 2017 — scheduled (emphasis on that) writing about what I do with Genode in hope that it is useful to somebody or even that others join in :-)
[1] FWIW http://usr.sysret.de/jws/genode/porting_wishlist.html
Apart from that, I am afraid I have no precise items for this year's roadmap. I agree with Norman; we need the infrastructure to keep a running Genode system in sync to the latest changes to provide better test coverage. I imagine that this will keep us busy for some time and there are still some items from the old roadmap left that needs to be addressed as well.
Regards Josef
Fellow genodians-
Now that Genode's base API is going totally async..
it would be great to see an example of some cooperating processes where each might have the flexibility to across the network of different machines... I realize there are plenty systems for supporting an RPC... but I gather Genode's new Async perspective, might also better inform how one might best configure and synchronize / clean_up a set of processes exchanging data and running possibly on different machines..
That is: an example of how one might best do RPC like things within the philosophy of the new Genode API would be very helpful... it could start as more of a toy program, but the thought here is that we might polish and maintain it as part of Genode's getting started / coding style documentation...
Is there an existing Genode RPC like example that might be a good starting point ?
-Peter
On Sat, Jan 7, 2017 at 6:33 AM, Josef Söntgen < josef.soentgen@...1...> wrote:
Hello everyone,
looking back at the the roadmap of 2016 it is clear that we missed some items; nevertheless, I think all in all the year went well. Norman already noted some observations, namely prioritizing the existing user base over the future one. Looking back at this week's clean-up efforts I believe that spending more time on refining the base APIs was indeed the right decision. Using the new interface or switching the used kernel seamlessly while testing components feels so natural now and with the ABI mechanism provides a great foundation for building the infrastructure for package/deployment management.
That being said, one thing I missed from last year's roadmap discussion (although I am not sure if that was actually discussed on the ML or only at a coffee break) is the intention of making more information about Genode available to and by the community, i.e. in the form of writing how-tos for specific tasks or just by writing informally about interesting things that happend while working on Genode. Since parts of the APIs were or are still in flux I understand that it is difficult to write detailed articles that are valid for the years to come and probably one of the reason why one hesitates to spend time on that. That merely leaves the more informal part. Judging by the huge amount of out-dated information for <insert your favourite topic here> in all the weblogs on the internet I am not sure if spending time on that is a good idea either. Than again, were is the harm in documenting the process of writing a new component or porting existing software [1] to Genode? After all it should be fine if the focus is more on the process or the methodology. So, that is a goal of mine for 2017 — scheduled (emphasis on that) writing about what I do with Genode in hope that it is useful to somebody or even that others join in :-)
[1] FWIW http://usr.sysret.de/jws/genode/porting_wishlist.html
Apart from that, I am afraid I have no precise items for this year's roadmap. I agree with Norman; we need the infrastructure to keep a running Genode system in sync to the latest changes to provide better test coverage. I imagine that this will keep us busy for some time and there are still some items from the old roadmap left that needs to be addressed as well.
Regards Josef
-- Josef Söntgen Genode Labs
http://www.genode-labs.com/ · http://genode.org/
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
Hello,
My plans for this year:
* Enhance the Timeout framework to use the performance counters for time interpolation and RTCs for timestamps
* A server for DHCP and dynamic NIC router configurations to enable dynamic network configuration
* More automated testing of block drivers and graphical applications (screenshots, screencasts, pixel hashsums, scripted input)
* Continue my work on remote input and framebuffer
Cheers, Martin
Hi Josef,
looking back at the the roadmap of 2016 it is clear that we missed some items; nevertheless, I think all in all the year went well. Norman already noted some observations, namely prioritizing the existing user base over the future one. Looking back at this week's clean-up efforts I believe that spending more time on refining the base APIs was indeed the right decision. Using the new interface or switching the used kernel seamlessly while testing components feels so natural now and with the ABI mechanism provides a great foundation for building the infrastructure for package/deployment management.
it's really nice to read your reflection, now that we adapted a significant amount of components to the new API. This is exactly what I hoped to achieve with the new API!
That being said, one thing I missed from last year's roadmap discussion (although I am not sure if that was actually discussed on the ML or only at a coffee break) is the intention of making more information about Genode available to and by the community, i.e. in the form of writing how-tos for specific tasks or just by writing informally about interesting things that happend while working on Genode. Since parts of the APIs were or are still in flux I understand that it is difficult to write detailed articles that are valid for the years to come and probably one of the reason why one hesitates to spend time on that. That merely leaves the more informal part. Judging by the huge amount of out-dated information for <insert your favourite topic here> in all the weblogs on the internet I am not sure if spending time on that is a good idea either. Than again, were is the harm in documenting the process of writing a new component or porting existing software [1] to Genode? After all it should be fine if the focus is more on the process or the methodology. So, that is a goal of mine for 2017 — scheduled (emphasis on that) writing about what I do with Genode in hope that it is useful to somebody or even that others join in :-)
I like the idea very much. Dropping a comprehensive release-notes document every three months is not perfect to keep the attention of interested bystanders captured. A blog-like format would be a very good addition!
Cheers Norman
Hello,
thanks to everyone who participated in the road-map discussion! I have compiled the official road map now:
https://genode.org/about/road-map
I hope that it captures well our overall discussion.
There are a few topics that were discussed but did not appear on the official road map (like Johannes' Zynq line of work, Emery's gaming topic, or Martin's i.MX6 topic). Please don't take this as discouragement. Those topics are very interesting and valuable but I felt uneasy to make the road map too much dependent on your individual plans and thereby needlessly putting pressure on you. I think that it is better to deliver those features without prior announcement than to over-promise. Do you agree?
Cheers Norman
-
Christian Helmuth -
Emery Hemingway -
Frank -
Johannes Schlatow -
Jookia -
Josef Söntgen -
Madhu Macaque Labs -
Martin Stein -
Nobody III -
Norman Feske -
Peter Lindener -
Sebastian Sumpf