Shared publicly  - 
 
Yup. Looks like that's an actual real copy of Linux running in an emulator written in javascript in a browser window.

http://www.ubercomp.com/jslm32/src/

Fate of humanity: uncertain.
8
19
Avery Pennarun's profile photoReginaldo Silva's profile photoDenton Gentry's profile photoPeter Colijn's profile photo
12 comments
 
Sweet. How long to get X11+Chrome running on it to get infinite recursion? :)
 
I'm guessing the V8 engine would first have to support targeting the weird processor architecture they're using. And then something about quantities of available memory. Hmm, this makes me wonder if you could actually run this thing in the command line v8, which is way more lightweight than chrome itself. No, no, no, back to work... :)
 
Hmm. And actually, you could write a Linux device driver (in cooperation with the emulator) that would let you manipulate the DOM from your favourite programming language. I think the emulator boots Linux in about the time it takes to load gmail's javascript anyway... :)
 
Surely you'd want to mmap() the DOM, for performance reasons.
 
Author here...
I did it just for fun, of course, inspired by Bellard's jslinux.
The code is on github: https://github.com/ubercomp/jslm32/
The main gem is, of course, the CPU: https://github.com/ubercomp/jslm32/blob/master/src/lm32_cpu.js
To run the interpreted version instead of the one with on-the-fly code generation, the only thing that has to change is the line:

- var step = step_dynrec;
+ var step = step_interpreter; // this will run with an even slower interpreted loop (no code cache).

I was not expecting this to get the kind of attention it is getting, as the code is not yet "ready for prime time". The cache block is never cleared so this makes it consume tons of RAM, and of course it runs much better on Chrome where there is a nice terminal emulator I lifted from the chromium source tree.
 
Ha. Someday I expect to be extremely dismayed to learn what it means for a project like this to be "ready for prime time" :)
 
Something like "runs with consistent performance on all browsers released since circa 2010". Up until yesterday, I had never had it boot with IE, now it boots but it is sluggish, also the textarea does not show newlines correctly. I have also never tested on any mobile devices, and still have no idea if it works...
 
Yeah, looking back what I wrote, I too will be somewhat dismayed when saying "it's ready for prime time" when talking about projects of this nature is a natural thing...
 
What upsets me the most is that within a processor generation or so, the idea of running python on an emulated CPU so that I can program in that instead of javascript on my web pages will seem perfectly normal :)
 
I have yet to get over the idea of running a {java, python, erlang} virtual machine on top of the perfectly good physical machine, just for petty little things like garbage collection.
 
I admit, one thing I really like about python is it's just an interpreter, not a crazy complicated VM, and even its memory management looks suspiciously like smart pointers in C++. The idea of jitting javascript and running another language on top is only appealing because we're stuck with web standards that say javascript good, everything else bad. This way we can run javascript and still use everything else. Admittedly something like Native Client could be a little less gross though... if it can become a standard someday.
 
You're spot on when you say that "The idea of jitting javascript and running another language on top is only appealing because we're stuck with web standards that say javascript good, everything else bad". If there was some standard lower level way to generate and run code, that would be used instead.

The thing is, there's just too much perfectly good code in the world that cannot be run inside browsers. Think of all the code that goes into making a distro like Debian or Ubuntu, for instance. There's a lot of stuff in there that would make sense to run inside a browser, but it's just not possible for now. But the Javascript engines are becoming fast enough to make it possible to run some of this code. As it is possible, it will eventually happen, even if it's in a kind of weird way, such as what I'm doing with this toy project. Right now, Mozzilla's Emscripten [1] shows a more promising approach, but many programs will need a fair amount of tweaking to fit Emscripten's model.

In the future, approach followed by Bellard and myself might be more advantageous in that it allows code to run unmodified. I can only hope that, when running an emulator inside a browser window is fast enough that projects like jslinux or jslm32 become really viable, browser vendors will realize there's no point fighting the inevitable and standardize on a portable and efficient way to generate and run arbitrary code. Some pieces of the puzzle are almost here already (look at PNaCl - Portable Native Client, for instance), all we need is consensus and acceptance.

[1] https://github.com/kripken/emscripten
Add a comment...