5 ms·

Runtime.js – JavaScript library OS

116 points by shayief 11y ago

iamleppert 11y ago
How does this work with node.js based binary/native dependencies? Also, is it possible to customize the built image with libraries, etc? This seems really cool and a welcome replacement for the mess that is Docker.
- deleted 11y ago
  [deleted]
- jand 11y ago
  Quote from [1]: "Application, its dependencies and the core library are bundled up using Browserify, then packed into ramdisk image for kernel to use." 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 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.
  - shayief 11y ago
    this is correct, binary dependencies are not supported. The possible way to solve this is to compile non-js code into Asm.js/WASM or directly into js. I think this makes system a bit more stable (null-pointer error in the kernel mode will crash the OS for example) and makes V8 updates much more easier.
- rubiquity 11y ago
  From my understanding, I would say "yes." This project is trying to present itself in the same vein as Unikernels which are out to solve a similar problem as Docker but at a different level of abstraction.
bkase 11y ago
This library reminds me of some of the "future" introduced in this (satirical, yet insightful) talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Discussion: https://news.ycombinator.com/item?id=7605687 https://news.ycombinator.com/item?id=7605687 This is extremely cool, by the way.
jordwalke 11y ago
This looks really cool, I look forward to following the project. 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.
- jordwalke 11y ago
  A cool example: http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-things-done-in-the-browser/#nymote-mirageos-and-ucn http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-t...
  - nicklaf 11y ago
    Thanks for pointing this out--it brought my attention to the author's Irmin backend, based on the browser's implementation of IndexedDB: https://github.com/talex5/irmin-indexeddb 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. [1] http://roscidus.com/blog/cuekeeper/ http://roscidus.com/blog/cuekeeper/
- lomnakkus 11y ago
  On additional huge benefit to having a statically typed reflection-less language for a unikernel would be that dead code elimination becomes rather a lot easier. (You'd need whole-program analysis, but that's pretty doable for the ML's of the world, see e.g. MLton.)
- namuol 11y ago
  I'm confused. If you're writing OCaml in the first place, why not just directly run it on MirageOS? The obvious benefit of a JS VM unikernel is that you get to write your application in JavaScript...
pachydermic 11y ago
Relevant, as always: https://xkcd.com/1508/ https://xkcd.com/1508/
proppy 11y ago
I wonder if this could be used as an IoT/RPi OS, maybe swaping v8 for https://github.com/cesanta/v7 https://github.com/cesanta/v7 to make the footprint even more lightweight.
- shayief 11y ago
  this is a great idea, thanks. I wish v7 had the same c++ API as v8 so it could be easily swapped though.
buzzier 11y ago
>device drivers with javascript >assemler in browser what next?)
i336_ 11y ago
I'm not sure if this will be relevant or useful information, but I understand that a GSoC project added Lua to SYSLINUX. I'm not sure what the specifics of the memory access/stack structure is; the idea is to let you run Lua scripts directly in your bootloader, and it can also open an interactive REPL. 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.

116 points by shayief 11y ago

How does this work with node.js based binary/native dependencies? Also, is it possible to customize the built image with libraries, etc? This seems really cool and a welcome replacement for the mess that is Docker.

deleted 11y ago
[deleted]
jand 11y ago
Quote from [1]: "Application, its dependencies and the core library are bundled up using Browserify, then packed into ramdisk image for kernel to use." 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 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.
- shayief 11y ago
  this is correct, binary dependencies are not supported. The possible way to solve this is to compile non-js code into Asm.js/WASM or directly into js. I think this makes system a bit more stable (null-pointer error in the kernel mode will crash the OS for example) and makes V8 updates much more easier.
rubiquity 11y ago
From my understanding, I would say "yes." This project is trying to present itself in the same vein as Unikernels which are out to solve a similar problem as Docker but at a different level of abstraction.

bkase 11y ago

This library reminds me of some of the "future" introduced in this (satirical, yet insightful) talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Discussion: https://news.ycombinator.com/item?id=7605687 https://news.ycombinator.com/item?id=7605687 This is extremely cool, by the way.

jordwalke 11y ago

This looks really cool, I look forward to following the project. 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.

jordwalke 11y ago
A cool example: http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-things-done-in-the-browser/#nymote-mirageos-and-ucn http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-t...
- nicklaf 11y ago
  Thanks for pointing this out--it brought my attention to the author's Irmin backend, based on the browser's implementation of IndexedDB: https://github.com/talex5/irmin-indexeddb 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. [1] http://roscidus.com/blog/cuekeeper/ http://roscidus.com/blog/cuekeeper/
lomnakkus 11y ago
On additional huge benefit to having a statically typed reflection-less language for a unikernel would be that dead code elimination becomes rather a lot easier. (You'd need whole-program analysis, but that's pretty doable for the ML's of the world, see e.g. MLton.)
namuol 11y ago
I'm confused. If you're writing OCaml in the first place, why not just directly run it on MirageOS? The obvious benefit of a JS VM unikernel is that you get to write your application in JavaScript...

pachydermic 11y ago

Relevant, as always: https://xkcd.com/1508/ https://xkcd.com/1508/

proppy 11y ago

I wonder if this could be used as an IoT/RPi OS, maybe swaping v8 for https://github.com/cesanta/v7 https://github.com/cesanta/v7 to make the footprint even more lightweight.

shayief 11y ago
this is a great idea, thanks. I wish v7 had the same c++ API as v8 so it could be easily swapped though.

buzzier 11y ago

>device drivers with javascript >assemler in browser what next?)

i336_ 11y ago

I'm not sure if this will be relevant or useful information, but I understand that a GSoC project added Lua to SYSLINUX. I'm not sure what the specifics of the memory access/stack structure is; the idea is to let you run Lua scripts directly in your bootloader, and it can also open an interactive REPL. 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.