Catégorie : Internet

Vous savez, le grand réseau de pirates qui ruinent les gentilles majors du disque…

Merci Gnome-Unstable… Où comment j’ai pu installer Gnome 2.32.0 avant l’annonce de sa sortie officielle sur Archlinux ;)

Le dépot « Gnome Unstable » – comme son nom l’indique – permet d’installer en avant première l’environnement de bureau Gnome sur Archlinux.

Pour activer son utilisation, il faut rajouter en haut de son fichier /etc/pacman.conf les lignes suivantes :

# Gnome Unstable
[gnome-unstable]
Include = /etc/pacman.d/mirrorlist

Puis de passer à un petit :


yaourt -Syu

Paquets à mettre à jour

récupération de près de 200 Mo... Seulement ?

Bien que l’annonce officielle sera disponible dans la journée du 30 septembre, l’environnement de bureau est déjà disponible. Les seuls problèmes que j’ai rencontrés ?

  1. Obligé de réinstaller le paquet gdk-pixbuf2-2.22.0-1-x86_64.pkg.tar.xz à la mimine.
  2. Obligation de recompiler certaines dépendances de Gwibber 2.32.0. Mais ensuite, cela n’a été que du bonheur.

Gnome 2.32 et Gwibber 2.32...

Je ne me suis pas encore plongé dans les nouveautés, mais à ce que j’ai pu voir, les changements sont plus internes qu’externes. Le grand ravalement de façade étant l’arrivée du Gnome Shell dans Gnome 3.0 en mars 2011…

Je n’aurais plus qu’à désactiver le dépot une fois que Gnome 2.32 sera officiellement disponible. Mais je crains que le passage Gnome 2.32 vers 3.0 ne soit pas aussi facile que de la version 2.30.x à la 2.32…

Javascript contre-attaque ;)

On va se la jouer un peu George Lucas… Après un premier épisode sur la guerre du JavaScript, j’ai voulu voir les progrès fait en une grosse vingtaine de jours sur le plan de l’implémentation du JavaScript dans le futur Mozilla Firefox 4.0

Alors que la béta 7 commence à se faire un peu attendre, les modifications apportées à Jaegarmonkey sont assez régulières.

Pour mémoire, dans le précédent test, les résultats à SunSpider était de 478 ms et le score obtenu au benchmark v8 était de 1859 points.

Avec une compilation d’aujourd’hui, le 29 septembre, on a des scores bien meilleurs :

Sunspider : 440,9 ms. 38 ms de moins, soit un gain de 7,94%.

440 ms à SunSpider avec Minefield 4.0b7pre

v8 : 2236 points, soit un gain de 20,28% !

2236 points au benchmark v9 avec Minefield 4.0b7pre

Autant dire que la vitesse du JavaScript commence à devenir réalité 🙂

J’allais oublier les détails technique : Archlinux testing à jour, avec Gnome 2.32, le tout avec une machine à base d’Athlon X2 215, 3 Go de mémoire vive, et une carte nVidia GT210 en PCI-Express 16x.

Et pour éviter toute interférence, j’ai utilisé un profil fraichement créé. Voila, vous savez tout.

En vrac rapide plus ou moins libre ;)

Fin de semaine, un « en vrac' » s’impose.

Bon week-end.

Quand Microsoft ment encore une fois… Cela augure mal pour Internet Explorer 9

Dans la série des mensonges de Microsoft (cf l’épopée des « get the facts »), voici les mensonges sur les qualités supposées supérieure du navigateur Internet Explorer 9 (qui ne tournera que sur MS-Windows Vista et MS-Windows 7).

Dans une page, Microsoft compare Chrome 6, Mozilla Firefox 4.0 béta3 (alors que la béta 6 est sortie), et bien entendu IE9.

Mensonge microsoft propagande pour IE9

Le mensonge principal, c’est l’impossibilité – selon Microsoft – d’ouvrir un onglet accidentellement fermé. Hors, cette fonctionnalité existe au moins depuis Mozilla Firefox 3.6, et peut-être même la 3.5…)

