Lion: Hardware Growler crashes

For anyone using Lion and Hardware Growler (part of the excellent Growl package), you may have noticed that it crashes under some circumstances. (For example, see )

And if you're using it faceless, you may not even notice for awhile - say, til you realize you're waiting for a Growl that'll never come.

Fortunately, this is easy to slap a bandage over, with a simple bash script (all on one line):

while true; do if [ $(ps jaxwwww|grep [H]ardwareGrowler|wc -l) = 0 ] ; then open /Applications/Growl-1.2.2/Extras/HardwareGrowler/HardwareGrowler.app; echo "$(date): launched one"; fi; sleep 1; done

(I know; a hard-coded path - you'll have to fix it if your path differs - if you know a better way, feel free post in the comments.)

I tried using a longer sleep, though the resource utilization was indistinguishable, so I left it at "1", which means it recovers almost instantly.

This can be "automated" even further: Into a text document, paste this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>WindowSettings</key>
<array>
<dict>
<key>ExecutionString</key>
<string>while true; do if [ $(ps jaxwwww|grep [H]ardwareGrowler|wc -l) = 0 ] ; then open /Applications/Growl-1.2.2/Extras/HardwareGrowler/HardwareGrowler.app; echo "$(date): launched one"; fi; sleep 1; done</string>
<key>Columns</key>
<string>44</string>
<key>Rows</key>
<string>15</string>
<key>WinLocULY</key>
<string>678</string>
<key>WinLocX</key>
<string>611</string>
<key>WinLocY</key>
<string>0</string>
</dict>
</array>
</dict>
</plist>


Save it as "something.term".

Double-click / launch the document and it opens Terminal.app for you. Add it to your Login Items, in the Users & Groups (nee Account) preference pane, and it's automatic.

(I believe the "WinLoc" keys are ignored in favor of an offset from the most recent Terminal window; pity - I'd like to place this at the same location on the screen each time. Though of course, Lion's "Auto Resume" handles this nicely too. :)

Lion: Use spacebar to scroll or page

In Lion, using the space bar to scroll doesn't work very well - or, sometimes, at all. Even if it just worked a moment ago, in the same page.

Here are a few workarounds I've discovered:

1) Click in the area you want to scroll (ex: within a web page) and then press space.

2) Press the down or up arrows and then press space.

3) This is weird: Press a shift key and then press space!

coreaudiod using too much cpu

Strange; my MacBook was performing fine, though I happened to notice that the CPU usage of the "coreaudiod" process was constant at about 10%.

There was plenty of idle, though it was enough of an irritant - especially since it had the highest cumulative CPU time of all processes - that I wanted to look into it.

(BTW: Nice concise man page for coreaudiod. :)

Interestingly, CPU usage dropped down under 2% as soon as I plugged in headphones, and jumped back up to 10% when I unplugged the headphones - very consistently, each time.

I profiled coreaudiod with Instruments (part of the Apple Developer Tools).

It was spending a lot of time in DspFuncHelper::process_IIR_xmm_LR(). The interesting symbols in the symbol stack under that: DspFuncEQ, IOAudioEngineUserClient, IOA_HWDevice, IOA_SingleDevice, IOA_Device, CAPThread.

I tried turning the iTunes EQ off. And then toggled it a few more times. No change. I tried quitting iTunes. Nothing I tried made a difference. I don't have any other audio apps (*) so I dropped it there.

There's some chatter online about it, though none seemed useful. (Mostly the standard voodoo of "Have you tried turning it off and on again?" (ref: The IT Crowd)

However there was one suggestion by a user named "bompi" in the Apple Discussions, to use launchctl to stop the process gracefully:

sudo launchctl stop com.apple.audio.coreaudiod

It automatically restarts - and even if you're listening to something at the time, there's only a very brief interruption.

I'd still like to figure out what happened, why, and how to prevent it, however this at least is a temporary fix.

*Correction: Obviously there are other apps that use audio, though no significant ones came to mind at the time. However, I do use Skype and that can obviously use audio - and I'd been conferencing about 12 hours earlier -- with some audio trouble (on my end only; the other side reported that it was fine). FWIW, it was Skype v5.0.0.7980 and I see that v5.0.0.7994 is available so I'll try that and see if that makes any difference...

