On 16 June 2015 at 11:03, Martin Lucina <[email protected]> wrote: > > While this is an impressively minimal approach to accomplishing your stated > long-term goal (re-use of existing command line utilities for configuration > of unikernels) and short-term goal (helping with development and testing), > I'm concerned about two points: > > 1) "marketing" this as a first-class feature will give people the wrong > idea about what it is intended for. Someone will bake PHP and nginx into a > single unikernel and then get upset when PHP stomps all over their nginx. > > 2) figuring out your points 2) and 3) sounds suspiciously like implementing > a shell. One of the major points I'm emphasising when I speak of unikernels > is that there is no such thing as a shell, and thus your run-of-the-mill > exploits cannot exec() arbitrary commands. Granted, in this case you still > cannot execute *arbitrary* commands, but this feels like a step in that > direction. > > When I spoke with Justin in Cambridge, he made the point that the set of > command line utilities required to configure unikernels is quite small, and > that a better approach would be to (semi-manually?) "librarise" the > required utilities. > > Justin? Thoughts?
This seems an ideal case for a standalone "knead" utility that takes a bunch of programs and outputs something that can then be baked, no need for it to be part of baking... It can then be (im)proved as a standalone tool. Justin
