lavaps -- a lava lamp of currently running processes

lavaps

LavaPS is an interactive process-tracking program like ``top'', but with a much different attitude. Rather than presenting lots of specific info in digital form, it tries to present certain important information in a graphical analog form. The idea is that you can run it in the background and get a rough idea of what's happening to your system without devoting much concentration to the task.

LavaPS was inspired by Mark Weiser's idea of calm computing in this paper:

* ``The Coming Age of Calm Technology'' by Mark Weiser and John Seely Brown. A revised version of Weiser and Brown. ``Designing Calm Technology'', PowerGrid Journal, v 1.01, http://powergrid.electriciti.com/1.01 (July 1996). October, 1996. http://www.ubiq.com/hypertext/weiser/acmfuture2endnote.htm.

(This program dedicated to the memory of M.W.--I hope you would have thought it a good hack.)

Basic LavaPS is quite simple. Blobs live and grow corresponding to processes in the system (see BLOBS). Clicking the left mouse button on a blob shows information about that process. Clicking the right mouse button pops up menus that let you control LavaPS (see MENUS). The base at the bottom of the lamp includes icons for the menus and resizing, and allows one to move the lamp around.

LavaPS is all about blobs of virtual, non-toxic lava. Blobs in LavaPS correspond to processes in the system. When a process is started, a new blob is created. When a process exits, the corresponding blob disappears. Blob size is proportional to the amount of memory the process uses. Blob movement is proportional to the amount of time the process runs (if the process never runs, the blob will never move).

Blobs show several things. First, the basic color (the hue) corresponds to the name of the program which is running. Emacs is always one color, Netscape another (on my system, blue and yellow). Second, blobs get darker when the process doesn't run. Over time, the process will become nearly black and only its border will remain colored. Finally, if both physical and virtual memory are shown, then the part of the process will be a slightly different color showing what percentage of the process is not in physical memory.

