[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PFtop monitor

In some mail from Jason Dixon, sie said:
> LOL.  Sorry, didn't even bother to see that someone else already did
> something like this (with the same name, no less).  Please configure
> your procmail to redirect all future mailings from me to /dev/null.  ;-)
Well, while all of these "alternate" ways of viewing this sort of data
over time have been presented, what they fail to do is relate as much
information as you get with a curses-orientated program.
For starters, over slow links, not using a curses display is going to
be less efficient unless the entire screen full of data changes with
every update.
And that brings me to a second point - when using curses, you don't
need to keep a snapshot of what the last "screen" looked like in your
head and do a diff with your brain.  You can see what changes in front
of your eyes as a key not only where to look but how dynamic things are.
Plus on busy systems you don't need to worry about "does the output
exceed 1 screen length?" if the curses application has been properly
written.  Then there's the general load caused by running pfctl every
X seconds rather than running pftop once and so on (use vmstat to
measure the difference.)
There may be many ways to attempt to skin this cat, but not all of them
are nearly as good as they may seem to be, especially when compared to
just being able to use pftop.