This insert-at-the-end behaviour can be disabled by unchecking an option in the Edit/Attachments menu:

Unfortunately, the option always reverts to being checked again for subsequent emails, with no obvious way to disable this behaviour permanently.  As it turns out, the solution is simple:

If you disable this option while editing an email, it will remain disabled for that message only. If you disable this option from the main window, it will remain disabled for all future messages.

Tangentially, the option to “Send Windows-Friendly Attachments” can only be toggled when you are not editing an email.  When you have a message screen open, the option is greyed out.

These options seem like perfect candidates for Mail’s Preferences menu.  Why they exist solely as menu options and why they behave this way remains a mystery to me.

You can tell nginx to run worker processes under different credentials by setting the user directive in nginx.conf.

On OS X, you need to specify a valid group as well, since nginx will default to looking for a group that doesn’t exist. You will see “nginx – getgrnam()” in the error log when this happens. The easiest solution I found is to assign the OS X staff group:

user userid staff

It probably bears mentioning that changing the runtime credentials won’t negate the need for sudo if you run your web server on port 80, since OS X (and all Unixes) will not allow nginx to use that port unless it runs as root.

Adding spacer tiles is relatively simple:

1. Launch Terminal (from Applications/Utilities).
2. Cut and paste the following into the command line, once for each tile you want to add.  (Need 4 tiles?  Run it 4x.)
   defaults write com.apple.dock persistent-apps -array-add '{tile-data={}; tile-type="spacer-tile";}'
3. Restart the dock:
   killall Dock

Spacer tiles behave like normal application icons: they can be dragged into any position, or dragged out of the dock completely to remove them.

The workaround I chose takes advantage of existing muscle memory.  I had already configured an alias for exit, allowing me to type x to end a console session.

To solve the Terminal app problem, I repurposed x as a function in my ~/.bash_profile:
function x {
[ "$(w -h | grep "^$(whoami) *s[^ ]* *-"|wc -l)" -le 1 ] && osascript -e 'tell application "Terminal" to quit' || exit
}
The function checks for the number of active console sessions. When x is called and only one session remains, osascript is invoked to quit the Terminal app completely.

The wireless connection would disconnect when I unplugged my laptop or woke it up when not directly connected to power. Attempting to disable and re-enable the wireless interface did not fix it. Even unloading and reloading the driver modules did not fix it. The only fix was to reboot.

The following two things are both required to fix wireless issues with the rt2860sta driver.

First, Ubuntu was loading unnecessary drivers for my wireless card. I addressed this by adding the following lines to: /etc/modprobe.d/blacklist.conf

blacklist rt2800pci
blacklist rt2800lib
blacklist rt2x00usb
blacklist rt2x00pci
blacklist rt2x00lib
It seems that these additional modules were interfering with the rt2860sta driver during wake up.

In addition I needed to have Ubuntu to unload and reload my wireless driver before and after going to sleep. This is done putting the following line in /etc/pm/config.d/unload_wireless
SUSPEND_MODULES="rt2860sta"

Note that the file name there is not actually important. The line just needs to be in a file in the /etc/pm/config.d/ directory.

Rebooting once after making these changes has solved the problem.

When running the start.bat script or lord.exe it would fail with this error:
# Firing Up LORD.OVR
# Using EMS for faster overlay swapping.
Internal error #38019
Cannot continue.

I did few preliminary searches for these errors on Google and finding only complaints about them. I contacted Gameport which currently distributes the game and they pointed me to an obscure link on the authors website which has a patch for this bug.

The url to the patch for this issue is: http://lord.lordlegacy.com/dosemu/

There is also single forum posting on the authors site about this issue as well but it lacks useful keywords to make it findable. That forum posting is here: http://lord.lordlegacy.com/phorum/read.php?5,196

There is nothing unusual about this; Facebook is merely playing by their own rules. But there is an interesting side effect.

Facebook is a social platform, so all application pages allow you to list other friends using that app. Facebook for iPhone, the Facebook counterpart for the iPhone app, is no different.

These are all your Facebook friends who use (or once used)…

• iPhone
• BlackBerry
• Palm
• SonyEricsson
• INQ

It is worth noting that the Facebook for iPhone app remains in your profile until you explicitly remove it, so results may be misleading.  (After all, how would Facebook know that your iPhone fell into the toilet, when you may simply not have run their app for a long time?)

If any of this bothers you, breathe deeply… then get off the internet.

And my lawn.

cat ~/ confidential_information.txt | pbcopy
pbpaste > confidential_information.txt

The pbcopy/pbpaste manpages have more detailed information about their use.

An interesting footnote to OS X’s clipboard system is that there are actually four pasteboards, each assigned to its own, unique purpose. The Find clipboard is particularly useful because it enables search queries to be saved automatically between applications. To test this, enter a string in (for example) Firefox’s search box. Don’t copy it to the clipboard. Now open your text editor and start a new search. The same string should already be in the dialog box…

Parsa Fatehi kindly points out below that Google now has a simpler solution:
http://www.google.com/support/installer/bin/answer.py?answer=100386

As many have noted, recent Google software releases for OS X now include Google Software Update, a background daemon that checks for and installs updates to Google software with no user intervention and no option for disabling it.

In theory, GSU is removed automatically when the last Google software to utilise it is uninstalled from your computer… but this assumes that you use the uninstallers bundled by Google, and don’t attempt to remove the software by hand.

I’ll save my disappointment for another editorial.
Instead, here is a workaround:
sudo rm /Library/LaunchAgents/com.google.keystone.agent.plist
sudo rm /Library/LaunchDaemons/com.google.keystone.daemon.plist
sudo rm /Library/LaunchDaemons/com.google.keystone.daemon4.plist


sudo touch /Library/LaunchAgents/com.google.keystone.agent.plist
sudo touch /Library/LaunchDaemons/com.google.keystone.daemon.plist
sudo touch /Library/LaunchDaemons/com.google.keystone.daemon4.plist


sudo chmod 000 /Library/LaunchAgents/com.google.keystone.agent.plist
sudo chmod 000 /Library/LaunchDaemons/com.google.keystone.daemon.plist
sudo chmod 000 /Library/LaunchDaemons/com.google.keystone.daemon4.plist


This hint does not uninstall GSU – it only “disables” the launchd entries that would run GoogleSoftwareUpdateAgent.app at boot time.

We first remove each entry (sudo rm …) and create empty files (sudo touch …) in their place.  We then change their POSIX permissions (sudo chmod) to deny any access to these files (000) for all accounts except root.

Creating inaccessible dummy files is important.  Without them, the launchd entries can simply be replaced whenever Google software is run.  But with these steps taken, no Google app can reinstall the GSU launchd entries, unless they:

• ask for your username and password (to authenticate as root),
• use different filenames, or
• create local launchd entries (~/Library/Launch[…])

This hint is easily adapted for each of these cases. You can also use this technique to remove GSU completely.