Okay,but what does this buy you other than some leaky abstractions? A local file is not the same thing as a remote file, a local mouse is not the same thing as a remote mouse, and a local file is definitely not the same thing as a remote mouse. All that code in Windows that Plan 9 'doesn't need' contains a lot of logic for dealing with remote displays and input devices that is probably going to have to reside in your application if the OS isn't providing it. Simplicity is only a virtue if it's real; false simplicity is just kicking the can down the road for the next poor bastard to deal with.
I'll give you a practical example: Since the RaspberryPi doesn't have a real time clock, I bought a GPS module from adafruit, hooked it up to the Pi's serial line, and ran this two line script to start using it.
aux/gpsfs -b 9600
aux/timesync -G
gpsfs reads data stream from an NMEA compatible GPS device and provides four synthetic files: position, time, satellites and raw. timesync then uses the time file to synchronize local time to GPS. I can read the satellites files to see which GPS satellites were seen where and their SNR etc. The entire gpsfs program is under 1200 lines of C. The point being, it is fairly easy to provide such an interface for new devices. Since it is "just" a filesystem, standard systems tools can be used with them -- you don't have to teach them new tricks. Not everything fits in this paradigm but a surprisingly large number of things do.
Simplicity is a virtue only if you take it seriously.
Someone else mentioned that plan9 features are steadily being added to Linux but that misses the point entirely. Adding a set of simple features to a complex system makes the system even more complex as now you have even more things that can go wrong.
Please actually try researching the concepts and papers about Plan 9 and Inferno before making such sophomoric statements as "A local file is not the same thing as a remote file." As if no one has thought about this before.
As much as I love the way p9 modeled the world, I agree a tiny little bit about cwyers, in that the notion of file is stretched a little too thin. I do love the consistency but these aren't files anymore but namespaced objects, unless a file is a pipe `or` a register `or` a document `or` container of files.
Yes, it is. A file is just a representation of resources, nothing more. You can have files as a user convenience without even having a file system, but rather a persistent object store.
Are you objecting to the _notion_ that is called a file in Plan 9, or to the fact that it is _called_ a file? I would regard the latter as just a synecdoche, using the name of the most well-known realization of that general concept to stand for all of the realizations of that concept.
> A local file is not the same thing as a remote file
That's actually the easy case. Remote files are not local files, but local files are remote files: or more precisely, local files are a special case of remote files from the point of view of file access. If your filesystem API starts with the assumption that files are remote and must be handled as if they are remote, then you get pretty good local file access for free, as HTTP has been demonstrating for a couple of decades now. Of course if you instead start with the assumption that files are local and thus it's safe to do blocking I/O on them then when you add remote files you'll end up with an NFS-like mess instead. That doesn't prove that abstraction and generalisation can't work cleanly, it just shows that you were looking through the wrong end of the telescope. (Really, the distinction here isn't truly between remote and local but between unreliable and reliable. All remote file access may be unreliable, but it's certainly not the case that all local file access is reliable, or should be expected to be reliable. Especially not when you bring in user-space filesystems, as Plan 9 does.) Apparently Plan 9 actually started with a blocking-I/O-plus-thread-spawning model which was only so-so before it was fixed up: http://pdos.csail.mit.edu/papers/plan9:jmhickey-meng.pdf .
