Étiquette : libre

Vrac’ rapide et libre.

Un petit vrac’ en passant.

Voilou, c’est tout pour aujourd’hui !

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… »

Comment se débarrasser des révisions multiples dans WordPress 2.6.

WordPress 2.6 lors de sa sortie a proposé une fonctionnalité de révision multiple, bien utile quand un blog est multi-utilisateur. Mais quand un blog n’a qu’un seul rédacteur, on se retrouve avec souvent 10 à 15 révisions sur un billet, ce qui remplit vite la base de données et ralentit un peu l’ensemble du logiciel.

Faisant quelques recherches, je suis tombé sur ce billet qui propose une requête à exécuter pour éliminer les révisions superflues.

Bien entendu, la base de données doit avoir une copie en lieu sûr avant d’effectuer toute manipulation. Il suffit d’aller dans l’interface PHPMyAdmin de votre hébergeur, et de rentrer la requête SQL suivante :

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

Si tout se passe bien, vous pourrez lancer une optimisation de la table. J’ai pu récupérer par loin d’un petit méga-octet sur ma table sql concernant WordPress, passant de 6,5 à 5,8 Mo. 3 ans d’utilisation de WordPress, cela finit par peser 😉

Sinon, il existe une petite extension pour WordPress qui s’appelle Revision Control et qui permet de gérer le nombre de révisions au cas par cas.

Bon blog 🙂

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.

Les brevets logiciels ? De la bétise pure et dure.

Récemment, Microsoft a prouvé que les brevets logiciels sont de la bétise pure et simple… Il a déposé un brevet pour les touches « Page Up » et « Page Down » qui existent sur les claviers depuis des années… Et sûrement depuis le premier IBM PC de 1981.

Mais ce n’est pas le premier coup d’éclat de Microsoft dans ce domaine. Un brevet est passé un peu plus inaperçu. Le brevet 6,775,781 déposé en 2000 et accepté en 2004 décrit le fonctionnement de Sudo, outil qui date de 1980 !

Dans le jargon technique, on décrit comment un processus initié par un utilisateur simple peut être autorisé à avoir les pleins pouvoir pour effectuer une tache administrative : installation de logiciels par exemple.

Sudo est un outil qui date de l’époque ancestrale des premiers BSD (1980) et qui donc est la preuve de l’existence de ce concept largement avant le dépot du brevet.

On peut lire sur la page de l’outil sudo :

« Sudo was first conceived and implemented by Bob Coggeshall and Cliff Spencer around 1980 at the Department of Computer Science at SUNY/Buffalo. It ran on a VAX-11/750 running 4.1BSD. An updated version, credited to Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso and Don Gworek, was posted to the net.sources Usenet newsgroup in December of 1985. »

Ce qui donne traduit :

« Sudo a été conçu et implementé par Bob Coggeshall et Cliff Spencer aux alentours de 1980 au département de science informatique de SUNY/Buffalo. Il se lançait sur un VAX-11/750 utilisant 4.1BSD. Une version mise à jour, à mettre au crédit de Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso et Don Gworek a été posé sur le forum Usenet net.sources en décembre 1985 ».

Le code source de l’outil « asroot » devenu « sudo » est toujours disponible et lisible via google groups.

L’UAC – introduite avec une préversion de la béta 2 de Windows Vista en février 2006 – n’est que la partie graphique de ce mécanisme. Cependant, l’UAC n’est pas la première interface graphique dans ce domaine.

GKSu existe depuis pas mal de temps. Cet outil graphique pour Su et Sudo existe depuis… février 2004 ! On peut en effet récupérer le code source de gksu 1.0.3 depuis cette page : http://people.debian.org/~kov/gksu/old_stuff/1.0/

La preuve en image… GKSu à l’oeuvre avec une Ubuntu 5.10 (octobre 2005) dans une machine virtuelle sous VirtualBox 2.0.

GkSu sous Ubuntu 5.10

Comme quoi, quand vous verrez des articles élogieux sur telle ou telle fonctionnalité de tel ou tel OS (Windows, Linux, MacOS-X), vérifiez donc que ce n’est pas la pâle copie d’une technologie qui existe déjà.

