nteon

We use Web Workers as the basis for our processes, and processes perform system calls to the kernel (running on the main browser thread). Our standard system call mechanism is asynchronous and uses the standard postMessage API to/from Web Workers. When executing a system call, the language runtime saves the current call stack, and when the Web Worker gets a response to the system call, it resumes that thread.

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.

I know you were kidding, but one of the co-authors of Browsix wrote the Doppio JVM: http://doppiojvm.org/ a full JVM in pure JavaScript. It will soon run under Browsix!

not yet :) We're currently focused on command line programs -- it would be really neat to see Haskell running by adding support for Browsix into http://haste-lang.org/

Author here. One thing to emphasize is that all processes run in the browser and are isolated from whatever underlying OS/filesystem the browser is running on - there is nothing special to think about in terms of sandboxing or security. If as a developer you want to give users access to their underlying filesystem, you can do so as usual (HTML5 FS API in Chrome, https://developer.mozilla.org/en-US/docs/Using_files_from_we... in general).

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?

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.

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.

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.

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

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.

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

The Chromium team's blog post about this suggests that > 99% of HTTP/2 connections are _already_ negotiated with ALPN [1]. I imagine all of the CDNs and other large providers already use ALPN, so this mostly affects the long tail of small sites. It seems like the claims in the above blog post are overblown.

1 - http://blog.chromium.org/2016/02/transitioning-from-spdy-to-...

MathQuill is amazing, I haven't seen anything else as nice for inputting moderately complex formulas.

Can you describe an example of a better, real-world unit test you have in mind?

Do you also advocate against writing ES6 and using Babel?

Pierce's Types and Programming Languages ( https://www.cis.upenn.edu/~bcpierce/tapl/ ) is great - I'm working throught it now. Its goes through both untyped and statically typed languages. It also goes into how to implement these things in OCaml.

what is memory usage like in terms of number of allocations and peak RSS with B3 vs. LLVM?

You could easily do a syscall to get a signalfd file descriptor, then call os.NewFile to turn that numerical FD into a Go *os.File (https://golang.org/pkg/os/#NewFile). It seems like that should work fine!

C doesn't have generics, and is certainly a systems language. I don't think you have a strong point here. Systems != embedded.

"I still wonder why we can omit commas on import/var/const blocks and just can’t on lists and maps. Anyway, Rob Pike knows better than me! Viva la Readability!"

import/var/const blocks rely on semicolon insertion rules, list and map literals have a list of Elements separated by ',' [0]. I guess on the surface level I see how this is sort of inconsistent. It would be interesting to think about applying semicolon insertion to comma insertion.

0 - https://golang.org/ref/spec#Composite_literals

Has Debian really not given up?

Bundling is why chromium is (still) not in Fedora's repos[0], yet Debian has shipped it for years. I've assumed Debian was more lax on bundling or build reproducability issues - is there another reason?

0 - https://fedoraproject.org/wiki/Chromium

A 'replacement' for systemd should be designed to be drop-in: /sbin/init should read unit files (which in general are much nicer than init scripts), should provide systemctl with the same options, and if dbus is also undesirable (which most people who burn with fire-y rage for systemd do), should replace the communication between processes like systemctl and /sbin/init with something else, like a Fuse or 9p filesystem.

That would be pretty neat. But until then, the world will continue to run on systemd, because it _works_.

V8 uses a function's length in characters, _including comments_, to make optimization decisions. By removing comments and shortening var identifiers internal to a function, I can imagine a number of functions dropping under that 600-char threshold. Would be great to measure.

for an example, checkout this: http://pasky.or.cz/dev/glibc/ifunc.c

Two implementations are compiled (one is optimized using instructions only available on certain processors), and the decision of which one to use is made at program startup.

If you're using shared libraries in your program, you already have this extra indirection - at compilation/link time the compiler/linker doesn't know where in memory the shared library will be when the program is run, so every call into a library goes through the procedure linkage table (PLT), which works by looking up the 'real' function pointer in the global offset table (GOT).

So yea, populating this at runtime depending on the CPU features supported by your CPU is possible, and the linux dynamic linker does this: http://man7.org/linux/man-pages/man8/ld.so.8.html (check out the section on hardware capabilities).

very neat. It definitely seems useful to be able to do a speculative read/write from an eventloop, and only defer the IO to another thread if it would block.

Table 1 is looking specifically at getting a chunk of data off the wire and into the users code. Look at Table 2 for a comparison of redis read/write. Average time for a write is 163 μs - of which 137 μs is spent in fsync(2)

To be clear, 80% of kernel-time in that 1KB write is spent in fsync(), _not_ in the network stack. Network overhead is roughly similar between read & write requests. What Arrakis seems to be able to do is avoid the overhead of write & sync, presumably because it doesn't go through the VFS + filesystem + block IO code paths.

agreed - redis is a single binary with minimal dependencies, this seems like so much more work for no gain.

no - its not the job of the compiler to choose your memory allocator. There is talk, however, of replacing the current glibc allocator with jemalloc[1], which is the more appropriate place for that decision to be made.

1 - https://sourceware.org/ml/libc-alpha/2014-10/msg00419.html

the glibc allocator is based off of Doug Lea's malloc that was developed before multithreading was common. Optimizations for multiple threads + arenas were retrofitted on top of the existing code, whereas jemalloc was designed more recently from scratch for multi-threaded workloads, and was able to take advantage of recent research.