Étiquette : mozilla

Ubuntu : quand l’extrémisme libriste se rue sur un simple texte légal.

A croire que certains extrémistes libristes continue à faire des émules. La cause ? Un texte légal qui s’affiche au premier démarrage de Mozilla Firefox 3.0. Un « cluf » en plus léger et en plus lisible. Et voici qu’un tsunami de propos plus irresponsables et déconnecté de la réalité pleuvent sur l’un des logiciels libre parmi les plus connus.

Le bogue ouvert sur Launchpad vaut son pesant de cacahuètes coté extrémisme. Parmis les solutions proposées :

  1. Virer Mozilla Firefox de l’installation par défaut et le remplacer par IceWeasel, la version débianisée de Mozilla Firefox.
  2. Enlever carrément Mozilla Firefox et le remplacer par un « aBrowser ».
  3. Utiliser par défaut Epiphany (qui utilise le même moteur que Mozilla Firefox, mais sans le texte voué aux gémonies)

Stemp a pondu un billet sur son blog qui résume bien l’ambiance. J’ai envoyé le commentaire suivant, ignorant si Stemp l’effacera ou pas :

Désolé de le dire aussi cruement, mais cette histoire, c’est de la sodomie de mouche.

Passer à IceWeasel serait une erreur qui ferait perdre nombre d’utilisateurs à Ubuntu, car nombre de personnes qui utilisent pour la première fois Ubuntu ne reconnaissent souvent qu’une seule icone : celle de Firefox.

Le bug sur launchpad est gavée de haine, de crachats sur la fondation qui fait tout pour pondre un navigateur respectueux des utilisateurs et des normes.

La réponse risque d’être pour beaucoup : allez vous faire voir ubuntu, et ils resteront sur Windows, ou utiliseront une autre distribution.

Pour moi, ce bogue, c’est la signature de l’arrêt de mort d’ubuntu pour une frange non négligeable de ses utilisateurs, à cause de personnes trop plongées dans leur extrémismes libristes.

S’il y a une histoire à la « Abrowser », ma réponse sera : format et install fedora.

Triste à dire, mais je pense que je le ferais après près de 4 ans d’ubuntu (ma première ubuntu ayant été la dapper).

Cordialement,

Quelques liens pour compléter cette histoire, désolé, mais ils sont tous en anglais :

Le bogue 439604 qui reprend les arguments du bogue sur Launchpad. Le bogue 443918 qui a corrigé le problème sur les versions de développement et potentiellement sur les versions stables à venir.

L’argumentaire de Mitchell Baker, membre de la Fondation Mozilla.

Maintenant à chacun de se faire sa propre idée. Pour moi, si Intrepid Ibex suit une idée « extrémiste », mais réponse sera simple : même si je n’aime pas outre mesure la Fedora, elle m’accueillera à bras ouvert.

Les options d’optimisation agressives sont-elles inutiles ?

Dans une page de leur wiki les développeurs de Mozilla Firefox et des outils associés déclarent, je cite :

For Firefox 3 builds, please use –enable-optimize without flags.

Our testing has shown that different parts of Mozilla run faster at different optimization levels. For example, cairo, pixman and sqlite are compiled at -O2 because they are fastest at that level while the JS engine is fastest at -Os. [3] Don’t use –enable-optimize as a place to pass in random compile flags. That’s a global setting that sets optimization levels throughout the source tree and is different depending on the module being compiled.

If you still need to pass in other non-optimization flags to the compile, please use CFLAGS and CXXFLAGS instead of passing them to –enable-optimize.

Ce qui donne traduit :

Pour la compilation de Firefox 3, veuillez utiliser –enable-optimize sans options.

Nos tests nous ont montrés que les différentes parties de Mozilla sont plus rapides à différents niveaux d’optimisation. Par exemple, cairo, pixman et sqlite sont compilé en -O2 car ils sont plus rapide à ce niveau tandis que le moteur JS est plus rapide avec -Os. N’utilisez pas –enable-optimize comme un endroit pour insérer des options de compilations divers. C’est un réglage global qui définit les niveaux d’optimisation tout au long du code source et il diffère en fonction du module qui est compilé.