Acid3… Même Firefox 1.0 bat le score d’Internet Explorer 8 bêta 2.

Dans un précédent article, j’avais profité de la sortie de Google Chrome pour comparer la consommation mémoire des principaux navigateurs. Et le résultat d’Internet Explorer 8 bêta 2 au test acid3 faisait quand même pitié à voir en comparaison de la concurrence. A peine 21 / 100…

Ayant installé une vieille distribution Ubuntu Linux (la Breezy Badger, alias 5.10, octobre 2005) dans une machine virtuelle sous Virtualbox 2.0 pour les besoins d’un article qui va bientôt être rédigé, j’ai voulu voir comment s’en sortait des vieilles versions de Mozilla Firefox. J’ai donc essayé avec Mozilla Firefox 1.0.7 (la version 1.0.0 datant de novembre 2004), Mozilla Firefox 1.5.0.10 (la version 1.5 datant de novembre 2005) et la version 2.0.0.16 (la version 2.0 datant de novembre 2006). Pour ce dernier, j’ai récupérer la version 2.0.0.16 depuis le site de Mozilla-Europe.

Les résultats sont sans appel…

Mozilla Firefox 1.0.7 : 35 / 100

Firefox 1.0.7 et Acid 3

Mozilla Firefox 1.5.0.10 : 53 / 100

Firefox 1.5.0.10 et Acid 3

Mozilla Firefox 2.0.0.16 : 52 / 100

Firefox 2.0.0.16 et Acid3

Faut-il en conclure que sur certains plans, le moteur d’affichage d’Internet Explorer 8 bêta 2 a quatre bonnes années de retard à récupérer ? On pourrait le penser aisément.

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.

gNewSense 2.1 : vraiment libre ? ;)

Derrière ce titre polémique se cache le test de la dernière gNewSense en date : la version 2.1. Cette distribution dérivée de la Ubuntu 8.04 LTS se veut libre des pilotes propriétaires et de tout ce qui n’est pas libre, au sens développé par la Free Software Foundation. J’avais déjà testé une version au moins d’avril dernier.

Parmis les nouveautés agréables de cette distribution qui n’a pas encore de version 64 bits, un écran de démarrage comme celui des distributions classiques. J’ai utilisé une machine virtuelle kvm avec les lignes de commandes habituelles :

fred@fred-laptop:~/download$ qemu-img create -f raw gnew.img 32G
Formatting 'gnew.img', fmt=raw, size=33554432 kB
fred@fred-laptop:~/download$ kvm -m 768 -hda gnew.img -k fr -localtime -soundhw es1370 -usb -cdrom gnewsense-livecd-deltah-2.1.iso -boot d &

Ecran de démarrage de gNewSense 2.0

Après une installation simplissime, et avoir trafiqué le fichier xorg.conf pour avoir une résolution 1024×768 à la place d’une résolution 1280×800, j’ai un environnement aux jolis tons bleutés.

Pas de Mozilla Firefox, mais un Epiphany renommé WebBrowser.

epiphany-2.22.2 sous gNewSense

Il semblerait que gNewSense ait « virer sa cutie » et propose des logiciels utilisant Mono, implémentation libre du .net framework de Microsoft qui est tout sauf une technologie libre de tout brevet. Ce qui ne donne pas franchement envie d’utiliser une telle technologie, surtout avec le passé remplis de cadavre de la firme de Redmond (Netscape, OS/2, Wordperfect, Lotus-1.2.3 etc…)

F-spot, logiciel en mono sous gNewSense

Qui nous piquait déjà une crise pour un simple logo dans Mozilla Firefox ? 🙂

Comme dans mon précédent article, flash est remplacé par Swfdec, et Java par IcedTea.

flash à l'action sous gNewSense

java sous gNewSense

Que dire pour conclure : que gNewSense semble enfin être utilisable par des personnes qui sont des fanatiques du logiciel libre, mais vraiment les fanatiques de chez fanatiques 🙂

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 😉