6 ms·

Nice to see Plan 9 making a bit of a comeback these days (at least in HN). I would certainly be glad if some of the ideas behind it became more popular today.

• allodium 11y ago
  Which ones? I would like to know more about Plan 9.
  • reirob 11y ago
    http://fqa.9front.org/ http://fqa.9front.org/
  • xiaq 11y ago
    Plan 9 makes extensive use of pure-text IPC, more commonly known as file writes and reads. This is facilitated by the fact that each process sees its own filesystem hierarchy. For instance, GUI programs are built by reading from files like /dev/cons and /dev/mouse and writing to files under /dev/draw. Now it seems that this will end up in a mess when you try to run multiple GUI programs, but that is not the case - a WM can provide virtualized versions of these files, and each program still feels that it is using the entire screen and does not need to know about the WM at all. My description is likely not very accurate because I haven't really tried it, but you can find the whole story in the related man pages: http://man.cat-v.org/plan_9/3/cons http://man.cat-v.org/plan_9/3/cons http://man.cat-v.org/plan_9/3/mouse http://man.cat-v.org/plan_9/3/mouse http://man.cat-v.org/plan_9/3/draw http://man.cat-v.org/plan_9/3/draw. Another example is the authentication facility of plan 9. Instead of being a dynamically-linked library, it is a separate process that can be reached via IPC. Russ Cox et al have a talk on this (https://swtch.com/~rsc/talks/nauth.pdf https://swtch.com/~rsc/talks/nauth.pdf). This is also why Plan 9 has no dynamic linking, since those things are done with IPC instead.
    • cwyers 11y ago
      I am not sure I understand why that's desirable. Why is reading plain text out of /dev/mouse and writing plain text to /dev/draw an improvement over how Linux or OS X or Windows does it? EDIT: I get that Plan 9 is "more UNIX than UNIX" and that this is an extension of how UNIX behaved. I view that as a philosophical, rather than practical, point though.
      • thristian 11y ago
        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.
    • hobarrera 11y ago
      I really like the philosophy that the WM implements. I hope that Wayland (or whatever comes after X) would work in some similar fashion.
  • agumonkey 11y ago
    An academic made a list of interesting facts about p9: http://pages.cs.wisc.edu/~madthanu/qual-notes/plan9.txt http://pages.cs.wisc.edu/~madthanu/qual-notes/plan9.txt
• shepardrtc 11y ago
  I've been following it intermittently for years, and I, too, am glad to see it slowly being discovered and examined by techie folks. It really does have some great ideas, and I would welcome some of those being incorporated into systems in the future. But the argument always comes back to this: how can one even hope to bring anything like this up to part with current systems? And the answer is simple, yet not warm-and-fuzzy: You can't, not right away. This is something that will take time. I think highly of Windows, OSX, and Linux, but I don't think we should rest on our laurels. If we have the time and energy to do better, we should.
• koenigdavidmj 11y ago
  Its features are steadily getting added to the Linux kernel, at least in some form: - You have FUSE, which has some overlap with 9P. You lose the network transparency, but still can build specialized filesystems entirely in userspace with no special permissions, rather than requiring a kernel driver. - The clone(2) system call, which has a lot of options equivalent to those of Plan 9's rfork(2) allowing explicit control of what gets shared between the parent and child processes. - In particular, the filesystem namespace (read: mount table) can be one of the unshared items, though my understanding is that this still requires root permissions.
  • davexunit 11y ago
    >though my understanding is that this still requires root permissions. Unless you also unshare the user namespace, then an unprivileged user can act as the root user in the context of that namespace and create mount points.