This is Perl Underground here. We thought we could respond to a couple kids, cause there ain't nothin' like dissin' on FD. Part of this rant is just in general, and might end up in Perl Underground 6. So it's to be considered BETA, and thus criticism is UNACCEPTABLE!!!
Just kidding. RSnake and his talentless fanboys would like to diss Perl Underground in any way he can to mend any damage to his image. He likens us to Perl programmers he has schooled on security topics. This may mend his ego, but does not reflect accurately on the people of Perl Underground nor does it help understand the Perl issues we brought forth. RS wants to give the impression that he is an incredibly talented individual (a "Web application security god") who has, without reason, been maliciously targetted for a year by Perl programmers who must be untalented, otherwise they would be public. Nevermind that we critiqued many others, or that we connect readers with more positive information than poor code. Nope, we must be all about RSnake jealously. IceShamen claims we "pedantically analysed everything line for line" while RS states "I don't have a year to debug a small program, like apparently he does". A contributor spends maybe twenty minutes going over code of this size. We stated explicably in past zines that we are merciful and only discuss the occasional issue. Until you actually learn Perl, RSnake, it's hardly worth our time to teach you Perl OOP or proper documentation technique (what you call "Perldoc" is generally called "POD", by the way, but whatever). We do not intend to fix your code. Instead we simply offer the occasional suggestion to make you think. You two are responsible for your own code, it isn't our fault there are so many issues that we can only discuss (and notice, for that matter) a certain amount in a given publication size. "and the -w flag? Most people I know who write code for a living only turn that on while debugging. Once you put it into production why would you keep it turned on?" I bet the people you know who write code for a living are shit with Perl too. The warnings pragma (*not* just the -w flag, there are slight differences in practice but that's getting beyond you and offtopic) is highly useful in debugging AND in released code. Why? Because it catches runtime problems, fuckhead. There might be no warnings in your last set of tests, but different data can provoke them and reveal errors in your code. Lots of serious professional Perl programmers INSIST on warnings being on. On the other side of your argument, strict is compile-time, so why the fuck would you leave it in if you had the impression that even warnings was of no further use to you? strict is much less likely to make a difference to you if it passes in general, which is ironic given your position on warnings. Again, in practice Perl coders leave strict in to save time maintaining (instead of setting it again for every patch) and as a clear sign that the code is strict-safe and the author strict- aware, reasons that apply to warnings as well. The actual performance hit of either is unnoticable, certainly not a bottleneck in your program. "[...] changing the scope from global to local doesn't change how the code works - at all. Not to mention there are dozens of missing features that have been slowly added and will continue to be added with future revisions, so cleaning it up now doesn't make a lot of sense since it's getting a complete re-write anyway" Isn't that smart? Let's leave it as a total mess because we're just going to add more to it and make it a further mess? How about you get your code under control and maintain it. Or are you just too used to writing little piece of shit programs, that you do not have the organizational skills to manage a slightly-larger little piece of shit program with multiple contributors? How about you exclusively use file-scoped variables in C programs, because various shitheads aren't smart enough to design procedural code and you cannot figure out how to responsibly organize it? That probably sounds ridiculous, but that's the argument that RSnake is making. We saw both the beta and the 1.0, and both times thought the code sucked. You labelled 1.0 as a "production ready DNS enumeration tool". Maybe we just have higher standards than you for production-ready. Frankly, your code is shit, regardless of which version we criticize. You can hide behind the fact that we wrote about 0.9.9 instead of 1.0, but only so much changed. It's still shit, so is 1.0.3. Hardly anything has changed in the meantime, and it is no less enlightened. Almost everything shitty ("style") complaint, like, uh: if ($filename && $filename ne '') { are still around. Mostly it has just been moved around. Fresh shit has been added. Consider these two consecutive lines: $domain =~ s/\.$//g; my $inet = inet_aton("$domain"); Not cool RSnake, not cool. We are a collection of individuals who come together under an understanding. This understanding is that most programmers write code that is less than mediocre, and that concrete steps need to be taken to increase our standards at all levels. This is virtuous for both artistic and pratical reasons. Some do this in peaceful ways (and even we do, too, through other avenues), while we felt a need for more vocal protests. Many self-described security gods calmly discuss how better computer education is needed for average users to increase their security. We discuss how better education is needed for the pure mass of programmers, including those with blogs and fanboys, to increase the stability of our software infrastructure in both the short and long term. Every time a piece of bad software is distributed it damages this longterm goal for all of us. We do not expect perfect code (we certainly do not write perfect code), but we do expect basic research and at least mediocrity before distribution. We have a strong commitment to quality Perl code and doing our part to support the production and release of the best Perl possible. That's why if you release something, you better be able to take a bit of heat. We let a lot of code go that would not pass a basic code review at any respectable establishment, and instead we stick to noticably loud or shitty code. You wrote and published bad code, RS. Just as you can be rewarded for writing a moderately useful tool, you can be criticized for defecating on our art. We are anonymous because we have no need not to be. Being anonymous leaves our articles up for review publicly, instead of just providing names for you to attack ad hominem, although you tried anyways. Perl Underground is not about improving our programming careers. It is not about making a name for ourselves in security communities. It is not about having fanboys. It is not about having a blog, forum, or advertisements. It's about Perl. -- Click here for great computer networking solutions! http://tagline.hushmail.com/fc/Ioyw6h4fM6mtFdSymaRUi4nQIA5KxMxTHHZDKMZ4J8r8h0yR0j27LC/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/