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

Reply via email to