Profiter de Mozilla Firefox 3.5rc2 sous linux 64 bits.

Cet article est écrit à titre « pédagogique » et de culture générale informatique. Etant donné qu’il n’y a pas de version officielle de Mozilla Firefox 3.5rc2 en 64 bits pour linux, j’ai décidé de montrer comment faire.

Mozilla Firefox 3.5rc2 pour linux en 64 bits

Je me base sur une ArchLinux 64 bits, à jour, avec Xfce 4.6.1 (installé en utilisant le wiki anglophone. D’ailleurs, pour faire une digression rapide, si vous avez des problèmes avec le volume, installer le paquet oss et rajouter le daemon oss à la ligne DAEMONS du fichier /etc/rc.conf est radical pour corriger le problème).

Bref, en me basant sur la documentation disponible ici (notamment les pré-requis), on peut se faire un environnement de compilation facilement.

Pour autoconf-2.13, il faut utiliser le paquet autoconf-compat, disponible sur aur.archlinux.org via l’outil yaourt :

yaourt -S autoconf-compat

Une fois le code source récupéré depuis http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5rc2/source/, il suffit de décompacter le code source et de rajouter le fichier .mozconfig suivant :


export AUTOCONF=autoconf-2.13

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-fx

ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --disable-tests

Pour lancer la compilation. On se rend dans le répertoire du code source, à savoir mozilla-1.9.1 puis dans un terminal :


make -f client.mk depend
make -f client.mk build

Il faut compter entre 45 minutes et une heure.

Ensuite, il faut aller dans le répertoire objet où se trouve le code compilé :


cd ../objdir-fx
make package

Le logiciel se trouve dans le répertoire objdir-fx/mozilla/dist/. Une archive tar.bz2 est disponible. Il suffit de la décompacter dans un répertoire ailleurs pour obtenir un firefox indépendant du code source. Par exemple dans un répertoire applications 😉

Le plus simple est de créer un lanceur.

On peut récupérer le paquet de traduction française ici :

http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5rc2/linux-i686/xpi/

Une fois le paquet installé, il faut modifier une valeur dans about:config, il s’agit de general.useragent.locale à modifier en fr.

Une fois Mozilla Firefox relancé, la VF nous accueille.

J »aurais très bien pu utiliser le paquet proposé par AUR, mais je voulais avoir une version aussi proche que possible du code officiel.

En vrac’ rapide et plutôt libre ;)

Un petit en vrac’ rapide et plus ou moins consacré au logiciel libre.

Pour finir, l’obligatoire capture d’écran : Liferea 1.6rc4 sous Archlinux 64 bits.

liferea 1.6rc4 sous Archlinux 64 bits

Chromium, soit. Mais quid de Midori ?

Midori – en dehors de devenir le navigateur de l’environnement Xfce – partage le même coeur de rendu de pages Web, à savoir webkit. En dehors du fait que Chromium n’existe qu’en version 32 bits (pas de version native 64 bits), j’ai voulu voir les différences… Et si Chromium est finalement si intéressant que cela.

Dans ce but, j’ai installé dans une ArchLinux 64 bits dans une machine virtuelle kvm un environnement Xfce 4.6.1 avec la dernière version en date de Midori, la 0.1.7.

En dehors du fait de passer sans aucun problème Acid3, le score obtenu par Midori sur la 4ième version du test de rapidité du moteur V8 de Google Chrome. En effet, le score obtenu est de 871 points.

Chromium, une fois toutes les dépendances 32 bits installées, obtient un score de… 1025 points seulement… 17,68% plus rapide. Le moteur de JS v8 ne serait donc pas rapide que cela ?

D’ailleurs, le test acid3 est passé par Chrome, mais de manière imparfaite. Donc, on peut faire tout un tapage sur Chromium, mais il risque de fermer sa bouche bientôt sur Linux par rapport à Midori…

Maintenant, il est sûr que la puissance de frappe commerciale de Google est largement supérieure à celle de Midori et de ses développeurs…

Acid3 : un test pour des technologies récentes ?

C’est ce que pourrait faire penser le score « catastrophique » de la future version de Microsoft Internet Explorer, la 8.0.

Or, les technologies testées sont assez vieilles pour l’immense majorité. En effet, sont testés le niveau de compatibilité des technologies suivantes :

Donc, si l’on regarde bien, la grande majorité des technologies testées ont au maximum 8 à 9 ans d’age…

C’est peut-être ici qu’il faut trouver l’explication pour le « si bon » score de Netscape 7.0.2, basé sur Gecko 1.0.2. Tout simplement que depuis le début du développement de Gecko (1999, donc déjà 10 ans), l’accent est mis sur les normes ouvertes édictées par le W3C.

Enfin, je ne prétends pas être un expert dans le domaine des normes du W3C, mais simplement une personne qui observe les résultats obtenus.

Oui, IE8 a 7 années de retard technologique sur la concurrence !

Du moins sur le plan du supports des normes définies internationalement par le W3C dont Microsoft est membre.

Dans mon précédent article, j’ai été estomaqué de voir que Netscape 7.0.1 avait un meilleur score que Microsoft Internet Explorer 8.0 alors que les deux logiciels sortent avec 7 années d’écart.

J’ai donc voulu vérifier une nouvelle fois, mais j’ai utilisé la vénérable distribution linux Slackware 9.0 (sortie en 2003) pour valider les résultats précédemment obtenus. J’ai récupéré l’ISO de cette distribution (noyau linux 2.4.20) sur un miroir, puis je l’ai installé dans une machine virtuelle VirtualBox.

Pour des raisons de légèreté, j’ai utilisé WindowMaker comme gestionnaire de fenêtres, puis j’ai lancé Netscape 7.0.2 et demandé l’affichage du test Acid3. Résultat sans appel : 36 / 100.

36/100 pour Netscape 7.0.2 au test acid3 avec la Slackware Linux 9.0

Que la version 8.0 de Microsoft Internet Explorer soit améliorée, cela ne fait aucun doute. Mais combien de temps faudra-t-il pour que certaines vieilles technologies soient enfin implémenté dans le navigateur majoritairement utilisé sur la toile ?