• /usr/include/netinet/ip.h
• /usr/include/netinet/in_systm.h
• /usr/include/netinet/ip_icmp.h
• /usr/include/netinet/ip_var.h

So here’s a quick Bash script that links the relevant files to your iPhone OS and iPhone Simulator SDKs:

for path in /Developer/Platforms/iPhone*/Developer/SDKs/*; do
    for file in /usr/include/netinet/ip.h \
                /usr/include/netinet/in_systm.h \
                /usr/include/netinet/ip_icmp.h \
                /usr/include/netinet/ip_var.h; do
        if [ ! -f "${path}${file}" ]; then
            sudo ln "${file}" "${path}${file}"
        fi;
    done;
done

I’ve spoken to an Apple engineer and confirmed that this is the best way to do it, as well as filed a bug, which I encourage you to do as well if this annoys you.

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.

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.

After all of these updates, the script now takes a desired width and moves applications that support AppleScript such that they range horizontally to your desired width, centered on the screen, and stretching from the bottom of the menu bar to the top of the Dock.  In the future, I’d like to make a separate application, perhaps AppleScript-based, that will allow for user customization of how the windows are arranged, allow for custom application settings, and perhaps Spaces integration.

tell application "Finder"
	set screen_resolution to bounds of window of desktop
	set screen_width to item 3 of screen_resolution
	set screen_height to item 4 of screen_resolution
end tell

tell application "System Events" to tell process "Dock"
	set dock_dimensions to size in list 1
	set dock_height to item 2 of dock_dimensions
end tell

set desired_width to 1400

set side_space to screen_width - desired_width
set left_bound to (side_space / 2)
set right_bound to left_bound + desired_width
set bottom_bound to screen_height - dock_height
set top_bound to 22 (* for the menu bar *)

try
	tell application "iTunes"
		activate
		set the bounds of the first window to {left_bound, top_bound, right_bound, bottom_bound}
	end tell
end try

try
	tell application "Firefox"
		activate
		set the bounds of the first window to {left_bound, top_bound, right_bound, bottom_bound}
	end tell
end try

try
	tell application "Mail"
		activate
		set the bounds of the first window to {left_bound, top_bound, right_bound, bottom_bound}
	end tell
end try

try
	tell application "Vienna"
		activate
		set the bounds of the first window to {left_bound, top_bound, right_bound, bottom_bound}
	end tell
end try

With that in place, I saved it as an application in ~/Applications, and put it in my Dock. Now, whenever I change resolutions, I just click the button and everything is how I like it.

To change the script, you should be able to add any application with an AppleScript dictionary that supports moving and sizing the window.  The numbers I’ve used make the windows 1,400px wide, and the height that you want will depend on the size of your Dock. The script moves windows to the center, desired_width wide, and from the menubar to the Dock.

Note: I have had some trouble recently; sometimes when I change my resolution the AppleScript doesn’t pick it up.  To combat this, I told the Displays System Preferences pane to keep its icon in the menu bar; when my script uses the incorrect resolution, I change my screen resolution then change it back, which is enough for the script to detect the change.

Update 2008-05-28: Made some usability changes. Details here.