devloop :: blog

Opera a beau avoir tout un tas de fonctionnalités pratiques, il en manquait une depuis des années : le support des proxies SOCKS.

C'est maintenant réglé avec les récentes builds.

Mon aventure avec openSUSE a commencé avec la SuSE 9.1. J'ai d'ailleurs toujours le DVD de l'époque qui était fourni avec un magazine.
Même si je suis passé à un moment à Ubuntu et Slackware et que j'ai pû tester de nombreuses distributions, je suis toujours revenu à openSUSE qui me satisfait toujours malgré les petits pépins que j'ai pû rencontrer lors de migrations à la version supérieure.

Pour mon passage à la 11.3 j'avais envie de changer un peu. Au lieu de faire un upgrade comme j'en ai fait depuis plusieurs numéros de version déjà, j'ai décidé de reprendre sur des bases propres, c'est à dire supprimer la partition racine contenant les logiciels installés.

En plus de se débarasser ainsi des logiciels/librairies inutiles, c'était l'occasion de finalement faire le saut vers le 64bits puisque Shirley a un proc AMD64 et que j'étais resté sur du 32bits principalement par manque d'information et de peur que trop de logiciels soient indisponibles dans cette architecture.

L'objectif c'était aussi de se débarasser de deux partitions Windows que je n'utilisais plus (un XP et un 2000) d'autant plus que je suis passé de mes 700Mo de rams (oui 700Mo ) à 2Go.
J'ai donc bon espoir de pouvoir virtualiser certains systèmes d'exploitation autre que Minix, Windows 98 ou MenuetOS

L'installation en elle même s'est parfaitement bien déroulée. Graphiquement c'est beau ! A tel point qu'on se demande comment ils font pour nous étonner à chaque fois
J'ai passé beaucoup de temps à réfléchir à comment j'allais organiser mes partitions puisque je voulais en garder une, virer deux partitions primaires et redimensionner une primaire et une autre logique. Bref un sacré casse tête
J'ai changé certaines partitions de ext2/3 à ext4 au passage.

Ce qui a été plus problématique c'est la personnalisation du système après installation.
Premièrement l'installation du driver graphique nVidia nécessitait d'effectuer une manipulation particulière (décriteici dans la section Warning) : lancer le système avec une option nomodeset, créer une variable dans sysconfig et rebooter, tout ça pour pouvoir décharger le module nouveau et installer le driver proprio à la place

Maintenant le driver nVidia est disponible sur un dépôt externe pour ceux qui le souhaitent et l'installation est aisée. De mon côté j'ai toujours récupéré le driver sur le site officiel

Premières choses à effectuer ensuite : installer Opera bien sûr, Tor et le pager most dont je ne me séparerais pour rien au monde
J'ai voulu installer la dernière béta d'Audacious mais malgré une compilation réussie, il segfault à chaque fois que je tente d'ouvrir quelque chose
En attendant et en espérant que cela vienne de la version béta, je suis passé à DeaDBeeF pour la lecture de mp3. C'est simple et fonctionnel comme j'aime, mais pas aussi beau que Audacious et surtout ça ne lit pas les CD audios comme il faut. C'est à dire que comme la plupart des softs capables de lire ce type de support ça le fait en faisant un boucan d'enfer (on entend plus le CD tourner que la musique) au lieu de le faire silencieusement.

Cette version d'openSUSE a arrêté de nous casser les pieds avec Pulse et on retrouve ce cher ALSA

La distribution est rapide à démarrer, en un clin d'oeil on se retrouve devant l'écran de login.
En revanche je trouve la performance de KDE 4.4 médiocre et ce malgré mes 2Go de ram et le type d'activité que j'ai sur le poste (surf web, lecture de musique et vidéo et programmation) : ça saccade, c'est poussif, ça manque de fluidité. En lançant top on voit que Xorg pompe pas mal. La cohabitation avec KDE 4.4 est difficile.

Je suis donc parti à la chase à la "gaspi" et aux petites astuces en tout genre.
J'ai gagné pas mal en bidouillant mon Xorg.conf, en désactivant le scrolling fluide sous Opera et Firefox (aussi avec cette manip) et c'est déjà bien mieux
Je garde encore l'astuce raster en réserve au cas où.

J'ai aussi empéché le redimensionnement des fenêtres sous Firefox car ça commencait à me gonfler

Cela dit... il y aurait plus simple. Il suffirait de se servir de LXDE à la place qui est bien plus léger et que cette version d'openSUSE a très bien intégré.
Pour commencer il n'y a plus à bidouiller soit même la config, le menu & co.
Deuxièmement le mot de passe root est maintenant demandé lors de l'appel aux applications administratives (YaST, Wireshark...)
Enfin, là encore le graphisme est soigné.

Bref malgré les piètres performances du KDE que je cherche toujours à améliorer, je suis globalement satisfait de cette nouvelle version
D'ailleurs je vous laisse, j'ai un applet qui m'indique que je dois installer un correctif de sécurité pour gnupg2.

Un screenshot pour la route

