There's a relatively clear division of function, IMO, between GUI and console tools. In particular, for detailed analysis or bugtracking, what I want is logs I can grep through, console-based monitors (or raw /proc files) for information and status updates, and the rest.
But that's usually after I discover I've got a problem. Which is where the GUI fits in. Monitoring load, memory, swap, and network traffic, I've got a pretty good general idea of what's going on with my system. Abnormal readings in any one area and I can then go the the appropriate system tool for further digging.
I mentioned the WindowMaker monitoring utilities in my post. Three of these, wmmon, asmon, and wminet, are multimeters -- I get multiple functionality in 64x64 pixels of screen real estate. In the case of wmmon, I have to click through multiple graphs, asmon and wminet present five channels of output each.
The other thing that's useful from a GUI perspective is historical activity. Knowing current metrics are helpful, but having a historical trace on how it fits into context is also of use.
Again, getting to context, wminet is a really slick tool -- clicking on one of the five display lines (procs, users, ftp, http, smtp) brings up a console display of an appropriate tool, top and who among them.
And, in the specific case of running in console mode, you simply don't have the option of running a utility in the corner of a screen. You can probably work out tricks with syslog or emacs, but otherwise you're stuck with a single screen of text-based data. Powerful in some senses, limited in others.
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]