Now that Firefox 3.5 is out, I wanted to get it running on my 64-bit Debian 5.0 laptop—but there’s no 3.5 package in Sid yet, as of July 2, and mozilla.com only carries 32-bit binary tarballs for Linux. So I had to build Firefox 3.5 from source. Fortunately this turned out to be a lot less painful than I had imagined; this post will show you how I did it, in case you’re in a similar spot.

Build dependencies

The first thing to do is to make sure you’ve installed everything for the build process. Since you’re on a nice, civilized operating system like Debian, the following commands should have you covered:

$ sudo apt-get install build-essential libidl-dev autoconf2.13
$ sudo apt-get build-dep iceweasel

Obtaining the Mozilla source code

Mozilla’s official developer guide recommends downloading individual source archives for those who simply want to build a Firefox release, but I decided to get the source via Mercurial checkout, since this way there will be less to download and re-compile each time a security update comes along. The downside to this is that the initial download takes longer, and the full Mozilla source repository takes up about 686 MB on my hard drive.

First you’ll need to have the Mercurial source control manager installed on your computer, of course. If you don’t have it already, just type the following…

$ sudo apt-get install mercurial

Now change to whichever directory you want to keep the repository in, and run

$ hg clone http://hg.mozilla.org/releases/mozilla-1.9.1 \
    mozilla-1.9.1

This will copy the full Firefox 3.5 / Mozilla 1.9.1 development branch to your computer. If you’re on a slow U.S. residential Internet connection like I am, this might be a good time to go do something else.

Once this is done, check out the particular Firefox 3.5 release that you’d like to build. Since there have not yet been any dot releases at the time of this writing, I just did:

$ cd mozilla-1.9.1
$ hg checkout -r FIREFOX_3_5_RELEASE

With South Carolina’s Republican governor, Mark Sanford, caught up in a sex scandal, how does Fox News report the story? By claiming that the big, bad adulterer is actually a Democrat, of course:

Normally one might attribute such a thing to simple human error, but branding Republicans who have been caught up in sexual or political scandals as Democrats is hardly a new tactic to the Fox propaganda machine. Remember when Republican Rep. Mark Foley was caught sending sexually explicit text messages to teenage male pages?

In Foley’s case, he was branded a Democrat in three different video cutaways, on two different segments. When other media outlets finally called them out on this, Fox News refused to issue an actual correction — they just reran the segments scrubbed of any mention of Foley’s party affiliation. I wonder how this will play out with the Sanford story?

I fear for the future of our country, that a large percentage of our population apparently mistakes Fox News for a credible source of journalism.

Looks like I’ll be rocking out on my way to work tomorrow…

One of the things that I really like about pf, the OpenBSD firewall, is how it lets you define dynamic packet filtering rules — rules that filter based on your network interfaces’ current addresses at the time of filtering. For instance, if I want to allow SSH connections to my laptop only from my local network:

pass in on xl0 inet proto tcp from (xl0:network) to any \
    port ssh flags S/SFRA

(xl0:network) is not resolved to a specific address block at configuration load time; if you switch networks — say, if you go from home to work — the rule’s behavior will change accordingly.

Unless I have overlooked some recent change in Linux, this cannot be achieved in a direct fashion with iptables. You can insert a rule to reject non-LAN source addresses, but such a rule is static. When you change network addresses, the rule must be explicitly updated.

In lieu of rewriting all of netfilter to accommodate this use case (*cough*), I just wrote a shell script to help mitigate the pain of manually updating my laptop’s firewall rules — merely a shortcut to cut down on the amount of typing I do on any given day, but if you tend to move around as much as I do, all those keystrokes can add up :) So with this script you can, in one fell swoop, start and open up global access to an SSH server:

# ssh-serve any

Or only allow local access from the networks you’re connected to:

# ssh-serve lan

Or only local network access on a specific interface:

# ssh-serve lan eth0

Or only access from a given set of IP addresses and/or CIDR blocks:

# ssh-serve addr 192.168.0.104 10.18.0.0/16

Better yet, you can make the whole process automagical by hooking into your Linux distribution’s DHCP client. For instance, in Ubuntu Hardy Heron you can automate ssh-serve by creating a file /etc/dhcp3/dhclient-exit-hooks.d/ssh-serve:

# Allow SSH access from your local network only, and keep these filter
# rules up-to-date as you move from one network to another.
case $reason in
    BOUND|REBIND|REBOOT)
        ssh-serve lan
        ;;
esac

This script was written (and named) with Secure Shell in mind, but it could just as easily govern over any other service controlled by a standard SysV init script. See below the jump for the code…

This evening I had the chance to download Google’s newly-released (and by “released” I mean “beta”… hey, it’s Google) web browser, Chrome, and give it a try. They weren’t kidding when they said V8, the new JavaScript virtual machine in Chrome, should raise the bar for next-generation JavaScript implementations: it’s fast. How fast?

The above results are from Mozilla’s Dromaeo JavaScript performance test suite, so there’s little worry of this test being intentionally biased in Chrome’s favor. The scores above are the averages of five test executions on each web browser, running in the same Windows XP virtual machine on the same computer. Some notes:

• Each run of the test was performed in a fresh browser instance.
• IE 7 was unable to complete the test suite without crashing, although I am using a special, standalone version of IE 7 so this may be particular to my installation.
• In order to prevent IE 8 from complaining about the long JavaScript execution time, I set set the registry value MaxScriptStatements = (DWORD) 0xffffffff in the key \HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Styles.

So yes, Chrome does in fact have a much faster JavaScript engine than any other current web browser: in this test, more than eight times as fast as Firefox 3.0.1’s engine, and more than thirty times as fast as the latest beta of Internet Explorer 8. But how does the rest of the user experience stack up?