31–36 of 36 posts
Would it be possible to run Linux as a unikernel and port your application as a kernel module? How a leaned down Linux kernel would compare to includeOS?
Earlier quoted context omitted.
The mind reels. Not because Linux is a bad kernel, mind you, but because UNIX itself reeks of ideas that were ok when it was originally developed and clunky at best today. Even Microsoft seems to have given up. The future of computing looks pretty grim to me.
Could you elaborate?
If you're into unikernels, rumpkernels[0] are the least-modification-required approach I've seen. Basically, if you compile your program with a minimally (as minimal as is possible) modified compiler, you get "rumprunnable" output. there's a list of popular packages built to run on rump kernels[1] (Rust is supported[2]). I haven't tried to use the toolchain yet, but it's pretty appealing to me. The biggest issue is t…
I'm hoping we're be able to port libuv to IncludeOS (which should be doable, much like libuv IncludeOS is eventdriven). Then we should be able to get Node up and running. Running Node.js through IncludeOS on Nabla could be interesting in a "FaaS" context. Last I heard the author of Rumprun has picked up beer brewing full time and isn't interested in maintaining the project. It would be great if someone where to pick…
Thanks for mentioning OSv[0], I'd never heard about it before.
I'm excited to see what happens with Nabla, I read the accompanying paper and was pretty excited about the possibilities. Nabla's greatest strength is it's ergonomics, IMO, though rumprun comes close (someone took some time to make dockerized containers for it).
[EDIT] - looking at OSv's (primary?) tool capstan[1], I'm not sure it's quite the same, it seems more like linuxkit[2] than rumprun. Maybe my intuition is wrong, but it seems much more like you're bringing along a stripped down OS than you're writing a program meant to interact with a shared unikernel. The distinction is so fuzzy in my head I'm not sure there is one, but it feels different.
[0]: http://osv.io/
Earlier quoted context omitted.
I'm hoping we're be able to port libuv to IncludeOS (which should be doable, much like libuv IncludeOS is eventdriven). Then we should be able to get Node up and running. Running Node.js through IncludeOS on Nabla could be interesting in a "FaaS" context. Last I heard the author of Rumprun has picked up beer brewing full time and isn't interested in maintaining the project. It would be great if someone where to pick…
Thanks for shedding some light on the possible status of the Rumprun maintainer! Hope he's happy brewing beers :) Thanks for mentioning OSv[0], I'd never heard about it before. I'm excited to see what happens with Nabla, I read the accompanying paper and was pretty excited about the possibilities. Nabla's greatest strength is it's ergonomics, IMO, though rumprun comes close (someone took some time to make dockerized…
Earlier quoted context omitted.
The mind reels. Not because Linux is a bad kernel, mind you, but because UNIX itself reeks of ideas that were ok when it was originally developed and clunky at best today. Even Microsoft seems to have given up. The future of computing looks pretty grim to me.
Could you elaborate?
* Filesystem semantics. What POSIX actually says and what most people think it says in this regard is very different. And both groups acknowledge that the semantics are not very useful for things like high-performance distributed filesystems in HPC.
* Signals. Everything about signals is pretty annoying. You can't install per-thread signal handlers, which means you can't do things like "catch" segmentation faults. And signals aren't files, but you can only poll for file things to occur, so you have to reexpose signals as files via signalfd...
Earlier quoted context omitted.
The mind reels. Not because Linux is a bad kernel, mind you, but because UNIX itself reeks of ideas that were ok when it was originally developed and clunky at best today. Even Microsoft seems to have given up. The future of computing looks pretty grim to me.
Could you elaborate?
A lot of new kernel features have just given up to the point where current advice is to never call it unless you plan to exec immediately after. But the technical debt within the kernel for this misfeature is massive.