humphd / browser-shell Goto Github PK

I'm trying to build my own v86 from https://github.com/humphd/v86/tree/filer-9p-lastknowngood, but putting in the directory to load crashes the VM:

fs, path, and Buffer are all available on window for debugging, e.g., fs.stat('/', console.log)
index.js:1024 See https://github.com/filerjs/filer for docs.
index.js:1025 use ?debug on the URL if you need Plan9/Filer debug info from v86
?debug:508 no xr
index.js:12248 boot 0
index.js:12250 boot 1
index.js:12311 wait for prompt 1
index.js:12001 Unimplemented: #GP handler
index.js:12001 Execution stopped
index.js:11469 Unimplemented: #GP handler
index.js:11469 undefined
index.js:11469 Uncaught Unimplemented: #GP handler```

I used the docker build there. Something I'm doing wrong?

I wanted to use this project as an in browser ssh tool. I ran the setup shell script and then npm run build. Everything seems to be working except for the xterm console. It can't resolve the returned promise in waitForPrompt in vm.js on cold boot startup. For some reason it's not calling the callback function passed using add_listener

The network support doesn't work as the module 'ne2k-pci' module is not available. I have checked the defconfig of browser-vm to see dhcp and module are enabled. Did you trim down networking support? Or do you suggestion for networking support with extension of browser-shell?

Very interesting, on Brave 1.38.71 after some succesful page-loads (and writing a file to /mnt) it stops working:

I tried deleting all cookies/appdata etc (in the browserconsole) but didn't help.

Btw. I really like the idea of Filer (and to put nohost in there at some point). I can see how that could allow an (so far unused) paradigm for creating more independent & selfsufficient apps.
I mean, this whole you-need-a-server-for-file-CRUD paradigm seems a bit silly sometimes.

replacing the 9P filesystem with Filer with new Object creation 'const options = Object.create(emulatorParams);' in filesystem.js and assign it to filesystem doesn't work. Did you make any changes in the v86 library JS to make this workaround 'options.filesystem = filerAPI';

There is no setup instructions.

The modified and integrated Filer system in v86 removed wasm fetch call in libv86.js in lastknowngood. Is there any reason behind it? The v86 VM loads and works absolutely fine with libv86.js. Although wasm files are not loaded for better performance.

I'd say this project needs about 1,000 - 10,000 more github stars.

This is an absolutely fantastic project, unlike anything I've seen in web dev 👏👏👏, a true demonstration of the untapped power of the web. Not only that, but great writeup, the gifs, blog post, and explaining the details of what you had to do and who you had to talk to in order to get it working. I can't believe how responsive the terminal is WITHOUT wasm. We're going to use this at my University to teach linux to students (who mostly have Windows laptops).

In terms of a browser file system, over the years I've been incredibly interested in a client-side package manager. Instead of compiling S.P.A. websites into one giant monolithic file, the site just requests the package+version of npm libraries they need. The client would either already have a local copy and load it instantly or download it one time (instead of downloading an entire duplicate library for every site and every site-reload). You could potentially even pre-load library variables while waiting on the unique code of the website. This could make so many sites blazing fast even on low bandwidth. I've always wondered why Google hasn't built something like this into Chrome.

I'm also interested how much work it would take to connect the linux VM to the network through the javascript fetch API so that commands like wget would work. That would be an incredible step forward, but I imagine it isn't easy since it probably doesn't fit within Plan 9.

[Obviously you can close this issue]