Review: The Linux Programming Interface

No, I want to do none of those things... Maybe they are things YOU and others want to do... But, personally, I have no need for any of them, and they mostly seem like stretches and grasping at straws to justify them existing in a place they certainly don't belong (the filesystem)...

And, your example of a buggy app and/or kernel is just crazy... You want to be able to kluge around a serious app/kernel bug by stealing its socket out from under it, and replacing it via another running copy? How about just fixing the bug! What if it were holding a TCP port# instead? Do you complain that you can't "rm" listening TCP ports, too?

> If you're unhappy because a system leaves files around in /tmp that aren't used anymore

That's part of why I dislike them... They're scattered around wherever, often somewhere under "/tmp" (which is a really poor place for something designed to be a shared identifier for communication between multiple apps)... But, mostly I dislike them because THEY ARE NOT FILES! Just having them exist as a directory entry in the filesystem does not fulfill some Unix utopia idea of "everything is a file"... In order for that to be fulfilled, the things must actually be usable AS FILES... If they were designed such that you could pass one to an otherwise unsuspecting app, which just open()'d it normally, and that magically let that app talk to whoever is listening on the other end of the socket (a la a named pipe), then I'd be all in favor of them... That would be brilliant... But, no, you can't do that... All you can do with a Unix domain socket "file" is to bind() to it or connect() to it... They're not files; they're filesystem representations of unique socket addresses, and that's all... As such, there's no need for them to live in the filesystem at all... (Unless you have special rare needs like those previously mentioned which can only be solved by them having a pathname in the filesystem...)