7 ms·

> The everything is a file philosophy becomes much more clear then. To be honest, everything is a file is kind of a lie in unix. /proc and /sys are pretty much

> The everything is a file philosophy becomes much more clear then. To be honest, everything is a file is kind of a lie in unix. /proc and /sys are pretty much plan9 inspiration.

wolletd 3y ago
Also, a lot of devices require very specific ioctl() commands to work with and don't provide everything as a file. For example, you can't set the baudrate of a serial port by writing it to some /proc node.
- arghwhat 3y ago
  nit: The ioctl syscall targets files just the same as the write syscall. Everything being a file, and everything being read/write calls are different things. There's pros and cons.
arghwhat 3y ago
A more accurate term is that everything is a file descriptor. The main difference is that plan9 uses read and write for everything, whereas Linux and BSD uses ioctls on file descriptors for everything.
- vbezhenar 3y ago
  Everything is a descriptor. When I'm opening a TCP connection, there's no file, so calling it a file descriptor feels wrong. And at that point, the whole "everything is" turns into nonsense, because yes, everything is a pointer to something, so what.
  - arghwhat 3y ago
    There are named files (which have a file path) and anonymous files (which do not). You can see these in /proc/$PID/fd/$FD if you're curious - when the link doesn't start with '/', it's anonymous. Even process memory is just an anonymous file on Linux, and arguably a cleaner one as it operates on proper fds, instead of plan9 where a string "class name" (not a path) is used to access the magical '#g' filesystem. The difference to plan9 is not the files, but the way plan9 uses text protocols with read/write to ctl files. To open a TCP connection - if memory serves me right - you first have to write to a ctl file, which creates a new file for the connection. Then, you write the dial command to the ctl file of that connection, and after which you can open the connection file. On Linux, a syscall creates an anonymous file, and then everything after is operations on this anonymous file. There's some ideological benefits, but plan9 creates a mess of implicit text protocols, ugly string handling, syscall storms and memory inefficiencies. Their design is pretty much solely a limitation caused by the idea that all filesystems should exist through the 9p protocol, which as a networked protocol cannot share data (fds, structs), only copy (payloads to/from read, write). With the idea that all functionality had to be replaceable and mountable from remote machines, the only possible API became read/write for everything. I'd argue that fd-using syscalls and ioctls - basically per-file syscalls - is a superior approach to implement everything-as-a-file.
    - tonyarkles 3y ago
      I've only briefly looked at plan9 here and there over the years but you seem to have a pretty good handle on it and maybe could indulge me. Your comment raised a question for me that I hadn't considered before. If I've got a Plan9 system mounted over, say, NFS, would this all mean that (ignoring permissions) I could effectively open a TCP connection from that remote machine by writing appropriate information to a file on the NFS share? It would be pretty inefficient I suspect, tunnelling TCP over NFS, but it seems like there could be an incredible amount of cool hacks that might Just Work as a side-effect of them going all-in on "everything is a file".
    - Cloudef 3y ago
      Whichever superior depends on your use case and needs. Plan9's approach is very powerful whenever you need anything distributed, and makes lots of boilerplate to achieve that basically unnecessary. Linux nowadays is flexible for both approaches (in theory, the ecosystem might not be there), and I'm glad user namespaces are a thing.
      - arghwhat 3y ago
        Now, proper plan9-style namespaces, that I miss. :) User namespaces are still a hell of a lot clunkier than "each process inherits its parents' namespace".
        Cloudef 3y ago
        If you setup user namespace, the child processes will inherit that namespace. The difference is that plan9 is fully built on this idea and isn't multi-user, on linux you have to opt-in to this. It's very useful and underused (mostly used by containers). I wanted to ship my AWS lambdas this way, but sadly AWS lambdas don't allow user namespaces. https://github.com/aws/aws-lambda-base-images/issues/143 https://github.com/aws/aws-lambda-base-images/issues/143
        moody__ 3y ago
        Plan 9 is very multi-user, namespaces are actually one component in how it is multi user specifically. A given terminal may be designed to only have one user on it but CPU servers are still multi-user multiplexers, that part has not been given up.
- sph 3y ago
  Relevant talk by Benno Rice, "What UNIX cost us": https://youtu.be/9-IWMbJXoLM?si=OblWX3OMXWrSFinb https://youtu.be/9-IWMbJXoLM?si=OblWX3OMXWrSFinb

