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