Un rapide tour du propriétaire pour la distribution ArchLinux 2008.06 alias Overlord.

Archlinux est une excellente distribution qui m’avait donné beaucoup de plaisir durant deux mois. C’est donc avec la sortie de sa version 2008.06 que j’en profite pour l’installer dans une machine virtuelle KVM.

La dite machine suivant mon protocole classique : clavier français, disque virtuel de 32 Go, 768 Mo de mémoire vive et un circuit son es1370. Donc les classiques commandes dans un terminal :

fred@fred-laptop:~/download$ qemu-img create -f qcow2 arch.img 32G
Formatting 'arch.img', fmt=qcow2, size=33554432 kB
fred@fred-laptop:~/download$ kvm -m 768 -k fr -localtime -hda arch.img -cdrom archlinux-2008.06-core-x86_64.iso -soundhw es1370 -boot d &

L’installateur a été refondu. D’ailleurs, si on fouille dans les options du menu de démarrage, on peut trouver un clone d’un célèbre jeu vidéo. Pour y accéder ? Menu Tools / Space Invaders !

Accès à Space Invaders avec l'Archlinux.

Le début de la partie...

Fin de partie

L’installation se fait comme d’habitude. Après le premier démarrage, j’ai ajouter au fichier /etc/pacman.conf le serveur d’Archlinux.fr pour avoir accès à Yaourt. Donc, j’ai rajouté le dépot situé à l’adresse http://repo.archlinux.fr/x86_64/.

# pacman -S yaourt
# yaourt -S libx86 xorg hwd

Configuration de Xorg :

# hwd -u : hwd -xa

Ajout de Gnome ; je me suis basé sur l’article que j’avais jadis rédigé sur le wiki d’Archlinux.fr.

# yaourt -S gnome gnome-extra gnome-system-tools

Pour le support du gvfs, il suffit d’ajouter le module « fuse » à la ligne qui va bien dans le fichier /etc/rc.conf

Ajout du serveur Pulse-Audio, en se basant sur cet autre article que j’avais traduit depuis le wiki d’Archlinux.org.

Ensuite, j’ai crée un compte utilisateur en lui donnant les droits d’accès sur : wheel, audio, storage, optical, stb-admin et pulse-access.

J’ai utilisé GDM pour lancer le Gnome 2.22.2 installé.

Gnome 2.22.2 sous Archlinux

Pour finir, j’ai voulu voir s’il était facile de compiler Shiretoko.

J’ai ensuite utilisé le tarball du code source que j’utilise sur mon Ubuntu, et j’ai lancé la recompilation de Shiretoko avec le .mozconfig suivant :

. $topsrcdir/browser/config/mozconfig

# Options for ‘configure’ (same as command-line options).
ac_add_options –enable-optimize= »-Os -march=native -w -pipe »
ac_add_options –disable-debug
ac_add_options –disable-tests
ac_add_options –enable-default-toolkit=cairo-gtk2
ac_add_options –enable-strip

40 petites minutes d’attente, et voici un Shiretoko qui nous donne un aperçu du test Acid3.

Shiretoko sous Archlinux.

Que dire de plus ? Qu’Archlinux est toujours une aussi bonne distribution, mais que devoir parfois trifouiller les tripes de l’OS est lassant 🙁

Chi va piano, va sano e va lontano…

Derrière ce titre en langue italienne, que l’on peut traduire par « qui veut aller loin ménage sa monture », je voudrais parler des avancements sur le plan du passage de la dernière masturbation intellectuelle sur le plan des technologies de la toile, le test Acid3.

Alors que Firefox 3 vient de sortir, une faille de sécurité touchant à la fois Firefox 2 et 3 assez grave est révélée – et est confirmée par Window Snyder – et dont la date de révélation est quand même assez opportuniste, le travail pour améliorer le code de Shiretoko (nom de code de Firefox 3.1) dont la sortie est prévue pour décembre 2008.

La première – et unique ? – alpha de Shiretoko devrait offrir un score d’environ 80/ 100, comme le montre cette capture d’écran d’une version compilée ce matin même sur ma machine.

