apignotti

Well, the environment itself is a container. Supporting Linux "namespaces" used to implement containers is also a possibility.

As described in the project README we provide a GitHub Action workflow to convert Dockerfiles into bootable images for WebVM: https://github.com/leaningtech/webvm

1. Support for traditional copy/paste shortcuts is problematic, since Ctrl-C is interpreted as the SIGINT signal. Copying via the mouse menu should work. Pasting is supported via Ctrl+Shift+V.

2. We had these reported from several users and we will investigate as soon as we can: https://github.com/leaningtech/webvm/issues/102

To answer you question: filesystem chunks are cached/persisted using a local IndexedDB. It provides a fairly strong level of persistence, although the user can wipe it out of course.

Working offline is not truly possible since that would require downloading the full 2GB disk image, which is something that is deliberately avoided by the system architecture.

State is already locally maintained via IndexedDB, no data is ever sent back or saved on our servers.

All the components of the network stack are open source: namely the Tailscale go client and the lwip networking stack. Some (not fully trivial) glue code is also required, which is not currently published. We do plan to cleanup the stack and release it as one of our upcoming internship projects.

(Same answer as a more deeply nested comment below)

The technology is extremely flexibile, off the top of my head:

* Education (Linux, Programming, Security, ...)

* Live docs for arbitrary languages and binary libraries

* Preservation of historical software and games

* Virtualization of legacy Windows enterprise apps.

* Dev environment for Web IDEs

Just a few examples, the list could go on for long

The technology is extremely flexibile, off the top of my head:

* Education (Linux, Programming, Security, ...)

* Live docs for arbitrary languages and binary libraries

* Preservation of historical software and games

* Virtualization of legacy Windows enterprise apps.

* Dev environment for Web IDEs

Just a few examples, the list could go on for long

Yes, we are working on it right now. The immediate priority is booting a complete desktop environment. Next steps will include 3D graphics.

We support networking via Tailscale, we wrote a detailed blog post some time ago: https://labs.leaningtech.com/blog/webvm-virtual-machine-with...

Using Tailscale is the most effective solution for in-browser networking, we wrote at length about the topic some time ago: https://labs.leaningtech.com/blog/webvm-virtual-machine-with...

Hi, Lead Dev of WebVM and CTO of Leaning Technologies here. Happy to answer any questions you might have... potentially in a few hours, it's quite late here :-)

Even better, consider joining our Discord: https://discord.gg/yTNZgySKGa

Absolutely not. The app starts at the entry point and execute instructions as normal. Both the main executable and libraries are all loaded on demand from a disk image delivered chunk-by-chunk over HTTP. The disk backend is based Clouflare workers with multiple levels of caching to maximize perf.

You can opt-out by manually writing an email to them. The process matters.

An important, but little known fact about modern agriculture, is that _everyone_ buys seeds from specialized seed companies.

I consider 'Left Hand Of Darkness' to be the single book that resonated the most with me, with 'The Dispossessed' being my previous favorite.

On the other hand I was very disappointed from 'A Wizard Of Heartsea'.

WebAssembly is not magic, the simple reality is that browsers do not expose low level socket interfaces, so they cannot connect to arbitrary services on the wider internet.

We choose to use Tailscale since they allow WebSocket-based connections via their DERPs.

It is interesting that, originally, DERPs were intended to be a solution for machines in extremely limited networking environment where nothing but HTTP is allowed. Turns out browsers are exactly one of those extremely limited networking environments.

The point is to have a more efficient solution to deploy large scale Web applications. Efficiency here is measured in comparison to JavaScript, and it's based on 3 main points

  1. More compact representation due to binary encoding compared to text

  2. Improved compilation times, since WebAssembly is "lower-level" compared to JS and the engines can assume code has been already optimized and can skip a good chunk of the normal JIT optimization pipeline.

  3. Improved runtime performance due to strict typing. No type-checks, no bailouts, etc

These come with their set of drawbacks, the main one being that WebAssembly cannot _really_ use the DOM or interact with JavaScript directly and is effectively just a computational engine. Any interaction with the outside word is abstracted to "imports": calls with arbitrary semantics come from outside of WebAssembly.

At some point WebAssembly also had the advantage of predictable performance, with the idea being that code would be compiled once-and-for-all during module loading.

This promise was, as far as I understand, effectively abandoned first by the introduction of "Baseline" compilers (Liftoff, in V8 terminology) and in more recent times by the requirement of WasmGC, which (I think) has reintroduced the need for bailouts and dynamic recompilation.

As part of the next release cycle we plan to release our C/C++ JNI implementation so that 3rd party JNI components can be compiled to dynamically loaded .wasm libraries.

This will be based on Cheerp (our C++ -> WebAssembly compiler).

Integration with CheerpX is another possibility, but we think building the modules from source it's a more realistic solution in the medium term.

Shameless self-promotion: https://webvm.io

Powered by a x86->Wasm JIT. Technical writeup: https://labs.leaningtech.com/blog/webvm-server-less-x86-virt...

Correct, but the new CheerpJ 3 archicture will let us move quite quickly to modern Java versions.

3.0 will still be focused on Java 8, with a fully new JIT architecture that does not require any AOT compilation steps or preprocessing.

With 3.1+ will begin catching up with modern Java.

[Shameless plug]

We have just renewed our fully-client side take on the "Java playground" concept, powered by CheerpJ

https://javafiddle.leaningtech.com/

AWT and Swing apps work as well, which I believe to be quite unique.

Genuine question: I love Discord, but how on earth is it possible that such functionality was not built-in to begin with?

I really don't understand how the need for indexing and search was overlooked.

"record" is a Java 14+ feature. CheerpJ currently supports Java 8 only, but the 3.0 is designed to be scalable to modern Java versions.

The tradeoffs are more subtle. A JIT compiler has more timing constraint, but more information about the runtime behavior of code.

As a counter-point to your argument, consider a highly dynamic language such as JavaScript, in particular the '+' operator. An AOT compiler would have no choice but dispatch to a generic heavy implementation that could handle any possible combination of inputs. On the other hand a JIT compiler can observe the runtime values used and specialize using Inline Caches, potentially down to just a few instructions.

In the case of CheerpJ the virtual machine itself is pure C++ compiled to WASM, but the JIT-ted code and the objects are pure JS. Garbage collection is natively handled by the browser.

As WASM GC stabilizes we will consider supporting it as well.

Window movement is implemented in the current production release (CheerpJ 2.x), but not yet as part of the CheerpJ 3.0 rework.

We (Leaning Technologies) are proud to have been a big contributing factor to the standardization of WebAssembly tail calls.

https://news.ycombinator.com/item?id=32069418

Cheerp works with C code, it's also possible to use __attribute__((cheerp_jsexport)) as an equivalent to [[cheerp::jsexporp]].

Accessing DOM / external JavaScript can be done by using the __asm__ syntax while in C, use of the client namespace is only possible from C++ code

We don't support sockets out-of-the-box yet, but we have built a solution for the "networking-from-the-browser" problem a few months ago and we may backport that to Cheerp eventually.

https://leaningtech.com/webvm-virtual-machine-with-networkin...

Nice to see our technology, CheerpX, cited here. Running Wine on top of CheerpX/WebVM is in our plans by-the-way.

https://webvm.io

I do not think SQLite compresses data by default. Can you point to any documentation suggesting otherwise?