13 ms·

Hi - main author here. Browsix is not an interpreter. Browsix provides a shared kernel and primitives like system calls to _existing_ interpreters and runtime

by nteon 10y ago

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).

shurcooL 10y ago
Very interesting, can you tell us more how GopherJS is being used by Browsix?
- nteon 10y ago
  Yes! GopherJS has been amazing to work with. The majority of our changes (https://github.com/bpowers/browsix-gopherjs 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.
jonathanpoulter 10y ago
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 10y ago
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 http://bellard.org/jslinux/tech.html
- detaro 10y ago
  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 10y ago
    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 10y ago
      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...

by nteon 10y ago

shurcooL 10y ago

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

nteon 10y ago
Yes! GopherJS has been amazing to work with. The majority of our changes (https://github.com/bpowers/browsix-gopherjs 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.

jonathanpoulter 10y ago

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 10y ago

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 http://bellard.org/jslinux/tech.html

detaro 10y ago
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 10y ago
  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 10y ago
    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...