
Runtime.JS – Operating system kernel built on V8 - espadrine
http://runtimejs.org/
======
jdiez17
This is eerily close to some of the things discussed in The Birth and Death of
JavaScript[1].

[1] [https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
thegeomaster
My thoughts exactly. I recently posted the link to that talk here on HN
somewhere, and now seeing this is really creepy. Especially:

>All kernel components, device drivers and user applications execute in a
single address space and unrestricted kernel mode (CPU ring 0). Protection and
isolation are provided by software. Kernel uses builtin V8 engine to compile
JavaScript into trusted native code. This guarantees only safe JavaScript code
is actually executable.

>Every program runs in it's own sandboxed context and uses limited set of
resources.

~~~
angersock
How's that creepy?

It's freakin awesome!

------
adrusi
A lot of these ideas seem really good. I like that all processes run in CPU
ring 0 and safety is ensured by the VM. It seems like this is more flexible
and allows for more easily provable safety guarantees. That said, I think
javascript is the wrong way to go, and especially how they're doing it.
Javascript carries with it the idea of garbage collection, which is
fundamentally incompatible with hard realtime systems because it can create
unpredictable pauses. What happens when a driver is communicating with a
graphics card over a PCI bus or with an SSD over SATA and suddenly there's a
GC pause? It might miss some bytes, and in the worst case scenario, the serial
data stream will still be valid and the driver will carry on like nothing
happened, returning corrupted data.

I'm somewhat confused about the concurrency model in Runtime, The frontpage
says it ditches traditional preemptive multitasking in favor of an event loop,
but another pages says it runs a v8 isolate on each core. I'm going to assume
that this means on my machine with 8 virtual cores there would be 8 parallel
event loops. An eventloop for multiplexing OS processes on the timeline is
simply not appropriate for the general usecase. If any process performs a CPU-
bound operation, it would block all other processes in the same v8 isolate.
This system is also not very good for multicore operations, it's impossible to
properly balance to load on each core, leading to poor performance.
Traditional kernels can run a single thread on core A one millisecond and core
B the next, but even if it's possible to send a process between isolates, it
would be a lot less efficient than simply remapping the address space.

I think it would be much better use LLVM bitcode instead of javascript.
Instead of JIT compilation, the Kernel compiles the program to machine code
when it loads it into memory, verifying that it's not using any unauthorized
constructs statically. LLVM bitcode is already being used like this by PNaCl.
It offers the same security guarantees as javascript, but without the overhead
associated with it.

~~~
lgeek
> I like that all processes run in CPU ring 0 and safety is ensured by the VM.
> It seems like this is more flexible

This approach has a few issues which make it impractical for use by a real
general purpose OS:

* it moves all work related to safety either to the dynamic compiler (not so bad), when it can statically prove that the code is safe or onto the critical path if it cannot statically prove it safe (which generally causes significant slow-downs). For example a traditional OS will use VM to isolate application memory (where the performance impact comes from the occasional TLB miss), while this sort of approach might require boundary checks to be compiled before many memory instructions

* the problems mentioned above could be mostly avoided by requiring use of a language or bytecode format designed to allow the compiler to use static checks, but then all your applications have to use it (which is what Runtime.JS does)

* it potentially allows more complex interactions between the OS/VM and the application compared to traditional system calls, which is the sort of things that often enough creates hard-to-predict side effects

> allows for more easily provable safety guarantees.

I don't know about that, hardware is normally formally verified, while
software normally isn't. While hardware bugs still exist, there are far fewer
than in software.

~~~
pjmlp
This approach tried in the past multiple times:

\- Mesa

\- Cedar

\- Smalltalk

\- Lisp based OS (Interlisp, Lisp Machines)

\- Oberon and derivatives

So I think at least for home systems it could work.

------
vomitcuddle
Similar, more mature projects based around other languages: Erlang:
[http://erlangonxen.org](http://erlangonxen.org) C#:
[http://en.wikipedia.org/wiki/Cosmos_(operating_system)](http://en.wikipedia.org/wiki/Cosmos_\(operating_system\))
C#:
[http://en.wikipedia.org/wiki/SharpOS_(operating_system)](http://en.wikipedia.org/wiki/SharpOS_\(operating_system\))

~~~
agumonkey
Haskell's :

\- House
[http://en.wikipedia.org/wiki/House_(operating_system)](http://en.wikipedia.org/wiki/House_\(operating_system\))

\- HOP (House parent) [http://lambda-the-ultimate.org/node/299](http://lambda-
the-ultimate.org/node/299) (topic recurse on jnode and others)

------
tinco
They seem to be rolling their own HAL? Quite terrible if you think about it.
Someone should really start a project that strips down Linux to the point that
you could use its HAL for projects like these. I've heard things like USB or
Ethernet drivers are incredibly hard to implement, let alone graphics drivers.

If we want a future in which it is feasible to design an operating system from
scratch we really need some nice way of decoupling HAL implementations from
the OS. At the moment we can't even separate graphics drivers from window
systems, so perhaps it's a naieve desire.

~~~
leccine
You can forget about Linux in this regard. It is a giant bloated blob where
"striping down" is very hard. On the other end there are some promising
projects like [http://osv.io/](http://osv.io/) or Minix. Actually Microsoft
did a good job on separating graphics drivers from everything else, to the
extent when you can just restart the driver when it crashes.

~~~
thegeomaster
This reminds me of the Tanenbaum–Torvalds debate [0]. It's interesting to see
how a microkernel approach is today more useful for derivative projects and a
monolithic blob like Linux is good only for distribution as Linux as a whole.

[0]:
[https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16...](https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI\[1-25-false\])

------
octo_t
I was hoping this would be getting V8 to run on the bare metal, removing the
need for an operating system underneath. That part would be very cool.

~~~
diminish
When will V8 itself be written in js and emulate a v8.

~~~
cpeterso
Mozilla Research did this a few years ago:
[https://wiki.mozilla.org/Narcissus](https://wiki.mozilla.org/Narcissus)

------
jbuzbee
OS Kernel in JS? As seen many times before on Hacker News (And it still blows
my mind) just go whole hog:

[http://bellard.org/jslinux/](http://bellard.org/jslinux/)

~~~
adrusi
jslinux is a virtual machine compiled with emscripten + a barebones linux
distribution. It's very different from this project.

~~~
stephen_g
JSLinux is actually not compiled with emscripten - it's written directly in
JavaScript. There are some more notes on how it works here:
[http://bellard.org/jslinux/tech.html](http://bellard.org/jslinux/tech.html)

------
Gonzih
What if I actually like using threads instead of that fancy single threaded
event loop?

------
malandrew
A few weeks ago when coreutils was released re-written in rust, I decided to
check if Atwood's Law held true for coreutils as well. At the time I didn't
encounter a JavaScript version of coreutils, but with a project like this
showing up, I guess it may only be a matter of time.

------
drinchev
I can't stop asking myself ... "BUT WHY?!". I'm sorry for being sarcastic, but
what could be the benefit of using such an OS?

~~~
thegeomaster
Actually, I think there's a pretty good motivation behind this.

When executing JS code in a browser, it runs inside a safe VM and can't touch
any of the memory or variables that don't belong to it. However, the browser
itself has to go through a lot of the abstractions and safeguards required by
the kernel in order to run. Particularly, every syscall induces a context
switch which costs a lot of CPU cycles. This happens on every operations that
needs access to hardware, such as reading from a file or from a socket for
IPC. Also, the kernel needs to update the MMU registers so it can map its own
address space, invalidate the whole TLB, etc etc etc.

The basic idea here, it seems, is to avoid all these costs and build the
system so the user can run nothing that isn't a VM. The VM will provide fail-
safes and terminate offending code. This allows everything to run in a single
address space and under ring 0, thus avoiding context switching.

This is beneficial to (and only to) code that we used to run under a browser
or some kind of JS virtual machine (Node.JS servers come to my mind here). Web
apps such as editors (Atom maybe?) or any other kind can now run natively and
run way faster, which is very important on low-cost low-end machines, without
all the overhead that they know pay twice (first to virtualize JS from
everything else, and then to virtualize the browser processes). However, the
raw performance that can be gained from writing fast C/C++ code will
essentially be lost. The more JS code you were running before, the more a
naked metal JavaScript OS will benefit you.

It's not clear to me if this will ever be necessary. What I just said is the
justification of the idea, just from the top of my mind. Anyone feel free to
correct me if I screwed up the argument :)

~~~
serge2k
It's a cool idea, why implement it in a shitty language?

~~~
thegeomaster
Because, sadly, everyone is hopping on the JavaScript bandwagon. But it's not
as bad as it seems. There is CoffeeScript which is IMHO a considerably better
language, and there is ClojureScript which brings the wonders of Lisps into
JS. And for simple webapp logic I can tolerate JavaScript. It's also an
uncomfortable but true fact that JavaScript is today one of the most-used
languages in the realm of forward-driving forces of tech (that would be the
startups). Most GitHub repos are in JS, too.

However, the lack of integers will always be my pet peeve, and I really can't
imagine how could someone arrive at such a horrible idea.

~~~
fetbaffe
Depending on your use case, you can use Int32Array

[https://developer.mozilla.org/en-
US/docs/Web/API/Int32Array](https://developer.mozilla.org/en-
US/docs/Web/API/Int32Array)

------
ah-
>Runtime.JS uses global non-blocking event loop to dispatch tasks for the
whole system. Preemption is supported by design (and by V8), but haven't been
implemented yet.

How would you implement preemption in an event loop based system? Can you just
stop execution of functions in the middle, run a different function for some
time and then continue with the original one?

~~~
shayief
Yes, V8 supports this for contexts. Each program runs in its own context.
Engine puts interrupt guard checks into every function and every loop. So its
possible to interrupt context even in a middle of infinite loop.

------
nawitus
Similar project: jsos

[https://github.com/charliesome/jsos](https://github.com/charliesome/jsos)

------
sebastianconcpt
A truly OS based on a dynamic language. Beautiful. A round of applause. All
the best to this project.

------
z3t4
Does this mean we can run JS on embedded systems / low cost CPU ? That would
be awesome.

~~~
hamiltonkibbe
You would need a JS runtime compiled for your target device, or a standalone
JS compiler for your target device. EDIT: Assumed you meant running JS on-the-
metal. If you're running an OS then you could just have a JS interpreter (or
V8) running on it.

How do you define an interrupt handler in JS?

~~~
pjmlp
By exposing an API on the runtime?

No different from any other language.

~~~
hamiltonkibbe
Except that the compilers and toolchains already exist for other languages,
and --as far as I know-- don't currently exist for JS.

If I wanted to run $SOMEFILE.js on an msp430 today, how would I go about it?

------
ricardobeat
See also [https://github.com/NodeOS](https://github.com/NodeOS)

I don't see any mention of node. Is the plan to implement a whole new suite of
low level libraries with different APIs?

~~~
tinco
NodeOS is more like a Node/Linux, which after a while we would just call Linux
because it's shorter and catchier ;)

Runtime.JS seems to be a full operating system, not just a suite of tools on
top of Linux. If it gets in any usable state it would probably be possible to
make a Node implementation that works on Runtime.JS. The node implementation
would be pure Javascript and would be wrapping around the low level API's of
Runtime.JS.

------
hamiltonkibbe
Who's got my heady JS-to-ASIC compiler?

~~~
pjc50
You know, I'd been considering doing a something-to-Verilog compiler for a
while; with a brutally restricted subset of JS it should be possible.