There are some more subtle aspects of blob physiology: initial placement is dependent on the process id (blobs appear roughly left to right) and user id (processes for the same user start at the same height, with root's processes at the top).

Blobs also move along the longer distance of the lamp: if you resize it they may change direction.

Please don't ask me about the chemical composition of the virtual lava.

The right mouse button pops up menus which control LavaPS, including:

Proc: control the process under the menu: ``Nice'' it (make it take less CPU), unnice it (the reverse; only works if you're root), or send it a signal. Signals are terminate (the polite way to stop a process; ``terminate'' allows it to clean up after itself), kill (the forcefully way to stop something not listening to terminate), stop and continue (temporarily stop and resume the process), and hang-up (used to restart certain processes). Beware that these commands will be disabled if you don't have privileges to run them, and under some circumstances even ``kill'' won't stop a process.

Who: track processes by me or by everyone (including root, httpd, etc.).

What: track process physical or virtual memory or both. Most modern operating systems can keep all of a process in RAM (physical memory), or can let pages that aren't currently used float out to disk (virtual memory). Virtual memory is always a superset of physical memory. You can track either one, or both. When tracking both, virtual memory appears as a different colored strip down the middle of the process blob.

How: general lava lamp details: sizing, speed, and window manager interaction. Putting too little or too much lava in your lava lamp would make it boring or overflow. LavaPS therefore usually runs with patent-pending lava autosizing where blobs fill about a quarter of the lamp. This feature can be turned off (at your peril) with the How menu. You can also control the desired size of the blobs (when autosizing is enabled) or the absolute size of the blobs (when it's not) with the Grow and Shrink options.

Also under How, Jumpier and Smoother control the quality of lavaps animation. The smoother the animation, the higher the CPU overhead of lavaps (because of more frequent scans of the process table). Less smooth is more efficient.

Help: you'll have to figure this one out on your own.

Quit: this one's even harder than Help.

Basic LavaPS is quite simple. Blobs live and grow corresponding to processes in the system (see BLOBS). Clicking the left mouse button on a blob shows information about that process. Clicking the right mouse button pops up menus that let you control LavaPS (see MENUS).

The right mouse button pops up menus which control LavaPS, including:

Proc: control the process under the menu: ``Nice'' it (make it take less CPU), unnice it (the reverse; only works if you're root), or send it a signal. Signals are terminate (the polite way to stop a process; ``terminate'' allows it to clean up after itself), kill (the forcefully way to stop something not listening to terminate), stop and continue (temporarily stop and resume the process), and hang-up (used to restart certain processes). Beware that these commands will be disabled if you don't have privileges to run them, and under some circumstances even ``kill'' won't stop a process.

Who: track processes by me or by everyone (including root, httpd, etc.).

What: track process physical or virtual memory or both. Most modern operating systems can keep all of a process in RAM (physical memory), or can let pages that aren't currently used float out to disk (virtual memory). Virtual memory is always a superset of physical memory. You can track either one, or both. When tracking both, virtual memory appears as a different colored strip down the middle of the process blob.

How: controls blob sizing. Putting too little or too much lava in your lava lamp would make it boring or overflow. LavaPS therefore usually runs with patent-pending lava autosizing where blobs fill about a quarter of the lamp. This feature can be turned off (at your peril) with the How menu. You can also control the desired size of the blobs (when autosizing is enabled) or the absolute size of the blobs (when it's not) with the Grow and Shrink options.

Help: you'll have to figure this one out on your own.

Quit: this one's even harder than Help.

The Tcl/Tk version of LavaPS can configured from X resources (only if they're loaded with xrdb) or with the file $HOME/.lavapsrc. In both cases, the format is like:

        lavaps.autosize: false

setting whatever resource you want (in this case autosize) to some value (false). In the .lavapsrc file, the ``lavaps'' before the period can be omitted.

The following resources are supported:

geometry (default none). Specifies the initial window location and size in X-style (see X(1)).

who (default me). Whose processes should we be watching, anyway? My processes (set to ``me'') or everyone's (set to... ``everyone''). Can also be the process id of a single process if you're very single-minded.

what (default both). What kind of memory should blob size correspond to, either both, physical, or virtual.

autosize (default true). Keep the blobs at a reasonable size by dynamically changing scaling?

debug (default false). Enable debugging messages.

checkInterval (default 2000). How frequently (in milliseconds) should we check to see who's run? Defaults to 2 seconds which seems ``reasonable'' on my computer; shorten the interval if you want more frequent updates and have a faster computer (or are more tolerant than I am :-).

shaped (default true). Allow lozenge control (see next).

lozenge (default true). Make the lamp lava-lamp (lozenge) shaped using X11 shaped windows. Disabled if shaped is false.

clicklessInfo (default false). If set, process information pops up without clicking. (Not yet fully working.)

Q: The blobs are as jumpy as little rabbits, How do I make the animation smoother?

A: Set the checkInterval resource to a smaller value. Currently, Resources like checkInterval only work in the Tcl version.

Q: I'm running LavaPS on my Timex Sinclair and it consumes a lot of CPU, making my editor ed run slowly. How can I make LavaPS take less CPU?

A: Set the checkInterval resource to a larger value. Currently, Resources like checkInterval only work in the Tcl version.

Q: Lozenge-shaped LavaPS is so cool, but I keep loosing it on my 8000-pixel wide xinerama multi-screen display. How can I resize lozenge-shaped LavaPS since it doesn't have any title bar?

A: In the Tcl/Tk version: (1) Read your window manager documentation, most have ways to resize windows other than the title bar (sometimes using a menu). (2) Set the geometry explicitly with the -geometry command-line option or the geometry resource. (3) Put the title bar back (unfortunately loosing the lozenge shape) by setting the ``shaped'' resource to ``false''.

In the Gtk version: the base has controls to let you move and resize the lava lamp.

* On Linux, LavaPS doesn't properly track the process names of processes that change at run-time (because it uses /proc/*/stat rather than /proc/*/cmdline). (Bug identified by Murray Smigel.)

* Add support to change the font size as an option (feature request by Andrej Ricnik).

* Add a scaling factor to CPU speed. (Also make the default time-step proportional to CPU speed.)

* A --root option to run in the root window. (Unfortunately this isn't as simple as just using wish's -use.)

* Should have an option to label things with the hostname.

* Window shrinks to zero on startup with tkstep installed. (Hopefully gone away?)

* Flag and resource to force/control directionality.

* Show all processes but those by these uids (root, http, etc.). Also some way to exclude the (large) mfs image under FreeBSD, or big X11 processes.

* Set-able default scaling of blob size.

* Should verify that blobs can occupy the whole, whole screen. (Possible bug raised by Mark Yarvis.)

* When things are resizing they should probably maintain some relationship between visual space and memory that is not affected by odd horizontal:vertical ratios.

* Pop-up sliders to adjust scaling.

* Resources to adjust blob border width (suggested by Anthony Thyssen).

* The info window should be pinnable (like in OpenLook), and then auto-update. http://www.debian.org/Bugs/db/49/49884.html

* The Solaris port needs support for detecting command lines.

* This should work as a Gnome panel applet. It works in Afterstep's panel, but not Gnome 1.1.

* Finish clickelessInfo (it doesn't yet work). (Idea suggested by Yermo Lamers).

* Should allow LavaPS to show absolute memory usage, not just relative memory usage (suggested by several people including Johannes Nix).

* Non-linear scaling of memory usage (to accommodate the wide range of process sizes). Suggested by Johannes Nix.

* Option to suppress mem grow/shrink messages. (Suggested by Jerrad Pierce.)

* Background transparency. (Suggested by Jerrad Pierce.)

* Configuration pop-up dialog. (Suggested by Jerrad Pierce.)

* It would be nice if it looked like the lamp was actually filled with fluid and had a light down the bottom. So the background would be shaded with some color that followed a gradient of high intensity at the bottom to low intensity at the top, and this background gradient color would add the blob color of blobs that are floating in the background. (Suggested by Matth Lowry.)

* Clicking on non-blobs should allow you to move the window. (Suggested by Glenn Alexander.)

* Flag to disable blob borders. (Suggested by Glenn Alexander.)

* Three-dimensional lavaps using OpenGL.

* Several bugs remain in the Tcl version and won't be fixed: (a) Lozenge-shaped windows don't always properly draw the border. (b) Lozenge-shaped windows flicker for me on FocusIn/FocusOut events.

* Other bugs have also been overtaken by time: (a) LavaPS steals lots of colors on a pseudocolor display. Such displays aren't much used any more.

LavaPS was reviewed as app-of-the-week (see http://www.linuxcare.com/viewpoints/ap-of-the-wk/03-10-00.epl) by Brett Neely of Linuxcare.

ps(1)

Johan Walles's Bubbling Load Monitor http://www.student.nada.kth.se/~d92-jwa/code/ provides a similar service.

LavaPS is Copyright (C) 1998-2003 by John Heidemann.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License, version 2, as published by the Free Software Foundation.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.

John Heidemann, CWjohnh@isi.edu.

The idea of doing a lava lamp arose in discussions with David Taylor at USC. Although he didn't end up taking it on as directed research, the idea of a top-like lava lamp seemed too good not to follow-up on.

Thanks to two enthusiastic early users (Ted Faber and Mark Yarvis) for encouragement, suggestions, and bits of code.

LavaPS includes a small amount of code from xscreensaver by M. Dobie, Patrick J. Naughton, and Jamie Zawinski. On Linux it uses Chuck Blake's /proc scanning library. Building LavaPS uses tcl2cc by Ron Frederick, from tclcl (see http://www.isi.edu/nsnam/tclcl/ for details). Thanks to these authors for releasing their code to LavaPS.

Johann Visagie, CWjohann@egenetics.com, is the current maintainer of the FreeBSD port.

Hubert Feyrer CWhubert.feyrer@informatik.fh-regensburg.de, is the current maintainer of the NetBSD port.

Ashley T. Howes CWdebiandev@ashleyhowes.com is the current maintainer of the Debian Linux package.

Thanks to all the port contributors (listed above).