unix-junkie

I'm a former nmap core developer and even though I no longer actively contribute the project still is very close to my heart. It wasn't "revolutionary" at first, in that port scanning was already a thing, there were multiple available scanners out there. Most of these tools had their own syntax though, and they usually offered one specific type of scan. So nmap came and aggregated everything into a relatively simple tool. It then became incredibly successful and from that popularity nmap got its greatest strengths IMHO : portability, versatility (these crazy options implemented to satisfy super-specific needs) and the OS and service version signatures captured as a collaborative effort over more than a decade!

Thanks Fyodor & team!

The Stanford HPC team reported last year having sent more than 2PB to Google drive using Lustre/HSM. This was using the public API and the fact that gdrive is free for *.edu sites.

See https://www.eofs.eu/_media/events/lad16/07_thiell_cheap_n_de... (slides) and https://www.youtube.com/watch?v=WbE0nl5V8WE

Here is the paper: https://papers.nips.cc/paper/6596-dimensionality-reduction-o...

I appreciate naxsi for its ease of use and efficiency: https://github.com/nbs-system/naxsi

I would add "The Formation of the Scientific Mind" by Gaston Bachelard. This text analyses the nature of the mental patterns that prevent from making actual discoveries (what he calls "epistemoligical obstacles").

nmap dev here.

Nmap is already asynchronous, as you described multiple requests are multiplexed (cf select(2), epoll(7), kqueue/kevent depending on your platform...)

The core difference between nmap and zmap is that the latter is stateless. Which allows a much higher throughput, but also prevents from applying some smart detection mechanisms. Thus, both tools are complementary, and no, there is no work being done to make nmap stateless.

I don't get it, it seems to me that this fix is incorrect.

It's pointless to check for such a signed integer overflow after it happened.

What's the point in having such a RAM/core ratio? By assigning 4 threads per core (which is fairly common to exploit manycore architectures) you don't even have 4Meg of memory per thread.

I would totally agree that memory constraint is sort of tied to manycore architectures, but in this case I find it pushed to the limits.

Nmap leverages that cool stuff for precise PHP version fingerprinting.

See http://nmap.org/nsedoc/scripts/http-php-version.html