Very curious who you mean by "us." Are you part of a Plan9 user community? Interesting.
I remember firing Inferno up inside a Java applet a few years ago. I think something that might generate some interest is a) compiling Plan9 (kernel + rootfs) to JavaScript, and b) interfacing that boots-inside-JS environment to Web APIs for mouse, audio, graphics, etc. It would essentially be [all the work of] a new platform port (albeit one without a CPU architecture (!), and using JavaScript hardware/"peripherals" :P), but I think that making the effort needed to implement this would send a good message that Plan9 is built by people who are interested in keeping their work relevant, and that they think it's worth that (which of course it is ^^, but - you know, advertising). Yeah, it won't significantly sway the status quo (sadly), but I'd definitely argue that the lack of a JS port of Plan9 is - as crazy as it sounds - a real hole nowadays.
Browsers will never do raw TCP/IP due to security concerns and that is a fairly noteworthy roadblock. WebSockets goes over HTTP+TCP, and WebRTC data channels are SCTP. But if you wrote a Plan9 driver of some sort that handled WebSockets/WebRTC (WebSockets would be significantly easier) and let you talk 9P over that, and then wrote an appropriate driver (that listened on a local port) for native Plan9, you could talk from an in-browser Plan9 instance to a native instance running on real hardware or a VM.
I'm not sure how far plan9port goes in terms of 9P emulation, but it might be worth to figure out how to make the native (aka non-browser) side of the WebSocket/WebRTC<->9P transport work with plan9port as well as "real" native Plan9. That way users who are running just the one copy of Plan9 in browser can talk to it with plan9port tools. If plan9port can't already do that though (can it?) then maybe that would be asking a bit much (adding functionality to plan9port is a bit of a tall order).
This would make firing the system up and playing with it a whole lot easier, akin to how you can run DOS games from the Web Archive in-browser because they compiled DOSBox to JS.
While I expect that the most straightforward (and non-insane) path to doing this would be Emscripten, it may be a very fun research topic to make the Plan9 C compiler and/or the bytecode generator JIT directly compile/generate WebAssembly code :> - with a fully capable toolchain you could even compile the kernel directly to wasm, skipping the translation overhead of Emscripten!
WebAssembly is still in the early stages, although there is some active (albeit early) browser support for it floating around, and you can build and test things without having to recompile your entire browser AFAIK (yes, if I understand correctly, browsers already include alpha-stage wasm parsing code). I suspect your best bet is likely to be to skip the likely-outdated noise on websites and just chase the Chromium/Firefox/WebKit/Emscripten teams (particularly Emscripten, which is spearheading compile-to-wasm) for the latest advice.
It would be especially awesome for you to be able to immediately follow the "Chrome officially supports WebAssembly" HN post (maybe a few months away) with "Plan9 runs in-browser and compiles directly to wasm" :D - while most people will just punt and follow the "put your .js on your site, run it through $compiler and put the .wasm file next to it like this" tutorials, you'd probably get a bit of traffic and exposure from directly generating wasm. A LOT (LOT) of people - mostly hacker types - are going to want to know how wasm works, and... showing off Plan9 as the tech demo of the fact that you're directly generating wasm... well......
It's not yet perfect; see https://github.com/WebAssembly/design/blob/master/FAQ.md#is-.... At this point wasm specifies no way to talk to the DOM but only allows you to invoke high-speed code execution from JavaScript. It may be worth waiting for DOM access capabilities, although as that link mentions, it's already viable to compile language VMs to wasm, so OS kernels sound reasonable too.
Us - yes I am part of the plan9 community - though somewhat inactive at the moment - I'm doing a degree in Supply Chain Management so my focus is on that.
That's all well porting a plan9 to JS but it's the kernel services that make plan9 different.
"Everything is a file" is the core concept. The rest is just things built on top of that.
We have a boot CD, it boots in Qemu, we have an emulated environment that runs on on Linux/BSD in 9vx, we have mounting 9p in the Linux kernel, we have plan9ports in Linux/BSD.
I hope to explore Plan 9 in greater depth than I can right now too.
I agree that the kernel services are what make Plan 9 different. I think the "everything is a file" concept is something that has not been explored nearly as much as it could be.
Thanks for mentioning 9vx, I completely forgot about that project! Just downloaded it and fired it up (managed to figure out the correct invocation without needing the (nonexistent) manual :P). That would be a really interesting port to JS.
I agree that Plan9 is not at all hard to get at - but if you can run it just by visiting a website, a LOT more people will play with it. Even if they just fire it up, go "huh, neat" (or more likely "how on earth do I use it") and close it, that does increase platform exposure.
I can't help but remember all the DOS games that are directly playable on the Web Archive. Inferno used to run in-browser because it's the perfect tech demo of the platform. Plan 9 should be able to too IMHO.
At this point in time Web browsers are not the perfect environment for general-purpose x86 emulation, I can't argue that. If things were different we'd run everything inside the browser. But I think Plan9 is sufficiently resource-light, fast, and cleanly-designed enough that it would make an excellent candidate.
I remember firing Inferno up inside a Java applet a few years ago. I think something that might generate some interest is a) compiling Plan9 (kernel + rootfs) to JavaScript, and b) interfacing that boots-inside-JS environment to Web APIs for mouse, audio, graphics, etc. It would essentially be [all the work of] a new platform port (albeit one without a CPU architecture (!), and using JavaScript hardware/"peripherals" :P), but I think that making the effort needed to implement this would send a good message that Plan9 is built by people who are interested in keeping their work relevant, and that they think it's worth that (which of course it is ^^, but - you know, advertising). Yeah, it won't significantly sway the status quo (sadly), but I'd definitely argue that the lack of a JS port of Plan9 is - as crazy as it sounds - a real hole nowadays.
Here's the NetBSD kernel running in JS, although it doesn't have a proper shell/tty interface (it's just a proof-of-concept): https://ftp.netbsd.org/pub/NetBSD/misc/pooka/rump.js/
Browsers will never do raw TCP/IP due to security concerns and that is a fairly noteworthy roadblock. WebSockets goes over HTTP+TCP, and WebRTC data channels are SCTP. But if you wrote a Plan9 driver of some sort that handled WebSockets/WebRTC (WebSockets would be significantly easier) and let you talk 9P over that, and then wrote an appropriate driver (that listened on a local port) for native Plan9, you could talk from an in-browser Plan9 instance to a native instance running on real hardware or a VM.
I'm not sure how far plan9port goes in terms of 9P emulation, but it might be worth to figure out how to make the native (aka non-browser) side of the WebSocket/WebRTC<->9P transport work with plan9port as well as "real" native Plan9. That way users who are running just the one copy of Plan9 in browser can talk to it with plan9port tools. If plan9port can't already do that though (can it?) then maybe that would be asking a bit much (adding functionality to plan9port is a bit of a tall order).
This would make firing the system up and playing with it a whole lot easier, akin to how you can run DOS games from the Web Archive in-browser because they compiled DOSBox to JS.
While I expect that the most straightforward (and non-insane) path to doing this would be Emscripten, it may be a very fun research topic to make the Plan9 C compiler and/or the bytecode generator JIT directly compile/generate WebAssembly code :> - with a fully capable toolchain you could even compile the kernel directly to wasm, skipping the translation overhead of Emscripten!
WebAssembly is still in the early stages, although there is some active (albeit early) browser support for it floating around, and you can build and test things without having to recompile your entire browser AFAIK (yes, if I understand correctly, browsers already include alpha-stage wasm parsing code). I suspect your best bet is likely to be to skip the likely-outdated noise on websites and just chase the Chromium/Firefox/WebKit/Emscripten teams (particularly Emscripten, which is spearheading compile-to-wasm) for the latest advice.
It would be especially awesome for you to be able to immediately follow the "Chrome officially supports WebAssembly" HN post (maybe a few months away) with "Plan9 runs in-browser and compiles directly to wasm" :D - while most people will just punt and follow the "put your .js on your site, run it through $compiler and put the .wasm file next to it like this" tutorials, you'd probably get a bit of traffic and exposure from directly generating wasm. A LOT (LOT) of people - mostly hacker types - are going to want to know how wasm works, and... showing off Plan9 as the tech demo of the fact that you're directly generating wasm... well......
It's not yet perfect; see https://github.com/WebAssembly/design/blob/master/FAQ.md#is-.... At this point wasm specifies no way to talk to the DOM but only allows you to invoke high-speed code execution from JavaScript. It may be worth waiting for DOM access capabilities, although as that link mentions, it's already viable to compile language VMs to wasm, so OS kernels sound reasonable too.