Slashdot Mirror

Does that mean you've never written a serious app in js? If so what makes you qualified to compare?

Have you see the x86 emulator written in javascript?

http://bellard.org/jslinux/tech.html

It only runs one program I've seen - Linux. It boots, I can vi, cc, run it and it's not slow. And it's doing all this in a browser tab. Or as many as you want.

Have a go doing this in python and let us know when we can compare the two.

Or do this: http://osjs.0o.no/

http://bellard.org/jslinux

You can even run it on a smartphone! (The perf will be *terrible* but you can do it).

aaaand I'll be abel to boot Linux faster!

Having experienced just how slowly pdf.js renders documents longer than a page or two - I can't WAIT to see how well implementing swf in javascript goes!

Implementing SWF in Javascript can't possibly be more complicated than implementing A Javascript x86 emulator that boots into Linux and can run gcc .... could it?

Probably not emscripten-based, but here you go.

M. Bellard's Javascript PC Emulator ?

Off-topic, but you can actually already run an entire Linux OS in the browser. Of course, first you have to emulate an x86-based computer to run it on.

You think I'm joking...

Javascript is Turing-complete, last time I checked.

1. Write compiler for <your favorite language> in Javascript
2. Write printer driver in <your favorite language>
3. ???
4. Profit!!!

TinyCC doesn't require anything else to run, is small, fast, and has enough functionality for hobby-level stuff. For an IDE, just use notepad or something.

However, if you get fired for this, it's going to be your own fault for knowingly violating the rules. Brining your own laptop might not be acceptable either, depending on the environment, but that would be the best possibility so it's definitely worth checking out. Another possibility is to use remote desktop or ssh or something to connect to your home box running whatever IDE you'll want, but again, check with your managers. If they don't allow it, just read a book about programming instead.

I've actually been tempted to have a fling with TCC.

Small, tight, flexible, low maintenance and can do the business just about anywhere.

What about Ken Thompson's C compilers from Plan 9? You can get them quite easily if you download the Go distribution. Additionally, you get cross-compilers for free (you get all target platforms simultaneously in every install).

I've actually been tempted to have a fling with TCC.

Small, tight, flexible, low maintenance and can do the business just about anywhere.

x86 machine code is a publicly standardised, widely know and extensively studied language. By modern standards is actually quite simple.
Forget about minified JavaScript. I have seen 'documented' scripts that were harder to understand than machine code.
Proof in point JavaScript can execute x86 code anyway: http://bellard.org/jslinux/.