80 / 100 avec une pré-alpha de Shiretoko.

Alors que la course au passage du test Acid3 a ressemblé à celle du passage du test Acid2 précédemment, il est assez certain que le test ne sera complètement passé que par Firefox 4 qui sortira dans environ… un an et demi 🙂

Quoiqu’il en soit, mieux vaut prendre son temps pour le passage du test, que modifier le code source d’un navigateur uniquement pour le passer. Ne serait-ce que pour éviter des problèmes de lourdeurs par la suite 😉

Des nouvelles de Shiretoko.

Décidément, je crois que je ne me ferais jamais au nom de code de Firefox 3.1 😉

Bref, voici quelques nouvelles à la veille de la sortie de la version finale de son « papa », Gran Paradiso alias Firefox 3.0.

Commençons par la masturbation intellectuelle, j’ai nommé le test Acid3. On frôle actuellement les 80 / 100. Quelques bogues ont été corrigés, et on arrive à 79 / 100 pour le moment. Ce qui est déjà pas si mal, étant que 8 tests supplémentaires sont passés par rapport à Firefox 3…

79 / 100 avec une préversion de Shiretoko alpha1

Sur le plan des bogues considérés comme bloquant la sortie de cette version en décembre prochain, ils sont actuellement au nombre de 10, les bogues qu’il faudrait voir disparaître, 45.

Parmi les bloquants : java non reconnu dans les pré-alpha actuelles, deux plantages liés à flash et à swfdec, son implémentation libre.

Parmi la liste des « à faire disparaitre » : des améliorations dans le support du SVG, dans le support des CSS3, le support de la balise <video> avec les codecs theora, gstreamer et directshow.

Informations trouvées via l’excellent blog « Firefox Extension Guru’s Blog« .

Firefox 3.1 pré-alpha1 et Acid3 : vers la lutte finale ? ;)

M’étant abonné au bug qui permet de suivre l’évolution du support de la nouvelle masturbation intellectuelle des navigateurs web, j’ai nommé le test Acid3, j’ai pu constater ses dernières heures qu’au moins 3 bogues concernant le dit test avait été marqué comme « FIXED ».

Il s’agit des bogues 421765, 412567 et le 128585.

Ce qui donne maintenant un résultat de 76 / 100 pour la pré-alpha1 de Firefox 3.1, soit 5 tests de mieux que le futur Firefox 3.0 qui doit être publié dans le courant du mois. Toujours bon sur le plan du support des normes du W3C au final 🙂

Firefox 3.1 alpha 1 et son score de 76 / 100 au test acid3

Vers un meilleur support des CSS3 dans Firefox 3.1 ?

Non, je n’ai pas fait de faute de frappes dans le titre. Je parle bien de Firefox 3.1, dont la sortie est prévue pour décembre 2008.

Le support des CSS3 semble être assez intéressant, pour ne pas dire « parfait » sur le plan des sélecteurs.

En effet, jettant un oeil sur la page de suivi de modification du code de Firefox 3.1 (mozilla-central actuellement), j’ai pu lire ceci :

2008-06-02 20:17 -0700 L. David Baron – Implement :first-of-type, :last-of-type, and :only-of-type. b=128585 r+sr=bzbarsky default tip
2008-06-02 20:17 -0700 Daniel Glazman – Implement :nth-child(), :nth-last-child(), :nth-of-type(), :nth-last-of-type(). b=75375 r+sr=bzbarsky
2008-06-02 20:17 -0700 L. David Baron – Make nsPseudoClassList capable of storing integer pairs for :nth-*(). b=75375 r+sr=bzbarsky

Ce sont des sélecteurs liés aux CSS de 3ième génération. J’ai donc lancé le test du site CSS3.info, la capture d’écran étant suffisamment parlante.

Le test de compatibilité des sélecteurs CSS3 est réussi à 100%

