fixes

iPhone 3GS or 3G (software unlocked by redsn0w/ultrasn0w & similar) going from full signal strength bars to 1 bar to no bars, both 3G signal and wifi, to SEARCHING… to NO SERVICE, back to full bar signal strength, repeatedly, randomly especially with location services / GPS running (mouse pointer arrow visible in top right of iPhone screen) is because you’re using version 6.15.00 modem firmware (commonly called a baseband or BB) on your iPhone 3G/3GS.

Downgrade iPhone modem firmware to 05.13.04 to fix searching/no signal iPhone 3GS problems using redsn0w version 0.9.14b2 for OS X or Windows. Instructions and downloads are available from iPhone Dev Team:

- basic instructions on using redsn0w to downgrade modem firmware from 06.15.00 to 05.13.04

- updated instructions with 0.9.14b2 version of redsn0w.

6.15.00 modem firmware used for software unlocks of iPhones is meant for iPad, not iPhone. (Find your iPhone 3GS / 3G modem firmware version in Settings –> General –> About –> Modem Firmware (near bottom).  Format is MM.mm.pp.

From my little experience with jailbreaking & software phone carrier unlock iPhones, using iPad modem software on an iPhone 3GS / 3G is not a good solution.  Sure, your iPhone 3GS / 3G is unlocked, but your iPhone is barely operational, constantly dropping and searching for wireless signals during which the iPhone is useless especially when GPS / location services functions are running.

Update Feb 6, 2013: See Lior’s comment/fix to Bootcamp Assistant not giving the option to make your USB drive into a Windows installation bootable drive.

Here’s my solution to the ”Installer disc could not be found” problem when installing Windows on a Macbook Pro Retina with Bootcamp using Bootcamp Assistant.  At the Install step, after sizing partitions for the Macintosh HD drive, Bootcamp Assistant will return an error :

Bootcamp Assistant 4 is a step-by-step program on Mac’s (available in “Other” programs group, same group where you find Disk Utility, visible below) that will guide you through setup of dual boot Windows and Mac OS X on your Macbook/iMac/Mac Pro.  Bootcamp Assistant can create a bootable Windows installer USB key from your Windows 7 ISO image file (download official Windows 7 ISO images) or use your Windows install DVD if you have bought one, but Bootcamp Assistant sometimes can’t recognize the USB key as being a bootable “Installer disc” when the Partitioning step of Bootcamp Assistant is reached.

The solution: use Disk Utility to partition Mountain Lion’s hard disk, then restart holding alt/Option key and choosing the Windows USB key install image as the drive to boot from.

Finding Disk Utility on Mac OS X Mountain Lion:

Start Launchpad, click on Other and find Disk Utility.

Launch Disk Utility.  You’ll see something similar

Select the top most drive, which should be your 251 GB or 502 GB APPLE SSD.

On the right you’ll see 5 tab buttons: First Aid | Erase | Partition | RAID | Restore.

Choose Partition. Then click the + button below left of the rectangle.  This adds another partition to the rectangle, separating the top and bottom with a bar.  Drag this bar up and down to resize your OS X Mountain Lion partition (space on the drive dedicated to Mac) and the BOOTCAMP partition that you will create to hold Microsoft Windows.  I went with about 60GB.

Change the Name to BOOTCAMP or something that helps you remember this is your Windows partition.

Change the Format to MS-DOS (FAT).  This will be reformatted during Windows installation to NTFS.  Click Apply to save the changes and then reboot your Mac and we’ll begin Windows installation.

During reboot, you’ll hear the startup “Chime”.  Press and hold the alt/Option key and you’ll be presented with drives to boot from.  Use the arrow keys and return button to select the Windows yellow USB key drive containing your Windows 7 installation files. This will begin the Windows install.

First screen where you’ll need to make selections is the drive selection of where to install Windows 7. Select the BOOTCAMP partition you created in Disk Utility.

Click Drive options (advanced).  This will reveal the Format option, which you’ll need to use in order to reformat the partition for use by Windows 7 (formatting the partition to NTFS).

Follow the rest of the Windows installation steps and stay at your Mac during the process.  Windows will need to reboot several times during the installation process and you’ll need to be ready to press/hold the alt/Option key during the Mac boot-up chime so you can select the BOOTCAMP partition to boot up into to continue the installation process.

Once the install is complete and you’ve booted into Windows 7, don’t forget to install WindowsSupport files that were put onto your Windows 7 installation USB key.

These support files adjust the resolution and keyboard/trackpad for best usability.

Enjoy your Bootcamped Macbook Pro Retina with OS X Mountain Lion and Windows 7!

Lior’s solution to no-bootup option for your USB drive Windows installation disk in Bootcamp Assistant (thanks Lior!):

If you have only 2 options in the boot camp assistant, or if bootcamp doesn’t recognize the windows installer disk when its on a bootable usb, it’s because bootcamp doesn’t recognize your macbook as a model that should install windows from a USB, its actually quite easy to fix, just follow these simple steps:

1. go to Applications>Utilities> right click on boot camp and click Show Package Conents, you’ll find a folder inside called Contents (If i remember correctly, not on my Macbook atm). Inside that folder exists a file called info.plist.
2. Right click on the folder containing the file > get info > change permissions so any user can read & write. Do the same for the file itself (right click > get info…).
3. Right click on info.plist and choose Open with > Text Edit.
4. at the end of the document theres a list of strings that contain different versions of Mac computers, the list is titled something like: “USB boot Versions”, add your Mac’s version to the string list ( MB40 ) if your version is Macbook 4,1 (you can see this by clicking on the System information App in the Utilities folder).
5. save the file and change back the permissions on the file and folder.

Now open boot camp and you should see the option to create a Windows 7 installler on a USB, and also bootcamp will look for a windows installation on any USB’s after you partition the hard drive.

Firefox stops loading pages after several hours or days of continuous use.The problem often starts with only some page loading errors: stylesheets not being applied (ugly white pages with no images), buttons not working, forms not submitting, etc., then quickly gets worse until Firefox is completely unusable and often cannot be restarted.

Sound familiar?

The problem has to do with Adobe Flash Player.

Symptoms

Common symptoms of the Firefox loading problem:

• web page buttons in Firefox stop working (clicking doesn’t do anything)
• links stop working (clicking links produces no action)
• parts of web pages stop loading in Firefox (or Camino)
• stylesheets stop being rendered or applied, which make pages show up with:
  • a plain white background web page,
  • 1994-style bright blue links,
  • plain times new roman font text,
  • simple bulleted lists,
  • borders on table cells.
• new tabs or windows show up completely blank
• Firefox won’t quit or shutdown

When Firefox stops loading pages properly, the problem begins with subtlety, then the situation degrades quickly until Firefox is completely unusable.  Previously, the only solution was to restart Firefox, killing the Firefox process (using Activity Monitor - Quit Process) if Firefox wouldn’t shutdown properly.

This solution was only a temporary fix with the root Firefox page load problem still there.  Clearing the cache in Firefox, then restarting, also seemed to help reset the loading problem on Firefox, up until it starts again after several hours or days of web surfing.

Fixing “Firefox Stops Loading Pages” Problem

A permanent fix to this Firefox loading problem: upgrade Adobe Flash Player to version 10 from version 9.  Strangely, Mozilla/Firefox nor Mac OS X Leopard never recommended this update, even when Adobe published version 10 of Flash Player, wheres Firefox 3 comes by default with Flash Player 9, and actually, still does.  Perhaps Mozilla considers Flash Player a system component, rather than a browser component and doesn’t notify Firefox users of updates to such pieces of software.  This seems a bit odd to me, considering the only time I use Flash Player… is with web browsers, regardless of whether its Firefox, Safari, or Camino.

Step 1: Check your version of Adobe Shockwave/Flash in Firefox

Open a new Firefox tab or window.

In the address bar type in about:plugins and hit enter.

This will load a special Firefox configuration page showing you all the plugins installed for use with your version of Firefox.

Scroll down to the bottom until you see a heading for Shockwave Flash.

The key piece of information in this section is just above the blue bar where it reads: Shockwave Flash 9.0 r115

This tells me that I’m running Adobe Flash player version 9 and what I need to do is upgrade to Flash version 10.

Update: Another way to check which version of Flash Player you have installed is to visit Adobe Flash - About page, which will tell you your currently installed Shockwave Flash version (bottom right hand corner in the Version Information box.)

Step 2: Download & Install Adobe Flash 10

In Firefox (or any browser) go to http://get.adobe.com/flashplayer/. You’ll see this page:

Click on the big bright Agree and Install Now button.  Let Adobe install Flash 10 on your computer.

After the install is complete, we can check that Flash 10 has been installed.  Restart Firefox and again visit the about:plugins configuration web page.  You should now see the following:

Congratulations. You’ve upgraded to Flash 10. Firefox should now be able to load web pages continually, without restarting/cache clearing, no matter how long you keep Firefox open and running.

I’ve been running with Firefox 3.0.2 on Mac OS X 10.5.2 Leopard with Adobe Flash 10 for nearly a month now and Firefox hasn’t stopped loading pages once after having upgraded to the new version of Flash Player.  I’m confident this is a permanent fix for those who’ve been running Firefox with Flash 9 and have been troubled by the eventual page load problem.

(I want to thank unsound of the Mozillazine Forums for pointing me in the right direction with this problem.)

Our brand new iPod Touch 16GB version 2 arrived today.  First problem: can’t connect to wifi router (Wanadoo/Orange). Our wireless password was not accepted.  After entering the wifi password multiple times we discovered that the wireless password on the iPod is case sensitive (capital letters vs. small letters makes a difference).

Entering the WEP/WPA wireless key into the iPod touch in all upper case letters solved the wireless password problem.  And I’ve heard to not use the Caps Lock key to do this, rather, just use the Shift key (requires it to be pressed each time while tapping a letter or number).  This doesn’t make logical sense to me (Shift key vs.Caps Lock for upper case letters), so feel free to give Caps Lock a try first.

On web pages with accented characters, such as on French language websites, Firefox 3 may show a diamond question mark symbol instead of the accented character.

To fix this character set display problem in Firefox 3, change the Character Encoding under the Menu -> View -> Character Encoding from Unicode to Western ISO-8859-1 if you’re reading Western European language based web pages.

When connecting to a remote mysql server, the login/user must have rights to connect to the mysql server from outside of the local server, i.e. localhost. You need to edit the user record within the mysql.user table or add a new record for this user, giving it access to connect to the mysql server from a host other than localhost.

Login to the mysql server add run the following command:
grant all privileges on *.* to 'user'@'192.168.25.1' identified by 'password' with GRANT OPTION;
Replace “user” and “password” and “192.168.25.1″ with your mysql username, password, and the IP address of your computer that you’re connecting (to the mysql server) from.

Remember that your mysql server must also allow connections from remote hosts.

By default mysql does not allow connects to itself from any host besides localhost, for security reasons.

When you get an error “Can’t connect to mysql server on [remote server]” when trying to connect to the remote SQL server via the mysql command line tool, log into the server running the mysql server and edit the /etc/mysql/my.cnf config file.

In particular, comment out the following line:
bind-address           = 127.0.0.1
This allows for connections from any host.

Next, update the mysql user to allow it access from a host other than ‘localhost’.

Using keyword tag searching in Firefox 3 is broken and not working with OpenDNS.  Keyword tag searching, i.e. typing the letter G for Google in the address bar, then typing the search words or terms, then hitting enter, should do a google search.  If you’re using OpenDNS, Firefox 3’s keyword tag searching in the address bar gets hijacked by OpenDNS, returning OpenDNS results instead of Google search results.

To fix this, go into Firefox’s hidden configuration page by typing into the address bar “about:config”.

A warning will come up.  Just click “I’ll be careful, I promise”.

Then filter the items you’re shown by typing “keyword”.

Double click on the Value for Keyword.URL and replace the value with the following (without quotes) “http://www.google.com/search?q=”

Click OK.

Try doing a keyword tag address bar search in Firefox: “g peanut butter”. Hopefully you’ll get something like this:

You may have to quit and restart Firefox to have this change take effect.

Can’t empty the trash bin because some files are locked? “Operation not permitted” when moving files? Try unlocking the files first in Finder.

Open Finder. Highlight the files in question. Right click on the files and select Get Info. Uncheck the Locked checkbox.

Continue deleting or moving the files as you please.

Symptoms

• AirPort wireless connection randomly stops working, even though signal strength to base station is good.
• Wireless connection strength drops, clicking on AirPort starts scanning, wireless strength returns to full, but Internet connection is lost.
• Can’t create wireless connection to DLink DIR-625 wireless router after upgrading to 10.5.2.

Possible Causes

• AirPort attempts to connect to stronger “Recent networks” listed in preferences file /Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist
• Apple has updated its AirPort wireless connectivity to a more recent draft of the “wireless n” proposed standard. This is a faster version of wifi than the previous 802.11 wireless g, b, and a standards. (References: Wikipedia 802.11, Discussions at Apple.com).
• [Added 080618]: AirPort is finding neighboring wireless router base stations on the current wifi channel and is attempting to connect to them. (References: Gedblog, TUAW.com)
• [Added 080824]: AirPort attempts to connect to based stations listed in “Preferred networks”, listed in System Preferences => Network => Advanced => AirPort => Preferred Networks. See the fix for AirPort Preferred Networks problem.
• [Added 090105]: Real Player Downloader.  Mechanics of problem unknown. See comment below by Jerry Zakariasen.

Diagnostics

• [Added 080618]: AP Grapher reports on nearby wireless internet base station signals. This is useful in determining if you’re having interference or competing wireless access point problems. If this is the case you can try changing wireless channels on your router.
• [Added 080618]: iStumbler is another wireless base station search tool similar to AP Grapher that you may find more to your liking.

Fixes/Solutions/Workarounds

Please, before implementing any of these fixes, try them one at a time and wait to see if there is any improvement in the situation before trying the next. Keep track of which fixes you have tried and report back when one of them (or none of them) in particular solved your problem so that we know which solutions are useful and which are less likely to help, thus moving forward in our knowledge of how to diagnose and fix wireless dropouts on Apple AirPort connections. Many thanks. ~ Ben.

• Backup /Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist file, then delete it. Reboot. Leopard will create a new AirPort preferences file with a single entry with your current wireless base station.
• For D-Link DIR-625 wireless router (from discussions.apple.com):
  1. Within Setup => Advanced => Advanced Wireless, change RTS Threshold to 2306
  2. Change Fragmentation Threshold to 2306
  3. Use “Mixed 802.11n, 802.11g, and 802.11b” within Setup => Wireless Settings
• [Added 080618]: Change wireless channel on your wifi router (e.g. AirPort Extreme base station, NetGear, Linksys) from 6 (the default) to anything from 1-4 or 8 to 11. Please refer to your router’s instruction manual on how to do this. The reason for avoiding channels 5 and 7 is that wifi routers by design will automatically switch to one channel above or below their current channel when wifi signal noise passes a certain value. Thus, if you were having problems on channel 6, your router and AirPort have already tried channels 5 and 7 and you’re still experiencing problems.
• [Added 080618]: If possible, use the 5Ghz transmission frequency/band for your wireless router. Most wireless devices (nearly all wireless routers and cordless telephones) in homes use the 2.4Ghz transmission band. Avoiding this band will result in much less radio noise. Again, this is a setting on your wireless access point rather than on your Mac. Please refer to your wireless base station’s instructions on how to change radio frequency (if possible).
• [Added 080618]: Keychain Access is an Apple program that saves passwords to websites, to your Mac itself, to wireless base stations, etc. The keychain entries related to wireless base stations is a potential cause of wireless drops in Leopard 10.5.2 with the theory being that Keychain Access was modified in this release, breaking (somewhat) keychain items created in older versions (10.5.1 and prior). Deleting and recreating the keys in 10.5.2 and beyond may resolve this issue if you are affected.Launch Keychain Access within Finder: Applications => Utilities => Keychain Access. On the top left, select System, underneath login. Find the name of your wireless base station or router, often called an SSID in networking terms. For me it’s WANADOO-D310. Under the Kind column it should read AirPort network password. You may find multiple keychain entries for wireless base stations you’ve used in the past. We want to delete them all, but before doing that, save their passwords. You do this by right clicking on the item, for me WANADOO-D310, and choosing Copy Password to Clipboard. If you are asked to allow access to this item by kcproxy, click Allow.
  Then create a new text file somewhere on your mac and paste the password that’s been copied to your clipboard. This will make it easier when you have to reconnect to this base station. You might want to note which base station/wireless router this password is related to while doing this. I did this by simply writing the name of the wireless router beside the password. After backing up the passwords, delete all the keychain items of kind AirPort network password. Now turn off the AirPort connection by clicking on the AirPort menu bar icon (looks like the image at the top of this post) and selecting Turn AirPort Off. Open System Preferences => Network. You’ll notice that Network Name select list will no longer have your base station listed. Click Turn AirPort On. AirPort will search for wireless networks (takes about 30 seconds) and will eventually pop up with a window saying None of your preferred networks are available, but you should see your wireless base station listed as one of the networks.
  Select your network and click Join. You’ll be asked for your password. Hopefully you remembered to save that password somewhere and can simply copy and paste it back in. (Use right click => Paste rather than Apple Key + V, which won’t work for this password field). After this you should be reconnected to your wifi base station. If you return to your Keychain Access window, you should once again see your base station listed with the System Keychains. You can close the Keychain Access and Network preferences pane windows. If you have multiple wireless networks that you use often, you’ll have to search and reconnect to them with the passwords you’ve saved. Hopefully the recreated keychain items will keep you connected.
• [Added 080624]: Remove Preferred Networks. From within System Preferences => Network => Advanced => AirPort, using the minus button, remove all preferred networks except for the current wireless access point you’re connected to.
  
• [Added 090105]: Remove Real Player Downloader. Jerry Zakariasen mentions in the comments below that uninstalling Real Player Downloader for Mac has fixed wireless network drops on his mac.  See his comment below for more details. Thanks Jerry.

Background

Just after upgrading to 10.5.2 I noticed that once in a while my AirPort wireless connection would drop to 2 or 3 bars, then return to full signal strength, but I couldn’t access the Internet after that. There didn’t seem to be any pattern to these dropouts of wireless connection. No interference from neighboring base stations either. Yet everything was ultra stable with 10.5 and the only change I made was upgrading (finally) to 10.5.2.

After doing some research, I had a theory that AirPort was searching through old wireless connections within /Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist constantly looking for a better signal. And whenever the current wireless connection suffered from minor transient interference (say cordless telephones), it would immediately try to connect to another base station or try to switch to a different channel. Have a look at your version of the airport preferences file by navigating to it in Finder, starting with Macintosh HD, then Library, Preferences, and finally within the SystemConfiguration folder. You can simply hit enter with the file highlighted to use Quick Look. You can also use Terminal to quickly print the file to the screen with the following command: cat /Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist

Once the AirPort control software in 10.5.2 set about trying to find a better wireless connection, it would never successfully get back your original wireless connection which was really fine. Hence, from time to time, you would see a slight drop in wireless signal strength, then after clicking on the AirPort wireless icon, it would scan for networks for a few seconds, then return to full strength, yet you would have already lost Internet access.

The fix is simple:

1. Drag the /Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist file to your desktop (as a backup),
2. Delete the file within SystemConfiguration,
3. Reboot and let Leopard create a new airport preferences file with only your current wireless connection listed within it.

With only one base station listed in “Recent Networks” within the file, AirPort won’t try scanning for other stronger networks and you’ll stay connected.

That’s the theory anyways. It’s worked for me so far. Hope it helps you too.

Leave a comment if you have questions or have tried the fix with success/failure.

How to fix Slow Web Browsing and Slow Internet in Leopard (10.5.x)

Symptoms

• Web pages load slowly in Safari or Firefox in Leopard.
• Web sites won’t load, only load partially, stop loading after a few hours.
• Slow DNS (domain name) lookup in Leopard. First load of web site is slow with “looking up domain” in browser status bar.
• Once website is loaded, browsing to that site is fast.
• AirPort wireless strength drops, then Internet connection is lost (see related post).
• Email programs are slow in connecting to servers.
• SSH sessions are slow to connect to remote servers.

Possible Causes of Slow Internet under Leopard

• Your ISP’s DNS servers are (sometimes) slow to respond due to high traffic.
• Firefox, Camino, Safari is requesting domain name lookups in IPv6 format (2001:db8::1428:57ab), but your DSL router/cable modem answers with IPv4 addresses (192.0.2.235) (references: mozillazine.org, mozilla.org bug, arstechnica.com). Safari may not be affected by this as WebKit is said to use IPv4 domain lookups first, then uses IPv6 if IPv4 fails.
• Your router, acting as a DNS Proxy, doesn’t recognize nor forward IPv6 domain name lookup requests.
• Leopard is now requesting SRV (service) records for domain name lookups. Your router does not recognize nor forward to SRV requests.
• Your ISP’s DNS servers don’t recognize or doesn’t respond to SRV queries or respond with NXDOMAIN.
• [Added 080618] Poor wireless router performance in general (references: entropy.ch). To test this, try connecting directly to your DSL router/modem if you are using an intermediate router such as an Apple AirPort Base Station, or NetGear/Linksys wireless router and seeing if web and internet speeds increase.

Fixes/Solutions/Workarounds

• Use better faster DNS servers, like OpenDNS.org (208.67.222.222, 208.67.220.220).
• Connect directly to DNS servers to avoid DNS forwarding through your router (acting as a DNS proxy).
• Turn off IPv6 DNS lookups in Firefox/Camino (references: mozilla.org).
• If DNS forwarding is required, change the DNS servers directly on the router.
• Update your router’s firmware (references: jungledisk.com, ubuntu.com) for better SRV and IPv6 handling and better performance overall.
• Below are detailed instructions on applying these fixes to slow dns lookups/slow Internet on Leopard

Details

After upgrading to Leopard, plenty of Mac OS X users have complained of “slow internet” when browsing the web, yet Windows PCs or Macs with Tiger (10.4) on the same network are much faster.

DNS Lookups

A domain name lookup or DNS lookup is done every time you visit a web page, say “apple.com”, as you’re actually visiting “17.149.160.49″. A DNS Resolver on your computer sends a request to a DNS Server that handles this lookup or translation from names (easy to remember) to numbers (hard to remember). Once your browser has this numerical IP address it can start loading the web pages at that server location.

Domain Name System Lookups in Leopard

With Leopard, a major change occurred in DNS lookups. Any program in Leopard that can use version 6 IP addresses (IPv6 explained below) will send out a new type of DNS lookup request - the SRV Record. In Tiger and previous OS X versions, DNS lookups were A record requests.

SRV records are new (sadly, 8 years old is new in the DNS world), provide more information than A records, but have terrible support in terms of hardware (your DSL router or cable modem) and DNS servers that answer with SRV information. For every SRV request that Leopard sends it must wait for a valid reply. If the request fails, Leopard must try again. If it fails again, Leopard will finally ask for an A record. This is one reason why Mac users are experiencing slow Internet on new Macs with Leopard or after upgrading to Leopard from Tiger.

Domain Name Lookup Chain

Diagnosing slow Internet problems under Leopard is difficult due to the many different slowdowns that can occur along the domain name lookup chain when connecting to the Internet in OS X. For an application like Firefox or Safari to find a domain name, this is roughly what happens:

1. Firefox/Safari is asked to load a web page at a domain name (example: “apple.com”).
2. Browser starts work on getting an IP address for that domain (a domain name lookup).
3. Browser checks for recently translated domain names in its own internal “cache” and thus already has the IP address.
4. If “apple.com” is not found in cache, Firefox/Safari then asks Directory Services (an OS X program that does DNS lookups) for the answer.
5. Directory Services (DS) searches for the domain in its own DS cache (view the DS cache using Terminal: dscacheutil -cachedump -entries).
6. If domain is not found in cache, DS checks flat (text) files such as /etc/hosts for the domain name (see the file using Terminal: cat /etc/hosts).
7. If domain is still not found then DS sends a domain name lookup request to the first DNS server listed for your AirPort wireless card or your Ethernet card (your network interfaces). The first (and usually only) DNS server is often your router (often listed as 192.168.1.1 in System Preferences => Network => Advanced => DNS tab).
8. If the router doesn’t recognize the name lookup request (SRV/IPv6), the request will be either ignored, returned without result, returned with error. If the router does recognize the DNS request, it checks its own DNS cache for a matching domain lookup.
9. If domain name is not found in cache, the router forwards the request to the ISP’s DNS server.
10. If the first ISP DNS server doesn’t respond or doesn’t have the record, the router sends a second lookup request to the next DNS server listed in its configuration. Continue until all DNS servers are exhausted.
11. When name lookup result is received by router, it saves the result to cache, then forwards the domain name record back to the requesting computer.
12. Directory Services on Leopard, receives the answer, places it in cache, then returns the results to the requesting application: your browser.
13. Firefox/Safari receives the DNS record, with IP address, stores it in cache, then starts to retrieve the web page at that location.

(Illustration by Lion Kimbro on Wikipedia - Domain Name Systems article)

Any one of the links in the chain can be a potential source of slow Internet speeds when browsing or retrieving mail, etc. The difficulty lies is finding out where the problem exists and how it can be fix. Compound this complexity with the number of different DSL routers in use in homes, the number of different firmware (software inside the router), number of different ISP DNS servers

Caches

Caches store recent domain name lookup results in order to save time when the domain is requested again. Each time a domain name lookup is made, caches are checked to see if the lookup has occurred recently and if so, use the cache result. If no result is found in cache, the domain name lookup has failed and the DNS lookup request continues down the chain. A domain lookup may fail all the way down the chain until it’s finally resolved with the second or third DNS server listed, taking maybe 15 seconds to finally succeed. But, once domain lookup has been successfully performed, this domain request “answer” is cached all the way back up the chain, for varying amounts of time. Browsers like Safari and Firefox normally cache domain name lookups for 1 minute (30 minutes if you’re Internet Explorer in Vista). Leopard’s Directory Services program caches lookups for one hour (3600 seconds) by default.

Once a successful domain lookup has occurred, web pages from the same site will load very quickly, since the domain and its IP address are known and cached in memory. When the cached domain lookup result expires, the vicious cycle of slow domain lookups restarts. This often leads to the confusing pattern of fast Internet / slow Internet performance that can be seen sporadically throughout a browsing session.

IPv6

IPv6, the new way of addressing all things on the Internet, is important and necessary as we’ll eventually run out of IPv4 addresses (like 17.149.160.49). But part of the issue with slow browsing and slow Internet on Leopard is the combination of how IPv6 is used in Mac OS X and the current state of DSL routers and cable modems.

Whenever a program on Leopard can use IPv6 addressing, such as Firefox, it will request IP addresses for domains in IPv6 and if that fails, Firefox will then try IPv4 domain lookups. The reason this adds to the slow Internet problem is that many routers and DSL or cable modems in peoples homes are not capable of handling/routing IPv6 domain name queries (properly). This can cause repeated, failed DNS queries in IPv6 format, with the requesting application eventually falling back to sending IPv4 domain lookup requests that are successfully answered. The unfortunate problem with this “IPv6 then IPv4″ order of domain lookups is users end up with delays of 5 to 10 seconds “looking up” a domain name, which is not a very long time to wait, but suffering short delays every time you visit a different website can be extremely frustrating.

SRV (Service Record) Requests

Part of the issue may be related to Apple’s decision to follow the Internet Engineering Task Force’s recommendation of using SRV queries instead of “A record” queries when looking up domain names in Leopard.

The problem with Leopard asking for SRV records from DNS servers is that many DNS servers still don’t recognize or respond to SRV type DNS requests, or respond with a non-existent domain (NXDOMAIN) error code. This is not exactly Apple’s fault for asking, it’s actually the fault of DNS server owners who are not updating their servers to the latest standards. Regardless, whenever a program like a web browser requests a DNS record and gets failed responses, or no response at all, the program retries its requests, but only after a certain delay. Each failed SRV request and subsequent retry adds time the user must wait before the browser or application eventually gives up on the SRV requests and tries an old-school basic A record request in an attempt to get the IP address of the domain name. And all DNS servers answer to A record requests, even the old dingy ones not following the latest IETF standards. You, the user, sees this request — no response — retry dance as the browser taking a long time “Looking up domain.com….”, often seen as such on the browser status bar at the bottom left hand corner of the window. Only when the browser or application has received a valid IP address from a domain lookup can it contact the web server and start to download the HTML and display the page.

Timeouts

The delay between lookup retries is important to prevent overloading DNS servers, DNS resolvers (like Directory Services on your Mac) and simply makes sense. It’s similar to walking up to someone’s house and knocking on the door: Normally you wait a few moments for a response before trying again. If you don’t wait, you don’t know whether no one’s home, or whether they’re just taking a few seconds to respond. Continued knocking doesn’t help you. (And perhaps will earn you a stern look if not make you the target of a hissy fit).

Hammering a DNS server with domain lookups without pause is not very productive since the DNS server will simply drop (not answer) requests that it cannot handle within a timely fashion, based on its current load and worse, may get you blocked from the DNS server.

Next we’ll see how we can solve or workaround the issues discussed above that could be slowing down Leopard’s Internet speed.

Solutions

• Direct DNS / Better DNS
• Disable IPv6 DNS Lookups
• Update DNS Servers on Router
• Update Router Firmware

Direct DNS / Better DNS

Update 080606: Leopard 10.5.3 may have changed the order in which DNS Servers are used.

Update 080606: DNS servers entered on a DHCP configured setup are used in reverse order. I.e. the last server entered is the first to be used. If you’ve manually configured a network location, DNS servers are used in the order that you’ve entered them/see them.

New 080606: If you wish to save your current network setup and have the option of returning to it easily, follow the instructions for Creating a New Network Location. Otherwise, follow the instructions immediately below to quickly add new DNS servers.

Add DNS servers to Current Network Configuration

This is the quickest & easiest way to use new DNS servers, which is to simply add them to the DNS tab found in System Preferences => Network => Advanced => click on DNS tab.

Click on the + sign at the bottom left hand corner near IPv6 or IPv6 addresses and type in the addresses of the DNS servers you wish, in reverse priority order. (Recommended: OpenDNS servers at 208.67.220.220 and 208.67.222.222). I.e. the server that you want to use first, enter it last. Afterwards, click Ok. Then in the Network pane, click Apply to make your changes active. If you’re using an AirPort wireless connection, wait a few moments for the connection to be re-established

Creating a New Network Location

The advantage of creating a new network location is the ease of which you can move back and forth between different network setups. By creating and using a new network location, you can always revert your changes by simply selecting your original (Automatic) network location from the Location drop down list.

In Leopard, open System Preferences => Network => click the Advanced button (bottom right corner)

Click TCP/IP tab (top left).
Write down on a piece of paper (or in TextEdit) the IPv4 Address, Subnet Mask (255.255.255.0), Router, and Configure IPv6 setting. Click Cancel.

Find the Location drop down at top of the Network preferences pane. Click it and choose Edit Locations.

Highlight “Automatic” if not already
Click the Gear icon on the bottom center, choose Duplicate Location

Choose a name, I used “Home”.
Change the Location drop down box by clicking on “Automatic” and then switch it to “Home” (or the name you chose in the last step)
You’ll see the following:

Select Airport on the left (or Ethernet if you’re not using a wireless connection).
Click Advanced at the bottom right.
Click on the TCP/IP tab-button.
Change the Configure IPv4 drop down box to “Manually”.
Here’s where you use the values you saved in Step 2. Fill out IPv4 address, subnet mask, router, configure IPv6 settings. Do not click OK, instead click on DNS near the top.
Click the + button, bottom left hand corner. This creates a blue outline under DNS Servers on the left half of this window.

Enter in the DNS server of your choice. I recommend OpenDNS at 208.67.222.222. (Don’t include a period at the end). Add a second OpenDNS server by clicking again on the + button and entering 208.67.220.220. These DNS servers will automatically redirect you to the closest / best server for you, regardless of whether you’re in France (like me) or in North America. Click OK. You should be returned to the Network preferences pane and see something like the following:

At this point you’ve created a new Location called “Home”, having setup AirPort or Ethernet with the correct settings and “Services” (i.e. DNS), but none of these changes have been made active. Let’s make a backup of the configuration file that will be updated before you apply your changes. In Finder, click on the hard disk icon at the top left corner (usually Macintosh HD), then navigate to this directory: /Library/Preferences/SystemConfiguration and find this file: preferences.plist. Simply copy the file to your Documents folder or to a spot of your choice. If you have to rollback the applied changes, you can copy this file back to the above location. If you’re using Time Machine, this file should be backed up already. Now you know where this file is, so replacing it with a Time Machine version should be straightforward.

Before we make our changes effective, we’re going to check how DNS requests are handled now, before the changes, and after to make sure we’ve changed our Network Settings properly.

Leave the Network window open as is and open up a Terminal window. We’re going to be using the tcpdump program to listen to DNS traffic between your computer and your DNS server.

Type this command and hit Enter: sudo tcpdump -i en1 -s 128 port 53

(If you’re using Ethernet with a cable, use en0 instead of en1, which is the AirPort wireless interface).

Supply your password when asked to do so.

You should see something like the following:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 96 bytes

tcpdump should now be running.

Open up another Terminal window and type the following command: curl http://www.csu.edu

This uses the curl program to read the web page located at www.csu.edu.

Going back to your tcpdump window you should see something similar to this:

00:31:37.026520 IP 192.168.1.132.56645 > WANADOO-D310.domain: 19279+ SRV? _http._tcp.www.csu.edu. (40)
00:31:37.029352 IP WANADOO-D310.domain > 192.168.1.132.56645: 19279* 0/0/0 (40)
00:31:37.029849 IP 192.168.1.132.56646 > WANADOO-D310.domain: 49549+ SRV? _http._tcp.www.csu.edu. (40)
00:31:37.032657 IP WANADOO-D310.domain > 192.168.1.132.56646: 49549* 0/0/0 (40)
00:31:37.034345 IP 192.168.1.132.56647 > WANADOO-D310.domain: 46004+ A? www.csu.edu. (29)
00:31:37.279043 IP WANADOO-D310.domain > 192.168.1.132.56647: 46004 1/0/0 A www.csu.edu (45)

Notice 192.168.1.132. That’s me, or really, my MacBook Pro’s AirPort wireless card. Then there’s a greater than sign (>) showing the direction of DNS traffic. WANADOO-D310 is my DNS server, which is actually the DSL modem/router, a.k.a. 192.168.1.1, which is passing domain name lookups to the real DNS servers at my Internet Service Provider (WANADOO, yeah I know goofy name). Remember the network settings we wrote down before starting all this? You’ll notice that the DNS server is 192.168.1.1.

OK, we’ve got a baseline of what our Mac is doing when looking up domain names, let’s apply our new network location “Home” that we created and see the difference.

Back on the Network preference pane, notice the Apply button on the bottom right hand corner. Once you apply your changes, your Mac will begin using the new Location you’ve created.

Take the plunge and click on Apply.

For AirPort wireless connections, you may have to click the Turn AirPort Off button, wait fifteen seconds, then click Turn AirPort On again in order for the new DNS settings to be used.

Going back to the Terminal window where we executed the curl command, and with our changes set, let’s execute another: curl http://www.unc.edu

Results will look like the following:

00:32:33.562589 IP 192.168.1.132.56663 > resolver1.opendns.com.domain: 39356+ SRV? _http._tcp.www.unc.edu. (40)
00:32:33.767237 IP resolver1.opendns.com.domain > 192.168.1.132.56663: 39356 NXDomain 0/0/0 (40)
00:32:33.767856 IP 192.168.1.132.56664 > resolver1.opendns.com.domain: 62833+ SRV? _http._tcp.www.unc.edu. (40)
00:32:33.809161 IP resolver1.opendns.com.domain > 192.168.1.132.56664: 62833 NXDomain 0/0/0 (40)
00:32:33.811130 IP 192.168.1.132.56665 > resolver1.opendns.com.domain: 45293+ A? www.unc.edu. (29)
00:32:33.853070 IP resolver1.opendns.com.domain > 192.168.1.132.56665: 45293 1/0/0 A www.unc.edu (45)

Notice what’s changed? WANADOO-D310.doman has changed to resolver1.opendns.com.domain. This is OpenDNS’ name for the DNS server we started using, 208.67.222.222, which we entered as our DNS for the “Home” location. Also, note how instead of just getting a 0/0/0 response, we’re getting NXDOMAIN 0/0/0? That’s at least the DNS server responding saying: that domain doesn’t exist (not exactly true, since the domain does exist, but it just doesn’t have an SRV record), rather than the DNS server sending back nothing, not even an error code. Also, notice how our Mac tried twice on asking for SRV records, and the DNS server responded twice, that no record exists for that domain, and then finally our Mac asks for an A record (A?) and gets one answer record back (1/0/0 A ww.unc.edu).

If you want to see a domain that actually has a proper SRV record, try this in the curl terminal window: curl http://s3.amazonaws.com

Results should be something like this:

09:36:56.440037 IP 192.168.1.132.61010 > resolver1.opendns.com.domain: 34536+ SRV? _http._tcp.s3.amazonaws.com. (45)
09:36:56.671881 IP resolver1.opendns.com.domain > 192.168.1.132.61010: 34536 2/0/0 CNAME s3-directional-w.amazonaws.com., (97)
09:36:56.673894 IP 192.168.1.132.61011 > resolver1.opendns.com.domain: 18143+ A? s3.amazonaws.com. (34)
09:36:56.715913 IP resolver1.opendns.com.domain > 192.168.1.132.61011: 18143 2/0/0 CNAME s3-1.amazonaws.com., A s3.amazonaws.com (69)
09:36:57.263186 IP 192.168.1.132.61012 > resolver1.opendns.com.domain: 32069+ PTR? 171.206.21.72.in-addr.arpa. (44)
09:36:57.306060 IP resolver1.opendns.com.domain > 192.168.1.132.61012: 32069 1/0/0 PTR s3.amazonaws.com. (74)

Here we’re getting 2 answer records (the “2″ in 2/0/0) on the SRV requests, which are CNAME records, first being s3-directional-w.amazonaws.com, second being s3-1.amazonaws.com. CNAME records are “nickname” records, which point to true name, or A Record. Right after that our Mac asks for an A record on the first CNAME that was returned to us (s3-directional-w.amazonaws.com) to get back the actual IP address (72.21.207.246), which you can verify by using the dig program.

This fix alone has made my Internet connection much faster since my ISP’s DNS servers were sometimes under heavy load and slow to respond to DNS queries. Most of the time, I’d get name requests done in 200-400ms. Not noticeably slow. But, on occasion domain name lookups would timeout after 7 seconds, multiple times, resulting in up to 21 seconds of waiting for a single name lookup request to occur. This is excruciatingly long when I often open up multiple different websites one right after another when starting a browsing session. To make matters worse, many websites are getting into the practice of placing different parts of the web page on different domain names. Let’s take CNN.com for example. To load this single page of President Obama… oh, I mean senator Obama, waving to the crowd, tcpdump showed name lookups for the following domains:

1. www.cnn.com
2. edition.cnn.com
3. i.cdn.turner.com
4. i2.cdn.turner.com
5. svcs.cnn.com
6. ads.cnn.com
7. i.cnn.net
8. ad.doubleclick.net
9. metrics.cnn.com
10. m1.2mdn.net

One Page. Ten domains. Ten DNS lookups. Ouch. And I’m not including PTR/Reverse Lookups for each domain, making it really 20 DNS queries.

And does anyone wonder why problematic DNS performance in Leopard would slow web browsing to a crawl?

Disable IPv6 DNS Lookups

Firefox and Camino by default do DNS lookups using IPv6 addresses by default, reverting to IPv4 if that fails. This can be a problem when the router that we are using to connect to the Internet doesn’t work with IPv6 DNS requests properly, if at all.

To disable IPv6 DNS lookups in Firefox and Camino, type the following into the browser address bar:
about:config
If you see a large “Be Careful” warning, simply click on “I understand and I wish to continue”. Next, you will see a long list of Preference Name, Status, Type and Value columns. Above all that is a bar in which you can filter which preferences to view. In the Filter bar type: ipv6
You should see something like the following:

To change the value for this preference simply double-click the name “network.dns.disableIPv6″. The value you want is “true”, which means that IPv6 DNS requests are disabled. If this value is already “true”, don’t double-click this preference.

To make the preference change active, close the browser and Quit Firefox completely (Apple Key + Q), then restart Firefox. You may have to repeat this Quitting and Restarting to have the change take effect.

After making this change, Firefox (or Camino if that’s what you’re using) will use IPv4 only when performing DNS requests.

Update DNS Servers on Router

If you have access to your router’s administration web page, you may be able to set its DNS servers manually, avoiding the buggy DNS servers located at your ISP. Refer the manual that came with your router, or speak with your service provider about how to access the router’s administration page. Often this page can be accessed at http://192.168.1.1, so simply type that address into your browser’s address bar and press Enter. With any luck you’ll have access to the Administration login page. Many router administration sites don’t have passwords, don’t have usernames, or use very simple standard passwords such as “admin”, leaving it up to the owner to change it to something more secure. Visit the router manufacturer’s web site for more information about accessing the administration features of the router.

Keep in mind that updating the router’s DNS servers will not avoid problems you may be encountering with the router’s poor DNS Proxying/Forwarding support. If your router can’t handle IPv6 or SRV requests coming from your Mac, these DNS requests will stop here at the router and will not be forwarded onto the new DNS servers you’ve just specified, making this fix completely ineffective. DNS requests that your router cannot understand will likely be ignored or returned without answer results. DNS Proxy/Forwarding issues are discussed further in the next section.

Update Router Firmware

For those who need to continue making DNS requests through their router, rather than directly against DNS servers, due to VPN or tunneling requirements, your fix may lie in upgrading your router’s firmware. Routers are in effect “the” DNS server for the majority of home broadband Internet connections since it acts as the DNS Proxy, taking domain name lookup requests from your computer, passes them to the ISP’s DNS servers for resolution, receives the results, and finally passes the name lookup results back to your Mac, all transparently in the background. This is why your DNS server address is the same as your “Gateway” which is a fancy name for your router, since all traffic passes through this “gate” of sorts. Thus the Gateway address is often 192.168.1.1, which in turn is also the address of the DNS server for the “Automatic” network Location in Leopard.

Be aware that DNS Proxying is a common failure point in the domain name resolution chain. If the router is not compliant with the latest Internet Task Force standards, it may not know what to do with SRV requests (which Leopard now uses) and may simply ignore them, return empty results, or return NXDOMAIN (non-existent) errors. Again, a firmware update may bring your router up to the latest standards for DNS servers.

If the router is a DSL Cable modem/router, contact your ISP and ask whether there is updated firmware for the model of router you’re using. If you’re more of a do-it-yourself person you can attempt to find the manufacturer of the router/modem and find the latest firmware from their website, if available. Disclaimer: updating the firmware of your router with the wrong firmware, or not completing the firmware update due to power loss, will render your router useless. Do not attempt to update the firmware if you are not confident of what you’re doing.

New Information

Update 080606: As per a discussion on Macosxhints forums, Apple may have changed the order in which DNS servers are used. In the screenshot, the listed DNS servers are used in the order they are seen, under Leopard 10.5.2. This is true for a manually configured Network Location. In 10.5.3, users are seeing the opposite order, i.e. In a DCHP configured Network Location (automatically done by your DSL router and ISP), the DNS servers listed are used in reverse order. (Bottom server is used first, then moves up the list as needed). Thus adding a new Network Location to use a given DNS server would be unnecessary.

Update 080614: Airport Wireless Connection Drops - This is a common problem for Leopard users after upgrading to 10.5.2. This isn’t exactly a slow Internet problem, but rather, a “no Internet” problem. See this related post on wireless problems on Apple AirPort connections.

The Beginning

This is not the end, but rather, the beginning of an article that I hope will continue to grow in scope to cover more problems and offer more solutions to slow Internet problems in Leopard. Please leave a comment if you’re experiencing a problem not discussed here and we’ll get working on diagnosing the issue and searching for a cure.

If you’re having troubles implementing a fix listed above, leave a comment and I’ll try to expand on the topic or reword it so that it is understandable to you and to everyone else I’ve confused.

Keep in the Loop

• Get updates and comments to this article by Email through Google’s FeedBurner:
  
  Enter your email address:

  Delivered by FeedBurner

• Subscribe to the comments feed to keep updated on new fixes and information I’ll add to this article. Every time this page is updated with new information, I’ll add a comment and you’ll be able to see what’s changed in your Feed Reader.

- Ben

Update: Stuart kindly dropped me a note regarding Apple’s fix for this.  See the end of the article for his response.

This evening while randomly working on articles for Installing Cats, I was watching DNS requests from tcpdump running in a terminal window and noticed something quite odd: a DNS request every three seconds for a PTR record as follows:
PTR? 1.0.0.127.dnsbugtest.1.0.0.127.in-addr.arpa

The first question was: “What the heck is making this DNS query?” Second: “Why is it so persistent?” Thirdly: “What the hell is with that bizarre address?”

1. mdnsResponder service is the origin of these repeated reverse-lookup requests.
2. mdns (multicast dns) / Bonjour is trying to see if you’re using a buggy router/adsl/cable modem by sending out these ill-formed reverse-lookup requests and seeing what response it gets back. Unforunately, many routers crash and do not respond to this request. Thus, mdns will repeat the request over and over again incessantly.
3. Explained in the last point. Address is meant to “diagnose” whether the router will respond to the “test” query in a poor or proper manner.

How did I stop mdns from continue to repeat its “test” dns request? I turned off AirPort for a few moments, waited for the mdnsResponder_Helper service to die off (in Activity Monitor), and then turned my WiFi card back on. mDns was kind enough to quit sending out these repeated queries.

The interesting thing is that I was using OpenDNS as my only DNS server. OpenDNS does handle mdns’ dnsbugtest queries fine, so I’m not sure what happened and why OpenDNS stopped responding to the requests. Perhaps they were just too fast? And instead of responding with a simple NXDOMAIN, it decided I was doing something malicious and deserved no response at all.

Either way, as a fallback plan, I’ve added my router’s dns’ ip into the DNS servers list within Network Preferences (under a new, custom Location where I’m specifying all settings, most of which are copied from the default Automatic location). If OpenDNS once again decides to not respond to the dnsbugtest queries, my router and ISP’s DNS servers should provide a second chance at mDns getting the response it’s looking for.

Read more about the technology of multicast DNS and Apple’s Bonjour service, created by the brilliant Stuart Cheshire.

From Stuart Cheshire on Sept. 16:

“[The repeated dnsbugtest requests] was a just bug, fixed and checked in back in March, and finally delivered to customers yesterday in 10.5.5.

The bug was that when mDNSResponder sent its DNS request to IP address X, and the response was sent back with source IP address Y, mDNSResponder would ignore the response as suspect and try again. Why people think it’s okay to reply with the wrong source IP address I don’t know, but they do, so now we accept those packets.”

This is good news for those who keep their Mac’s patched with the latest updates.  Thanks Stuart.

An explanation of why automountd is trying to find Backups.backupdb on the Internet…

I woke up this morning with a warning from Little Snitch outbound firewall that automountd wants to connect to Backups.backupdb on port 111.

Here’s what I’ve discovered since then.

automountd is a system service which mounts and unmounts network file systems (NFS) and lists contents of directories when requested (i.e. makes them accessible for use, like double clicking a .dmg file on your desktop, after that you can access the disk image).

Backups.backupdb is the Time Machine directory which contains your backups, usually on an external USB drive connected to your Mac.

When Time Machine is scheduled to do a backup, it tries to make a connection to Backups.backupdb to read its contents, which is automountd’s job to handle.
automountd pokes around, doesn’t find the directory within its network file system maps (when the external backup drive is not connected) and asks Open Directory/Directory Services “Yo, where’s Backups.backupdb?”

Directory Services stares at automountd blankly for a few moments and decides to check with DNS.

Directory Services asks the DNS server, “hey, you know where I can find Backups.backupdb”, to which your DNS server (located at your ISP or OpenDNS) will answer “Dood… that’s a nxdomain (non-existent domain) BUT, I’m gonna return you the address of a website with a bunch of search results and advertising”.

Here-in lies the rub: normally you should get a straight NXDOMAIN response from DNS meaning, there is no IP address for that domain. Instead, a lot of ISP’s (and OpenDNS) have capitalized on this and are returning an IP address to a web server dishing out search results and advertising, rather than a simple NXDOMAIN response. The result of which is applications such as Firefox or Safari, and services such as Time Machine , through automountd, are thinking that they’ve found the right address and therefore use it when handling requests.

The upside of this “service” is that instead of getting a “Website Not Found Error” in a browser, you get a list of possibly helpful search results of what you were really looking for.

The downside of course is that services such as Time Machine, have no idea that the address is not really the location of Backups.backupdb, but is in fact, a location of a website with search results and pay-per-click ads.

So, automountd attempts to read the contents of the directory called “Backups.backupdb” at the address returned by the DNS server, in my case “hit-nxdomain.opendns.com” located at 208.69.34.132, using a remote procedure call (rpc) on port 111. Of course, this remote procedure call will fail since 208.69.34.132 / hit-nxdomain.opendns.com is not a Network File System which accepts requests to mount drives, it’s a website meant for humans to see search results and click on ads.

Solutions to stop automountd from trying to connect to Backups.backupdb over the Internet?

• Leave your USB/firewire Time Machine backup drive attached to your Mac so that automountd can find it without having to ask DNS.
• Add a hosts file entry that maps “Backups.backupdb” to a local address, say 127.0.0.1. A rather crude, but possibly effective solution. I haven’t tried nor tested this solution, so I won’t elaborate on how that’s done.
• Added 080602: If you’re using OpenDNS, they offer a way to exclude certain non-existent domains from being subject to the “search results” page response of hit-nxdomain.opendns.com. Thus, you can add the domain name of “Backups.backupdb” to the Typo Exceptions list and OpenDNS will return a straight NXDOMAIN response when queried for that domain. See the following screenshot for an example. Before adding frankie_valens to the Typo Exceptions list, an A record query to OpenDNS resulted in this response: 1/0/0 A hit-nxdomain.opendns.com (48) which is OpenDNS’ search results page address. After adding the fake frankie_valens domain and retrying the same query the answer is now NXDomain 0/0/0 (32) which is a proper non-existent domain response.

Although I know the first solution works for me, I’d like to call on some autofs experts for advice on how to handle this situation, with a more graceful solution.

Which is what I’m going to do right now and we’ll see what we can work out.

Updates and links to follow.

Update 2008-06-01

I think I’ve found just the right Apple autofs expert, Rajeev Karamchedu, that could help us figure out how to prevent automountd from connecting to spurious websites of search results due to a non-existent domain (NXDOMAIN) response from our DNS service provider, in this case, OpenDNS. Rajeev! Master of all things autofs… care to lend us some expertise on solutions to the above issue?

Fix for “caution: filename not matched” error when trying to unzip multiple files at once in Terminal.

Solution for unzipping multiple zip files with a single command.

Open up a Terminal window on OS X, go to the directory containing the zip files and enter this command:

unzip \*.zip

The backslash escapes (prevents) the wildcard character (the “*”) from being expanded by bash shell interpreter. In English: the files in the directory are the filenames “unzip” is trying to extract from the first file it finds when using “*”.

Example:

/myzips directory contains zip files: first.zip second.zip third.zip

Trying to run: “unzip *.zip” will cause the unzip program to take “first.zip” as the archive to play with, and will look for files “second.zip” and “third.zip” within “first.zip” to expand/extract. Obviously not what you want to do.

Not escaping the * character will result in errors like: “caution: filename not matched”.

First find your current sleep setting by opening Terminal in OS X and entering this at the prompt:

pmset -g | grep hibernatemode

That should return you something like “hibernatemode 3″. Remember this number, send an email to yourself, write it down on a scratch pad, whatever it takes to remember your default mode. Mode 3 keeps your RAM powered during sleep to allow super fast wake-up, but also writes an image file of all memory onto disk in case power is lost.

To change the hibernate safe sleep setting to not create an image file on the disk, i.e. mode 0 (mode zero, not the letter ‘o’), enter the following in a Terminal window:

sudo pmset -a hibernatemode 0

Enter your password when asked to do so. This prevents Safe Sleep from saving your memory contents to disk, in large part the cause of not being able to wake MacBook’s from sleep.

If you’d like to get back about a gigabyte or more of disk space, delete the memory image file with the following Terminal command:

sudo rm /var/vm/sleepimage

Macworld has a great article with more information about safe sleep and hibernation on MacBooks.

Open the lid and nothing? Tap keys, change brightness, close and re-open lid and your MacBook still in sleep mode?

Solution: Turn off Safe Sleep. Or use Smart Sleep.

If you open your MacBook lid and notice that you can’t wake your MacBook from sleep, it’s because of the Safe Sleep system Apple designed. This system puts all your current memory (your RAM) onto the disk, so that it can power down the RAM, save energy, and keep the current working state of your computer, even if you ran out of battery power, changed batteries, etc.

Problem is, it’s slow. And buggy. Often when waking from sleep by opening the lid, the MacBook will remain in sleep.

My solution to this: don’t use Safe Sleep. Unless you’re constantly working on battery power and hate plugging in, you likely won’t ever notice you’re not using Safe Sleep’s hibernate to disk mode.

Here are some instructions on how to turn off Safe Sleep on a MacBook Pro Leopard or Tiger to avoid wake-up problems.

If you still want to use Safe Sleep with disk caching of RAM, use Smart Sleep by Patrick Stein. This software adds a preference pane to your Mac, allowing you to not use disk hibernation until you reach a low battery level, say 20% remaining battery.

While watching a tv series encoded with divx, in avi package format on a Macbook installed with Leopard, I noticed that Front Row would randomly crash and return to the desktop.

First step in investigating what was causing the crash is to look at the syslog.

• Open up Terminal (Applications => Utilities => Terminal)
• Go to the /var/log directory (cd /var/log)
• View the syslog file (less system.log)
• Go down to the latest entries in the log file (Shift + G)
• Look for a line saying “Saved crashreport to /Users/[username]/Library/Logs/CrashReporter/Front Row_2008-04-27″ or something to that effect. The username will be your Mac OS X username and the date attached to the Front Row text will of course be different.  These crash logs are created whenever a program you are running stops for some unknown reason (i.e. a crash).
• Press “q” to quit the “less” program.
• Goto the CrashReporter directory (cd /Users/[username]/Library/Logs/CrashReporter). Replace [username] with your username.
• Open the latest Front Row crashlog with “less” (less Front Row_2008_2008-04-27). If you’re having trouble typing the name, just hit the Tab key, which will attempt to fill in the blanks as best as possible, creating spaces with escape characters.
• Look for the line saying “Crashed Thread” and note the number beside it. In my case it was “22″.
• Now use the search function within “less” by hitting forward slash “/” then typing “Thread 22″. This is case sensitive so make sure you capitalize “T” in Thread.
• You should see Thread 22 Crashed: followed by what file was related to the crash of Front Row.  In my case it was listed as “com.yourcompany.XviD_Codec”.

If you continue reading, you’re doing the following AT YOUR OWN RISK.  You can royally screw up Front Row and any type of movie/video watching by performing the following, so if you have any qualms, do not perform the next steps.

My fix was to move the AppleIntermediateCodec.component and AppleMPEG2Codec.component files from /Library/QuickTime to a backup directory and replace it with Xvid_Codec 1.0 alpha.component which is detailed in another post on how to watch xvid encoded avi files on Mac OS X. To move these two files elsewhere, create a backup directory on your home directory (mkdir ~/QuickTime_backup) then use the “mv” command (mv AppleIntermediateCodec.component ~/QuickTime_backup/) (mv AppleMPEG2Codec.component ~/QuickTime_backup). Now install the alpha xvid component for Mac.

Make sure QuickTime isn’t running, or fully Quit QuickTime and then start Front Row and attempt to watch the same file that was causing Front Row to crash before.

The reasoning behind removing these two QuickTime codecs is that they aren’t on another MacBook book of mine, which doesn’t have Front Row crashing problems.  That’s the only logic I have behind this fix.

So far, the change has worked.

Best of luck.

To reduce the temperature of my MacBook Pro I use smcFanControl by Hendrik Holtmann.  Normally my MacBook Pro would run somewhere close the 55-60C mark without doing anything intensive, say a 10-15% average CPU utilization.  I found this somewhat hot for my tastes, especially when using the built in keyboard where it would be uncomfortably hot to touch the speaker/heat dissipation grilles on either site of the keyboard.

I generally run the two internal MacBook Pro fans at 2600rpm each to keep the temperature 50C or below, depending on ambient temperature.  The cost is a little fan noise which is noticeable in a dead quiet room.  If you’ve got any music or background noise, you won’t notice it.  Either way, it’ll blend into the background quickly since it’s “white” noise anyways.

I’m unsure which version is the latest for smcFanControl so here’s another link to smc Fan Control version 2.1.2 in case it’s more recent than the above link.

This post was due to a comments discussion on how to turn off the macbook pro display when using an external display for Front Row.

I recently copied over a set of PDF ebooks from an external drive to my “home” folder (usually your login name under Places within Finder) and a few minutes after that my Macbook Pro fan started to go nuts and I noticed my CPU temperature was up near the 70 degree C mark.

Cutting to the chase (fix): Open up System Preferences -> Spotlight Preferences -> Click Privacy button -> Click + button at bottom left and add the directory where you’ve just put your PDF files. In a few minutes, ATSServer will stop going nuts.

I quickly loaded up Activity Monitor (found under Applications -> Utilities in Finder, if nothing shows up after starting Activity Monitor, hit Apple key + 1), sorted processes by CPU descending (by clicking on the CPU column) and noticed that a process called ATSServer was hitting about 60% CPU time with mdworker below it at about 23%.

These two processes were really chewing up processor time and I had no idea what I had done to set this off, having never seen ATSServer before, I googled “What is ATSServer?” and found a forum thread on support.apple.com where people were batting around theories of what was causing ATSServer to go nuts.

For me it turned out to be the PDF books that I had just copied over to my Documents folder. Turns out that Spotlight, Apple’s file and text indexing service, tries to parse text in files, make thumbnails of pdfs (dear god),
and many other things including the kitchen sink.

Here’s an excerpt from Apple on Spotlight (warning PDF file) when they released Spotlight with Tiger (OS X 10.4):

Spotlight is comprehensive. Spotlight searches across your documents, images, movies, music, PDFs, email, calendar events, and system preferences. It can find some- thing by its text content, filename, or information associated with it, known as metadata. This allows you to find a photo by entering the brand of camera that took it, the name of the person who emailed it to you, or the date you last opened it.

I guess Spotlight is a bit too ambitious when it comes to PDF files. Simply copying over 300MB worth of PDF docs shouldn’t cause Spotlight to lose its mind. My guess is that it’s attempting to parse all the text within the PDFs and put those results into Spotlights database. Result: nastiness. PDF’s are exactly “fun” to parse I guess.

If you’ve noticed that your Macbook or Macbook Pro purchased in 2006 or 2007 is losing its battery life at an alarming rate, you’re not alone. Apple has had a very large batch of Sony lithium-ion polymer batteries for their laptops that are losing their maximum charge capacity very quickly.

If you’ve noticed that your 4 hour battery life dropping to just over 2 hours recently, check your System Profiler for some information about your laptop battery power system.

System Profile can be found in Finder => Applications => Utilities => System Profiler.

Once you have System Profiler open, find Power underneath Hardware. Click on that item and on the right side of the window, scroll down until you find the Battery Information heading.

The three values we’re interested in are Full charge capacity (mAh), Cycle count, and Battery health.

A normal reading for Full charge capacity is about 5200-5400 mAh (milliamp hours). That translates into just over 4 hours battery life. Cycle count is how many times the battery has been used to capacity and recharged. Battery health is a word describing overall life expectancy and condition of the battery.

Remember that Apple has published on its Apple Support site that their laptop batteries are designed to hold 80% of its original charge capacity after 300 cycles (see the footnotes).

Doing the math, that means the Full charge capacity should be around 4160 to 4320 mAh after 300 cycles. If your Macbook battery is failing, like mine, it should read less than 3250 mAh, with a Health of “Fair” after far less than 300 cycles.

But, don’t despair. With that juicy price paid for the best laptop available on the market comes pretty good customer service. Bring your Macbook into an authorized service center, an Apple flagship store, or call up Apple support hotline and explain the situation. Also note that there are several support forum threads on Apple.com about users describing the same situation and what Apple has done for them:

http://discussions.apple.com/thread.jspa?threadID=1227431&tstart=0

http://discussions.apple.com/thread.jspa?threadID=1300374&tstart=0

For Macbook users experience battery life problems as described above the warranty coverage is being extended to two years, so even if your Macbook is out of warranty, your battery may still be in warranty.

I currently have a battery being sent to me and we’ll see how things turn out.

Good luck.

Error: uncaught exception: Permission denied to call method XMLHttpRequest.open FireFox/Mozilla browser fix / solution:

• Go to address “about:config” in Firefox (i.e. type that in the address bar and hit Enter)
• Search for “signed” in the filter bar
• Double click the item “signed.applets.codebase_principal_support” to change its value to “true”
• Create (or edit if already present) the “user.js” file found in the below directories. By default this file does not exist so create a new blank user.js file if you don’t find it in the following paths (as specified on Mozilla.org):
  • On Windows Vista/XP/2000, the path is usually %AppData%\Mozilla\Firefox\Profiles\xxxxxxxx.default\, where xxxxxxxx is a random string of 8 characters. Just browse to C:\Documents and Settings\[User Name]\Application Data\Mozilla\Firefox\Profiles\ on Windows XP/2000 or C:\users\[User Name]\AppData\Roaming\Mozilla\Firefox\Profiles\ on Windows Vista, and the rest should be obvious.
  • On Windows 95/98/Me, the path is usually C:\WINDOWS\Application Data\Mozilla\Firefox\Profiles\xxxxxxxx.default\
  • On Linux, the path is usually ~/.mozilla/firefox/xxxxxxxx.default/
  • On Mac OS X, the path is usually ~/Library/Application Support/Firefox/Profiles/xxxxxxxx.default/
• Place the following lines within user.js:
  
user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.open", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.sites", "http://localhost.com:3000");
user_pref("capability.policy.XMLHttpRequestToAnySite.CDATASection.nodeValue", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.attributes", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.childNodes", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.firstChild", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.getAttribute", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.getElementsByTagName", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.lastChild", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.nodeName", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.nodeType", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.parentNode", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.tagName", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.nextSibling", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Element.previousSibling", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.HTMLCollection.length", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.HTMLCollection.item", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.attributes", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.childNodes", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.firstChild", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.getAttribute", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.getElementsByTagName", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.lastChild", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.nodeName", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.nodeType", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.parentNode", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.tagName", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.nextSibling", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.Text.previousSibling", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.XMLDocument.documentElement", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.XMLDocument.getElementsByTagName", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.channel", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.open", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.responseText", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.responseXML", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.send", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.setRequestHeader", "allAccess");
user_pref("capability.policy.policynames", "XMLHttpRequestToAnySite");

