Install Multiple 'Bleeding Edge' Firefox Versions in Linux

Posted by hkwint on Mar 24, 2010 11:01 PM EDT
LXer Linux News; By H.Kwint - The Netherlands 		Mail this story
Print this story


LXer Feature: 24-Mar-2010

Whether you want to run the newest and safest version of Firefox or you want to test a new Alpha, it might happen the package manager of your Linux distribution doesn't include the version you want. In this article we'll look at ways to install the newest version beyond the package manager, and even better: Running multiple Firefox versions on the same system - even at the same time!

Firefox 3.6.2



March 23rd, the German government project Bürger-CERT warned against using Firefox versions before 3.6.2. Though I was not sure if this vulnerability also applies to Linux versions of Firefox, I decided to update as quickly as possible. For Windows users, it's easy: Firefox tells them there's a new version, Mozilla did the Quality & Assurance testing of the new version, so they can click on 'Update available' and they're up to date and less prone to exploits.

For Linux users however things are not so easy. They have to rely on their distribution for the Q&A, and they will have to wait for the package maintainers to include the newest version of the browser. I use Gentoo, and there's no company behind it. Though it has a pretty big community, it is not nearly as big as the Debian community. As a result of this Gentoo isn't normally the first distribution to ship the newest versions of software. As a result, 3.6.2 was not yet available for Gentoo, though it was recommended by Mozilla.

If you want to install the newest pre-compiled version anyway there are roughly speaking three manners to do it: The good, the bad and the ugly.. Let's start with 'the good' way. That's waiting for the newest version to appear in your software repository. If not, your distribution will have guidelines how to ask for it. For Gentoo, this means filing a bug report and kindly asking if someone can make a 'recipe' (in Gentoo terms: ebuild) for the newest package. For other distributions, this means someone will have to compile and 'package' the result and submit it. However, Gentoo package maintainers are volunteers who have a life beyond Gentoo, and one thing they don't like is being bugged about a new version several times every three seconds after a new minor version is out. Normally, the package maintainers will know a new version is out before most users do anyway.

So let's progress to the bad way: About the same as the Windows way, but worse. Mozilla provides pre-built binaries on their website. Someone might download these, unzip and run them. Probably, you're probably going to be OK if you do this. However, this means 'bypassing' your package manager and this may lead to unexpected results: Dependencies might not be met, or the binary Mozilla provided may not be aware of quirks specific to the distribution you're using. Also, un-installing might be a problem.

Therefore I decided to use the ugly way: That's providing your own recipe or package. In Gentoo chances are big this is really easy, probably much easier than for any other distro as I will show. What you're basically doing is, take an 'old' recipe and just change version numbers in the file name. That's all it takes to make a new ebuild! After that Gentoo's package manager 'portage' is ready to install it. Of course there's no guarantee this will work, and you're on your own for supporting this dirty hack. Nonetheless, it worked flawlessly in this case. Here's how you do it:

# cd /usr/portage/www-client/firefox-bin

This is where the recipes for 'pre-compiled Firefox' live. Note the recipes of 'compile it yourself' Firefox are in www-client/mozilla-firefox. For the following steps, be sure you're root, or use sudo for the following steps. Now copy:

# cp firefox-bin-3.6-r1.ebuild firefox-bin-3.6.2.ebuild

Note for future reference: firefox-bin-3.6-r1.ebuild is the existing recipe, and 3.6.2 the one that didn't exist yet. When 'ebuilding' portage, it will look at the file name to decide which version number it should download. However it also does file fingerprint checking: it checks the files to download against given hashes. But it doesn't know about the 3.6.2 files yet so it doesn't have the right fingerprints. The following is at your own risk, as you're going to create your own fingerprints and _you_ are the one going to say the downloaded files are trustworthy:

#ebuild firefox-bin-3.6.2 digest

This will download all files, assume whatever is downloaded is the right thing and add fingerprints to the fingerprint-file, the one called 'Manifest'. Now we're ready to install! As time of this writing, the existing 3.6-r1 is still not deemed stable. That's to say, the package maintainers are not sure if it's stable yet. This is comparable to the 'testing' branche other distributions use, and in Gentoo it's called 'keyworded'. By default, portage doesn't install 'keyworded' packages, so we have to inform portage it's ok. One way to do this is:

# echo =www-client/firefox-bin-3.6* ~x86 >> /etc/portage/package.keywords

Now you can proceed with

# emerge -p firefox-bin