Dommage cependant que certaines parties ne soient pas encore supportées, comme les ombres sur les polices, cf le bogue 10713 qui empèche d’avoir un bel affichage « ombré » sur le test Acid3 dont le résultat s’est légèrement amélioré récemment, passant de 71 à 73/100 🙂

73 / 100 au test acid3 avec Firefox 3.1 pré-alpha1.

Comme quoi, Firefox 3.1 prévu pour décembre ne sera pas qu’un simple « ravalage » de Firefox 3 🙂

Webkit-gtk : Acid3 est presque passé ? :)

Je me suis basé sur la révision 31787 de WebKit-Gtk pour rédiger cet article. Après avoir lancé une compilation en activant le support du SVG – avec un ./configure --enable-svg-experimental – puis une fois la compilation terminée avec le programme de test GtkLauncher.

Si au premier passage, le test n’est pas passé, au second lancement, celui-ci se lance, donnant un résultat presque parfait, n’affichant qu’une erreur : « Linktest failed ».

Webkit r31387 sous Ubuntu Hardy Heron AMD64.

Au moins, cela laisse de l’espoir pour le futur d’Epiphany, dont la version 2.24.x (en clair, celle qui sortira avec Gnome 2.24 en septembre prochain) d’utiliser WebKit sans gros problème de rendu.

Acid3 : WebKit et Opera vainqueur « ex-aequo » ?

En l’espace de quelques heures, les équipes d’Opera et de Safari ont annoncé passé officiellement la totalité du test Acid3.

Webkit l’annonce en grande pompe :

With r31342 WebKit has become the first publicly available rendering engine to achieve 100/100 on Acid3. The final test, test 79, was a brutal torture test of SVG text rendering. Details of the bugs we fixed will follow. Indeed, we found a critical bug in the test itself that would have forced a violation of the SVG 1.1 standard to pass, so until a few hours ago it was not possible to get a valid 100/100. Acid3 test editor Ian Hickson has the details.[…]

Ce qui donne traduit :

Avec la révision 31342, Webkit a été le premier moteur de rendu disponible à atteindre les 100/100 sur Acid3. Le test final, le 79, était une torture brutale du rendu d’un texte en SVG. Le détail des bogues corrigés suivra. En effet, nous avons vu un bogue critique dans le test lui-même qui aurait forcé une transgression de la norme SVG 1.1 pour son passage, donc jusqu’il y a quelques heures il était impossible d’atteindre les 100/100. Le créateur du test Acid3, Ian Hickson a les détails.[…]

Pour être complet, des ajouts ont été faits pour rendre le passage « plus valide », et un autre annonçant qu’avec la révision 31356, la versions Windows est disponible.

Opera de son coté, a fait l’annonce aussi. Mais avec une subtilité intéressante ; l’annonce du passage est intéressante à lire :

Today we reached a 100% pass rate for the first time! There are some remaining issues yet to be fixed, but we hope to have those sorted out shortly.

We will release a technical preview version on labs.opera.com within the next week or so. For now, the screenshot above shows the Acid3 test as rendered in our latest WinGogi Desktop build. WinGogi is the Windows version of our reference builds used for the internal testing of Opera’s platform independent Core.

Ce qui donne traduit :

Aujourd’hui, nous avons atteint le score de 100% pour la première fois. Il reste quelques problèmes à corriger, mais nous espérons faire cela rapidement.

Nous publierons une version technique d’aperçu (Note du traducteur : une version alpha, donc) sur labs.opera.com d’ici la semaine prochaine environ. Pour le moment, la capture d’écran montre le test Acid3 affichée dans la dernière compilation de WinGogi Desktop. WinGogi est la versions Windows de nos compilations de référence utilisée pour les tests internes sur la plateforme Opera.

Donc, les deux déclarent passer le test Acid3, et un seul mot : félicitations. Cependant, dans un cas, on peut vérifier les dires avec une compilation téléchargeable, et sur l’autre, uniquement un communiqué.

Etant comme un certain apôtre, je ne crois que ce que je vois… Seul l’avenir nous dira quel sera le premier moteur STABILISÉ et donc rendu grand public qui passera Acid3. Je maintiens mon pronostic pour Safari et donc Webkit. Mais je peux aussi me tromper… Seul l’avenir nous le dira !