> The everything is a file philosophy becomes much more clear then. To be honest, everything is a file is kind of a lie in unix. /proc and /sys are pretty much plan9 inspiration.

wolletd 3y ago

Also, a lot of devices require very specific ioctl() commands to work with and don't provide everything as a file. For example, you can't set the baudrate of a serial port by writing it to some /proc node.

arghwhat 3y ago
nit: The ioctl syscall targets files just the same as the write syscall. Everything being a file, and everything being read/write calls are different things. There's pros and cons.

arghwhat 3y ago

A more accurate term is that everything is a file descriptor. The main difference is that plan9 uses read and write for everything, whereas Linux and BSD uses ioctls on file descriptors for everything.

vbezhenar 3y ago
Everything is a descriptor. When I'm opening a TCP connection, there's no file, so calling it a file descriptor feels wrong. And at that point, the whole "everything is" turns into nonsense, because yes, everything is a pointer to something, so what.
- arghwhat 3y ago
  There are named files (which have a file path) and anonymous files (which do not). You can see these in /proc/$PID/fd/$FD if you're curious - when the link doesn't start with '/', it's anonymous. Even process memory is just an anonymous file on Linux, and arguably a cleaner one as it operates on proper fds, instead of plan9 where a string "class name" (not a path) is used to access the magical '#g' filesystem. The difference to plan9 is not the files, but the way plan9 uses text protocols with read/write to ctl files. To open a TCP connection - if memory serves me right - you first have to write to a ctl file, which creates a new file for the connection. Then, you write the dial command to the ctl file of that connection, and after which you can open the connection file. On Linux, a syscall creates an anonymous file, and then everything after is operations on this anonymous file. There's some ideological benefits, but plan9 creates a mess of implicit text protocols, ugly string handling, syscall storms and memory inefficiencies. Their design is pretty much solely a limitation caused by the idea that all filesystems should exist through the 9p protocol, which as a networked protocol cannot share data (fds, structs), only copy (payloads to/from read, write). With the idea that all functionality had to be replaceable and mountable from remote machines, the only possible API became read/write for everything. I'd argue that fd-using syscalls and ioctls - basically per-file syscalls - is a superior approach to implement everything-as-a-file.
  - tonyarkles 3y ago
    I've only briefly looked at plan9 here and there over the years but you seem to have a pretty good handle on it and maybe could indulge me. Your comment raised a question for me that I hadn't considered before. If I've got a Plan9 system mounted over, say, NFS, would this all mean that (ignoring permissions) I could effectively open a TCP connection from that remote machine by writing appropriate information to a file on the NFS share? It would be pretty inefficient I suspect, tunnelling TCP over NFS, but it seems like there could be an incredible amount of cool hacks that might Just Work as a side-effect of them going all-in on "everything is a file".
  - Cloudef 3y ago
    Whichever superior depends on your use case and needs. Plan9's approach is very powerful whenever you need anything distributed, and makes lots of boilerplate to achieve that basically unnecessary. Linux nowadays is flexible for both approaches (in theory, the ecosystem might not be there), and I'm glad user namespaces are a thing.
    - arghwhat 3y ago
      Now, proper plan9-style namespaces, that I miss. :) User namespaces are still a hell of a lot clunkier than "each process inherits its parents' namespace".
      - Cloudef 3y ago
        If you setup user namespace, the child processes will inherit that namespace. The difference is that plan9 is fully built on this idea and isn't multi-user, on linux you have to opt-in to this. It's very useful and underused (mostly used by containers). I wanted to ship my AWS lambdas this way, but sadly AWS lambdas don't allow user namespaces. https://github.com/aws/aws-lambda-base-images/issues/143 https://github.com/aws/aws-lambda-base-images/issues/143
        moody__ 3y ago
        Plan 9 is very multi-user, namespaces are actually one component in how it is multi user specifically. A given terminal may be designed to only have one user on it but CPU servers are still multi-user multiplexers, that part has not been given up.
sph 3y ago
Relevant talk by Benno Rice, "What UNIX cost us": https://youtu.be/9-IWMbJXoLM?si=OblWX3OMXWrSFinb https://youtu.be/9-IWMbJXoLM?si=OblWX3OMXWrSFinb