This meme is a silly amateur-hour wheel re-invention and ignorance of history.
Yeah, well fuck you too.
As it turns out, I am an amateur, at least when it comes to POSIX, but more importantly I find this stuff fun. I hadn't realized that having fun and learning about new topics was such an offensive thing to do.
Maybe this is just frivolity, but it's surely a better way to spend a few minutes than crapping all over somebody else's fun.
Right on. I'm all about learning, sharing knowledge, and having fun. Kudos to you and Ryan for having the balls to study in public.
What I find interesting, and somewhat alarming, though, is that experienced web developers such as yourself seem to only now be learning the fundamental, bedrock principles of how the technology you use every day actually works.
Maybe it's because high-level abstractions weren't widely available, or because the books I had on hand were Stevens' classics, but I learned network programming starting with socket(2), and to this day still ask what each of socket/bind/listen/accept do when I'm interviewing sysadmins, much less developers.
It's remarkable to me that a whole breed of web developers today might not have any exposure to networking below the HTTP stack offered by their favorite programming language.
Off-topic but...we need a proper computer science/programming collection of papers, books, etc. built up so that people can go off and learn things from the past instead of learning about them independently and then spawning blog posts about it.
For learning this side of Unix, I've found the following very helpful (note that this is a bit BSD-centric):
1. _The Unix Programming Environment_ by Kernighan and Pike. The best overall intro to the pipes, shebangs, and other assorted command line stuff in Unix. Very old school, but still very relevant - those are the root of many of Unix's strengths. (K&P's _The Practice of Programming_ is also excellent, though not as specific to Unix.)
2. _Advanced Programming in the UNIX Environment_, 2nd ed., by (the late) W. Richard Stevens. This and man pages will go a long way.
3. The man pages themselves. It's generally understood that OpenBSD's man pages are particularly well written, but if you're using Linux and the GNU userland, there will be lots of differences in the details.
4. The 4.4BSD "Programmer's Supplementary Documents" (PSD) - This is a collection of papers and man pages. While some are out of date, and some are mainly of historical interest, the introductions to tools such as make, lex, yacc, gdb, etc. are quite good, and often a tenth the length of the corresponding O'Reilly book. (These papers may be installed with your distro. OpenBSD has them in /usr/share/doc . I bought the book used for a couple bucks.) There are also "User's Supplementary Documents" (USD) and System Manager's Manual (SMM) collections, with papers on configuring sendmail, using vi, etc.
5. _The Art of Unix Programming_ by Eric S. Raymond - I recommend this one in spite of finding ESR incredibly irritating. It's a very good conceptual overview of the big design ideas in Unix and their ramifications, albeit one interspersed with narcissistic soapboxing by the author.
In general, using a Linux distro with a strong emphasis on having a friendly GUI layer can keep you at arms length from really learning Unix. Dig around in /etc. Learn to use cron and ed. (No, really.) Get your hands dirty.
I would also highly recommend learning a scripting language that integrates well with C (some people like Perl, Python, or Ruby, I prefer Lua), because really using Unix well is going to involve some C. Working with C isn't scary unless you're trying to build a large system in C - try instead to break it up into a suite of smaller programs, rather than one monolithic one. Take advantage of pipes and all the other existing Unix infrastructure. It's there to help keep complexity at bay.
For Unix systems-level/network programming, I'd also add to the list:
1. UNIX Network Programming: Networking APIs: Sockets and XTI; Volume 1 (W. Richard Stevens) - the books is considered the bible of the BSD networking APIs, and if you're interested in writing network software at any scale, in any language, you should start with this book -- everything else builds from here.
2. Write Great Code: Volume 1: Understanding the Machine (Randall Hyde) - At the end of the day you're writing code that will execute on a machine. Understanding how the machine works will help you understand your code.
3. The Design and Implementation of the FreeBSD Operating System (Marshall Kirk McKusick, George V. Neville-Neil) - If you've ever wondered how copy-on-write pages work (some of the magic behind the fork(2) model), or how your processes get scheduled, this is a good place to start -- even if you aren't using a BSD, the tenants hold.
Computer programmers are never taught how to read papers. Someone should write a paper on how to read computer science papers.
(For me, the issue was with getting over the "this is too hard for me" mentality. Some papers are hard, but you have to read them once, keep them in mind, and then read more. Then come back to the original paper, and it makes sense. The first paper that I noticed this effect on was "Applicative Programming with Effects". The first time I read it, it made no sense. Functor? Application? Category? A few months later, I read it and thought "this is brilliant". Like everything, practice makes perfect.)
As an aside, you can usually find a lot of papers behind the ACM paywall by searching on CiteSeer or Google Scholar, particularly searching with the authors' names.
If you find a paper hard to follow, start with the others it references. I've found a few niche papers that were worthwhile just for their bibliographies. (I didn't know what the issue was typically called.)
It's a wiki where people can summarize published papers (both publicly available and paywalled). Seemed like a good idea, both for people to practice summarizing what they've learned and for quickly finding relevant papers.
Sure, but people will still rediscover things independently, unless they choose to read everything ever written before actually doing anything.
I don't think that blog posts (or any form of writing) needs to be restricted to sharing new information only. Writing can serve as a mechanism for demonstrating what you have learned to potential clients/customers... it can serve as a means of solidifying concepts in your own mind... it can serve as a journal to help you remember things you were thinking in the past.
We need a snappy name like "analysis paralysis" that is focused on people who spend all their time studying rather than doing. They (we) intend to do, but never fell like they know enough to start.
I think most of the reaction to your response was due to your tone. I've seen a lot of blog posts where someone was mind-bogglingly astray* , and coming in saying "You're all wrong, you idiots, they solved this problem in the 70s, ..." just makes people ignore you. I think suggesting leads for further exploration (in this case, libevent, nginx, etc.) is more helpful, without being a slap in the face.
* Whereas this series seems to be people getting excited about using Unix syscalls from their preferred scripting languages, probably for the first time.
Yeah, well fuck you too.
As it turns out, I am an amateur, at least when it comes to POSIX, but more importantly I find this stuff fun. I hadn't realized that having fun and learning about new topics was such an offensive thing to do.
Maybe this is just frivolity, but it's surely a better way to spend a few minutes than crapping all over somebody else's fun.