I would expect to be called on shortcomings... But that didn't happen... Someone who didn't bother to understand the code mis-applied it to his situation and then called that misapplication for being flawed.
See, I responded in a conversational chain about "brute forcing a key" with a basic structure on how to blacklist a brute force attempt source. (and in two other places I did paste the same code since Slashdot doesn't let you easily fold sub-topics, but in each case the conversation was slightly different.)
Now at no time did I say "this will solve all your problems or address all your issues". For example one of the "short-comings" was about logging and the other involved use _inside_ a VPN where connection rates would be intentionally much higher. Neither is a real short-coming as people with even trivial knowledge of program flow and iptables in general would know how to deal with both situations. Things like picking the network interfaces to apply the rules to, and fully understanding that where rules are not desired, they should not be applied. (it's kind of no-duh that way, life). [In fact, if you look at the command I use "ext+" (instead of the default "eth+" et al.) as the interface, which is completely non-standard to deter "cut and paste" application and encourage thought about how the model might be used.
Logging is another issue wholly. Most people collect _way_ more logs than they should and then end up losing their important information in a flood of data. [ASIDE: this is why Gestaltism failed and the Scientific Method came to prominence.] It _shouldn't_ take much brain at all to figure out the various ways that logging would dress onto the skeleton above. On systems with high logging standards I usually replace most-or-all "ACCEPT" rules with a jump to an accept chain that contains uniform "success" logging (e.g. see LOG target --log-prefix element). I like to put failure logging at "the point of failure detection", and only one fail notice, so that I don't have to fish through repeats. Then I let tools (like the way the "recent" match stores the date/time of encounters) do their jobs rather than spending a lot of CPU to re-chew raw logs for no flipping reason at all. [Mil-spec sites will, clearly, have other requirements, which are solved by other means.]
As for the Condescension. That too is a useful tool, applied quite carefully in this case, that makes people think and re-read instead of reflex flame. Now you have jumped valiantly to the defense of some clod, and I decry you for that, because you have amplified his mistake with your opprobrium. This makes you more wrong than him. You have stepped in as arbiter of form with disregard to content. You are pure noise with no signal whatsoever. your single data point is my *horror* repetition of the code in other contexts. You got me. I am willing to put the same idea in front of more than one subset of a conversation. How this must wound the internet, and confuse it beyond its ability to cope. The internet has never seen repetition so foul as I have done here.... oh wait....
I do indeed condescend, to him, and to you. His histrionic, left-handed, and unsupported assertion (q.v. "I would be fired if...") set the tone for what followed and I was willing in whole to treat with him on his terms. Your yappy-dog, I want to seem important too, infantile insertion was not even up to the low bar we were dancing above. Oh good show to you find tagger-along. You have wounded me to the quick with your amazing and subtle support of his shortsightedness. Bravo!
If you don't understand why littering a design pattern/example with noise is just plain bad instruction, perhaps you should retire from the field and take up something that better suits your cook-book-only, can't be bothered to think, self-limiting mentality.