https://www.destroyallsoftware.com/talks/the-birth-and-death...

Have we not almost arrived at this dystopian javascript hella-future though?

I mean, with unikernels which run node in ring 0:

http://runtimejs.org/

And that we can run an emulated linux in browser:

http://bellard.org/jslinux/

I'm doing my best to ignore it all....

Extended JavaScript runtimes for C, C++, Go, and Node.js that support running programs written in these languages as processes in the browser.

Does that mean it's an interpreter? The main page doesn't say much.

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

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

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.

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.

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? :}

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

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.

To quote Bobby's comment above:

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

Running Unix processes inside a browser actually is new functionality. You can now also run Unix processes inside a browser on a Windows host, for example.

Virtually all Windows PCs have a Browser installed and running. Most users know how to open and operate a Browser.

Of course it's kind of redundant for everything to be reimplemented into the browser, things that should be implemented and used on a OS level, but I think it's a testament of the shortcomings of the UX design or even more fundamental paradigms of personal computing.

I have never had any trouble running either MSYS2 or Cygwin on Windows computers even when the amount of privileges given to my account has been very low.

WSL (and flinux) enable unmodified linux binaries to be run on Windows. WSL handles this at the kernel level, while flinux uses a higher level BCT.

cygwin has another purpose: It requires everything to be built from source, linking against one or more native Windows libraries (most notably cygwin1) that emulate POSIX. In short: cygwin's goal isn't to run unix programs whatsoever, it just provides Windows applications with an interface to use emulated POSIX calls - which is awesome, too.

Since WSL supports binaries at the kernel, performance is much greater for features where cygwin would have to emulate a completely different paradigm (like fork).

So while cygwin is pretty useful for a quick and usually dirty porting of unix programs to Windows, and is even frequently used to emulate(!) a unix environment, WSL can run any linux environment of your choice (the standard being ubuntu) natively.

You compile the source (C or Java) to an intermediate representation (JS or bytecode), which is then shipped to the client and executed by a language VM.

How is the end user supposed to modify the code, or break the DRM to create a local copy, or port it to another platform once this isn’t supported anymore?

WebAssembly breaks that ability, while Java at least retains it somewhat.

On the other hand, the browser devtools all still work on pages that use it. If the owner of the site you're debugging is friendly they'll include source maps so that you see the original source. If they're not then you get a disassembled view of the webassembly code. This is not very different from seeing a prettified version of a minified or obscured Javascript file.

I don't think that it changes the equation that much, except that execution speed will be better.

I’ve spent a few weeks looking at those, comparing them, and manually deobfuscating examples.

Even getting through DRM in most web- or android apps is easier than trying to get through similar example projects in webassembly.

> If the owner of the site you're debugging is friendly they'll include source maps so that you see the original source. If they're not then you get a disassembled view of the webassembly code.

The whole point is that this shouldn’t just be "if the owner is friendly", but a technical or legal requirement.

I mean, we already have early systems where you pay a tax if you create copies of stuff, which is distributed to creators, and in return you may just rip CDs, etc.

Why would a truly open source world be a dystopian nightmare? Creators still would get paid, innovation would be a lot faster, without sacrificing anything. And it would find a legal solution to what is already done illegally with the remixing culture, and also allow it in software.

I’ve spent quite a while reversing example projects in both formats, and I really hate WebAssembly.

Pragmatic situations basically.

/s

That said, my vibe is that by the time this matures enough (and Safari on iOS works well enough with it) that it's performant, there will likely be another solution that's better.

Seriously though, as a developer I find the Surface Pro far better suited for mobile productivity, I can't imagine getting much done on an iOS device while traveling besides answering email.

https://github.com/plasma-umass/browsix

Seems they are using web workers to implement a POSIX environment.

And their shell demo do not even support cd(!).

    $ TEST=1
    $ echo $TEST
    $TEST

    $ cat README | while read L; do echo "README: $L"; done
    

    $ read L
    /usr/bin/read: command not found
    $ while true; do break; done
    /usr/bin/while: command not found
    $ echo "quotes"
    "quotes"

https://github.com/plasma-umass/browsix/blob/master/src/bin/...

It doesn't do much, and certainly does not qualify as being unmodified existing code (which is what this whole system is supposed to be able to run as one of its benefits.)

The shell currently used in the demo is dash, compiled with emscripten: https://github.com/plasma-umass/browsix/blob/master/src/dash...

Which ends up in the build through our gulpfile: https://github.com/plasma-umass/browsix/blob/master/gulpfile...

