Yawn. This article is three years old, and even in 2005 was mostly trite, recycled trash (X11 sucks on a line with 200ms latency? Do tell...). And big chunks of it are just plain wrong (no, stdin and stdout are not always pipes, are not forced to be unidirectional, and yes you can tell the difference) or incomplete (the author apparently has never heard of the scatter/gather I/O using readv/writev, nor kqueues/epoll, and doesn't seem to know much about signals either).
Basically everything in this is either wrong or disingenuous. Stay away, it's just flame bait. If you want to read a good flame about unix, "The UNIX-HATER's Handbook" did all this much, much better. Read that. The linked article isn't worth your time.
Also, you can see most of these criticisms handled quite impartially in Eric Raymond's "The Art of Unix Programming," which I'd say is required reading for any would-be "hacker."
Except that everything in that book is cribbed from better primary sources, not the least of which are Kernighan+Plaugher's "Software Tools", Stevens APUE, and "The Unix Haters Handbook".
scatter/gather, kqueue, and signals: finish your argument. How do these rebut the article? (Also: where are you still using readv/writev? "THIS PROGRAM NEEDS BUFFERING").
I know it's an old article, but I'll buck the trend and call it out as a thoughtful critique, mostly wrong, but well worth considering.
1. "Everything is a file". Yep, Unix tried. Yep. Unix failed. Sockets are not files. Programs can't access the network transparently. You still can't really event loop the disk.
2. "Everything is text". Not so much, unfortunately. Text works; you can build software tools in Bourne shell to manage them. ls(1)? Bad example: sysadmins use du(1) to sort by disk usage. And binary works just fine in Unix; I wrote an SNMP agent --- complete with ASN.1/BER encoding --- in Bourne shell on a dare.
3. "No reflection. Commands aren't discoverable." The author has an ill-advised admiration for OSX's skin-deep metadata features, which rely heavily on the same filename semantics as every other general purpose operating system (file types are a scourge). What operating system supports command reflection? What operating system even supports consistent "help" semantics? Hell, what programming language has licked this problem?
4. X11. Yes, worse than NeWS and DPS. Problem is, DPS? Also a Unix design.
5. Every geeky CS sophomore writes the program to make shell pipelines bidirectional. Meanwhile, who processes audio on stderr and video on stdout? Would a fully general DAG of sources and sinks be awesome? Yes. Go write that Masters Thesis, please.
6. Speaking of Masters Thesises: async system calls? Also awesome. Comparing QNX to a general purpose operating system? Not so much. This isn't something you hate about UNIX, it's something you hate about all mainstream systems.
7. Poor interfaces for kernels to send messages to userland? Not a real problem. Create a point on the filesystem the program can open. Support "mmap" to give userland an aperture to work with, or support "poll" to deliver messages. This problem needs a concrete example. OSX has all of Mach's capabilities. Where did they turn out to be a win?
8. Not going down this C vs. the world rathole. Just going to win the argument by pointing out that the lingua franca of Unix is no longer C; it's pretty much every other language that has mainstreamed since then, except C# and Visual Basic.
9. It would suck if there wasn't a library for consistently handling wildcards. Unfortunately, there is. "man 3 glob".
10. This is a rehash of #3, and it again uses OSX as an example without acknowledging that OSX uses the same "inband signalling", which is why I can't attach #*&(! Pages documents to my gmail messages, because they're directories and not files.
I wrote this because it was fun to write, not because I hated the article. I liked the article; it made me think. Anyone who can write for "InformIT" about asynchronous system calls knows what they're talking about, even if they are mostly wrong.
Basically everything in this is either wrong or disingenuous. Stay away, it's just flame bait. If you want to read a good flame about unix, "The UNIX-HATER's Handbook" did all this much, much better. Read that. The linked article isn't worth your time.