as usual, and if it suggests to install 3.6.2 as we wanted, you're ready to go and remove the '-p' (pretend) and portage will install 3.6.2. When done, be sure to run Firefox-bin and not just 'firefox', as 'firefox' will refer to the 'compile yourself' www-client/mozilla-firefox and both can be installed at the same time using different versions on Gentoo.

Firefox 3.7-alpha4

Then, we proceed with Firefox 3.7-alpha4. Please don't run this version before you have read the following paragraph about "Multiple versions"! Otherwise you might screw your existing Firefox profile, so you're warned! It's a good idea to back up your ~/.mozilla directory before proceeding. I proceed using the 'bad' way. Installing this one is pretty easy: Download your zipped archive from Mozilla. I chose firefox-3.7a4pre.en-US.linux-i686.tar.bz2. Move it to some dir where it can't cause harm, in my case it's ~/sys. unzip it:

tar -xvjf firefox-3.7a4pre.en-US.linux-i686.tar.bz2

You can delete the archive file if you want, and rename the resulting directory to Firefox-3.7 if you like claritiy. Then, you can simply cd to Firefox-3.7, and there's your binary! Please note, it's probably not in your $PATH (it shouldn't be!), the directories where your system looks if you want to start some command. So, to run this version, you have to manually cd to the directory where you unzipped 3.7 and manually run ./firefox. Note this 'tree' isn't "installed" on your system - which makes this solution only 'halve bad' - it can be considered a portable version of Firefox. That's why it's easy to remove. Say I wanted to remove this Firefox 3.7, all I would have to do is:

rm -rf ~/sys/firefox-3.7

Now, let's run our new version, but not before we give it its own profile!

Multiple versions

Now, besides 3.6.2 installed in the first paragraph, we're going to run 3.7a4, the newest alpha at times of this writing. To do this, we need multiple profiles to make sure a 3.6 profile won't crash 3.7 and the other way around. Also, as 3.7 is considered 'Alpha' it shouldn't touch our 'production' profile for 3.6. Here's how to proceed: In a console, run (as your normal user):

$ firefox-bin -ProfileManager

Now a window will open listing your available profiles. In my case the default profile is named "71vcz8af.default". I rename that one to "3.6". Then I say: Create profile, and a wizard will make a new profile for me. You can give your new profile a name, in my case I call the new one: "3.7". However, I don't want it to be populated by FF 3.6, so instead of "Start Firefox" I choose "Exit". We now have our profiles in place, and it's time to consider the -no-remote option. When you or some other application (many do!) run 'firefox URL' from the command line, firefox would normally look to see if there's already an open window of Firefox. But we don't want 3.6 and 3.7a to interact, so whenever we start one of the two, we run 'firefox-bin -no-remote'.

If you start Firefox with this option, it will start a new instance of Firefox instead of adding a tab to the current open Firefox window. Now, we have to make sure 3.6 starts with the old profile. I use WindowMaker as my desktop environment, so I map my Firefox shortcut key / start menu entry to "/usr/bin/firefox-bin -P 3.6 -no-remote'. The /usr/bin part is the part which makes sure my 'global' system Firefox is started (the one that's installed), and the "-P 3.6" part is the part which makes sure the 3.6 profile is used. Now if I simultaneously wanted to run 3.7, here's how to do it:

$ cd ~/sys/firefox-3.7
$ ./firefox -P 3.7 -no-remote

Here the ./ part is what makes sure I'm running the executable in this directory, and not from $PATH, which would normally default to /usr/bin/firefox - and that might be another version. The "-P 3.7" part, as you might have guessed, makes sure it's run with the new 3.7 profile.

Enabling WebGL

One of the new cool things about 3.7 is that it supports a mapping of JavaScript to OpenGL, called WebGL. In other words it enables websites to use hardware 3D acceleration. To enable this, go to about:config in your Firefox 3.7alpha. Type 'webgl' in the filter bar, and set 'webgl.enabled_for_all_sites" to true. To be secure, you might set dom.ipc.plugins.enabled to false. Now you can fully enjoy the WebGL demos on the web using hardware acceleration. For example, how about this shiny teapot you can rotate with the mouse (leftclick / drag)? If you hold Ctrl and use the mouse wheel, you can even zoom!

Installing Flash 10.1 beta

One of the big annoyances I have with Firefox is that it always becomes unstable and hangs after watching a few Youtube vids. This also goes for Opera. This is caused by the shitty Flash plugin provided by Adobe, most Linux users will probably have 10.0.45. However, Adobe bettered its life with 10.1 beta it seems, but it's not in most software repositories as far as I can tell. Therefore we're going to use the 'ugly' method again to install this one. It's rather easy: In the url-bar of Firefox I type 'flash beta linux' and I hit enter. In the green square on the right, I choose: Get the Flash Player 10.1 pre-release.

In the next screen, I click "Download plug-in for Linux (TAR.GZ). I unzip it and move 'libflashplayer.so' to ~/.firefox/plugins, and I'm done! To be sure, I uninstalled www-plugin/adobe-flash from my system. Restart Firefox, 3.6 or 3.7 doesn't matter, go to about:plugins, and with a bit of luck it will tell you it's running Shockwave Flash 10.1d 51 (or higher!). What I noted using this 'pre-release' is that, even though it's not that well tested yet, it's not as cripple as 10.0.45 and I can watch multiple Youtube vids consecutively without Firefox hanging.

JaegerMonkey

As a last part of my journey into 'bleeding edge' Firefox I wanted to install the 'highly experimental' JaegerMonkey (JM) javascript (js) engine, slated to replace SpiderMonkey in the near future. The story is a bit complex, so here's my short version of it: Firefox comes with a js interpreter called SpiderMonkey - which is slow, and a highly optimizing engine called 'TraceMonkey' which is 'super awesome fast'. However, when something cannot be optimized by 'tracing' by TraceMonkey, Firefox falls back to interpreting using SpiderMonkey, and that's why javascript in Firefox is pretty slow sometimes. The people behind JM hope to solve this by means of 'replacing' the SpiderMonkey interpreter by using Apple Webkits 'Nitro' JIT (Just In Time compiler) instead of interpreting. So, when it makes sense, be 'super awesome fast' by means of tracing, and if not, fall back to 'still really fast' using Nitro.

Building JM is not that hard, you have to do a 'clone' using the Mercurial source control management tool (one Gig of downloading in my case), then you have to configure with "-enable-methodjit' and than you have a command line javascript interpreter called 'js'. However, I didn't understand this command line interpreter was all that is supported at this moment, even though the JM wiki clearly states so: "Currently we only support shell builds". I had to ask on IRC and some kind soul explained to me integrating JM in FF wasn't supported yet, and it might be a good idea if the JM wiki stated it was 'absolutely, absolutely, absolutely not intended for end users, only for developers discussing the direction of the project'. I agree, but nonetheless it's interesting.

For what it's worth: I downloaded Google's V8 benchmark suite (easy to 'wget') and ran version 5 of it using the JM command line interpreter. With the -m switch, it uses the new method-jit, and without the switch it doesn't. With the switch and the JIT enabled, I reached a 38% higher score than without it, but I'm not really sure of this results given I'm not a developer and it was the first time I ever compiled a js-engine and ran benchmarks using the command line version of said js-engine. But anyway, if you're an end user and you're not sure of what you're doing and you're using something aimed at developers only, chances are you finally reached the bleeding edge!

Conclusion

So what did we learn? Windows users are lucky, being served with well tested upgrades which are easy to install. Linux users are lucky having multiple ways to install new versions. It's pretty easy installing and using some new Alpha version of Firefox in Linux. Installing and running multiple versions of Firefox on Linux is not that hard, as long as you know what you're doing and keep them apart. WebGL is really cool, and it will change the cloud: It's theoretically possible CAD and games will be web-based running on fat power hungry x86 servers and available from power efficient ARM-netbooks and smart phones acting as clients, where rendering is done with hardware acceleration of the ARM portable devices!

Flash 10.1 beta is much better than the old cruft Adobe supplied when it comes to using your browser as a Youtube-player, but OGG video (OGV) is still even better of course. People in #developers of irc.mozilla.org are friendly to lost end-users trying to achieve something that's impossible even when the Wiki clearly says so. And JaegerMonkey will bring faster javascript to Firefox. Finally let's end with a screenshot showing my result:

Screenshot of multiple Firefoxes
That's it, I'm thirsty: Time for a Jägermeister.

  Nav
» Read more about: Story Type: LXer Features, Tutorial; Groups: Community, Gentoo, Linux, Mozilla

« Return to the newswire homepage

Subject Topic Starter Replies Views Last Post
Firefox security issue does not affect Linux Sander_Marechal 0 2,371 Mar 25, 2010 5:57 AM

You cannot post until you login.