Hacker News Reader

Hacker News

Comment by snadal | Hacker News Reader

Full thread

snadal

Disclaimer: not being sarcastic at all.

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

View on HN

The use case is right there in the text:

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

This is exactly what I was thinking, the most advanced LaTeX typesetter is probably mathjax, but it can't and probably won't [1] handle full LaTeX. Just consider this pretty simple LaTeX,

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

With a little bit of fanciness (sourcing the .sty sheets) behind the scenes, this could faithfully reproduce LaTeX.

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

Edit: formatting

I could see the example of LaTeX in the browser being actually useful, when for example you're on a computer where you don't have permissions to install software.

I expect it's much the same use case as for asm.js and WebAssembly — just a different solution to the same problem. The intention is probably for it to become an easier way to port software to the web, although it seems like a lot more work will have to be put into it for it to be remotely viable for many programs.

Speaking asm.js and WebAssembly... they would be good tools to implement a Unix environment.

We already work with asm.js, and I've gotten some WebAssembly prototypes running under Browsix as well. Browsix is nicely orthogonal to those projects -- WebAssembly lets you compile existing C/C++/Rust code to run in the browser with almost no overhead, and Browsix gives you the environment your program expects (pipes, sockets, a filesystem, subprocesses).

No, I cannot. I'm mystified why anyone would spend their time building this...

Because it's a good demonstration of how the Web is advancing by showing that this kind of thing is possible.

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.

It's the JavaScript platform that's advancing, leaving the web behind. A browsix process might happen to use a web page to bootstrap but it can't be part of the web because it doesn't have a URL.

> Because it's a good demonstration of how the Web is advancing by showing that this kind of thing is possible.

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

Would more possibilities slow down state of the art or speed it up?

There are many possible things you can do with a frying pan, but only a few of them are good ideas. The flexibility of the Web is a generally good thing, but often misused and often for inferior reinventions of the wheel like this. The amount of research time spent making Web browsers into feeble operating systems would have been better spent elsewhere.

I wouldn't call this an advance. The web does not interact well with your host system. it creates its own silo. and this is just another step in the silo direction. why talk to the host at all? embrace the web! entrust all your files and software to us!

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.

Don't you think the in-browser latex editor (with no backend server required) would be useful for at least some people?

If this worked properly, I'd find it incredibly useful. It'd give me a Posix command-line environment inside the browser, with all the commands running locally, backed by a file system on cloud storage somewhere, which would work anywhere, regardless of what computer I was currently working on.

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.

Academic usage is all I can think of. May as well aim for QEMU in JS, then this can all be moot.

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

Reply on news.ycombinator.com