4 ms·

Under Windows, to run a program on one host and display and interact with it on another requires a special "remote desktop" client and special hooks into the gr

Under Windows, to run a program on one host and display and interact with it on another requires a special "remote desktop" client and special hooks into the graphics driver and kernel. Under Plan 9, the tool you use to redirect output from one machine to another is just "mount": mount /dev/mouse and /dev/draw from the other machine onto this one, run the command you want, and they appear on the remote machine - no changes required to the kernel or graphics drivers or any other part of the system. Of course, remote display is just one application - since Plan 9 exposes just about everything as a filesystem, you can mount a remote machine's TCP stack or editor session or authentication keys or even actual ordinary file storage, transparently and easily.

cwyers 11y ago
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.
- vezzy-fnord 11y ago
  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.
  - agumonkey 11y ago
    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.
    - vezzy-fnord 11y ago
      Which is the point. Files may be synthetic references to resources and not actual on-disk files, it's a general abstraction.
      - agumonkey 11y ago
        It's just a vocabulary thing, `file` is not that generic.
        vezzy-fnord 11y ago
        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.
        typedweb 11y ago
        A file is an object that supports the methods open(), read(), write(), and a few others. That's about a generic as you can get.
        agumonkey 11y ago
        If I write <data> /dev/net/tcp can I read and get <data> back ? Can I append <data> /dev/mouse ? Sharing {open,read,write,close} interface, but with exception and different semantics leads to a weird flavour of genericity.
    - EdwardCoffin 11y ago
      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.
- bakul 11y ago
  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.
- leoc 11y ago
  > 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 http://pdos.csail.mit.edu/papers/plan9:jmhickey-meng.pdf .

cwyers 11y ago

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.

vezzy-fnord 11y ago
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.
- agumonkey 11y ago
  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.
  - vezzy-fnord 11y ago
    Which is the point. Files may be synthetic references to resources and not actual on-disk files, it's a general abstraction.
    - agumonkey 11y ago
      It's just a vocabulary thing, `file` is not that generic.
      - vezzy-fnord 11y ago
        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.
      - typedweb 11y ago
        A file is an object that supports the methods open(), read(), write(), and a few others. That's about a generic as you can get.
        agumonkey 11y ago
        If I write <data> /dev/net/tcp can I read and get <data> back ? Can I append <data> /dev/mouse ? Sharing {open,read,write,close} interface, but with exception and different semantics leads to a weird flavour of genericity.
  - EdwardCoffin 11y ago
    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.
bakul 11y ago
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.
leoc 11y ago
> 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 http://pdos.csail.mit.edu/papers/plan9:jmhickey-meng.pdf .