Speeding up Firefox on OSX

Wow! There's two very simple actions that will speed up firefox.

After some time of using firefox the address bar can slow down considerably. SpeedyFox is an extension that claims to speed up the browser, but there's no need for an extension - it's simple enough to do manually.

Here's how you do it.

1. Quit firefox.

2. Open your favorite Terminal.app or iTerm.app

3. Change to your profile directory
cd ~/Library/Application Support/Firefox/Profiles/your_profile_code.default

4. Issue the command to vacuum your sqlite db's
for x in *.sqlite; do echo 'VACUUM;' | sqlite3 ${x}; done

That's it! Next time you start firefox it'll be faster.

And the second tweak you can make is to reduce the page render delay. I guess firefox has this since it assumes pages take a while to come in - but I don't see the point.

1. Open up the about:config area:

2. Edit the print.print_pagedelay config item, and set it to 0 (zero). This tells firefox to start drawing the page immediately instead of waiting half a second.

git svn checkout

git-svn checkouts are pretty simple, but here's a reference anyway:

Checking out the SVN tree within GIT

$ mkdir git-svn-project
$ cd git-svn-project
$ git svn init https://svn.server.url/repos/svn-project
$ git svn fetch

Staying up-to-date with upstream SVN commits

$ git svn rebase

Commiting back to SVN

$ git commit -a
$ git svn dcommit

git-svn and failed svn commit hooks

The workflow of using GIT with SVN can be a steep learning curve. After the easy part of getting an SVN checkout within GIT, you could end up in a situation where an SVN pre-commit hook fails, leaving your in a bit of a muddle.

The solution to this may not be immediately obvious, so it's necessary to understand what GIT is doing under the hood.

When you have a git-svn checkout, git maintains the svn repository state in a remote branch. You work within your local branch and commit changes locally. When you're ready to commit back to SVN you'd normally just do a "git svn dcommit".

If you make some local git changes and commit locally, then do the dcommit that is rejected by a pre-commit hook, then normally in SVN you would fix the error locally and re-try your commit. In GIT the commits have been separately checked-in locally, so GIT will try to commit each change separately to SVN - but this won't work because the first local commit was rejected by SVN.

The solution is to create a new git branch, forked from the current branch just before your rejected commit. To do this you would first want to look at "git log" to get the commit hash from git, then create your new branch and change to it:

$ git log
  # find the commit hash you're after
$ git branch temporary_branch 68b8976ba0944
$ git checkout temporary_branch
$ git merge --squash dd7354fcd397 7f5e78f7e737ed4 5e07bf3c6f5c15
$ git svn dcommit

You'll then want to go back to your local master git branch, and likely clean up after yourself:

$ git checkout master
$ git svn rebase
$ git reset --hard HEAD
$ git branch -D temprorary_branch

Disclaimer: You'll want to check the last "reset --hard" and "branch -D" commands do lose anything before running them. I.e. don't do anything here without understanding it first!

Locale problems

This has happened too many times - so here's a note: http://www.peterryan.net/2007/11/05/perl-locale-is-corrupted-after-gutsy-upgrade/

EDIT: The target site appears to break, so here's the fix:

 sudo locale-gen
sudo dpkg-reconfigure locales

Thanks to armware on December 12th, 2006, 01:00 PM for identifying this.

Changing root users' shell in Mac OSX Leopard 10.5

Leopard changes the way users are managed on Leopard. Some online resources say you have to enable root, then you can change the users' shell via the System Preference, however that didn't work for me.

Directory Utility never connected to any directory, and thus didn't work as a solution for Enable Root. The solution here is to use dsenableroot on the command line.

Then the obvious sledgehammer for editing users accounts, vipw, didn't work. The next obvious tool for editing the shell was chsh and that did the job.

Xen and keeping time: NTP, DomU's and hwclock

There's plenty of discussion out there on keeping time in Xen DomU's. Unfortunately there is no one definitive source of information.

After much research I've come to the conclusion that the following is the best way to keep all Dom clocks synchronized:

• Set independant_wallclock=0 on all Dom's
• Run NTP in Dom0 only (not OpenNTP, and not in DomU's)
• Cron "hwclock --systohc" to run daily or twice daily, but never more than once every 55 minutes.
  

Here is a more in depth explanation of the possible ways of keeping time, and the reasoning behind using the above solution.

1. The default method for keeping time is for the DomU's to get their time directly from Dom0.
2. An alternative methods involves setting each DomU to have an independant wallclock, then to run NTP in the DomU's

I used the second method fairly successfully for a long time, but then some flaws in this solution became apparent. Primarily, Dovecot IMAP/POP3 would constantly complain that TimeWentBackwards. This highlighted to me that using an independant wallclock like this wasn't working well. While other processes didn't complain, I can imagine that a changing clock could easily confuse several things.

I then set the DomU's back to the default independant_wallclock=0, disabled NTP on the DomU's and only ran NTP in Dom0. Unfortunately there was still a significant drift in the DomU's even though Dom0 was correct, however the DomU's all seemed to have very similar drive relative to the Dom0. There are a couple of reasons for this.

OpenNTP doesn't set the Dom0 clock in the same way that NTPd does, and so NTPd works out of the box much better. But this still didn't solve the problem. It seems that something changed between ntpd and/or kernel versions.

I believe ntpd used to make use of the "11 minite mode" outlined in the hwclock man page. After some investigation it turned out this was not the case, and can be confirmed by using "adjclockx --print". If the status value isn't 64, or doesn't have the 64 bit set, then "11 minute mode" is on. Despite various sources indicating that ntpd would automatically turn on "11 minute mode", it didn't. Further investigation seems to indicate that "11 minute mode" is not a Good Thing(tm), so I'm guessing that's why it doesn't get set when ntpd is started. A greater discussion about this can be found here among many other places.

So we now know that NTPd is prefered over OpenNTP, and that using hwclock is prefered over "11 minute mode". And that's why I use the settings outlined above.

Convert cue bin files to iso on linux

When faced with cue/bin files the first reaction is to convert them to something you can use.  Essentially this isn't necessary.

If the contents of the cue/bin files is a movie or audio, mplayer can read the files natively:

mplayer "cue:///path/to/image.cue:track"

If you do need to access the contents of the raw image, then cdemu is your friend.  Once installed you need to start the cdemud daemon, then use the cdemu tool to expose your raw image on a new cdrom or dvd device, such as /dev/dvd2.

root@ # /etc/init.d/cdemud start
user@ $ cdemu -b system load 0 "/path/to/image.cue"
user@ $ mount -t iso9660 /dev/dvd2 /mnt/dvd2

Like this you have no need to perform any time consuming conversions with tools such as bchunk or bin2iso which proved to be unreliable for me.

If you want to burn the cue/bin files to disk - cdrdao should be able to do that, though I haven't tested it.