Webkit : des résultats acid3 variables ?!

Certaines remarques sur le score passé par WebKit (la version de développement du moteur de rendu du navigateur d’Apple, à savoir Safari, logiciel libre) m’ont fait me poser des questions.

Un score de 95% (étant donné qu’il y a 100 « sous »-tests dans le test) pour une nocturne récente de la version MacOS du moteur, des versions très récentes (révision 31108 pour Windows et 31107 pour linux) donne des scores inférieurs quoique proche.

La seule différence entre les deux révisions datées d’hier ? Un bug de compilation sous Windows.

Révision 31108 sous Windows : 94%

94% avec Webkit pour Windows

Révision 31107 sous Linux : 90%

90% avec Webkit pour Linux

4 tests passés sous la versions Windows bloquent avec la version linux. Etrange, étant donné que c’est le MÊME code source utilisé pour le moteur sur les 3 plateformes. Et pourtant, je ne fais que suivre les infos proposées pour la compilation du code. L’utilisation d’autres options faisant planter la compilation avant son terme ! 🙁

J’avoue y perdre le peu de latin que j’ai jamais acquis. Des idées ?!

En tout cas, le score s’approcherait du mythique 100%, du moins si on en croit ce billet du blog des développeurs de Webkit…

Acid3 : bilan à Pâques 2008.

Il y a une quinzaine de jours, j’avais fait un bilan des versions de développement de Safari et Konqueror 4.x (WebKit), Firefox 3 (Gecko 1.9), et d’Opera 9.5 (en préversion béta 2).

Après avoir compilé le code de WebKit pour GTK, à savoir la révision 31232 en date du 22 mars 2008, j’obtiens un score de 89%. Soit 2% de plus.

Bilan de Webkit en date du 22 mars 2008 sous Acid3

En ce qui concerne Gecko 1.9, en pré-béta5, le score s’améliore légèrement, en passant à 71%.

Bilan de Gecko 1.9 pré-béta5 sous Acid3

Enfin, le bon le plus spectaculaire est celui d’Opera. La version hebdomadaire de Pâques – il ne faut pas demander beaucoup plus à ce logiciel propriétaire 🙂 – le score atteint 77%, soit un bond de 10%.

Bilan d'Opera 9.50 pré-béta2 sous Acid3

Le classement final évolue légèrement :

1er : Webkit, passant de 87 à 89%
2ième : Opera 9.5 pré-béta2, et remonte d’une place, passant de 67 à 77%
3ième : Firefox 3.0 pré-beta5.

Score qui ne risque plus de trop évoluer pour Firefox 3, peut-être un ou deux pourcent de plus.

Petit point sur Acid3 – Webkit… Le champion toute catégories ? ;)

Ce billet complète le précédent. J’ai pu compiler sans trop de problème la révision 30885 du moteur Webkit, et les résultats sont explosifs… 87/100 !!!

Webkit sous Acid3...

Pour compiler le moteur Webkit, je me suis basé sur cette page : http://trac.webkit.org/projects/webkit/wiki/BuildingGtk. Le code source étant récupérable sur cette page : http://nightly.webkit.org/

A noter que le support du svg soit désactivé… En effet, voici ce que donne le bilan de la commande ./autogen.sh :

Build configuration:
Enable debugging (slow) : no
Code coverage support : no
HTTP backend : curl
Optimized memory allocator : yes
Features:
HTML5 cross-document messaging : yes
HTML5 client-side storage support : yes
HTML5 video element support : no
Icon database support : no
SVG support : no
SVG animation support : no
SVG filters support : no
SVG fonts support : no
SVG foreign object support : no
SVG as image support : no
SVG use element support : no
XPATH support : yes
XSLT support : yes
GTK+ configuration:
GDK target : x11
Hildon UI extensions : no

Quoiqu’il en soit, il semble être certains que la future version stable de Webkit passera lui aussi le test acid3… Du moins, c’est bien parti pour 😉