Hi, I'm one of the main authors of Browsix. One of our goals is to run C code - we have simple utilities from sbase running, and more complex code like latex and GNU make (the README needs updating). The main complication is that C code does system calls, which are traditionally blocking, and there isn't a good way to achieve that in current browsers with just ASM.js. So, we currently use the Emterpreter[1] (which is much slower) to make sure that anything on the stack underneath a system call can be saved and restored. SharedArrayBuffers should let us implement something faster in the near future.
Interesting. Normal javascript has a "yield" directive, but I guess that it is not part of ASM.js. Is this something that ASM.js will eventually support?
Also, is Emterpreter really an interpreter, or do they still compile parts of the code to ASM.js for performance (e.g., parts that do not contain system calls)?
The emterpreter is really an interpreter, but as you guessed, you can direct the compiler to compile parts of your code to ASM.js so that you can benefit from native-like performance for CPU-intensive parts of your app.
Yield is relatively new, part of ES6, and I think is tied into async/await. It might be possible to use it in combination with something like Babel, but I didn't go down that route. I think the way forward is SharedArrayBuffers and their blocking wait()s on futexes.
My (limited) understanding is that asm.js doesn't allow blocking code, which means it's not a good fit for a Posix like model with a main function which calls out to external services. (I'd love to be wrong here.)
I hear that there's a plan for some form of limited shared-memory concurrency which might be abusable to allow threads, but I haven't made much of the designs.
My point: JavaScript, it's ecosystem and community are bad enough to be proprietary. It's the new skurge of the web browser and what do people do? Make 'applications' with it.
You mention Bluetooth for example in the beginning which is an example of hardware that is yet not supported from the browser.
Applications beyond what can currently be done in a UNIX shell would be good. You already have thought long about it. I feel you can tell us much more about possibilities!!!
As another example of what we can do with real Unix abstractions in the browser, we have :
https://meme.bpowers.net/
Which runs a standard Go HTTP server in a web worker, and instead of doing XMLHttpRequests to a remote service, can route those requests to the in-browser HTTP server! In this case it is about 10x slower, but I think that is an artifact of the GopherJS compiler I have yet to work out.
I'm not the author, sorry. Just spotted this on the Google Summer of Code projects list. Read through the paper too, quite creative stuff. I suppose Bluetooth was just an example as the project is still kind of proof of concept at present.
A number of things - do you have a small microservice that was easier to write as server-side code, but you don't want to worry about scaling it? Run it in-browser without code changes or worrying about jank - the server is run in a Web Worker, and any long running computations can happen concurrently with rending, layout, and input handling.
Same with traditional C and C++ applications. Wrapping program invocations or APIs with Emscripten can be a pain, and if you have a couple of programs you want to use together, forget it. Browsix lets you compile the program down to a single js file, provide input as you expect (by sticking files on a filesystem, or providing stdin), and register a handle for stdout + stderr.
I feel that the additional layers of indirection are quite costly for the convenience of running programs in a Unix environment inside the browser. I can understand the practicality of that for prototyping, but it seems a bit baroque for a production system.
But then, the idea of heaping Javascript monsters upon a mere browser seemed ludicrous to me 20 years ago - so I may not be the best judge of those sort of things...
A different animal (no pun intended) but this project also provides the ability to render a web-based shell if that's your primary use for this http://pigshell.com/v/0.6.4/
Looks interesting but did anyone get the demo to work?
Click on the "live demo" link, quite a long delay (few minutes), finally terminal-like display appears with "$" prompt.
However entering usual unix commands, ls, cd, etc., gives error: "Error while executing /usr/bin/ls: TypeError: get length method called on incompatible Object", or "/usr/bin/cd: command not found".
Running with FF Nightly. Don't know if it's me, FF, or the app.
First, (as silly as it is), 'cd' is not yet implemented, as that is a shell intrinsic.
Second, Firefox stable (46) is currently supported, but something has changed in the nightly that breaks us. It should be simple to track down, but in the meantime using almost anything other than FF nightly should work! (Safari, Gnome Web, Chrome{,ium}, IE Edge).
$ lsb_release -i
Distributor ID: Gentoo
$ ls {,/usr}/bin/cd
ls: cannot access /bin/cd: No such file or directory
ls: cannot access /usr/bin/cd: No such file or directory
$ type cd
cd is a shell builtin
If it isn't working in this javascript project, maybe it is only faking the Bourne shell (badly)?
It was only a question of time until someone would come up with this. The next logical step is to rewrite the browser in JS, so it can run inside the browser.
Yea - the shell is an MVP, to say the least. I plan on replacing it later this week with something like term.js to provide a more consistent terminal experience.
Also it would save you the trouble of writing a shell from scratch :)