Autre mensonge, l’impossibilité de combiner barre d’adresse et de recherches. Qui a dit Mozilla Firefox 3.0 (au minimum ?)

Et aussi, pas de proposition d’adresse au fur et à mesure de la saisie… Qui a dit « Barre d’adresses intelligente » ?

Mensonge microsoft propagande pour IE9 - onglets

Bref, quand Microsoft ment, ce n’est pas à petite dose. Bah, c’est habituel de leur part, pourquoi s’étonner ? 😉

J’ai mis des captures d’écrans avant que la page ne soit modifiée…

Kraken, un test de mesure taillé sur mesure par la Fondation Mozilla pour Firefox 4 ?

C’est du moins ce que dit Pierre, d’Opera-Fr.com dans son commentaire.

Le test est disponible à cette adresse : http://krakenbenchmark.mozilla.com/

J’ai donc voulu vérifier cette affirmation, en me basant sur les dernières versions de développement disponible de Chromium, d’Opera et bien entendu de Mozilla Firefox 4.0 pré-béta7.

Voici les résultats :

  • Minefield 4.0 pré-beta7 : 14789,5 ms
  • Opera 10.70, révision 9047 : 17229,4 ms => 16,49% plus lent que Minefield
  • Chromium 7.0.517.0 : 20009,9 ms => 35,29% plus lent que Minefield

Minefield 4.0 prébeta7 avec Kraken

préversion Opera 10.70 avec Kraken

Chromium 7 - Kraken

Donc, optimisé ? Voici ce que dit la présentation du test Kraken :

Kraken focuses on realistic workloads and forward-looking applications. We believe that the benchmarks used in Kraken are better in terms of reflecting realistic workloads for pushing the edge of browser performance forward. These are the things that people are saying are too slow to do with open Web technologies today, and we want to have benchmarks that reflect progress against making these near-future apps universally available.[…]Kraken will evolve quickly over the coming weeks and months as we build out its test suite and continue to push forward the capabilities of the open Web, as we make the workloads more realistic and varied.

Ce qui donne traduit rapidement :

Kraken se concentre sur des charges de travail réalistes et vers les applications à venir. Nous pensons que les critères utilisés dans Kraken sont meilleurs en termes de charge de travail reflétant réaliste pour repousser encore les limites de performances du navigateur. Ce sont des choses que les gens disent être trop lents à avoir avec les technologies du Web ouvert aujourd’hui, et nous voulons avoir des repères qui reflètent les progrès par rapport à ces applications qui seront universellement disponibles dans un futur proche.[…]Kraken évoluera rapidement au cours des prochaines semaines et des mois que nous construisons sa suite de test et en continuant à faire progresser les capacités du web ouvert, ce que nous ferons avec de la charge de travail plus réaliste et plus variée.

Je laisse chacun juge de la partialité du test. S’il était aussi partial, les autres navigateurs seraient largement plus loin. Maintenant, à voir si ce test en plus sera le test de trop !

Pino 0.3 pre-alpha sur Archlinux ? Passez votre chemin.

Ayant lu l’annonce d’une pré-alpha de Pino 0.3 (qui repart de la feuille blanche), j’ai voulu compiler le code source, comme indiqué sur le site en question.

Mais je n’ai pas réussi, car j’ai eu droit à un problème de blocage : libindicate…

En effet, quand j’ai lancé la commande de compilation du code, j’ai eu droit à cette erreur :


-- checking for module 'indicate >= 0.3'
-- package 'indicate >= 0.3' not found
-- libindicate not found, support disabled...
-- Configuring incomplete, errors occurred!

Qu’à cela ne tienne. Compilons cette bibliothèque typiquement ubuntu-ienne. J’ai donc utilisé le paquet disponible sur AUR, et j’ai eu droit à un échec, même en utilisant le PKGBUILD modifié :