• Edit the line containing “http://localhost.com:3000″ and replace that URI with whatever URI you are developing on (or publishing to). For me it happens to be localhost.com:3000. Normally it would be just “localhost” for most people or localhost:3000 for Rails project developers.
• Save the user.js file
• Exit out of Firefox or other Mozilla based browser. If on Mac OS X, fully quit Firefox by hitting Cmd+Q, don’t just close the current browser window (which leaves Firefox still running in the background).
• Launch FireFox again.
• Exit out of Firefox again. The config file that Firefox actually uses to control the browser is called “prefs.js”, not “user.js”. user.js is the file that we, the end user, are supposed to make changes to, which are then copied over to prefs.js when Firefox is loaded. For whatever reason, the prefs.js file will not be updated with the contents of user.js until you exit Firefox, launch it, exit again (at which point prefs.js will be updated), then launch Firefox once more and your changes are ready for use.

After the above steps are completed, you should be able to make XMLHttpRequest calls cross-site / cross-domain with your AJAX code without Firefox/Mozilla security getting in the way.

The bevy of user_pref settings above creates a new site security policy that allows the listed XML HTTP Request commands to be performed from “http://localhost.com:3000″ to any address. Normally, Firefox will only allow XMLHTTP Request calls within the same domain. For example if you were on microserf.com domain, Firefox would not allow the website http://www.microserf.com to make XMLHTTPRequest calls to http://www.hackmehard.com since this was a major exploit that crackers would use to hide their evildoings in the background of apparently benign sites.

