Hi Krishna, The project does look interesting though a cursory look suggests that it demands some dedicated time to understand (let alone prototype). Thanks for the information.
-Neeraj On Mon, May 23, 2016 at 11:18 PM, Krishna <[email protected]> wrote: > Hello Neeraj, > > Regarding point-3, eVenti[1, 2] would be a good showcase project > especially with CGD. > > Cheers, > --krishna > > [1] https://medium.com/@jlouis666/eventi-ffd423d82b35 > [2] https://github.com/jlouis/eventi > > > On 23 May 2016 at 21:56, Neeraj Sharma <[email protected]> > wrote: > > Hi, > > > > I've been preoccupied due to multiple reasons and as much I wanted to > could > > not give due importance to the lingering questions in my mind after work > on > > getting the Erlang language on RumpRun unikernel. Although it was good to > > get erlang on RumpRun, the achievement was short lived because I wonder > how > > many it for their pet projects forget about going into production. > > > > I think the discussion goes beyond Erlang on RumpRun and applies to other > > languages built over RumpRun as well. I am unaware of the latest and > > greatest in RumpRun, so correct me if there is something which is already > > addressed. Having said that I can present my views for at least the > > challenges related to Erlang adoption. > > > > 1. In general people are content with traditional operating system and > > applies them in all use cases where unikernel based approach should be > used > > instead. > > > > 2. The framework to build and package Erlang application on RumpRun is > ugly > > (not surprisingly the intent was to get it to work in the first place) > and > > needs a lot of improvement. > > > > 3. There is a lack of a showcase project which demonstrates the power of > > Erlang on RumpRun, which motivates wider adoption. > > > > 4. Although related to point-2 I would like to indicate separately that > > Erlang build is way beyond something which can be termed as a bloat. This > > again is a consequence of neglecting it in the interest of a working > > prototype (achieved earlier). The final output should be inline with the > > principle of unikernels; which is to be a working-bare-minimum > distribution > > ultra-small. There are some ways of achieving that, but may require a > lot of > > time to gain desired design, flexibility or performance. > > > > The intention of this email is not to propose a solution rather than > > initiate a discussion, but I couldn't resist presenting my views of > trying > > to tackle point (2). I worked with numerous build systems and believe > that > > something similar to the openembedded + yoctoproject (due to my love for > > python) can help in this respect, whose design require a steep learning > > curve but makes sense after a while and gives a lot of flexibility and > reuse > > in the end. Having said that the idea is to make it easy for packaging > > applications on top of RumpRun which is much nicer than what exists > today. > > > > > > -Neeraj > > > > -- > Rivers know this: there is no hurry. We shall get there some day. > -- Winnie-the-pooh >