make[3] : on entre dans le répertoire « /home/fred/download/libindicate/src/libindicate-0.3.6/libindicate »
CC libindicate_la-indicate-enum-types.lo
libtool: Version mismatch error. This is libtool 2.2.6b Debian-2.2.6b-2ubuntu1, but the
libtool: definition of this LT_INIT comes from libtool 2.2.10.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b Debian-2.2.6b-2ubuntu1
libtool: and run autoconf again.
make[3]: *** [libindicate_la-indicate-enum-types.lo] Erreur 63
make[3] : on quitte le répertoire « /home/fred/download/libindicate/src/libindicate-0.3.6/libindicate »
make[2]: *** [all] Erreur 2
make[2] : on quitte le répertoire « /home/fred/download/libindicate/src/libindicate-0.3.6/libindicate »
make[1]: *** [all-recursive] Erreur 1
make[1] : on quitte le répertoire « /home/fred/download/libindicate/src/libindicate-0.3.6 »
make: *** [all] Erreur 2

Je ne suis pas personne a abandonné aussi vite, mais il est dommage de devoir utiliser une technologie supplémentaire pour un logiciel qui vantait sa légèreté à l’origine. Même si Gwibber est un peu plus lourd, au moins une version fonctionnelle est disponible…

La guerre du JavaScript aura bien lieu…

Dans le petit monde des navigateurs, la guerre est désormais passé à celle de la vitesse d’interprétation du Javascript. En plus de la guerre des respects des standards, qui sera surement le sujet d’un autre article.

J’ai donc pris les grands noms des navigateurs multiplateformes à savoir Chromium (coeur de Google Chrome), Mozilla Firefox et Opera.

J’ai testé la dernière version stable et la dernière version de développement disponible.

A savoir : Chromium 6 et 7 pre, Mozilla Firefox 3.6.9 et 4.0 beta6pre, Opera 10.62 et 10.70pre.

Les deux tests utilisés ont été SunSpider 0.9.1 et v8 Benchmark v5.

Continuer la lecture de « La guerre du JavaScript aura bien lieu… »

Pino 0.3 : Le duke nukem for ever des clients twitter / identi.ca ?

Derrière ce titre volontairement provocateur, je ne fais qu’exprimer le sentiment que j’éprouve envers le coté « moribond » de ce projet. Alors que j’ai encensé de nombreuses fois ce logiciel, l’utilisant dès février 2010 – et m’occupant de la traduction sur de nombreuses versions 0.2.x

Cependant, tous les éléments qui font penser que la version 0.3.x sera – jusqu’à preuve du contraire – un vaporware :

C’est quand même dommage de voir un si bon outil devenir un vaporware… Oui, je sais, je n’ai pas le niveau de perfection dans la capacité de mettre le doigt où cela fait mal d’un certain Cyrille…

En vrac’ rapide et libre avant le week-end.

Comme le week-end approche, un petit en vrac’ se justifie.

C’est tout pour aujourd’hui. Bon week-end

Une nouveauté visuelle de Mozilla Firefox 4.0beta6 : un bouton « arrêt, rechargement, chargement » tout-en-un

Alors que la 5ième béta de Mozilla Firefox est prévue pour le 7 septembre, la 6ième béta est en cours, comme l’on peut voir avec l’identifiant d’une compilation effectuée ce matin vers 10 h 30 : Mozilla/5.0 (X11; Linux x86_64; rv:2.0b6pre) Gecko/20100903 Firefox/4.0b6pre

Dans cette avant-dernière béta (7 bétas sont prévues), une nouveau graphique va simplifier la barre de tache : un bouton tout en un au niveau de la barre d’adresse, qui permet de lancer le chargement ou le rechargement, voire d’arrêter le chargement d’une page en cours.

Une image valant mieux que mille mots, voici où se trouve ce bouton :

Un aperçu du bouton en fin de barre d'adresse dans Mozilla Minefield 4.0b6pre

Pour info, cet ajout d’icone, c’est le bug 544816. En ce qui concerne le « Bouton » Firefox en haut à gauche de la fenêtre, c’est le bug 585370…