Apple to drop Xserve

(For reference, Apple's Xserve Transition Guide.)

This has been written about by some good folks:

• A Eulogy for the Xserve: May It Rack in Peace (By Chuck Goolsbee, via TidBITS.)
  
• On the Xserve thing... (By John Welch (Bynkii), with a link to his full MacWorld article.)

They cover the downsides, however:

Apple's target market is the end user. Overwhelmingly.

As such, the server market has always been a straddle of the world of the end user and that of the IT department - though clearly there are still some markets where an Apple server is a great fit, such as organizations where there is no IT department.

However, the target for the Xserve in particular has moved - in large part, to the cloud (such as AWS (Amazon Web Services).

And the cloud is built, in large part, with commodity hardware - not Apple's business at all. The cloud is much less about serious high-quality equipment, as it is about lots of cheap stuff that is configured so that failure is fully expected; just toss it (while something else automatically takes over its load) and slot in another.

That's the hardware side, which is all Apple plans to drop (in January).

On to software:

Apple explicitly will continue to develop Mac OS X Server and will continue to develop some server configs based on its other CPUs; a Mac mini with Mac OS X Server is a very nice server - and fits Apple's target market much better. It's no Xserve - and many of us have no need for all the Xserve does -- nor any need to pay for it.

Though this transition will cause some pain for those of us who find great utility in the Xserve, this is a great move for Apple and aligns its resources where they fit best.

Oh - and by the way, here's a left-field idea:

Apple is in a far stronger position now, than when it first started selling Mac OS X Server. At which time, tightly tying it to Apple's hardware made great sense. And Apple's very firm policy (full price) on licensing even virtualized instances of Mac OS X Server, while rather painful, made a certain amount of sense too.

Now? The landscape is significantly different. The business case can be much more solidly made, that Apple could license Mac OS X Server on commodity hardware - including in the cloud.

A stretch, yes. But within reach.

Strong passwords

Microsoft has a page to check your password, which rates its strength.

Good idea - to help people choose stronger passwords - however:

• I certainly wouldn't want to tell anyone my password, especially over the Internet; I'll keep it between me and whatever service I need a password for. (Yes, as it notes at the bottom of the page "The password you enter is checked and validated on your computer. It is not sent over the Internet." however I'd have to read the code to confirm that - and that it hasn't been changed since the last time I read the code. An unlikely requirement for the intended audience.)
  
• I certainly wouldn't want to tell Microsoft in particular; regardless whether you trust them or not, they're a big target, so why take the chance of being "collateral damage"?
  
• The page has little intelligence behind it; here are some example strength ratings:
  • Medium: qwertyuiopas (12 characters - straight across the keyboard)
    
  • Strong: abcdefghijklmn (the first 14 letters of the alphabet)
    
  • Strong: 12345678912345678912 (20 digits, in order)
    
  • BEST: 28 of any letter.
    

Whoops.

Recipes for tm-diff (Time Machine difference)

A few recipes for using the tm-diff.sh script that I posted earlier (see link for details):

• Ignore errors/warnings (ex: "Permission denied"):

  tm-diff.sh folder1 folder2 2> /dev/null

  
  
• Find all files, regardless of their privileges/permissions:

  sudo tm-diff.sh folder1 folder2

  
  
• Display disk usage, in "human-readable" sizes (ex: KB, MB, GB...):

  tm-diff.sh folder1 folder2 | while read f; do du -h "$f"; done

  
  
• Display disk usage, with a grand total at the end (sizes in KB):

  tm-diff.sh folder1 folder2 | while read f; do du -k "$f"; done | awk '{ sum += $1; print; } END { print sum; }'

  
  
• Display the largest 50 files (sizes in MB):

  tm-diff.sh folder1 folder2 | while read f; do du -m "$f"; done | sort -n | head -50

  
  
• Display the smallest 100 files (sizes in KB):

  tm-diff.sh folder1 folder2 | while read f; do du -k "$f"; done | sort -rn | head -100

  
  
• Display a full listing (with mode/privileges, owner, group...):

  tm-diff.sh folder1 folder2 | while read f; do ls -l -h "$f"; done

  
  

Notes:

1. This presumes you've set your PATH so it'll find the tm-diff.sh script. (Or use its full path.)


2. In the commands above, "folder1" and "folder2" of course represent the paths to the two Time Machine backup folders to compare; they'll look something like:

   /VOLUMENAME/Backups.backupdb/USERNAME/2009-07-20-091153



3. The script explicitly searches for regular files only; no directories or other special files.


4. I use a read loop, since this will get the full path, including "special" characters like spaces and double-quotes.


5. Sizes are in the classic style ("as God intended"): KB = 1024 bytes; MB = 1024 KB; GB = 1024 MB ...


6. Most Time Machine backups contain tens of thousands of files, so these will take awhile. The ones that sort will display no files, until all of them have been found, to be sorted - so they will seem to take even longer.

Show differences between two Time Machine backups

Below is a quick Bash script to display the difference between two Time Machine backups.

The output is simply the pathnames of the files that were added to Time Machine in that time period. This may of course be piped to another command/script to provide further info - say, the amount of space used.

Cheat: Provide a simple date (formatted the same way that Time Machine does) instead of the "older" backup pathname, and it'll work whether or not there was a backup then. (The order of the arguments is unimportant; the script will figure it out.)

#!/bin/bash

LF=$'\n'
usage="Usage: $(basename $0) Time-Machine-folder-1 Time-Machine-folder-2"
usage=$usage$LF"(Compare the two Time Machine backup folders;"
usage=$usage"find and display files that were backed up in that time period.)"

function tweakDate { # to a fmt understood by find cmd
   echo "$1" | awk -v FS="" '{print $1$2$3$4$5$6$7$8$9$10" "$12$13":"$14$15":"$16$17}'
}

if [ ! $# == 2 ] ; then
{
   echo "$0 requires two arguments; the Time Machine folders to compare." >&2
   echo "$usage" >&2
   exit 1
}
fi

baseName1=$(basename $1)
baseName2=$(basename $2)

# NB: operator must be escaped or will signify redirection
if [ "$baseName1" \< "$baseName2" ] ; then
{
   olderFldr=$1
   recentFldr=$2
   olderFldrName=$baseName1
   recentFldrName=$baseName2
}
else
{
   reverse=TRUE
   olderFldr=$2
   recentFldr=$1
   olderFldrName=$baseName2
   recentFldrName=$baseName1
}
fi

if [ ! -d "$olderFldr" ] ; then
{
   echo -n "Warning: $olderFldr doesn't seem to exist;" >&2
   echo " maybe you're just using it to specify a date?..." >&2
}
fi

olderFldrParent=$(dirname $olderFldr)
recentFldrParent=$(dirname $recentFldr)

if [ ! $olderFldrParent == $recentFldrParent ] ; then
{
   echo -n "Warning: These folders are not in the same parent folder;" >&2
   echo " this may not be what you want..." >&2
}
fi

olderFldrDate=$(tweakDate $olderFldrName)
recentFldrDate=$(tweakDate $recentFldrName)

if [ ! -d "$recentFldr" ] ; then
{
   latestBackup="${recentFldrParent}/$(ls -1 $recentFldrParent | tail -2 | head -1)"

   echo "Can't find $recentFldr; searching the latest backup" >&2
   echo "    ($latestBackup)" >&2
   echo "    for files modified between $olderFldrDate and $recentFldrDate." >&2
   echo "    This may take awhile..." >&2
   echo $LF >&2

   find -x "$latestBackup" -type f -newermt "$olderFldrDate" \! -newermt "$recentFldrDate" -print
}
else
{
   echo "Now searching for backups in $recentFldrName" >&2
   echo "    that are more recent than $olderFldrDate." >&2
   echo "    This may take awhile..." >&2
   echo $LF >&2

   find -x "$recentFldr" -type f -newermt "$olderFldrDate" -print
}
fi

# eof

Cloudera Desktop setup tip: DNS, DNS, DNS

Yes, it's important with Cloudera Desktop, just like everything else - try to fudge domain names and get bit.

Strange errors like:

"An unknown error occurred: hdfs put returned bad code: 255 stderr: 10/02/18 18:41:52 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:8020... Bad connection to FS. command aborted."

When attempting to upload a file - and I know that localhost is indeed responding properly on that port because it works find from the command line.

Solution: Spend the few minutes to determine what the real domain names are (*1) and set up the config files (*2) properly.

*1: ifconfig will tell you the IP address of the node you're on; host will tell you the domain name. If there is none, see *3 below.

*2: config files of potential interest:

/usr/share/cloudera-desktop/conf/cloudera-desktop.ini

/etc/hadoop/conf/masters

/etc/hadoop/conf/slaves

/etc/hadoop/conf/core-site.xml

/etc/hadoop/conf/hdfs-site.xml

/etc/hadoop/conf/mapred-site.xml

/etc/hadoop/conf/hadoop-metrics.properties

/etc/hadoop/conf/hadoop-env.sh

/etc/hadoop/conf/configuration.xsl

/etc/hadoop/conf/fair-scheduler.xml

*3: No domain name? See whoever's in charge of DNS, to fix it. That you? Well, you can either do it right (a little effort up front, pays big in the long run...) or you can try to handle it via /etc/hosts - good luck with that though.

Note to self: Don't shortcut DNS!

Snow Leopard pestering for keychain password

Interesting new behavior in Mac OS X 10.6 (Snow Leopard):

Services that formerly required a single authentication of the keychain (at launch) now ask every time, if the keychain is locked.

I've noticed this at least with Apple Mail and Google Contact Sync (ex: the gconsync process asks access the keychain).

The new behavior is certainly more secure (formerly, the passwords read from the keychain had to be stored somehow, to use later, thus providing an additional potential place to steal them). However, I don't agree it's worth the trade for the level of bother.

And it forces me to either:

1) Type my keychain password frequently (some risk there; ex: if someone's watching).

OR

2) Adjust the automatic keychain locking to be less frequent - which could well result in it never being locked (since it would continually be a accessed, resetting the countdown to automatic locking).

I didn't like either, so I found a way to tell Mail to check (poll) less frequently; every six hours:

defaults write /Users/mvgfr/Library/Preferences/com.apple.mail PollTime 360

(The above is to be issued to a command line prompt, all on one line. If you're not familiar with the command line, here's a beginner's guide. Standard warnings for the command line apply; if you're not careful you can do serious damage.)

This works for me, since I'm using Mail only as a backup of my mail messages; I compose and read mail in other ways.

(The Mail Preferences window allows a maximum of 60 minutes - and this is what shows when set as above, though the custom setting is thankfully maintained and not overwritten.)

Google Contact Sync (gconsync) took a little more effort; documented at the previous link. The concept may apply to other types of synching, though would require changing another parameter, since the above is specific to Google Contact Sync.

Decrease Address Book sync frequency (And some keychain tips)

Snow Leopard's "new" Address Book sync with Gmail's Contacts works great - though I'm not sure why it defaults to sync every hour; I certainly don't change contact info that frequently. :)

If you keep your keychain locked most of the time* being bothered to authenticate OR click cancel, twice, is a needless bother.

So, here's the command to set the frequency to whatever duration you like (in seconds); I chose a full day, since that's more than enough for me:

defaults write ~/Library/LaunchAgents/com.google.GoogleContactSyncAgent StartInterval -int 86400

It's also apparently necessary to log out and back in, to get the change to take effect.

*Keychains can hold some pretty sensitive info. If you don't have the keychain lock itself after X minutes inactivity, you should consider it. Pop open the "Keychain Access" app (in /Applications/Utilities/) and take a look at what's in your own keychain - sure you want to leave that unlocked? If not:

• Click the "Edit" menu
• Select "Change settings for Keychain 'login'..."

  I recommend turning both checkboxes ON and setting a short lock time.

Now, once you've done this, you may find that Safari is pestering you mercilessly, to authenticate. This is because it's being very careful and storing virtually everything you type in Safari, in the keychain - since it can't tell how sensitive everything is, though it knows that some of it might be credit card numbers and the like. Fortunately there's a solution that's both secure and convenient; tell it not to store that info:

• Click the "Safari" menu
• Select "Preferences..."
• Select the "Autofill" tab
• Turn OFF the checkbox for "Other forms".

  (If you're curious, you can see what it's been storing by clicking the "Edit..." button to the right of the checkbox. It's mostly web searches and other such innocuous stuff. As you can see by the other checkboxes, passwords are stored separately.)