emscripten can compile C code, or anything that can produce LLVM bitcode, directly into JavaScript, allowing heavyweight code like Ruby/Python/Lua, physics engines, raytracing, FreeType, text-to-speech, etc. to run in a browser. JSLinux emulates the 386 instruction set to the point it can boot a stock Linux kernel, start a terminal, and run ELF executables like the Busybox command-line utilities in a browser (JSLinux's Fabrice Bellard could probably do MAME in JavaScript in his sleep one-handed.) So despite the innovations in Native Client, targeting JavaScript in an HTML5 browser is the way forward. And until Google implements Portable Native Client, NaCl doesn't even give you the ability to run in any Chrome browser, you need an architecture-specific executable. But portable NaCl is just running LLVM bytecode, and emscripten is already turning that into plain JavaScript without requiring a new black box in each web page.

Does anyone know if any of the native apps in ChromeOS/ChromiumOS and Android are written in NaCL or PNaCl? That would make some sense.

And the OS runs as webapp http://bellard.org/jslinux/

Firefox is a great operating system, if only it included a decent browser :P

Not necessary, you can boot linux in it and run emacs and browse with w3.

Fabrice Ballard already wrote an x86 emulator in javascript. Just install the standard x86 JVM inside of that and you're good to go.

Yes, that's why this is completely unnecessary.

Fabrice Ballard already wrote an x86 emulator in javascript. Just install the standard x86 JVM inside of that and you're good to go.

... ever since jslinux booted a Linux 2.6.20 image.

In Firefox, JavaScript runs 386!

tiny C compiler has been doing this for a while. Give it a string containing the function, and it returns a function pointer. And of course, Lisp had a 'compile' function (taking an S-expression of course) for almost forever.

Tiny C compiler does this for years:
http://bellard.org/tcc/

Features

SMALL! You can compile and execute C code everywhere, for example on rescue disks (about 100KB for x86 TCC executable, including C preprocessor, C compiler, assembler and linker).

FAST! tcc generates x86 code. No byte code overhead. Compile, assemble and link several times faster than GCC.

UNLIMITED! Any C dynamic library can be used directly. TCC is heading torward full ISOC99 compliance. TCC can of course compile itself.

SAFE! tcc includes an optional memory and bound checker. Bound checked code can be mixed freely with standard code.
Compile and execute C source directly. No linking or assembly necessary. Full C preprocessor and GNU-like assembler included.

C script supported : just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line.

With libtcc, you can use TCC as a backend for dynamic code generation.

This is the real "Linux on the desktop".

Even still, the JavaScript performance of Firefox Nightly is top-notch. Jaegarmonkey with type inference is about twice as fast as Chrome dev channel on many of the CPU-bound microbenchmarks. It falls down on some scheme-like ones where you're defining new types all the time, but in general it at least matches V8. And they've got a bunch of improvements on it in design for the IonMonkey engine.

For instance in http://bellard.org/jslinux the shell responds much quicker in Chrome, but in Firefox any CPU-bound task like "gzip < /bin/zcat > /dev/null" is twice as fast (you have to use a stopwatch since the system time is in emulated hz).

Some measurements of PC emulator on FF, Chrome on i7.

Though even the Javascript PC emulator http://bellard.org/jslinux loads the Linux kernel pretty much equally fast on both.

It depends... comparing nightly to dev channel:

# x=1; while [[ $x -lt 1000]; do x=$((x+1)); done

Chrome: 2 seconds
Firefox: 20 seconds

# time gzip < /bin/zcat > /dev/null

Chrome: 206 seconds
Firefox: 102 seconds

# find /

Chrome: 11 seconds
Firefox: 6.5 seconds

# for x in /bin/*; do $x --help; done 2>/dev/null >&2

Chrome: 12 seconds
Firefox: 5.5 seconds

Looks like whatever busybox is doing for the shell is fantastically slow in Firefox, but pretty much everything else I tried was about twice as fast. No wonder Google wants everybody to move to Dart, huh?

Or in JavaScript ;-)

http://bellard.org/jslinux/tech.html

How's the "Native Client" a big step when we've already seen the Javascript PC Emulator:

        http://bellard.org/jslinux/

I guess a Chrome browser pulling up that page, the Javascript PC Emulator booting X to run Chrome to run a Native Client PC emulator would be a neat hack...

Dan

Well, we already have QEMU in javascript so why not run a full VM + OS to read your PDF?

So not only do you need to make sure your browser runs on all OSes (or OSen if you must), you need to make sure all OSes can run in your browser!

BTW, thats the real thing: http://bellard.org/jslinux/index.html (Thats not a shock site)

http://hackaday.com/2009/03/03/distributed-computing-in-javascript/ - nothing new under the sun! However, to all those who say "it would be way too slow in JavaScript", I refer you to the entire OS in browser (previously on slashdot) http://bellard.org/jslinux/

Another JavaScript TRS-80 Model III emulator (with non-obscurified code): http://trs-80.com/
JavaScript Apple ][: http://www.megidish.net/apple2js/
JavaScript Linux PC: http://bellard.org/jslinux/
etc.

(also the C64 emulator mentioned above)

JavaScript is the new 8-bit emulation hotness!

The x86 emulator running Linux in Javascript wasn't impressive enough to you?
http://bellard.org/jslinux/

And now that you can boot Linux inside a VM written for javascript in a browser a web shell should be able to do pretty much anything.

Uuum, that's still the case. We just don't listen to "normal" broadcast radio anymore. ^^

But I agree. I heard Emacs has a browser? Letâ(TM)s run this in it: http://bellard.org/jslinux/
And then start Emacs in it, and browse the web. ;))

