On 26/05/16 18:21, Neeraj Sharma wrote:
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?
It just doesnt look right thought it'll take some time sorting it out.
I guess I am fine with the intent of the repo limited to demonstration
rather than anything else right now.
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.
I did spend some time on this but then I am still evaluating how bulk
of the functionality can be inherited from someplace else rather than
to write one from scratch :)
