[nteon]

Hi - main author here.

Browsix is not an interpreter. Browsix provides a shared kernel and primitives like system calls to _existing_ interpreters and runtimes that target JavaScript.

For example, we extended both the GopherJS and Emscripten compilers and runtimes to talk to our shared kernel, so that processes written in C and Go can run in parallel (on separate Web Workers) and communicate over pipes, sockets and the filesystem in the browser (much like they can in a standard Unix environment).

[jonathanpoulter]

Thanks, this is super exciting. It really could push LaTeX on the web. In my opinion, this solves the problem I feel similar to every attempt to implement Vim keybindings has, what features of the original to implement (everyone wants something different), slight bugs or limitations which aren't at first apparent.

[cyberpunk]

Are you not easier emulating x86 then trying to reimplement the entire linux syscall table in javascript?

Then you can run anything that works on ia32 unmodified -- gcc, linux, X, firefox.. Whaytever...

Someone already did it: http://bellard.org/jslinux/tech.html

[nteon]

JSLinux is a tremendous feat of engineering.

If you want to run realistic programs in the browser (and not just technology demos), WebAssembly, asm.js, and compilation to JavaScript in general is the way to go. WebAssembly can easily execute within a factor of 2 of optimized GCC binaries, whereas JSLinux is ~80x slower.

Paired with compilers like Emscripten and GopherJS Browsix has the potential to be a relatively fast and lightweight solution to running legacy code in the browser in a way that integrates with existing tools for web UIs.

[cyberpunk]

Do you have a real world use case for this sort of thing? I'm digging the ability to do these kinds of satanic rites, but I'm not really sure that there's a practical use today other than pushing the bounds of what's possible..

[nteon]

I think the most compelling use case is running legacy code in the browser (and in applications like Atom and Visual Studio Code) - like our Latex example.

Another good use case are command line tools like graphviz. Someone wrote a wrapper around an emscriptenized Graphviz that looks great, but Browsix should lower the bar for using great existing tools like these from JavaScript.

[detaro]

Sounds like a lot of unnecessary overhead, running an extra kernel and an extra layer of interpreter, with code/semantics that don't match well to the lower (JS) interpreter. Sure, it's the best (=only) way to run existing binaries, but why not make use of the fact that source code is available for many applications?

[cyberpunk]

Because you need to write an entire kernel and I guess a compiler, and probably modify the applications to work on it instead of just dropping an ubuntu iso that works on any other system into it and using it unmodified?

I'm not sure the overhead is reeally that significant... I mean, we have pretty fast computers these days and I'm not sure even a 30% perf increase is worth all the effort of writing your own kernel and compiler when we're talking about doing something like running native binaries inside a browser which is pretending to be a real kernel...

It's awesome we can do these things today, and I guess that's reason enough to be doing them, but I'm not sure why we wouldn't want to just run any x86 (windows, linux, bsd, whatever) and not have to play catchup all the time..

Can we use asm.js to make qemu work? :}

[cyberpunk]

Thinking about it a bit more...

The linux ABI has an implemention on SmartOS, BSD and even Windows now... This is great, we have a set of syscalls that can be hit on almost any of the major OS's -- it might not be the greatest/fastest thing ever to translate linux syscalls into whatever native, but the bigger picture here is that linux somehow ended up accidently being what things like cloudabi were pushing for.

If the linux syscall table becomes the target, and those apps work everywhere, soon enough we won't need to mess around making things that run on bare metal support a lot of different os's with tons of IFDEF's and so on.. We just target the one ABI and leave the translation to the OS..

If this is an attempt to implement the linux syscall table in browser, then that means we could run these binaries in even more places!

It took I imagine quite a lot of folks quite a lot of time at MS and Joyent to do so though and I thought reading through this that it wasn't binary compat with linux?

tl;dr -- not binary compat with linux, then emulation is probably more useful. compat with linux; we're getting really close to having a standard binary format that works _EVERYWHERE_ and that's pretty fucking cool :}

shrug I'm not really that far thinking most times...

[shurcooL]

Very interesting, can you tell us more how GopherJS is being used by Browsix?

[nteon]

Yes! GopherJS has been amazing to work with.

The majority of our changes (https://github.com/bpowers/browsix-gopherjs) amount to an alternative implementation of the compiler/natives/syscall package (we started before GopherJS had its own filesystem implementation). This lets us use the stack saving + resuming support GopherJS already has to implement blocking system calls.