Now if you manage to make the Emacs browser inside jslinux to itself run jslinux, but run migrate the OUTSIDE OS to it, I will officially marry you. I don't care if you're woman, man, heshe, cat (is fine too), mutant, alien or Cthulhu. That would be epic! ;)

This demo is rendering to an HTML5 *canvas* as a virtualized framebuffer in an interpreted language with no hardware support whatsoever. Are you *seriously* trying to use this as a complaint against Javascript? I remember back when "demo" just meant "write a cool app to show off"...

Of course it's not the way someone would build a real app in Javascript, but it's an excellent demo to help people understand what the platform can do and how it might be improved. And for those of us who understand all of the tools that went into it, it's just pretty damn cool.

A couple weeks ago a story was posted about a demo that booted a real 2.6 Linux kernel image with ramdisk entirely in Javascript: JSLinux.

That takes a whole 6 seconds to boot to a bash prompt *in Javascript* on my machine. SO SLOOOW, Javascript sucks!!! ;)

It seems pretty damn impressive that web browsers are as powerful as an entire computer ...

I think it has more to do with the power/stability/impressiveness of the JavaScript engines and implementations of standardized ECMAScript specifications. I had submitted a story about Fabrice Bellard emulating a very basic (even primitive) computer and then running Linux in it. But that got rejected.

Developers are slowly coming full circle and using JavaScript a client side application. As the performance cost of emulation and virtualization are outweighed by better machines and as HTML5 become more solid and supported, expect some pretty crazy awesome demos to be seen and maybe a handful of them turning into something generalized and really useful (like the mentioned Emscripten).

Not exactly what you said, but there's a javascript x86 emulator running Linux: http://bellard.org/jslinux/

And your hyperbole is based on what evidence? Linux 2.6 runs fine even in an x86 emulator written in Javascript.

If some one makes an equivalent for DOS (or perhaps HTML5) that can run old games I suppose that would solve all these issues.

They were all easily obtained as files via http using wget. Except for root.bin which was 403 forbidden.

76002325 86 -rw-r--r-- 1 sexton www 88024 May 17 10:42 cpux86.js
76002326 2 -rw-r--r-- 1 www www 549 May 18 00:15 home.html
76002327 16 -rw-r--r-- 1 sexton www 14858 May 16 14:14 linuxstart.bin
76002328 6 -rw-r--r-- 1 sexton www 5379 May 16 14:14 tech.html
76002323 8 -rw-r--r-- 1 sexton www 6534 May 17 05:26 term.js
76002324 1664 -rw-r--r-- 1 sexton www 1679494 May 16 14:13 vmlinux26.bin

% wget http://bellard.org/jslinux/root.bin
--2011-05-18 00:39:07-- http://bellard.org/jslinux/root.bin
Resolving bellard.org (bellard.org)... 88.191.75.179
Connecting to bellard.org (bellard.org)|88.191.75.179|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2011-05-18 00:39:07 ERROR 403: Forbidden.

But I noticed if I asked for this file via a web browser then root.bin got translated to root.bin.en.gz and you can ask for this by name with wget and it works.
unzip it and call it root.bin and then it all works.

vi works in this thing. manpages don't. Probably should be there though, easily added.

"wait 10 seconds while I boot linix in a browser window to look up the manpage". Hysterical. Course, I should have seen this coming, 10 years ago IBM RAID controllers made you boot linux on your pc *just* to configure the device.

I'm not sure where thing is in the range from "slick" to "game changer". But it's inbetween those two somewhere.

They were all easily obtained as files via http using wget. Except for root.bin which was 403 forbidden.

