Apple Doesn’t Like “Die, You Gravy-Sucking Pig-Dog!”
There’s a relatively well-known Easter egg in BSD’s shutdown.c: a function named die_you_gravy_sucking_pig_dog (side note: I’ve got three-to-one odds that say whoever wrote that has a huge UNIX beard). It turns out that Apple doesn’t care to have such uncouth function names floating around, so they re-defined it:
#ifdef __APPLE__
void log_and_exec_reboot_or_halt(void);
#else
void die_you_gravy_sucking_pig_dog(void);
#endif
Sure, it does the same thing, but I don’t think log_and_exec_reboot_or_halt has the same panache.
Big Nerd Ranch
My cabin at the Big Nerd Ranch.
Hopefully, I will continue to improve the content of this site in the months to come. To that end—among others—I’m at the Big Nerd Ranch in Atlanta, Georgia for their Advanced Mac OS X Programming course this week. I’m very excited and hope to learn as much as I can possibly fit into my brain.
User Accounts Disabled
To help fight spam, I’ve disabled user account registration on this blog and deleted all subscribers. I apologize if anyone actually used that feature; if RSS isn’t enough for you, e-mail me and I’ll make you an account. Unless you try to sell me Viagra.
Automatically get the latest Chromium snapshot with launchd
I’ve been checking out the snapshots of Chromium recently, and they’re coming quicker than you can say “multithreaded web browser.” To facilitate always having the latest version, I wrote a quick LaunchAgent that takes care of it on Mac OS X. First, I have a script named ~/bin/chromiupdate:
#!/bin/bash
# Downloads the latest version of Chromium.
remove_working_dir()
{
rm -rf "${WORKING_DIR}"
exit 0
}
USER_DIR=$(dscl . -read /Users/$(whoami) NFSHomeDirectory | awk '{ print $2 }')
USER_APP_DIR="${USER_DIR}/Applications"
CHROMIUM_DIR="${USER_APP_DIR}/Chromium.app"
LATEST_URL="http://build.chromium.org/buildbot/snapshots/sub-rel-mac/LATEST"
TMP_DIR="/private/tmp"
WORKING_DIR="${TMP_DIR}/.chromium_launchd"
URL_BEGIN="http://build.chromium.org/buildbot/snapshots/sub-rel-mac"
if [ ! -d "${CHROMIUM_DIR}" ]; then
mkdir -p "${CHROMIUM_DIR}"
fi
INSTALLED_VERSION="$(defaults read "${CHROMIUM_DIR}/Contents/Info" SVNRevision)"
VERSION=$(curl "${LATEST_URL}")
if [ "${VERSION}" != "${INSTALLED_VERSION}" ]; then
logger Installed Chromium version \(${INSTALLED_VERSION}\) does not equal \
latest version \(${VERSION}\), updating now...
mkdir "${WORKING_DIR}" || exit 1
trap remove_working_dir 1 2 3 6 15
cd "${WORKING_DIR}" || exit 1
curl -O "${URL_BEGIN}/${VERSION}/chrome-mac.zip"
unzip chrome-mac.zip
rsync -HavP --exclude="Contents/MacOS/chrome_debug.log" \
"${WORKING_DIR}/chrome-mac/Chromium.app/" "${CHROMIUM_DIR}/"
if [ "$(ps -aef | grep -i chromium | grep -v grep)" != "" ]; then
open "${USER_DIR}/Library/Scripts/Chromium Update Dialog.app"
fi
logger "Chromium update complete. Version ${VERSION} installed."
remove_working_dir
else
logger Installed Chromium version \(${INSTALLED_VERSION}\) is up-to-date. \
No action needed.
fi
exit 0
Next, I have a property list named ~/Library/LaunchAgents/com.slaunchaman.chromium.plist:
<?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>Label</key>
<string>com.slaunchaman.chromium</string>
<key>Program</key>
<string>/Users/slauncha/bin/chromiupdate</string>
<key>KeepAlive</key>
<false/>
<key>StartInterval</key>
<integer>3600</integer>
<key>RunAtLoad</key>
<true/>
<key>StandardOutPath</key>
<string>/dev/null</string>
<key>StandardErrorPath</key>
<string>/dev/null</string>
</dict>
</plist>
Finally, I have an AppleScript at ~/Library/Scripts/Chromium Update Dialog.app:
display dialog "Chromium was just updated. You should restart it."
The LaunchAgent runs once an hour, checking to see if the installed version of Chromium is older than the latest snapshot. If so, it downloads it and uses rsync to copy the changes. The script places Chromium in ~/Applications, but it shouldn’t be hard to modify to put it into /Applications.
Take Me Home 1.0.1 Rejected
Apple rejected Take Me Home 1.0.1 for a small issue, so I’ll have to hurry up and finish 1.1 to get that issue fixed. Rest assured it’s being worked on.
Computers are Disgusting
I recently wrote a script to automatically install firmware updates for our Macs. The problem with them is that for some, you have to hold down the power button to finish the installation after the machine has turned itself off. Now I don’t know about you, but I sure as hell don’t want to go around to 900 or so Macs and hold down their power button after installing an update. This script, while it can’t hold down the button for me, does allow student staff to automate the proces up to that point. I don’t have to give them a password they could use to break the system, they can do the update for me, everybody wins. It’s a beautiful system.
Well, today, I was testing the script out. The problem with testing it is that you can only test a given computer once; once the firmware update is installed, it won’t show up as needing to be installed anymore. So, I packed up my stuff and went to our biggest computer lab to do some testing. My test subjects were some “CyberStations,” computers we have with basic web-browsing and e-mail loadsets. They’re relatively unused during the summer, so if I broke any it wouldn’t be a big deal. I went up to one, ran the update, and waited. That’s when smoke came out of the back of the computer as the update ran. Oh shit, I thought, this thing is on fire!
Let’s go back a minute to my description of CyberStations. Their loadset consists of a vanilla Mac OS X Leopard install with some applications taken out, Firefox, Thunderbird, and Adium. Basically, it has the Apple-provided web browser, e-mail client, and IM program, as well as the leading open-source alternative for each. Nothing on these computers is too taxing. As a consequence, the fans never need to run too heavily, as the computer never really gets too hot.
Back to the smoking machine. I was sure it was on fire—where there’s smoke, there’s fire, right? Well, the student employee to whom I was demonstrating the script wasn’t too sure. He placed his hand on the back of the computer (an iMac G5, not that it matters) and didn’t feel any heat. So, if it wasn’t smoke, what was it? That’s when I realized what had happened. The fans, never having been run too hard, hadn’t been blowing a whole lot of dust around. When they ran full speed during the firmware update, dust had come flying out of the computer’s vents. A white, puffy cloud composed largely of the dead skin cells that had fallen off of our users’ skin for years. It was coming out of the bottom, out of the back, and even where the screen met the case. I quickly held my breath and stepped back.
I’m really glad that we have student staff to do the rest of this.
How to Move Your Blog from WordPress.com to DreamHost (Or Other Hosting Companies)
WordPress.com is, don’t get me wrong, a great service. They offer no-hassle blog hosting for free using WordPress, my blogging platform of choice. At a certain point in a young blogger’s life, however, it’s time to move on to using WordPress’ more advanced features; uploading new themes, hand-editing theme components, and maybe even throwing Google AdSense on there. WordPress is always free from WordPress.org, is easy to set up, and very easy to customize and administer. So, with a little help from blog-well, I was ready to go. This blog post is a derivation of blog-well’s work (click that link over there to see it), but I’ll be focusing on DreamHost where they focused on GoDaddy.
- Step 1: Obtain Hosting.
Obviously the first step here is to sign up for a hosting account. DreamHost’s process is simple enough that I won’t bore you with instructions. - Step 2: Tell DNS to point to WordPress.com
Now we have to tell your blog’s DNS servers to point to WordPress.com, where your blog is currently. This step might seem counterintuitive—after all, we’re trying to point WordPress.com to your blog, not the other way around—but this is how you let WordPress know that you’re in control of your domain. Assuming that you want your blog at blog.yourdomain.com, you need to make a “CNAME” entry as follows:blog 14400 IN CNAME yourblog.wordpress.com
Once that change propagates (which can take anywhere from a few minutes to a few hours, and you may need to reboot your computer), visitors to blog.yourdomain.com will be redirected to yourblog.wordpress.com. For DreamHost, follow these pictures:
- Step 3: Sign Up for WordPress.com Domain Forwarding
This part, unfortunately, costs a little bit of money—$10 per year. When you’re logged in to WordPress.com and at your dashboard, click “Upgrades” and then “Domains.” Enter your new domain in the field once you’ve paid for 10 credits and you’ll see it appear on the domain screen. - Step 4: Tell WordPress.com to Point to Your Domain
- In the “Domains” view on your WordPress.com dashboard, click “put blog here” next to your domain. This tells WordPress to take all traffic sent to yourblog.wordpress.com to blog.yourdomain.com or whatever you want. The end result should look like this:
- Step 5: Re-do Your Custom Domain
Go into your domain’s DNS settings again and delete the CNAME entry you made earlier. Now you’re all set to go! If you’re using DreamHost, you can do the easy install of WordPress to have it automatically updated to the latest version and the database automatically created for you.