<div dir="ltr"><div class="gmail_default">Hi</div><div class="gmail_default">   Norman-</div><div class="gmail_default"><br></div><div class="gmail_default">   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..</div><div class="gmail_default">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. </div><div class="gmail_default"><br></div><div class="gmail_default">   I find encouragement that Genode already supports the Zynq_7000 SOC.</div><div class="gmail_default">   Then it might be good to support at least one of the most common ARMv8_64 bit targets... most likely the Raspberry Pi 3..</div><div class="gmail_default"><br></div><div class="gmail_default">   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..</div><div class="gmail_default"><br></div><div class="gmail_default">   Hope this helps,</div><div class="gmail_default">      -Peter</div><div class="gmail_default"> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 21, 2016 at 4:04 AM, Norman Feske <span dir="ltr"><<a href="mailto:norman.feske@...141....1..." target="_blank">norman.feske@...1...</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone,<br>
<br>
the end of the year is approaching. So it is the right time to make up<br>
our minds for the upcoming year.<br>
<br>
<br>
Review of the past year<br>
-----------------------<br>
<br>
When reviewing the roadmap for 2016, it is quite clear that our initial<br>
goals moved a bit out of focus throughout the year. Our overall theme<br>
was to make Genode more easily available outside the inner circle of<br>
developers. Topics like system configuration, package management, and<br>
tutorials spring to mind. However, the four releases of 2016 were mostly<br>
concerned with base technologies rather than end-user facing features.<br>
Just to name a few topic:<br>
<br>
* RISC-V architecture<br>
* Hosting Genode on top of the Muen separation kernel<br>
* Using Genode with the seL4 kernel<br>
* Fundamental revision of the framework API<br>
* Huge device-driver improvements (like wifi, graphics, USB, ACPI)<br>
* Features like VirtualBox 5, virtual networking, TOR, Rust, ...<br>
<br>
There were two reasons behind this shift.<br>
<br>
First, exploring new ways to combine Genode with other technologies<br>
(like RISC-V, seL4, Muen) is very exciting from a developer's<br>
perspective and creates new opportunities for collaboration. On that<br>
account, I am particularly happy about the relationships that we now<br>
enjoy with the Muen and seL4 developers.<br>
<br>
Second, we realized that the concerns of the existing Genode users<br>
should be prioritized over extending the user base. The existing users<br>
are primarily interested in API stability and maturity. So personally, I<br>
made it my priority to free Genode from legacies and known architectural<br>
limitations. Over the year, we introduced and cultivated the new<br>
framework API that is designed for safety, achieved cross-kernel binary<br>
compatibility, and revised the framework's most fundamental protocols.<br>
This was quite a feat! Now, knowing that the time of sweeping<br>
architectural changes lies behind us, I feel much more confident that<br>
users of Genode will enjoy it.<br>
<br>
Even though we largely deviated from our original plan, I am very<br>
satisfied with the outcome of the past year. After all, the roadmap is a<br>
plan. Plans can be changed.<br>
<br>
<br>
My goals for 2017<br>
-----------------<br>
<br>
There are still two low-level construction sites left that I want to<br>
wrap up, which is the introduction of application binary interfaces<br>
(ABI) and ability to dynamically configure the init component. The ABIs<br>
largely decouple library implementations from their users and thereby<br>
will greatly ease the creation of a scalable package-management system<br>
on top of Genode. The dynamic init will potentially cover the use cases<br>
of most of today's custom-implemented Genode runtime environments (like<br>
launchpad, cli_monitor) by one versatile solution that scales well.<br>
This, in turn, will facilitate the creation of more sophisticated and<br>
dynamic Genode systems. In contrast to the "Turmvilla" scenario that I<br>
am currently using, such systems could be defined and reshaped not only<br>
at their build time but during runtime.<br>
<br>
With the ABI and dynamic init in place, I'd like to concentrate on<br>
stressing the framework, both in terms of using it much more intensively<br>
and by creating artificial stress. By the time of the release of version<br>
17.05, Genode should - in principle - be well suited for the the<br>
maintenance of a long-term supported version.<br>
<br>
When looking at my use of the Turmvilla scenario on my laptop, I see two<br>
principle limitations. First, the system is hard to set up. Installing<br>
it on a new machine is quite a burden. (i.e., I have shiny new x260 on<br>
my desk that gathers dust because I don't find the time to install<br>
Genode on it) This needs to be fixed! Second, the system does not stay<br>
up to date automatically. I would love to always use the components of<br>
the latest master branch so that I can detect and correct regressions<br>
that slip through our automated tests. Consequently, I need to craft a<br>
solution that allows me to update Genode on the fly and - if anything<br>
goes wrong = allows me to roll back to the previous version.<br>
<br>
There are many other ideas on the back of my head. But the topics<br>
outlined above are the most important ones for me.<br>
<br>
Now I am interested in your plans and goals for 2017! ;-)<br>
<br>
As every year, I will to consolidate the discussion into the official<br>
roadmap by mid of January.<br>
<br>
Cheers<br>
Norman<br>
<br>
--<br>
Dr.-Ing. Norman Feske<br>
Genode Labs<br>
<br>
<a href="http://www.genode-labs.com" rel="noreferrer" target="_blank">http://www.genode-labs.com</a> · <a href="http://genode.org" rel="noreferrer" target="_blank">http://genode.org</a><br>
<br>
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden<br>
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth<br>
<br>
------------------------------<wbr>------------------------------<wbr>------------------<br>
Developer Access Program for Intel Xeon Phi Processors<br>
Access to Intel Xeon Phi processor-based developer platforms.<br>
With one year of Intel Parallel Studio XE.<br>
Training and support from Colfax.<br>
Order your platform today.<a href="http://sdm.link/intel" rel="noreferrer" target="_blank">http://sdm.link/intel</a><br>
______________________________<wbr>_________________<br>
genode-main mailing list<br>
<a href="mailto:genode-main@lists.sourceforge.net">genode-main@...172...<wbr>net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/genode-main" rel="noreferrer" target="_blank">https://lists.sourceforge.net/<wbr>lists/listinfo/genode-main</a><br>
</blockquote></div><br></div>