On Fri, May 27, 2016 at 2:17 AM, Antti Kantee <[email protected]> wrote: > 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. > > > ugly/bloated/etc is a common computer engineering term for situations where > one cannot quantify what is wrong, but still want to hold that something is > aesthetically displeasing. If one cannot quantify what is wrong, nothing is > wrong (save for problems with one's quantification skills). What I'm trying > to say is that we should first problems for which it's easy to succinctly > state what exactly is the problem. That should also lead to better ability > to quantify what is wrong with "ugly". >
The Erlang build packages everything right now (in rumprun-packages), which needless to say is unnecessary. Typical Erlang deployment is not done like that and follows a different path. Having said that if the intent of rumprun-packages is for demo and proof of concept I now dont see Erlang package too bad at what it was meant to do. It does demonstrate that Erlang can run on Rumprun unikernel. Although at some point it will be great to have template project (for deployment) which allow people to build on than write one from scratch. The erlang.iso contains a lot of unnecessary stuff like header files, static libs, source files for modules and tools. This is the typical output of 'make install', which is required for dev machine but not for release. Additionally, the release process for a typical deployment (on a regular os) will not make much sense on a unikernel. For example code reload (or swap) needs to be designed while building Erlang+unikernel or left altogether due to nature of it. Having 100s or 1000s of nodes cannot be dynamically patched simultaneously anyways, and while some nodes exist certain others can be upgraded without much impact of bringing them down for an upgrade rather than taking the dynamic code reload and save a node from downtime. I tried to give a very high level picture because I'll not do justice to the topic while scribbling couple of lines anyways when this demands a couple of pages. I hope it gets the message across. As an interim approach bulk of the bloat can be cut down easily by just removing all the extra flab. I am trying to understand Erlang internals to probably do a better job than the already existing Erlang release build procedures. Additionally, those were not designed for use case which Rumprun brings out anyways. -Neeraj
