On 09/04/15 12:46, Martin Lucina wrote:
On Thursday, 09.04.2015 at 12:18, Antti Kantee wrote:
Can't the components just be built like they normally are: as
libraries? I don't see them being different from the rump kernel,
which is just libraries too.
Yes, but the packaging system needs to know about them, in the sense that
"nginx" depends on "openssl".
Sure, that's what a packaging system does.
The rump kernel will also just be a package. If, heaven forbid, there's
be a security vulnerability in the NetBSD kernel, we'll just bump that
version like we'd do for, just to pick some random examples, openssl or php.
There's also the question of what to do about components for other language
runtimes (e.g. NodeJS, Python, Ruby plugins), so that's something to keep
in mind while we're handwaving.
Can you elaborate? I don't know enough about language runtimes to know
what you're referring to.
The more challenging bit is figuring out how to get more than one
"b" into the image and especially how to control what is going to
happen when you run the image. This is #5 in my list above.
Other than configuration scripts, what is the use-case for having more than
one "b" in an image?
See configuration thread for a simple example.
I'm sure there are cases where someone would want a tradeoff between
less isolation and more performance in case of tightly knit cooperative
processes. The world is never black and white, and greatest isolation
is not always the correct answer, just like greatest performance is not.
I think it's a reasonably low-hanging fruit to support which doesn't
go against the whole unikernel concept.
But, I can't think of any such cases now, so my latter example is rather
poor. Should "present evidence or shut up", as someone told me ...