Si vous avez toujours besoin de passer des options de non optimisation au moment de la compilation, veuillez utiliser CFLAGS et CXXFLAGS au lieu d’utiliser la ligne –enable-optimize.

Continuer la lecture de « Les options d’optimisation agressives sont-elles inutiles ? »

Vers un « porn mode »…navigation en mode privée dans Firefox 3.1 ?

Le mode en navigation « privée » plus connue sous le surnom de « porn mode » est désormais à la mode… (Je sais, le jeu de mots est nul, mais on est vendredi, hein).

Qu’est-ce que le « porn mode » ? C’est tout simplement un mode de navigation qui laisse le minimum – voire aucune trace – des activités de l’utilisateur. En clair, un mode de navigation sur la toile de manière anonyme. Google Chrome appelle ce mode « Incognito », le futur – et monstrueusement copieur – Internet Explorer 8 parle du mode « In Private » – même si les résultats ne sont pas franchement probants.

Safari, le navigateur d’Apple propose ce mode « furtif » depuis environ 3 ans, depuis la version 2.0 de Safari, sortie conjointement avec MacOS-X Tiger.

Si on en croit cet atticle de Mozilla Links, le mode « furtif » serait donc de retour… Plus d’info ?

Le bogue de suivi de cette fonctionnalité : le bogue 248970. Et une page du wiki expliquant le pourquoi du comment de cette fonctionnalité.

Je mettrais des captures d’écrans dès que l’interface aura commencée à être insérée. Espérons que ce sera rapide 😉

Utiliser des versions de développement de logiciels de navigation, est-ce une folie ?

Cette question m’est venue soudainement à l’esprit. Je me suis aperçu que depuis l’an 2000 – p’tain, 8 ans déjà – que j’utilise des versions de développement de navigateurs. En effet, depuis l’an 2000, j’ai utilisé en compilant 99% du temps : la suite Mozilla de sa version 0.6 à la version 1.7.5, Mozilla Firefox depuis qu’il s’appellait Phoenix 0.1 (en septembre 2002).

Bref, cela fait donc 8 ans que je ne sais plus ce qu’est un logiciel de navigation en version stable. Serais-je donc un indécrottable geek accroc aux versions « bleeding edge » ?

Merci à une certaine Valérie – qui se reconnaitra – de m’avoir fait cette remarque 🙂

Concours de vitesse en javascript…

Dans un précédent billet, je parlais de l’impact de TraceMonkey sur les tests concernant la vitesse d’exécution de Javascript. J’ai donc voulu tester les performances de Firefox 3.0.1, Shiretoko pré-bêta1, Opera 9.60 bêta et du dernier Webkit en date sur les tests proposés par Google pour le moteur de javascript V8 qui équipe Google Chrome.

La lecture du résultat est simple. Avoir 100 comme score est la base. Plus le score est important, mieux c’est.

Continuer la lecture de « Concours de vitesse en javascript… »

Et SeaMonkey 2.0 dans tout cela ?

Alors que Shiretoko alpha2 vient juste de sortir (), j’ai envie de parler d’un certain SeaMonkey 2.0, qui se basera sur un Gecko 1.9.1 final (base de Firefox 3.1 alias Shiretoko).

Un bogue intéressant, c’est le bogue 394522 : « Migrate SeaMonkey preferences panes to use <preferences> »

En clair, c’est une volonté d’utiliser les outils du toolkit de Mozilla Firefox et de laisser tomber lentement mais surement le vieux code XPFE qui commence à prendre la poussière.

En effet, si on ouvre les préférences d’un SeaMonkey (version de développement) récente, on s’aperçoit d’un message, qui annonce que la migration est en route.

Le panneau des préférences en cours de migration

En ce qui concerne l’abandon du code XPFE dans SeaMonkey, le code a connu une purge dans ce domaine depuis quelques temps. Cf les bogues 380786 et 386906.

D’ailleurs l’alpha1 de SeaMonkey 2 ne saurait tarder, le code devant être gelé aux alentours du 9 septembre.

Ce sera une bonne nouvelle pour les fans du successeur de la suite Mozilla dont les buts sont précisés sur cette page.

Vrac’ons rapidement.

Un petit vrac rapide, sur le pouce.

