Browsix – A Unix-Like Operating System for the Browser | Hacker News Reader

Browsix – A Unix-Like Operating System for the Browser

github.com

66 pointsoskrim26 comments

Cool, but why not allow us to compile C code, and run everything in ASM.js? That would make it more Unix-like in my opinion.

Also it would save you the trouble of writing a shell from scratch :)

Don't even get me started on javascript, it's the new flash player.

Except, Flash Player is proprietary software; and JavaScript is a standardized programming language, with multiple implementations.

But I get your sentiment;

Welcome to the Atwood law.

I get you.

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.

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.

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.

1 - https://github.com/kripken/emscripten/wiki/Emterpreter

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.

Wow, looks like a big deal. I've been reading through https://github.com/plasma-umass/browsix/blob/master/doc/repo... which is a really nice article, but I'd recommend you to tell a bit more on what this level of indirection brings.

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

    > You mention Bluetooth for example in the beginning which
    > is an example of hardware that is yet not supported from
    > the browser.

In what way? There's Cordova/PhoneGap, W3C Web Bluetooth; JS libraries like noble and bleat.

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.

Hi, one of the authors here. Thanks!

We have a tech report, that has more details on what we are aiming for here: https://web.cs.umass.edu/publication/details.php?id=2414

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.

Conceptually, I'm digging it. But what would the use cases look like? (not as a skeptic - as a 'I wonder what this opens up')

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 can't decide if you are serious or tongue-in-cheek... I'm worried.

I'm quite serious. What's your concern - that it is unrealistic, or that we should stick with mostly-static, single-threaded web-pages forever?

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/

There's also this https://github.com/shellinabox/shellinabox and this http://www.web-console.org/

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.

What am I missing?

ls /usr/bin gives me:

  cp
  cat
  cpu-intensive-program
  curl
  dot
  echo
  exec
  fork_test
  go-bench
  grep
  head
  hello
  hello-socket
  http-example
  lat_syscall
  ls
  mkdir
  nice
  node
  pipeline-example
  priority-test
  rm
  rmdir
  sh
  sha1sum
  socket-example
  sort
  stat
  tail
  tee
  touch
  wc
  xargs

Doesn't seem to be cd, but ls does work. Chromium on Arch.

> Doesn't seem to be cd

That's expected:

    $ 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)?

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

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.

It's been done - see Gary Bernhardt's "The Birth and Death of Javascript".

Dunno if it is something to do with Firefox, but backspacing past $ produce some interesting error output.

Seems to only happen right after a command though, hitting return a few times gets rid of it.

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.

Reply on news.ycombinator.com