Re: Roadmap 2018

2018-01-22 Thread Christian Helmuth
Hello,

thanks for your input and ideas. In fact, the ebook reader as a
potential Genode target pops up from time to time, but it never gained
traction though. In my opinion one reason is a lack of interest in the
current developer community as there are many other attractive
targets. Another reason is the diversity of hardware platforms and
peripherals used in embedded devices as well as power-management
demands, which always brings a significant increase of efforts to
enable devices to a useful degree. I appreciate you sharing that
valuable information about the ereader hardware landscape, which may
help to spark some interest in the community. We core developers
decided on the more desktop-oriented Sculpt (and a touch of
networking) for this year's roadmap.

The upcoming version of the Genode Foundations book will be published
in the usual PDF but also in ebook formats. Because of personal
interest, I'll revive and optimize the unofficial EPUB version we had
in the past.

Greets
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth


On Mon, Jan 15, 2018 at 01:38:26PM +0100, t...@gmx.net wrote:
> Having followed Genode's interesting quarterly development updates
> for quite some time, I hope to finally make a move towards a
> hands-on understanding and therefore set the modest goal for myself
> to at least read the entire handbook this year. Not as exciting as
> committing to any real development work, but hopefully easy enough
> to actually achieve and leaving room for more.
> 
> On to wishes.
> 
> 1. I think, it would be a good side project for developers, to add
> support for at least one ebook reader. My reasoning behind this is,
> that these devices are relatively cheap and actually useful beyond
> (embedded) software development work and seem to offer an easy
> enough application scenario to support. This could also raise
> awareness of Genode's existence beyond the current level.
> 
> Ereaders' innovation cycles are more developer friendly than, say,
> laptops', tablets' or smartphones' and the hardware used is more
> homogeneous. Many current models still use the i.MX6 SoC, including
> Kindle and Tolino devices, which Genode developers seem to be
> willing to support anyway.
> 
> The Tolino Shine 2HD, for instance, would appear to be an attractive
> target, since it boots from a microSD card, which could easily be
> replaced by one with a Genode image on it. While the technically
> very similar Kobo Glo HD does not seem to be sold any longer in
> Germany, it might still be in other countries (otherwise, I would
> have suggested the Glo HD, since its case is easier to open; Tolino
> and Kobo devices are designed by the same manufacturer, so that
> their hardware has always been very similar).
> 
> Ebook readers are not much more expensive than a development board
> but come with the benefit of an extra display. Some popular third
> party reading apps like koreader are also internally based on mupdf,
> for which I think, I've read, Genode had already some support, which
> leads me to believe, that a purely Genode-based typical ebook reader
> scenario could be within reach with reasonable effort from a
> knowledgable developer, who has run a Genode scenario on i.MX6
> before.
> 
> This could be a basis for a later support of further ebook readers,
> including more professionally oriented ones like the Onyx Boox Max
> Carta (also uses i.MX 6), which could even be used as a full
> development machine, considering its large eye-friendly display and
> built-in Bluetooth for keyboard connection. Maybe an incentive for
> sunlight-affine programmers, if such exist, not to mention my wish
> to see Genode support stylus input in general.
> 
> 2. While ebook reader support itself would also offer Genode the
> opportunity to present its native documentation, the handbook, in an
> attractive form, it might be an easier first step to provide an
> official EPUB version of the handbook. The current PDF version from
> the web site, for its formatting, is not very ebook reader friendly,
> regarding the mainstream 6 inch devices. It would be nice to either
> see an EPUB version or a PDF optimised for common ereader screen
> sizes. Given the surprisingly poor margin truncating support of many
> of these devices, a PDF should have small margins. (The current
> state of stock ereader software screams for something better.)
> 
> I think, these two points are my main input for the roadmap 2018
> discussion. I also like the quality and resilience aspect, which
> Norman alluded to in his discussion starter. Seeing critical
> co

Re: Roadmap 2018

2018-01-21 Thread Norman Feske
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

-- 
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


Re: Roadmap 2018

2018-01-19 Thread Nobody III
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" 
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
>
--
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


Re: Roadmap 2018

2018-01-19 Thread Norman Feske
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


Re: Roadmap 2018

2018-01-19 Thread Norman Feske
Hi Ben,

> 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.

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.

> 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.

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

-- 
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


Re: Roadmap 2018

2018-01-18 Thread John J. Karcher

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!