Ce n'est pas nouveau !
Quand on voit les différents standards (X)HTML, les normes ECMAScript, les histoires d'encodage des caractères, les flux RSS, les images, les animations Flash, le format CSS et que tout ça avance à une vitesse monstre, c'est déjà pas facile.
Mais quand en plus chacun y va de ses "solutions" propriétaires, ses balises à lui, les webmestres qui s'improvisent du code HTML entre deux standards (en supposant que les balises en question soient fermées), l'interprétation du code qui diffère d'un navigateur à un autre et les astuces à ajouter dans les pages pour réparer les erreurs... on s'en sort plus.

On pouvait penser que la base (le protocole HTTP) était, lui, correctement implémenté... mais après avoir travaillé sur une nouvelle implémentation des cookies dans Wapiti, force est de constater qu'on est loin du compte

Premier sujet d'énervement : les dates utilisées dans les entêtes. Quand un serveur déclare un cookie auprès du client, il utilise l'entête "Set-Cookie" avec un champ nommé "expires".
Ce champ donne la date à laquelle expira le cookie associé. Or cette date n'est pas une date relative mais une date "absolue" dans ce style : "Sat, 27 Jun 2009 16:33:21 CET".
C'est déjà énervant de devoir jongler avec les fuseaux horaires mais en plus il faut jongler avec le format de la date.

Lors de mes tests j'ai trouvé quatres formats de date différents présents dans le champ expires des cookies ou les entêtes HTTP Date et Expires.
Avec ou sans virgule, avec le décalage horaire sous forme numérique ou sous la forme de trois lettres (GMT, CET), avec ou sans tirets, avec le mois placé avant ou après le numéro du jour.
Parfois un même serveur (comme www.amazon.com) utilise deux formats de date différents, juste histoire de compliquer les choses :|

Le plus drôle c'est que si on jette un coup d'oeil aux RFC 2109 et RFC 2965 qui définissent le bon usage des cookies dans le protocole HTTP, on apprend qu'il faut utiliser un champ baptisé "max-age" pour l'expiration des cookies et que sa valeur est... relative au moment présent !! (par exemple max-age=500 définie une durée de vie de 500 secondes)

Seulement presque aucun serveur, CGI et compagnie ne respectent ces spécifications. Au lieu d'utiliser les méthodes revues et corrigées, ils continuent depuis plus de 10 ans de se baser sur les anciennes specs de Netscape.
La raison serait principalement le non respect de ces specs par le navigateur de Microsoft et il semble que ce dernier persiste même arrivé à la version 7

Malgré l'existence d'un entête "Set-Cookie2" compatible avec l'ancienne méthode de Netscape, les navigateurs ne semblent pas bien pressés de suivre les bonnes règles. Il n'y a qu'Opera qui fait figure de bon élève dans cette histoire

La librairie libcookie de Python montre aussi des défaillances. Pour le moment j'ai pu réécrire le script cookie.py, en analysant directement les entêtes et abandonnant le format LWP/Netscape pour un format XML au niveau du stockage Vu comment les choses se présentent ça va se terminer sous la forme d'une librairie.
Les modifications ne sont pas encore visibles dans le SVN.

Hors sujet :
Qu'est-ce qui est arrivé en premier ? L'extravagance de Michael Jackson ou sa dépendance aux médicaments et autres substances ?
La réponse en vidéo. How !

Mieux vaut tard que jamais, j'ai découvert FlashBlock pour Opera. Je l'utilise depuis une semaine et j'en suis très content.
Il est composé d'un UserJS et d'un feuillet de style. Une fois les fichiers copiés dans leurs dossiers Opera, il suffit d'aller dans Afficher > Style et de sélectionner "Flash Blocker" pour l'activer.
L'utilisation est exactement la même que celle du plugin Firefox et en plus c'est compatible avec les dernières build béta d'Opera 10

FlashBlock pour Opera

Je me suis intéressé au format de fichier utilisé par le navigateur Opera.
Bien que les spécifications soient disponibles, on trouve peu d'outils pour gérer les historiques, caches et cookies du navigateur
Finalement je suis parvenu à écrire un script Python qui extrait les données du fichier cookies4.dat et les affiche dans un format texte plus conpréhensible que le format binaire d'Opera.
La sortie générée ressemble à ça :

Opera Cookie Dumper
File version: 1.0
Application version: 2.1
Cookie file
Size of idtags: 1 bytes
Size of payload length fields: 2 bytes
MSB: 0x80
===================================
dsource.org
        dsource-auth_data  = a%3A11%3A%22autologinid%22%3Bs%3A6%3A%22userid%22%3Bi%3A-1%7D
        path = /projects
        path = /dsss
        trac_session  = e7f77d380bc7290b2347490c
        path = /tutorials
        trac_session  = 49ca56cec7f142d58d2201ea
userfriendly.org
        __qca  = 1239814048-45958653-24014683
...

Toutes les informations n'apparaissent pas. Actuellement il n'est affiché que le domaine, le path sur le serveur et les noms et valeurs des cookies.

Durant mes recherches j'ai découvert un tag non documenté (tag id 0x26) qui correspond en réalité au champ "Delete new cookies when exiting Opera is checked" dans les préférences de site. Si la valeur est à 2 cela signifie que la suppression est activée. Si la valeur est à 1 ou si le tag est omis cela signifie que la suppression n'a pas lieu.
Il y a aussi un flag 0x27|MSB que j'ai rencontré mais je n'ai pas pû découvrir sa signification

Dans tous les cas ça peut être utile pour faire du Web Browser Forensics et le code est disponible ici :
opcodump.py