[hannasm]

Is your interpretation that these two statements are at odds? What even is the intended meaning of "a file"?

To me it could be:

Something accessible via a file descriptor that can be read from and/or written to. Feel free to add some other details like permissions, as needed.

Perhaps they should allow for folders as well, since a complex piece of hardware undoubtedly needs to expose multiple files to be robust, but the underlying intention was to create a standardized way of interacting with hardware.

Sectors on disk, switches, analog devices like a speaker, i2c and other hardware ideas all need to be read from or written to in some form to be useful

[tsimionescu]

I think they meant that in any widely used Unix system today, there are a loooot of things which are not files, so the design is not honest.

The most common example of soemthing almost all programs interact with universally is BSD sockets. In Plan9, which goes out of its way to follow this everything is a file philosophy, TCP/UDP connections are actually represented as files. You open a file and write something to it to create the connection, and then you read or write to other files to read the streams, and you write again to the control file to close the connection. On the server side, you similarly write to a control file to start accepting packets, and monitor a directory to check for new connections, and so on.

Note that "file" here has a pretty clear definition: anything that can be interacted with using strictly the C FILE api - open()/read()/write()/close().

[otabdeveloper4]

Take a simple and obvious example - say, controlling a musical instrument from a computer via MIDI.

Calling that a "file" is ... a humongous stretch, to put it mildly.