4 ms·

a summary of the linked discussion: # tptacek dislikes that nmap is in C; others point out that this was not a bad language choice back when it was written #

a summary of the linked discussion: # 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?

tptacek 15y ago
Sigh. 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.
- tmp1234123 15y ago
  Thank you for responding to my insults. > 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.

tptacek 15y ago

Sigh. 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.

tmp1234123 15y ago
Thank you for responding to my insults. > 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.