C’est tout pour aujourd’hui.

Quel est l’impact de TraceMonkey ?

Je parlais dans un billet il y a une grosse semaine de l’arrivée du compilateur JIT pour le module javascript de Shiretoko du doux nom de TraceMonkey.

J’ai voulu voir le gain de vitesse pure en terme d’interprétation de javascript. Pour cela j’ai utiliser SunSpider, et différents navigateurs, à savoir Firefox 3.0.1, une pré-béta1 de Shiretoko compilée maison en suivant les options officielles de compilation.

A titre de comparaison, j’ai aussi testé Opera 9.52 et une nouvelle préversion d’Opera 9.60 qui sortira d’ici quelques semaines, et peut-être un peu avant Shiretoko prévu pour le début 2009.

Continuer la lecture de « Quel est l’impact de TraceMonkey ? »

Au moins, sauf contre ordre, pas de Shiretoko Alpha 3 ;)

Selon ce compte rendu de la Fondation Mozilla, le code de la version béta1 de Firefox 3.1 (connu sous le nom de code Shiretoko) est prévu pour être gelé le 9 septembre prochain. En ce qui concerne la version alpha2, selon ce billet du Firefox Extension Guru’s Blog, la sortie de la version alpha2 est prévue pour le 11 septembre.

En tout cas, il est certain d’une chose : il n’y aura pas d’alpha3. J’utilise une version de développement officielle pour rédiger ce billet, comme le prouve la capture d’écran :

Une préversion béta1 de Shiretoko sous Ubuntu Linux

Voir le bogue 452778 pour suivre la sortie de la version alpha2.

Tracemonkey has landed.

Derrière ce détournement d’une phrase célèbre prononcée en 1969 – wikipedia est votre ami – le compilateur JIT pour le module javascript que j’évoquais hier vient d’arriver sur le code de développement du tronc de Shiretoko, dont la version alpha2 est prévue pour bientôt.

En effet, ce matin, réveillé à 4 h 30 par mon chiot labrador de 9 mois, j’ai allumé l’ordinateur tout en sirotant mon thé. Et après le duo habituel hg --verbose pull ; hg --verbose update pour mettre à jour le code source, j’ai pu lire ceci :


pulling from http://hg.mozilla.org/mozilla-central/
searching for changes
adding changesets
adding manifests
adding file changes
added 1167 changesets with 2340 changes to 146 files

Quoique l’arrivée du code n’est pas encore super bonne. Après une tentative de compilation avortée, j’ai viré le répertoire de compilation, et relancé la dite compilation. Mais il semble y avoir un léger problème au niveau du fichier libxul.so… 🙁


../../staticlib/components/libgklayout.a(nsCanvasRenderingContext2D.o): In function `nsCanvasRenderingContext2D::PutImageData()':
nsCanvasRenderingContext2D.cpp:(.text+0x4165): undefined reference to `js_ArrayToJSUint8Buffer'
/usr/bin/ld: ../../staticlib/components/libgklayout.a(nsCanvasRenderingContext2D.o): relocation R_X86_64_PC32 against `js_ArrayToJSUint8Buffer' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld a retourné 1 code d'état d'exécution
make[4]: *** [libxul.so] Erreur 1
make[4]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx/toolkit/library »
make[3]: *** [libs_tier_toolkit] Erreur 2
make[3]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx »
make[2]: *** [tier_toolkit] Erreur 2
make[2]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx »
make[1]: *** [default] Erreur 2
make[1]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx »
make: *** [build] Erreur 2

Bref, c’est pas encore cela… Je sens que je vais ouvrir un petit bogue malgré la tentative pour que la compilation se fasse en code 64 bits, si j’en crois cette révision rajoutée récemment…


author David Anderson
Thu Aug 21 18:07:26 2008 -0700 (at Thu Aug 21 18:07:26 2008 -0700)
changeset 18331 7098e0020929
parent 18330 91fe6b5784bd
Fixed x86_64 build issue (accidentally trying to build 32-bit nanojit).

J’ai rapporté le bogue 451669. On verra bien 😉

Euh, après une petite recherche, il semblerait que le bogue 451242 soit responsable ici… Oups 😉