'slow' was a little too direct, however whiny comments like yours should be downvoted to ruin too. show us the code or blog post you wrote, else stop being a little bitch. Also quote marks are for quoting ffs.
Actual post: http://news.ycombinator.com/item?id=2317547
I stand by my argument in spite of the downvote though - whining about something and expecting everyone to have read your previous thoughts on the subject is douchey whether or not you're a hot-shot HNer.
# tptacek dislikes that nmap is in C; others point out that this was not a bad language choice back when it was written
# tptacek complains that nmap is more of an all-in-one tool; rcamera posts that it is also provided as smaller tools eg. ncat, nping, ncrack, etc. (pretty cool - I didn't know that)
# tptacek provides about 60 line ruby script which to my untrained eyes look like they perform more or less the same function as `nmap -p T:1-65535 $IP`
edit: he also complains about performance - I'd be very surprised if the ruby script outperformed a suitable nmap command - maybe you need -T5?
I don't dislike that nmap is in C! C is my favorite language. I do think that most HN people --- who typically do not know C --- should know that nmap doesn't benefit much from being written in C, because nmap is IO-bound.
Do ncat, nping, ncrack, &c provide fast simple working port scanners? Then what do I care about them?
If it doesn't intrigue you that you can outperform nmap (in its default settings) and come close to it with carefully tuned settings with sixty lines of Ruby, I don't know what to tell you. I guess just vote me down. I think it's interesting, that's all.
> I don't dislike that nmap is in C
I guess reading just the burgerbrain thread in the linked context I would have come to the same conclusion, that you like C and weren't criticising nmap being written in it.
Others and myself seem to be thrown off by the content of the parent to that thread, with the statement that nmap could be majorly improved upon, followed by a single paragraph stating that C is unnecessary (due to IO bound).
> Do ncat, nping, ncrack, &c provide fast simple working port scanners?
Valid point, the original comment was posted in response to the argument that nmap was too big, I reproduced it simply because I found it interesting. It shows that they have split out into different tools, but yeah nmap is still the port scanner.
Your point about it having a scripting language adds weight to the argument about it being bloated, however I'm dubious that this would add more than a few ms of performance loss, and there's always the argument that you can simply not use it.
> If it doesn't intrigue you that you can outperform nmap (in its default settings)
I don't have any excitement for the Ruby script and am disappointed to see it is exactly the same one that I or anyone else would have written when asked to scan 65535 ports. The nmap developers would be turning in their graves to see such a naive script be touted as "better performing".
I'm grateful that the nmap developers left their scanner with sane defaults so that anyone like myself can just use their tool responsibly without thinking, and then only dig into the man page if we need greater performance (-T5 amongst others, eg. --min-parallelism 10) or the linked article (-T insane).
> I think it's interesting, that's all.
Sorry, there's nothing new or interesting in that script. I've read other comments you've written which were knowledgeable and interesting, but not found that here and hope that you properly reference your criticisms in future.