The weirdness (and reason that cd + setting variables doesn't work) is because whenever you type a command in, it executes:

$ dash -c '$COMMAND'

Rather than having a long-running shell process listing to standard in. We plan to fix this and implement a full TTY subsystem in the next month or so.

``` $ ls /usr/bin cat cp curl echo exec grep head ld ls mkdir nice node rm rmdir sh sha1sum sort stat tail tee touch wc xargs ```

That means their claim that "Unmodified C, C++, Go, and Node.js programs run as processes on Web Workers"

...is not true, as otherwise they could've just "compiled" e.g. bash or some other shell to run on their system, along with GNU coreutils or similar.

dash -c "$COMMAND"

Processes can change their current directory (We support the chdir(2) system call), but the way the shell demo is currently implemented no state is retained between command invocations. We plan to address this shortcoming soon as part of a bigger TTY refactoring.

[1]: https://blog.codinghorror.com/the-principle-of-least-power/

Can someone explain what can be the use case for this?

> enabling unmodified programs expecting a Unix-like environment to run directly in the browser

The latex example is probably the best example. There are a handful of latex typesetter web pages, but the "quick and dirty" implementation for all of them are something like:

(1) take the input (2) shell out to run the latex app on a unix box (3) return the output to the user via the browser

Step (2) requires a complete unix environment. As usage scales, so too does the processing power required. Imagine if that app got 10k requests/second: suddenly you have a farm of "rendering servers" and middleware managing availability, request routing, etc.

This allows you to offload step (2) to the user's browser for a broader range of applications, with easier/faster/less rewriting. While the upfront cost is still more complex if you have to port the app to this js platform, there may be long term savings in simplicity/efficiency from the reduced server requirements. e.g., you could reduce the latex typesetting webapp to static files served from S3.

  \begin{align}
    x &= 2^2
    \intertext{so we can simplify}
      &= 4
  \end{align}

[1] https://github.com/mathjax/MathJax/issues/736

Edit: formatting

It's also a good project to learn about both the web and POSIX. Not that this kind of project is required when applying to job but it would seriously catch my attention when reviewing a candidate for any web or systems job. It's also top of hacker news so it's an excellent way to get your name out there.

you're emulating a filesystem inside the browser to manage files. while you have highly advanced filesystems sitting outside the browser with direct access to NVMe SSDs, much lower power consumption and all that. But nope, "do it in the browser" nullifies all the advances that native makes.

This being possible is a glaring deficiency of the Web, and an example of how it is stalling the state of the art.

I've been wanting something like this for ages (and have had a few ideas along those lines myself)...

The description of the technology glosses over all the really difficult bits, however, like how they turn compiled C into runnable Javascript. Emscripten? An interpreter? Gods help them, they're not using Clue, are they? How much overhead is there in executing the compiled code in chunks so that they can simulating blocking RPCs (for system calls)? Do they have a plan for threads? (I don't believe web workers support any kind of shared-memory threading.)

(later)

I found a demo here: https://unix.bpowers.net/

Inspecting the code shows lots of Emscripten stuff.

edit: found this http://bellard.org/jslinux/tech.html and this http://bellard.org/jslinux/

Error while executing undefined: Uncaught TypeError: Cannot read property 'split' of undefined

To implement C semantics, Emscripten uses a single, large JavaScript typed array as the heap. To the JS garbage collector, this heap is a big, opaque blob. Then your Scala Native program has its own garbage collector operating within its heap. The two garbage collectors are unaware of each other. This is just a vague intuition on my part, but it seems to me that an arrangement involving nested garbage-collected heaps is bound to be suboptimal. Scala.js is much better in this regard, since Scala objects are just JS objects, sharing a garbage-collected, compactable heap with the other JS objects.

But you are correct that it's a bad idea. Like running Scala.js on Rhino/Nashorn

So no, it would not make Scala.js redundant.

The real use case is running the browser in emacs, then that browser can run emacs with evil. That's a super quick way to get vim commands in emacs without any configuration issues.

So we build these low-level primitives (kernel, system calls, processes) on top of APIs the browser provides, and extend to-JS compilers + runtimes to use these primitives.

What will be interesting is to see if anyone ever gets to implementing X11 emulation.

kind of hilarious. wonder why that is..?

$ cat README Welcome to Browsix!

For more info, please check out: https://github.com/plasma-umass/browsix

Known issues with this shell: - 'cd' is not implemented. - backspacing past '$' produces "interesting" results $

    $ curl --help
    Error while executing undefined: Uncaught TypeError: Cannot read property 'split' of undefined