Each socket should have two file descriptors

He never said there was no reason that sockets behaved differently than other descriptors, only that the reasons didn't warrant the broken abstraction.

And finally, I think you missed the place where he claims the abstraction breaks down. He's not complaining that you use "open" to get a file's descriptor and "pipe" to get a pipe's two descriptors, any more than it's weird to get a socket descriptor for "socket". He's saying that once you have the descriptor, the single file descriptor for sockets forces the OS to implement a socket-specific call simply to get a FIN sent properly.

The reality is that sockets could be represented not with integer descriptors but with character arrays or structs and the Unix interface wouldn't be any less incoherent than it is now with accepting descriptors, a select call that works for sockets and not files, setsockopt, shutdown, recv, connected Unix domain sockets, ioctls, and so on and so forth.

Still, it's possible that open/read/write/seek is just not the right abstraction in all cases. http://yarchive.net/comp/linux/everything_is_file.html is interesting reading.

Design by effectively nobody can be at least as bad as design by committee.

As others pointed out, Plan 9 is much closer to a proper realization of the everything is a file design philosophy. Unsurprising, since it was grown entirely within Bell Labs under the supervision of the original Unix team. It's unfortunate it hasn't reached a point of being ready for mass adoption.

Here's another similar example of how "everything is a file" falls down that I wrote about in 2005 when complaining about terminals (http://www.advogato.org/person/habes/diary/6.html)

    Then there's the whole mess of pseudo-terminals.
    If you are like me, you might wonder at first why
    pseudo-terminals are necessary. Why not just fork
    a shell and communicate with it over stdin/stdout?
    Well, the bad news there is that UNIX
    special-cases terminals. They're not just
    full-duplex byte streams, they also have to
    support some special system calls for things like
    setting the baud rate. And you might think that a
    change of window size would be delivered to the
    client program as an escape sequence. But no, it's
    delivered as a signal (and incidentally, sent from
    the terminal emulator as an ioctl()).

    Of course, you can't send ioctls over a network,
    so sending a resize from a telnet client to a
    telnet server is done in a totally different way
    (http://www.faqs.org/rfcs/rfc1073.html)

This is still quite a good paradigm to follow - the semantics for waiting on, duplicating, closing and sending file descriptors to other processes are generally well-defined and well understood. For example, Linux exposes resources like timers, signals and namespaces through file descriptors.

Before that, you had completely different syscalls depending on the device you were using.

First, the missing background:

djb likes unix.

the unix philosophy is to compose small programs together to solve problems.

djb's own programs illustrate this really well. They are all small, focused tools. This allows each program to focus on their particular task or domain.

The primary method of composition in unix is the pipe in a shell. Each pipe has two descriptors. One for read and one for write.

It is very easy to create a pipe and handle pipe IO.

The article:

At some point, djb wanted to have some programs live on the network. This expands the composition beyond a single machine. If you just try to treat a socket as a standard pipe, you encounter the problem he describes.

Any program utilizing a pipe requires two file descriptors. If someone built a trivial 'netpipe', they could just 'dup' or 'dup2' the socket file descriptor to make it look like a normal pipe. The problem with that is now the socket won't close until both fds are closed. This means the remote end won't detect EOF. This means the 'netpipe' program has to be very clever in order to detect EOF and do a proper close on both so the remote can see the last bytes and then EOF.

   s/ucpsi/djb'"'"'s & applications/

The more fragmented an IP packet gets along the way the less likely it is it will reach destination, so you have to take into account path MTU size and split your datagrams accordingly. You also want to send as many datagrams as you have available in as few IP packets as possible and you want to do slow start for the same reasons TCP does it.

Result: your datagrams need to become a stream of bytes to be handled efficiently by any transport protocol sitting on top of IP.

EDIT: theoh says it better https://news.ycombinator.com/item?id=6080324

djb's argument here is that TCP sockets are more like pipes, with separate read and write buffers, and separate read-side and write-side close operations. This makes sense, but what about UDP sockets? What about operations that apply to the socket as a whole, like bind(2), listen(2) or ioctl(2)?

[0] http://cr.yp.to/ucspi-tcp.html