Amusingly, even my beloved ZX Spectrum, a machine very far removed from any POSIX standard (or any standard at all), also features an I/O abstraction interface as one of the many overengineered things in its ROM. The PRINT and LIST commands seem like they are meant for the screen, but in fact they can be told to send data over any "channel" (think 'character device'). By default you have a tty-like "channel" for the main screen, one for the input area, one for the printer and one for the network, and I think you can also open channels for files on a floppy (but not tape). On the other hand, LOAD/SAVE commands have an entirely different I/O abstraction for tapes, disks, ramdisks, etc. At least they use "files" in the traditional sense.

I/O abstraction is one HELLUVA drug.

It really escapes me why they tried to fit all I/O within the single umbrella of "file", only then to provide ad-hoc implementations of each "file type", when they could have just called the "file descriptor" a "resource descriptor" (or whatever) and let a file be a file, a socket be a socket and so on and so forth. Anyway, no one using Linux calls a socket a "type of file", do they? Because each of these abstracts different resources: the socket a network connection, the file some disk space, the pipe a virtual support for consumer-producer design patterns; and so they're different things, no matter how elaborately the authors of the standard(s) try to lie to us.

procfs and sysfs are indeed another type of perversion, in that they provide the illusion of persistent storage -- as opposed to device files and named pipes, which are indeed denoted as special types in the file system.

I can only feel sorry for the POSIX folks: it's so fucking hard to design an interface that on one hand supports the complexity they required, while on the other maintains consistency -- this also a propos our discussion regarding various types of disks. So I understand, they gave up consistency in favour of practicality, the end result being that the systems programmer will now also be doomed to suffering along with them.

I dunno about that, the Unix/POSIX conception of a "file" seems to be more like "an abstraction for accessing data external to the process", i.e. anything that's not a variable. You have sockets, FIFOs, procfs and sysfs entries that are not persistent, not finite, and sometimes they don't even store anything.