In general the security policy that Firefox has setup by default is a good idea. Setting up a new security policy as we have done above is generally safe as it only allows the site “http://localhost.com:3000″ to make cross-site/cross-domain XMLHTTPRequest calls of any sort listed. Any other domain would not be allowed to use this site policy.

This post originally started out due to the desire to develop Salesforce.com AJAX Toolkit based s-controls outside of their Ajax Tools IDE (yeah, their naming schemes leave something to be desired), which runs on their Force.com “no software” platform.  Of course I ran into huge problems with Camino / Firefox and cross domain XMLHTTPRequest scripting security issues.  The result of which is this post on how to get around the cross site scripting issues and develop javascript based s-controls on your local machine, using your preferred IDE (go go Textmate).

Update: This post has been superseded by How to Fix Ajax Error: permission denied to call method XMLHttpRequest.open.

For anyone developing S-controls and applications for use in Salesforce.com, developing directly within their platform is a bit of a hurdle. Using their Ajax Tools Development Environment for quick changes is fine. But, developing a serious piece of code purely using that tool is far from a pleasant reality today. Hence its natural to develop on a local machine then upload to Salesforce.com when a piece of software is ready for testing within the platform.

Find the definition of sforce.Transport, which should be around line 565.
Find the line: this.connection.open("POST", this.url, async); around line 591.
Add the following line before the previous line:

netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");


Change the relative URL paths for the Salesforce API from “/services/Soap/u/11.0″ to the following:

"https://www.salesforce.com/services/Soap/u/11.1"


A nice way to do this is simply add a constant at the top of connection.js and just replace all occurrences of the relative path with this constant:

const sforce_api_url = "https://www.salesforce.com/services/Soap/u/11.1"


After that, fire up your trusty browser and try making your Ajax Toolkit call again.

You may find it helpful to use a Javascript development environment like Jesse Ruderman’s Javascript Development Environment 2.0.1 when playing around with Javascript. [Jesse, you're the man]. Install it as a bookmarklet for the best user experience. It allows you to access all the javascript code and the document model in your current browser window through this development environment (which opens up in a new window).

Don’t forget the about:config stuff with the browser up above.

And finally, this is for debugging purposes on your local machine. Don’t publish code which disables security settings (which are there for a good reason) to a live deployment environment, such as Salesforce.com. Normally you’ll be installing the code you’re building as an S-control anyways, within the Salesforce.com platform, which will be exempt from any cross-site cross-domain scripting issues.

With Ruby on Rails 2.0.2 fresh out of the gates and hordes of (us) DHH fanboys coding away in Textmate on their Macs will soon realize that the new .rhtml template is now .html.erb. This file extension isn’t recognized as Rails (HTML) by default in Textmate 1.5.7.

All you need to do is edit the correct Textmate Bundle which you get to by finding in the Textmate Menu: Bundles -> Bundle Editor -> Show Bundle Editor -> click the arrow beside Ruby on Rails -> near the bottom of the list click on Rails (HTML), then on the right hand side area find:

fileTypes = ( 'rhtml' );

and change it to:

fileTypes = ( 'rhtml', 'erb' );


Greg is the man and posted the original fix to the Textmate html.erb bundle problem.

If Camino 1.x isn’t importing your Google Bookmarks (http://www.google.com/bookmarks) properly (it can hang during the import process) an easy fix or solution is to import your Google bookmarks into Safari first (File menu > Import Bookmarks).

Then from Safari, export the bookmarks to an HTML file.

Then return to Camino and import the bookmarks from an HTML file (File menu > Import Bookmarks > Select a File [from the drop down box] and select the Safari bookmarks.html file that you just created).

For those of you using MySQL database server on Mac OS X Leopard while developing for Ruby or Ruby on Rails, you might have run into an issue with the mysql rubygem installing OK, but not actually loading properly in irb, nor completing unit tests successfully.

If you’ve seen errors such as:

$ irb
>> require 'mysql'
LoadError: dlopen(/Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle, 9): Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib
Referenced from: /Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle
Reason: image not found - /Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle
from /Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:32:in `require'
from (irb):1


Or perhaps you’ve tried to run test.rb from the mysql ruby library install and ran into an error like this:

$ ruby test.rb
./mysql.bundle: dlopen(./mysql.bundle, 9): Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib (LoadError)
Referenced from: /Library/Ruby/Gems/1.8/gems/mysql-2.7/mysql.bundle
Reason: image not found - ./mysql.bundle from test.rb:5


The fix to the mysql ruby library gem installation was provided by jhclouse on the RailsForum site. I’ve edited the fix to work with Mac OS X Leopard’s pre-installed version of Ruby:

sudo install_name_tool -change /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib /usr/local/mysql/lib/libmysqlclient.15.dylib /Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle

The only difference between jhclouse’s fix and the one here is the location of the installed mysql rubygem. On OS X Leopard, ruby gems are installed in the /Library directory rather than /usr/local/lib.

Run the fix again in the main mysql ruby gem directory as there is another mysql.bundle file that needs fixing. This bundle file is used by the unit test file test.rb.

sudo install_name_tool -change /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib /usr/local/mysql/lib/libmysqlclient.15.dylib /Library/Ruby/Gems/1.8/gems/mysql-2.7/mysql.bundle


To run the unit tests for the mysql ruby gem you need to supply some command line arguments to test.rb:

ruby test.rb -- localhost [username] [password]

Replace [username] [password] with valid credentials for your MySQL server and you should have a fairly successful run of the unit tests for the mysql ruby gem.

Now that you’ve got the mysql C bindings for ruby installed, lets double check that it’s actually being used.

If you have a rails project, start with webrick (script/server) and load up your test site in a browser. Do something within your site that you know touches the database.

Now find the process_id for ruby by running ‘top’ in the command line. Top will return a list of all process names and their process ids. Find ruby amongst the list. For me it happened to be 3343.

Then we use that process_id in a magical program called ‘lsof’:

$ top
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
3372 top 5.3% 0:01.39 1 18 29 824K 188K 1416K 18M
3343 ruby 0.3% 0:06.77 2 19 247 60M 188K 64M 85M

$ lsof -p 3343 | grep mysql

ruby 3343 ben txt REG 14,2 86288 813474 /Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle
ruby 3343 ben txt REG 14,2 1967788 624481 /usr/local/mysql-5.0.45-osx10.4-i686/lib/libmysqlclient.15.dylib

lsof spits out the “list of open files” that are in use by a certain process, in this case the running ruby process that is serving our Rails site. In the above listing lsof shows that the freshly installed mysql ruby gem (mysql-2.7) that provides native C bindings for ruby to use when accessing MySQL, is currently being used. Sweet, we’re all good.

So is all this trouble really worth it? Why not just use the built in ruby libraries to interface with MySQL? If your Rails site touches a database, and most likely it does, you’ll see a 2-5x decrease in rendering time due to database calls. We’re only talking milliseconds, but it’s still a 2-5x boost in efficiency so it’s definitely worth it if you’re optimizing your Rails site. Whether it should be at the top of your tweaking to-do list depends on how optimized everything else is.

My Rails site in the testing environment was constantly generating on average about 30% of its page rendering time due to database activity. The following is hardly a definitive test, but is printed here simply for interests sake.

For an initial site load with the MySQL query cache reset, my home page rendering time looked like this before the C MySQL ruby binding installation:

Completed in 1.47017 (0 reqs/sec) | Rendering: 0.10060 (6%) | DB: 1.18992 (80%) | 200 OK [http://localhost.com/]

After, resetting the query cache in MySQL, clearing the browser cache and restarting webrick, the initial site home page load after installing the C bindings for MySQL via the ruby gem:

Completed in 0.70598 (1 reqs/sec) | Rendering: 0.08854 (12%) | DB: 0.56506 (80%) | 200 OK [http://localhost.com/]


The time to load was cut in half and the only thing that changed was the way ActiveRecord accesses the MySQL database.

Please note that if you’ve been using Mac Ports, this fix may need tweaking on your part. The problem and the fix are pretty straight forward once you know about the install_name_tool program. The mysql ruby gem is simply looking in the wrong place for a MySQL library that it needs to interface with. If you look closely at the first two directory paths you’ll notice that the first has an extra “/mysql” in between “/lib” and “/libmysqlclient.15.dylib”. Remove that extra “/mysql” folder from the directory path and you’re golden.

Have no sound when using QuickTime to play .avi or other movie films encoded with DivX? This is due to a missing audio codec for DivX encoded video files. Here’s a possible solution or fix to the problem of no sound in QuickTime DivX Movies.

In a follow up to my post about how to dual boot Tiger and Leopard on your Mac, this post is about removing large (unnecessary) files from your hard disk and recovering disk space on your hard drive before attempting to repartition Macintosh drives and dual booting.

Many folks have been noticing that repartitioning disks using Leopard Disk Utility often fails with an error of “no space left on device”, even though there is plenty of space “left on the device”.

A solution that many have found is removing any “large” files from your Tiger partition before attempting Leopard Disk Utility repartitioning. By large files I’m talking single files that are in the range of 1GB+.

Before running off and deleting large files on your hard disk willy nilly, please, make a backup of your Mac hard drive using SuperDuper! (free / donation-ware) or move these large files off to a secondary external hard disk connected via USB or FireWire.  If you find that you actually need these files later, you can always move them back or revert to your complete backup you made to an external drive.

A great program that helps with finding and moving / removing large files on your disk is Disk Inventory X. Disk Inventory X generates a visual file map of your disk like the one displayed here. Click on the large squares and rectangles to inspect the details of the files. The usual suspects that you can get rid of safely include scratch disks such as the Photoshop scratch disk and the Apple safe sleep memory image. This safe sleep / hibernate memory file takes the contents of your physical RAM and copies it to disk (in a single file) so that your Mac can “hibernate” for an indefinite period, with or without power, without losing what you were working on. The downside of this is that it creates a file equal the size of your physical memory. That can be anywhere from 1GB to 4GB for Macbook users.

The skinny on how to get rid of this sleep image file: First find your current sleep setting by entering this in a Terminal window:

pmset -g | grep hibernatemode

That should return you something like “hibernatemode 3″. Remember this number, send an email to yourself, write it down on a scratch pad, whatever it takes to remember your default mode. Mode 3 keeps your RAM powered during sleep to allow super fast wake-up, but also writes an image file of all memory onto disk in case power is lost.

To change the hibernate safe sleep setting to not create an image file on the disk, i.e. mode 0 (mode zero, not the letter ‘o’), enter the following in a Terminal window:

sudo pmset -a hibernatemode 0

Enter your password when asked to do so, then delete the image file with the following Terminal command:

sudo rm /var/vm/sleepimage

Macworld has a great article with more information about safe sleep and hibernation on portable Macs.

The best solution to the “no space left on device” errors while partitioning your Mac hard disk is to continue with finding and deleting 1GB+ files that you can live without or can move off to a temporary external disk. Then get back to repartitioning your Mac hard disk in preparation to setup a dual boot of OS X Tiger and Leopard on your Macbook.

Here’s a bizarre problem: All of a sudden I couldn’t hit the Ctrl F2 keyboard shortcut to set focus to the menu bar. It wasn’t because the shortcut was disabled through Ctrl F1 (by default the functions for keys F2 to F6 are disabled by default), it was due to some bizarre problem with Quicksilver - keyboard navigation voodoo. For some reason ^ F2 would only work after I had Command Tab’d to Quicksilver, hit Ctrl F2 (which worked, focus was set to the menu bar), afterwards, the shortcut worked as normal with all other open applications.

Bizarre.

Quicksilver is the bomb, btw, in case you didn’t know. Dock? What Dock?