- "Is WebVM a potential solution to "JupyterLite doesn't have a bash/zsh shell"?" https://news.ycombinator.com/item?id=30167403#30168491 :
- [ ] "ENH: Terminal and Shell: BusyBox, bash/zsh, git; WebVM," https://github.com/jupyterlite/jupyterlite/issues/949
And then now WASM containers in the browser FWIU
All these little optimisations... just aren't going to work well in a browser. I mean, I can already see that alpine (an extremely lightweight VM that I've had boot instantly with vagrant and other such stuff) is slow here. It's a cool hack. I just prefer things to be practical...
[1]: My utterly naive benchmark completes in 9s - time seq 1 50000000 | wc -l
In the longer term we plan to get unmodified Docker containers to work with CheerpX, including exposing REST APIs to the local Web app.
We have also internally speculated about a marketplace-like system to allow immediate conversion of traditional client-side apps to Web apps. This would be intended for the long tail of client software vendors that have not yet adopted Web-first distribution methods.
For more info, see the last few paragraph of the Networking section from our latest blog post: https://labs.leaningtech.com/blog/webvm-20#private-networkin...
You mention having a "virtual block-based file system". How easily can people integrate other devices into the VM, including custom devices? For instance, if someone had a different network filesystem they wanted to use, which could be tunneled over WebSocket or WebTransport, how easily could they integrate that into this? What's the equivalent of virtio here?
It looks like the client-side bits are largely proprietary? Is CheerpX the primary thing you consider to be your competitive advantage, or is it more about all the layers you're putting on top of that for things like Flash and Java and Oracle Forms and converting local apps to web apps?
It'd be nice to be able to build atop the underlying VM and extend it for all sorts of purposes, the way KVM has been open enough to become a focal point for the modern cloud, and have just the enterprise-y bits and "convert your local app to a web app" framework running on top of that being proprietary.
CheerpX is indeed proprietary, but free-to-use for individuals and open source projects. We do want to see the community building on top of our tech. Our Flash product is build on top of CheerpX and the official Flash player plugin that needs to be licensed separately from Harman/Adobe. Java support is provided by a completely different product called CheerpJ, although lots of the ideas and parts of the JIT engines are shared with CheerpX.
At this stage we believe that keeping CheerpX proprietary serves our growth plans the best, this could of course change over time as adoption increases and we build further added-value products on top. On the other hand the WebVM integration is FOSS since it doubles as an extensive sample of what can you build with our technology.
I was thinking more about arbitrary custom devices, like custom network drivers (e.g. to connect to a server-side virtual network rather than tailscale) or custom filesystem drivers at either the block or FS layer.
> At this stage we believe that keeping CheerpX proprietary serves our growth plans the best, this could of course change over time as adoption increases and we build further added-value products on top.
I'd be very interested in chatting with you about our respective products' future plans.
Sure, you can find me and the rest of the team on Discord: https://discord.leaningtech.com
https://jamesfriend.com.au/pce-js/ (https://github.com/jsdf/pce)
https://www.pcjs.org/ (lots of hardware and OSes) (https://github.com/jeffpar/pcjs)
https://infinitemac.org/ (https://blog.persistent.info/2023/03/infinitemac-dot-org.htm...)
https://jamesfriend.com.au/projects/basiliskii/BasiliskII-wo...
Here are a few things I encountered which might probably help others:
# Version mismatch:
The install version of node.js I had (v12.22.9) was too old to meet the project's requirements (>= 18.13).
To fix that, I used nvm to install the right Node.js version (>18.0) # Version check before install: Used the following to check version to verify before proceeding ahead with building it:
node -v
npm -v
It ran successfully, and I've been playing around with built-in Python3 and C scripts and pushed the modified repo to my personal GitHub. Thank you, dev!The main difficulties right now are two:
* Most docker containers are 64-bit, while CheerpX currently only support 32-bit x86 code * Due to CORS limitations it is not currently possible to downloaded layers from repositories such as Docker Hub
The first limitation will be eventually fixed, the second one will require a specialized repository, a proxy, or co-operation from the existing repositories.
Fundamentally, a real VM running a real OS needs lots of data.