I'm curious, if you wanted your unikernel to be running in a JS VM (I'm not sure what the primary motivation would be[deployment?]) why not take the approach of just compiling the type-safe MirageOS into JavaScript (possible because MirageOS/OCaml can also compile into JS). Unikernels are attractive because of, among other reasons, increased security. It's pretty well understood that a powerful type system (such as Mirage's use of OCaml) would be useful in reducing accidental security vulnerabilities as well. Come to think of it, I'd much rather trust mission critical server infrastructure to OCaml that compiled to JavaScript, over JavaScript. At the end of the day, you'd still be able to use it from within js via `require('OS')`, but its implementation would have had more bugs/vulnerabilities prevented by the type system.
https://github.com/talex5/irmin-indexeddb
That said, trying out this demo [1] of Cuekeeper gives an IndexedDB error message on Firefox 40.0.3 on Linux; perhaps IndexedDB is somehow not enabled.
The obvious benefit of a JS VM unikernel is that you get to write your application in JavaScript...
If you're starting with MirageOS, then obviously makes sense to just run MirageOS a bare-metal hypervisor. But if you're starting with the assumption that you will be running in a JS VM, then you have two options: build a unikernel in JS, or compile one to JS. The later option (MirageOS compiled to JS) also happens to leave open the possibility of easily being ran on a bare metal hypervisor with the unikernel implementation itself also running on bare metal (without a language level virtual machine) - because OCaml executes without a language level virtual machine (it's more like C++ in that sense).
> The obvious benefit of a JS VM unikernel is that you get to write your application in JavaScript...
What are some reasons why that would be a good thing in the case of unikernels? (I'm genuinely asking) The type system and invariants that it enforces are one of the things that makes OCaml based unikernels such a compelling idea to me. JavaScript, although I obviously find it useful for many things, doesn't seem to have as much appeal in this case.
Relevant to security: See MirageOS's Bitcoin Pinata project: http://amirchaudhry.com/bitcoin-pinata/
Edit: Again, it's still cool to see this project, and it's a great way to get more people experimenting with the idea of unikernels.
This is extremely cool, by the way.
Strangely, the effort was made to get Lua functioning, but not much has been practically done with it. Stuff like VESA support was even thrown around, but the whole thing was eventually abandoned(?!).
I see so many possibilities for something like this, generally speaking... and FYI, the code does apparently work.
This seems really cool and a welcome replacement for the mess that is Docker.
Since runtime.js uses browserify which itself is not able to handle binary/non-JS dependencies - i would say "no".
But this is just a conclusion and not an answer-by-knowledge.
[1] https://github.com/runtimejs/runtime
EDIT:
Did a quick test with bcrypt.
It failed - in contrast to a pure-JS "hello world" test.
Again, not a proof, but a stronger hint.
>assemler in browser
what next?)
