[lvc_]

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.

[fao_]

> 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.

[colejohnson66]

On the BeagleBone Black (haven’t used others), the GPIO pins are accessible through SysFS at /sys/class/gpio

[geofft]

And it can be, see /tmp/.X11-unix/.

[fao_]

Original 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.

[geofft]

On my machine systemd is configured by creating files in /etc/systemd, /lib/systemd, and potentially /run/systemd (even temporary/generated config turns into files) and then sending a message to /run/dbus/system_bus_socket. How does it work on your system?

[cycloptic]

There is a Wayland compositor called Wio that is looking for help in implementing a file system interface for window management, similar to the one in Plan 9. If you have experience writing FUSE file systems and want to help out, please contribute! Previous HN discussion here: https://news.ycombinator.com/item?id=19797152

[seba_dos1]

Umm, 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]

These 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]

Sure, 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.

[pcr910303]

> "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]

If 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