On 03/04/09 08:22, James Carlson wrote:
> Joep Vesseur writes:
>
>> Of course, this applies to a lot of programs, but I think for
>> many administrators, tcpdump is on the top of their lists.
>>
>> Also, even though wireshark might be the preferred open source candidate
>> for us, tcpdump is here to stay for a long time.
>>
>
> Pity the poor folks who write protocols for a living. Which one of
> these tools -- snoop, wireshark, tcpdump -- should we attempt to
> update to support our projects? Should we try to update them all?
> Should we pick one because we think it's nifty?
>
ISTR, as part of the arc case for wireshark itself, that we had decided
that wireshark was the tool we were going to support. Other tools
(snoop especially) seemed to be more or less devolving into planned
obsolescence.
I *thought* tcpdump was the precursor to wireshark anyway. Do I
misunderstand?
-- Garrett
> Worse still, if you look at tcpdump carefully, you'll see that it's
> essentially a subset of tshark, the command-line version of wireshark,
> including the same default file format, and even the same capture
> filters. But wireshark is far more capable and includes an extended
> filter syntax, more file formats, and a highly functional GUI
> (reminiscent of the old Network General Sniffer).
>
> This is an architectural mess, and this sort of unnecessary "choice"
> has serious costs associated with it. It affects many others, and not
> just those people who are building these random packages and
> delivering them. Plus, it's a waste of time: we should be delivering
> wireshark, but we haven't, even though the skids have been properly
> greased.
>
> I'm making a plea for some thought to be put into the process. Can we
> please do that? Or have we just completely given up on system
> architecture and the effects that one random project can have on
> another?
>
>
