As the author of Ncat, I disagree that it has "very different output" from
traditional and OpenBSD netcats.  Unless you specify -v (verbose mode),
Ncat usually doesn't have any output at all.  It silently connects to a
remote system (or listens for connections from remote systems) and relays
exactly what those systems transmit.  Also, nc.traditional does not even
support IPv6.  A failure because the remote host only supports IPv6 seems a
lot more problematic than any alleged difference in output.  The
traditional nc doesn't support SSL encryption either.  That's a problem for
communicating with modern web sites and mail servers as well as for
communicating securely between ncat instances.  Also Ncat fully supports
Windows and Mac, so users can interoperate between more systems.  And it's
more performance in many cases since it supports modern Linux I/O API's
rather than just select and poll.  Also traditional netcat is not
maintained by any particular organization.

For these reasons, we support having Ncat be one of the official Debian
Netcat alternatives.    It's already the default on many other
distributions, including Red Hat Enterprise Linux, Fedora, etc.  We also
love traditional and OpenBSD netcats and are glad those are offered by
Debian and Kali as well.

Cheers,
Gordon "Fyodor" Lyon

Reply via email to