For example, on Linux you'd load a web page by instructing a program to open an (AF_INET, SOCK_STREAM) socket, tell the kernel to connect() to some destination, send some bytes, read some bytes, and render those bytes as a page on your screen using another set of userspace libraries and system calls.
Whereas, on plan9, you might mount a remote server to a local namespace, look for the page you want, then pipe that file through an HTML renderer and the output to a display server. Or you might echo "connect 192.168.0.1!80" into /net/tcp/0/ctl, and read the result from /net/tcp/0/data.
Linux has borrowed several things from plan9, including /proc and /net, and you can even set up your system so you can pipe things to /dev/tcp. The single abstraction of files is a pretty good one for exposing all sorts of functionality to userspace, so you can get pretty good at doing just about anything without needing to drop into C or otherwise asking the kernel directly.
Disclaimer: I'm not a plan9 user, and I'm not saying that files are the best userspace abstraction.
The bash shell supports /dev/tcp by default for file descriptor redirections (so people who are using bash can already do this!).
And not all bashes support this -- Debian (and I suspect Ubuntu, Mint, etc., based on it) disables this option at build time.
You can get something fairly close via netcat, though IMO that also shows some of the weaknesses of the approach, which is that you're not interacting with a web page, say, so much as you're talking http to a socket. Not that there aren't times when that isn't an entirely sensible thing to do, but if you just want to read stupid stuff on the Wobbly Wobbly Wibble, it's a bit too thinky.
(All of which I'm sure schoen knows far better than I, though others might not.)
The idea of talking protocol-based stuff through something that looks vaguely directory / file-ish, and which could do sensible things with HTML (or audio, video, data, messaging stuff, email stuff, crypto stuff) and through which utilities and utilities would have access without needing to be specifically adapted to handle the cases might be interesting.
One of the things that Plan 9 can do is seamlessly treat remote resources as if they were local. From what I can tell, this is a remote grid that you can connect a local Plan 9 instance to.
I actually had Plan 9 working on some Sun 3/50s at one point. You could use it over a 2400 baud modem... a kind of broken one where I had to listen to the connection noises and twiddle the wires at the right moment to make it connect. A bad cell phone connection would have been nice.
Never seen it taken beyond KDE though.
Then again, KDE had/has many things that nobody seems interested in replicating. like how Konqueror could be divided much like a tiled WM, with each tile holding anything from (khtml driven) web sites, to local, ssh, smb or ftp directories, or even terminals (iirc).
One could basically create just the right tool for a local or remote file management job one needed.
Sadly i have abandoned KDE since the debacle that was 4.0...
I, however, just went on to the old project's page[0] and found this:
> Q: What is the /9/grid?
> A: A project begun by users of 4chan's technolo/g/y board to setup a free, decentralized grid computing network, available to users of any OS. By integrating Plan 9 based networking technologies (via Plan 9, Inferno, 9vx, or others) with our usual OSes, we can create transparent networks of whatever content and services we want. Note that there are several different projects using the term 9grid, the resources here are only a small portion of the world of Plan 9 + Inferno based distributed systems.