6 ms·
Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" - think of std{in,out,err} or
by lvc_ 7y ago
Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" - think of std{in,out,err} or network sockets. The implications are more around having a standard set of syscalls for moving data in and out of a program, abstracting away where it actually lives and treating the data itself as something opaque.
- pcr910303 7y ago> "Everything is a file" never meant "everything is a disk file" - think of std{in,out,err} or network sockets. 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.)
- geofft 7y agoIf you're sending a message to some process for it to consume, like X11 or like standard input to your shell, sure, you could technically interoperate via disk, but - 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
- fao_ 7y ago> Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" 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.
- geofft 7y agoAnd it can be, see /tmp/.X11-unix/.
- fao_ 7y agoOriginal parent commented that UNIX was dead, given that Wayland does not seem to have an accessible interface from the file system, and nor does SystemD, Pulseaudio, or any of the major new things on the desktop system, I am inclined to agree. Of course Xorg is accessible from the filesystem, but it's probably one of the last technologies to have such an interface.
- seba_dos1 7y agoUmm, but Wayland and PulseAudio do have accessible interfaces from the file system... Wayland even requires it, as opposed to X11 which could work over TCP socket as well. No idea about systemd though (I think it uses dbus?)
- datenwolf 7y agoThese are only sockets through, through which you have to multiplex-serialize all the commands. 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.
- geofft 7y agoSure, but that's the Plan 9 philosophy. UNIX doesn't even have /proc/$pid/fd/ - there's no way to refer to another process's stdio unless you have the fd passed to you, and stdio is kind of the basis of UNIX. So by UNIX's definition of "everything is a file," we're still there.