If your Mac beachballs when, for example, you're trying to unlock the screensaver, and comes back after a few minutes, "lookupd" could be the culprit. Look in your console log (/Applications/Utilities/Console) for lines like the following.

lookupd[283]: NetInfo connection failed for server 127.0.0.1/local
lookupd[283]: ni_statistics: Communication failure
DirectoryService[82]: NetInfo connection failed for server 127.0.0.1/local
DirectoryService[82]: NetInfo connection failed for server 127.0.0.1/local
DirectoryService[82]: NetInfo connection failed for server 127.0.0.1/local
DirectoryService[82]: NetInfo connection failed for server 127.0.0.1/local
DirectoryService[82]: NetInfo connection failed for server 127.0.0.1/local
lookupd[283]: NetInfo connection failed for server 127.0.0.1/local
lookupd[283]: ni_statistics: Communication failure
DirectoryService[82]: NetInfo connection failed for server 127.0.0.1/local
lookupd[283]: NetInfo connection failed for server 127.0.0.1/local
DirectoryService[82]: NetInfo connection failed for server 127.0.0.1/local

This is not a new problem. In fact, it's been around for years. John Bafford released unlockupd, in 2004, to work around the bug in lookupd that causes this problem. Here is his explanation of the issue:

Lookupd is the lookup and caching daemon responsible for handling NetInfo, DNS, and other such requests. Applications typically do not access lookupd directly, but rather, use standardized library functions (such as gethostbyname for DNS) which access lookupd on the application's behalf.

Lookupd has a bug (rdar://3632865) in its cache cleanup code that causes it to randomly crash. CrashReporter, the system crash log agent, does not properly handle lookupd crashes, and as a result, when lookupd crashes, the process is not terminated. Since lookupd has not terminated, mach_init does not respawn lookupd. From this point, any application that attempts to access lookupd, either directly or indirectly, will hang.

Once lookupd stops responding, it becomes difficult, but not impossible, to recover the system to a usable state. One technique which works, but is not recommended (for obvious reasons), is to leave a root shell running and `killall -9 lookupd` when it becomes obvious that lookupd has died (sudo does not work, since it requires lookupd's services, as does opening a new terminal window).

The bug number is apparently 3632865 in Apple's bug-tracking system, "radar". The rdar url above is usable by Apple folks, only. There's no way for the public to see the details of that bug number. Joel wrote a little article about this problem as well.

TFmonitor is a piece of software written by K. Seki that monitors your Intel Mac's fan speeds and temperature sensors. To the right is a screenshot of it in action on my MBP (core duo).

I like to bump the minimum fan speed on my Mac up to 2500 RPM to keep it cooler. Currently I'm just using the "smc" command-line program, although I've tried the various GUIs available now. I use the following:

/usr/bin/smc -k F0Mn -w 2710
/usr/bin/smc -k F1Mn -w 2710

Note that 2710 is the hexadecimal representation of 10000, which is 2500*4 (or 2500 left-shifted by 2). The primary problem with this method is that it doesn't stick past reboots or sleep/wake cycles, and has to be run again.

So I'm writing a little program to run idle in the background, wait for "I woke up" events, and re-set the minimum fan speed. Then I just need a prefpane to set the minimum speed and I'll be good to go.

[[[NSWorkspace sharedWorkspace] notificationCenter]
addObserver:self
selector:@selector(workspaceDidWake:)
name:NSWorkspaceDidWakeNotification
object:nil];

I know that FanControl does this already, but it seems to have the side effect of making my cpus run at full speed (2.17GHz) all of the time. If I just set the minimum fan speed using "smc" as needed, the CPU speed can still vary. For example, while typing this, I'm running at 1.67GHz.

$ sysctl kern.cpu_currentfreq
kern.cpu_currentfreq: 1667

Plus, it's a fun little project.

UPDATE: a fun little *abandoned* project. FanControl 1.1 doesn't peg my CPUs at full speed. CoreDuoTemp does mis-read the CPU speed, though. I'm happily using FanControl and running at 118ºF.

Version 1.05 of my plugin for Apple's mail client is available here.

Changes:

• Does not prompt mail check when it's told "0 recent" by the mail server (more reliably handles IDLE status messages)
  
• Handles erroneous CAPABILITY responses better (more reliably detects IDLE support)