Le blog d'un internaute aimant le logiciel libre, la musique et la rétro-informatique !
Mis à part le jeu de mots raté, et bien que je n’aime pas trop gwibber, il est désormais obligatoire de passer à sa version 2.31.91 pour accéder à Twitter. En effet, le service demande désormais une authentification.
Voila ce que cela donne :
Quand à Pino, difficile de rester optimiste, lorsque l’on sait que la dernière modification du code source date du 3 juillet, et que celui-ci ne compile pas avec des versions récentes de vala…
Tracker, c’est le moteur d’indexation et de recherches de fichiers de l’environnement de bureau Gnome.
Bien qu’une version 0.8.xx soit disponible, la version de développement 0.9.18 (au moment où j’écris cet article) est très facilement récupérable. Attention, comme toute version de développement, elle peut vous exploser à la figure 😉
A noter que depuis la version 0.9.16 – et uniquement en cas d’installation du logiciel en utilisant le code source (ce qui est somme toute assez courante sous des systèmes unix) – il faut installer Vala. Dans mon cas, j’ai utilisé le paquet AUR vala-devel, qui propose la version 0.9.7 du langage. Cf http://git.gnome.org/browse/tracker/tree/NEWS
Le code étant encore en développement, l’indexation semble assez longue, à moins que la lenteur constatée ne soit liée à la compilation d’une version de Minefield en même temps 😉
Un bug assez ennuyeux, pour ne pas dire qu’il facilite franchement le transit intestinal, semble que dans la version stable, tracker semble oublié le contenu qu’il a indexé, dès qu’on ferme la session 🙁
Bref, j’ai récupéré le précédent PKGBUILD, laissé à l’abandon par son créateur, et je l’ai modifié pour qu’il soit à jour, et surtout compilable.
Pour l’installer, il suffit de taper dans une console un petit : yaourt -S tracker-git
Et d’attendre en croisant les doigts 😉
Ce que l’on constate, c’est désormais que bien que l’interface n’ait que peu changé, elle est unifié quand on utilise le clic-droit sur l’icone en forme de loupe. L’entrée « courrier » est grisée. Cela doit être lié à la non-utilisation de ma part du logiciel de courrier Evolution, client officiel de Gnome.
Sinon, l’interface de recherche est toujours aussi claire. Et aussi complète 😉
Et comme disait la publicité pour un fabricant de compatible PC dans les années 1980-1990 : « A suivre ! »
La version 1.9 de Xorg-Server vient d’être rendu disponible sur Archlinux. Si on utilise le pilote propriétaie nVidia, il peut y avoir un problème de lancement de Xorg.
En me basant sur des infos trouvé sur le paquet AUR xorg-server-dev, il faut rajouter le fichier 10-ServerFlags.conf dans /etc/X11/xorg.conf.d/ avec le contenu suivant :
Section « ServerFlags »
Option « IgnoreABI » « True »
EndSection
Et normalement, après la mise à jour de Xorg-server en version 1.9, aucun problème 😉
Dans un article récent, je parlais du progrès fait par la pré-beta5 de Mozilla Firefox 4.0, alias Minefield.
J’ai voulu voir où en était les deux autres grands noms des moteurs de rendu du logiciel libre, à savoir Chromium (et son moteur de Javascript v8), et Webkit (et son moteur de Javascript Nitro).
J’ai donc fait compilé les deux via AUR, aussi bien pour chromium-browser-svn et webkitgtk-svn. En sachant que pour le second, je ne l’ai pas installé, histoire d’éviter des conflits avec les logiciels de ma machine.
La compilation du code source de Chromium demande pas mal d’espace… 4,5 Go environ…
[fred@fredo-arch chromium-browser-svn]$ pwd
/home/fred/download/chromium-browser-svn
[fred@fredo-arch chromium-browser-svn]$ du -sh src/
4,5G src/
Webkit est quant à lui, largement moins gourmand : à peine 720 Mo.
[fred@fredo-arch webkitgtk-svn]$ pwd
/home/fred/download/webkitgtk-svn
[fred@fredo-arch webkitgtk-svn]$ du -sh src/
722M src/
Une fois les deux logiciels compilés, j’ai utilisé v8 benchmark, sputnik (pour vérifier le niveau de compatibilité avec les normes définies du langage javascript), et html5test, pour finir, histoire de voir le niveau d’avancement de ce nouveau standard du langage html.
Chromium, qui se définit comme une version 7.0.501 (7ième version, déjà, en l’espace de quoi, deux ans ?), explose largement le score au niveau du Javascript… 4961 points, soit 4,45 fois plus rapide que Mozilla Firefox 4.0b5pre… Autant dire que la Fondation Mozilla a de la marge.
Coté respect des normes javascript, le score est plutôt bon : 5109/5246, soit un niveau de respect de… 97,38%.
Enfin, en ce qui concerne html5test, Chromium fait mieux que Mozilla Firefox, avec un score de 222 points et 10 points de bonus.
En ce qui concerne Webkit, j’ai utilisé l’outil GtkLauncher, qui offre une interface basique pour Webkit.
[fred@fredo-arch Programs]$ pwd
/homefred/download/webkitgtk-svn/src/webkit-build/Programs
[fred@fredo-arch Programs]$ ./GtkLauncher &
Le score du moteur de Javascript bien que moindre que celui de v8 reste honorable : 2984 points au benchmark v8, soit 2,67 fois le score de Mozilla Firefox 4.0b5pre. On comprend pourquoi la Fondation Mozilla veut intégrer Nitro dans son code source 😉
Coté sputnik, le score est vraiment bon : 5069/5246, soit un niveau de respect de 96,62%
Enfin, en ce qui concerne html5, le score est inférieur à celui de Mozilla Firefox et de Chromium, avec seulement 195 points et 12 points de bonus.
J’allais oublier, le score de Mozilla Firefox 4.0b5pre pour sputnik : 4978/5246, soit un niveau de respect de 94,89%
Mis à part la vitesse d’exécution, le respect du html5 et des normes javascript sont une marque de fabrique de moteurs de rendu libre. Les moteurs de rendus non-libre ? Je ne saurais dire, je ne les utilise pas 😉
Il y a une quinzaine de jours, je parlais d’une préversion de la 4ième béta de Mozilla Firefox 4.0. Désormais, on peut penser que la 4ième béta ne saurait tarder, étant donné que l’identifiant est le suivant :
Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b5pre) Gecko/20100819 Minefield/4.0b5pre
Coté test, n’ayant pas encore eu l’occasion de tester sunspider, je ne ferais que citer les chiffres brut, en faisant une différence entre les deux versions, séparées de 15 jours. La version de Minefield a été compilée environ 15 minutes avant la publication de l’article :
html5test.com : on arrive à un score de… 214 points… 14 points de mieux, ce qui est franchement pas si mal que cela 🙂
v8, test de vitesse de javascript : on passe de 1035 à 1114… Une progression de… 8%… Pour info, ma machine est propulsée par un AMD Athlon(tm) II X2 215 Processor (qui tourne de 800 à 2700 Mhz).
Bon, on est loin des scores d’un Chromium, mais le progrès est présent 😉