You're right that it never meant 'everything is a disk file', but generally the implication of the unix philosophy was that everything could be accessed from the filesystem.
Have a look at Plan9, which is essentially directly descended from 7th edition UNIX and IIRC was built from what was going to be 8th edition UNIX. It has a HTTP interface from the filesystem -- one can literally do GET requests on documents from the internet just by opening a file on the filesystem.
In the Plan9 model, each and everything is represented by an individual file system entry. In Rio (Plan9's windowing system) every window is represented by a directory in a 9p tree, and you draw to it by opening a framebuffer file inside the window directory and manipulating that.
Furthermore, terminals know about their windows, and can hand it over to whatever is started inside them, which essentially makes it possible to open windows "inside" a shell environment.
It's kind of a unified screen/tmux environment, and you can stack, mix and match how you desire.
As mentioned earlier, Plan9 is what UNIX research edition 8 grew into (as I understand it), it's possibly one of the best examples of the UNIX philosophy.
It's important to note that UNIX the actual implementation is a moving target because of the many versions, just because the designers didn't see something could be achieved in UNIX (resources, time, effort, etc.) or just plain didn't think about it, doesn't mean that it doesn't embody the UNIX philosophy :)
Yeah, and shouldn’t that (theoretically) file systems with very small delay? (For example, RAM based file systems for inter-process communication.)
I thought that it isn’t the slow storage that is blocking use of files, but more of a software problem that has significant overhead to use files as a communication method. (I’m not an expert here; please correct if I’m wrong.)
- UNIX itself has no inotify/kqueue/etc. feature, blocking reads are via pipes or sockets, not regular files (plain UNIX tail -f polls the file every fraction of a second)
- you're appending to the end of the file for a message that's going to get read once, and the file model of UNIX doesn't let you truncate a file from the beginning, so it will just grow indefinitely for no reason
- one benefit of the open socket/pipe approach is you get notified if the other side exits/crashes, you can't detect that from a disk file