14 Dec 2005 LiveSystem! See the System Live and more..
This idea was rotting er.. dormant in the back of my mind for a long time [see a comment I made back in Sep 2004].
Here is a screenshot of a dummy prototype


Currently it only shows processes that were programmatically added after collecting data from a DTrace script that printed execname, pid, parent pid. Assume that processes which are big are consuming more memory and processes which are reddish are consuming more CPU, and bluer are consuming less CPU resources. You can drag things around, and it automatically adjusts itself when processes get created or deleted.

It is written in C and uses GnomeCanvas library. I could have used Cairo, but libgnomecanvas was already there on Solaris.
I initially tried using libgraph from AT&T's graphviz which is an excellent tool for graph layout; but it did not meet some requirements outlined below.

I thought it would be a cool idea for the Solaris 10 University Challenge Contest. Any students who want to pick this up from here are welcome. Knowledge of Graph Theory, Operating System Concepts, and Computer Graphics would be helpful. It could help as a teaching aid, showing the system as its developers envisioned live! If it is usable and fast, it could be the substitute GUI for system administration and monitoring.

These are these simple concepts or assumptions for its design:

1. Model: The system is a graph (mostly tree or a forest)
2. Model: There are two types of nodes:
   1. box nodes: which contain everything under them (like zones, users, roles)
   2. object nodes: which are icons representing objects (devices, processes, printers, hard disk, sound)
   Edges show some relation ship (parent-child, processes listening on a network interface) or interaction(reading/writing to a device)
3. View: The system is visualized just like the way its designers visualized or drew them in presentations or technical papers. OR the system developers should be able to draw the system using a pencil and a paper
4. View: Assume an infinitely big paper is available, and can be zoomed in and out if the drawing is bigger.
5. View: The tree is drawn using a "fast incremental stable tree layout algorithm" Which means,
1. incremental: It is faster to compute the new layout, given an old layout and a change (either addition, deletion of edge or node)
2. stable: Number of nodes moved due to incremental layout must be small.
3. predictable: Positions of nodes must not change by a limit.
6. View: Objects have properties which becomes visually shown. (eg. color of a process node might indicate CPU usage, size indicate memory usage)
7. Controller: There are events that trigger additions/deletions to edges and nodes.(DTrace; also see Brendan Gregg's excellent DTrace collection)
8. Controller: There are simple actions that can be performed on the nodes (like killing a process, restarting a service, rebooting a zone, offlining a CPU etc..)

As a design guideline unlearn that things like drop down menus, option buttons, lists and tables exist. Think from a fresh perspective! do not try to mimic or copy administration tools on Microsoft Windows or Apple. Apply Chandan's law i.e "Make the common case faster and easier". It does not have to do "everything" - just the most common cases (which may be wanting to see "the status of something", to identify processes that are taking too much CPU time or disk I/O)

Link | Comments [2]