--
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


Re: Roadmap 2018

2018-01-17 Thread Norman Feske
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


Re: Roadmap 2018

2018-01-15 Thread tgvb
 Having followed Genode's interesting quarterly development updates for quite some time, I hope to finally make a move towards a hands-on understanding and therefore set the modest goal for myself to at least read the entire handbook this year. Not as exciting as committing to any real development work, but hopefully easy enough to actually achieve and leaving room for more.‎On to wishes.1. I think, it would be a good side project for developers, to add support for at least one ebook reader. My reasoning behind this is, that these devices are relatively cheap and actually useful beyond (embedded) software development work and seem to offer an easy enough application scenario to support. This could also raise awareness of Genode's existence beyond the current level.Ereaders' innovation cycles are more developer ‎friendly than, say, laptops', tablets' or smartphones' and the hardware used is more homogeneous. Many current models still use the i.MX6 SoC, including Kindle and Tolino devices, which Genode developers seem to be willing to support anyway.The Tolino Shine 2HD, for instance, would appear to be an attractive target, since it boots from a microSD card, which could easily be replaced by one with a Genode image on it. While the technically very similar Kobo Glo HD does not seem to be sold any longer in Germany, it might still be in other countries (otherwise, I would have suggested the Glo HD, since its case is easier to open; Tolino and Kobo devices are designed by the same manufacturer, so that their hardware has always been very similar).Ebook readers are not much more expensive than a development board but come with the benefit of an extra display.‎ Some popular third party reading apps like koreader are also internally based on mupdf, for which I think, I've read, Genode had already some support, which leads me to believe, that a purely Genode-based typical ebook reader scenario could be within reach with reasonable effort from a knowledgable developer, who has run a Genode scenario on i.MX6 before.‎This could be a basis for a later support of further ebook readers, including more professionally oriented ones like the Onyx Boox Max Carta (also uses i.MX 6), which could even be used as a full development machine, considering its large eye-friendly display and built-in Bluetooth for keyboard connection. Maybe an incentive for sunlight-affine programmers, if such exist, not to mention my wish to see Genode support stylus input in general.2. While ebook reader support itself would also offer Genode the opportunity to present its native documentation, the handbook, in an attractive form, it might be an easier first step to provide an official EPUB version of the handbook. The current PDF version ‎from the web site, for its formatting, is not very ebook reader friendly, regarding the mainstream 6 inch devices. It would be nice to either see an EPUB version or a PDF optimised for common ereader screen sizes. Given the surprisingly poor margin truncating support of many of these devices, a PDF should have small margins. (The current state of stock ereader software screams for something better.)I think, these two points are my main input for the roadmap 2018 discussion. I also like the quality and resilience aspect, which Norman alluded to in his discussion starter. Seeing critical components implemented in SPARK might be a step in a right direction and even would be, if there were nothing more to it, than a mere shift towards a more readable implementation language.

--
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


Re: Roadmap 2018

2018-01-12 Thread Norman Feske
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

-- 
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


Re: Roadmap 2018

2018-01-12 Thread Christian Helmuth
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
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

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


Re: Roadmap 2018

2018-01-11 Thread Alexander Boettcher
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 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,

-- 
Alexander Boettcher
Genode Labs

http://www.genode-labs.com - http://www.genode.org

Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth




signature.asc
Description: OpenPGP digital signature
--
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


Re: Roadmap 2018

2018-01-11 Thread Emery Hemingway
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


--
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


Re: Roadmap 2018

2018-01-11 Thread Nobody III
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 
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:
>
> 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
>
> --
> 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
>
--
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


Re: Roadmap 2018

2018-01-11 Thread Norman Feske
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

-- 
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


Re: Roadmap 2018

2018-01-11 Thread Stefan Kalkowski
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

-- 
Stefan Kalkowski
Genode labs

https://github.com.skalk | https://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


Re: Roadmap 2018

2018-01-05 Thread Norman Feske
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

-- 
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


Re: Roadmap 2018

2018-01-02 Thread Steven Harp

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
> 

--
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


Re: Roadmap 2018

2017-12-29 Thread John J. Karcher

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!

--
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


Re: Roadmap 2018

2017-12-27 Thread Christian Helmuth
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
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

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


Re: Roadmap 2018

2017-12-23 Thread Norman Feske
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

-- 
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


Roadmap 2018

2017-12-22 Thread Norman Feske
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