76002325 86 -rw-r--r-- 1 sexton www 88024 May 17 10:42 cpux86.js
76002326 2 -rw-r--r-- 1 www www 549 May 18 00:15 home.html
76002327 16 -rw-r--r-- 1 sexton www 14858 May 16 14:14 linuxstart.bin
76002328 6 -rw-r--r-- 1 sexton www 5379 May 16 14:14 tech.html
76002323 8 -rw-r--r-- 1 sexton www 6534 May 17 05:26 term.js
76002324 1664 -rw-r--r-- 1 sexton www 1679494 May 16 14:13 vmlinux26.bin

% wget http://bellard.org/jslinux/root.bin
--2011-05-18 00:39:07-- http://bellard.org/jslinux/root.bin
Resolving bellard.org (bellard.org)... 88.191.75.179
Connecting to bellard.org (bellard.org)|88.191.75.179|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2011-05-18 00:39:07 ERROR 403: Forbidden.

But I noticed if I asked for this file via a web browser then root.bin got translated to root.bin.en.gz and you can ask for this by name with wget and it works.
unzip it and call it root.bin and then it all works.

vi works in this thing. manpages don't. Probably should be there though, easily added.

"wait 10 seconds while I boot linix in a browser window to look up the manpage". Hysterical. Course, I should have seen this coming, 10 years ago IBM RAID controllers made you boot linux on your pc *just* to configure the device.

I'm not sure where thing is in the range from "slick" to "game changer". But it's inbetween those two somewhere.

http://bellard.org/jslinux/cpux86.js calls ya.load_binary() that makes XMLHttpRequest()s for "vmlinux26.bin", "root.bin", and "linuxstart.bin". For the latter two his HTTP server responds with root.bin.en.gz and linuxstart.bin.en.gz. After gunzip you can mount root.bin.en as a loopback ext2 filesystem to see the ramdisk FS contents; most binaries are hardlinks to the same 768kB BusyBox ELF 386 binary. I'm not sure what the 14,858 byte linuxstart.bin file is.

http://bellard.org/jslinux/config_linux-2.6.20

Neither. More informations there : http://bellard.org/jslinux/tech.html

Interesting read by the way.

You're wrong.

The code is written in pure JavaScript. So it's not a Java applet.

Don't feel too bad, though: It's a common error.

"Netscape originally invented a simple scripting language called LiveScript, which was to be a proprietary add-on to HTML. When Sun's new language Java became unexpectedly popular, Netscape was quick to jump on the Java bandwagon, and re-christened their scripting language JavaScript. Outside of the first four letters, there are almost no other similarities between the two."

You're comparing "applets" and oranges.

guys, guys... it's Java remember.

Just increase the applet memory.

(Correct me if I'm wrong though: I'm curious too!)

You're wrong.

According to http://bellard.org/jslinux/tech.html:

The code is written in pure Javascript using Typed Arrays which are available in recent browsers.

So, it's not a Java applet. It's JavaScript.

You're comparing applets and oranges.

Emacs and C compilers? Pah! A virtual machine running in javascript is mad genius unheard of since using graphics cards as software driven DVB modulators.

Fabrice also wrote his own version of emacs in his own realtime C compiler, and he also at one time held the record for calculating pi.

Fabrice also wrote his own version of emacs in his own realtime C compiler, and he also at one time held the record for calculating pi.

Fabrice also wrote his own version of emacs in his own realtime C compiler, and he also at one time held the record for calculating pi.

See Ken Thompson Reflections on Trusting Trust.

Now that there are multiple independent implementations of a C compiler, such as Clang for LLVM, TCC, and GCC, the trusting trust attack can be defeated with a compile farm.

No. The Linux kernel still requires GCC to compile.

Sure about that? There are non-gnu compilers, both free and non-free. If I build the system with DECC have I created DEC/Linux? Linux doesn't need a compiler to run.

And tcc builds the linux kernel: http://bellard.org/tcc