On 23/05/16 16:26, Neeraj Sharma 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.
Not surprising; pet projects and production projects are usually quite
different, and just throwing a rough diamond out there will rarely cut
it (or polish it?).
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.
I'd guess they are content with traditional operating systems like they
are content with petroleum-engine cars. As long as the pedals and
steering wheel look roughly the same, all it takes is some financial
incentive to see the need for change.
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.
How does this "ugly" manifest itself? Does it matter?
3. There is a lack of a showcase project which demonstrates the power of
Erlang on RumpRun, which motivates wider adoption.
the eternal chicken-egg
Paradoxically, it's very difficult to get people to use something out of
their free will. If you make them to pay you to use it, it's a
different story. So, in effect, a quick way to get to the point of
wider adoption is to attract a sales team. Unfortunately, I don't
remember seeing a lot of open source sales teams ...
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.
As long as it's not worse than standard Erlang, why is it a priority?
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.
Well, rumprun-packages isn't much of a framework, so much as a
collection of demos. Leadership in developing it to an orchestrating
system for building images and(or?) deploying/managing the fleet of
instances is up for grabs. But, I think everyone already understands
that we're not there yet, and words without concrete actions won't
change things.
My ramblings in this email are so void of useful content that I'm going
to flip a coin to decide if I should send this. (blame the coin)
