
Why is “Everything is a File” unique to Unix operating systems? - sathyabhat
http://superuser.com/q/364152/4377
======
ralfd
On the linked superuser site there is repeatedly mentioned that Mac OS X is
build "on top" of Unix. This is not quite right. OS X has a BSD userland, but
in many ways its developers thought differently.

For example "/dev/audio" doesn't exist on OS X. CoreAudio is taking a
different route than the "everything is a file" Unix approach.

~~~
4ad
And /dev/tcp does not exist in Unix. Neither does /dev/draw.

Everything is a file broke in Unix in the '80s when sockets and X windows
came. Original Unix' developers tried (and succeeded, IMO) to fix these
problems and created Plan9. In Plan9 all I/O, being regular I/O, GUI
applications, networking etc are done through the namespace.

Unix means two things today, one is a useless certification, usually referred
as UNIX and the other one is a loose set of tools, ideas and encompassing
practices. Mac OS X fits both these definitions.

------
JoeAltmaier
It may be handy at one level to treat everything as a file. But squashing
complex objects through the file api is a hack. I'd hope somebody had some
better ideas in the last 20 years.

~~~
1337p337
If you have a look at, e.g., Plan 9 and Inferno, I think you might be
surprised at how expressive a file-based API can be.

For a trivial example, webfs supports REST quite handily without a loss of
expressive power (and REST itself is a simple but powerful abstraction), and
because things need not be piped through curl, you can, for example, point
your image editor at what it believes to just be another file on the
filesystem, rather than requiring the image editor to support HTTP.

The other half of this is that abstractions can and are built atop this. The
Limbo programming language, for example, provides typed channels (which, as I
understand it, also made it into Go) and its standard library provides
functions for treating arbitrary files as typed channels. So, the OS need only
concern itself with "files" (really, in Plan 9 and Inferno, these are less
like files and more like names in the processes' respective namespaces), and
whatever complex objects the language concerns itself with are easy to ship
around between a process and the outside world without hacks (unless
marshalling objects is considered a hack).

------
joe_the_user
Googling on the topic, I found:
[http://www.linuxtopia.org/online_books/programming_books/art...](http://www.linuxtopia.org/online_books/programming_books/art_of_unix_programming/ch03s02_3.html)

An interesting discussion of how Window NT's lack of everything-is-a-file and
standard command line tools metastasizes into a security and configuration
nightmare. It gives an idea of how important unix's the _unifying metaphors_
are for creating a good operating system.

~~~
4ad
Windows NT, just like any relevant operating in the last 30 years, operates on
the same I/O to files abstraction as Unix. I'd say Windows NT does it even
more than _modern_ Unix, at least in NT NICs are real devices in the
namespace.

The BSD people in the '80s forgot this fundamental abstraction and introduced
sockets, then X came, again neglecting 15 years of good practice and
introduced a completely incompatible model to do I/O.

Rob Pike, Ken Thompson and other Unix people were dissatisfied with this and
created Plan9, a Unix descendant where truly all I/O happens by operating on
the namespace and without an ioctl(2) system call.

Many, including myself, believe Unix took a very wrong path in the 80s and
that _modern_ Unix is more clumsy and inconsistent than the systems it was
designed to replace, but architecturally speaking Windows NT is pretty much
the same as _modern_ Unix.

/edit:

I've seen both in the cited article and in OPs link that people confuse files
with files descriptors.

~~~
geocar
What exactly do you mean by this?

> at least in NT NICs are real devices in the namespace.

~~~
4ad
In Windows NT device objects get instantiated in \Device, including network
cards. Also, different TCP/IP layers are accessible as well, like \Device\Tcp,
\Device\Ip. In Unix the network stack is not accessible in the file system at
all, there's nothing in /dev, it's just a special API in the kernel.

In Windows you'd use a networking API as well, but the networking API is a
convenience layer over file based I/O.

The difference between Windows NT and Plan9 is that Windows NT device I/O is
IOCTL based, not composable, not replaceable and not exportable, but it's just
how you'd do things in Unix v7.

------
Craiggybear
In DOS everything was a file too. Its not just *nix.

~~~
colanderman
Definitely not. Once you got past CON, LPT1, and COM1, it was BIOS calls and
I/O ports all the way.

~~~
Craiggybear
COM and LPT are files, though. And can be treated as such. As in COPY *.PS
LPT1:

Devices such as screens were treated as files by their device drivers as well.

~~~
colanderman
_COM and LPT are files, though._

Right, that's what I said.

 _Devices such as screens were treated as files by their device drivers as
well._

I remember writing a whole hell of a lot of port-banging code to make graphics
and sound work on DOS.

