Sans frontière › Geekeries

Informatique en tout genre

Fil des billets - Fil des commentaires

mardi 25 mars 2014

Un nouveau navigateur dans Weboob

Le navigateur (ou Browser) est dans Weboob une classe pour faciliter l'écriture de modules. Comme son nom l'indique, il est là pour contenir les fonctions habituelles d'un navigateur Web, évitant au module de devoir gérer les requêtes de bas niveau.

Browser1 est le navigateur historique, basé sur mechanize, et ajoutant des fonctionnalités propres à Weboob. Malheureusement, il est apparu au cours du temps que mechanize avait de nombreuses limitations, et que son architecture rendait certaines choses (comme la gestion des formulaires) très laborieuses.

Browser2 est le nom de code pour le remplacement de ce navigateur. C'est un projet qui dure depuis quelques versions de Weboob, mais est arrivé cette fois dans la branche de développement. Il est cette fois basé sur requests. Cette bibliothèque est plus bas niveau que mechanize, et de nombreuses fonctions sont donc cette fois directement intégrées dans Weboob. Et ça permet de simplifier beaucoup de choses.

Romain a déjà beaucoup écrit sur Browser2, mais je complète par mon opinion. J'ai récrit quelques modules avec, et on peut dire que c'est vraiment de grand changements. En effet, non seulement Browser2 est plus simple, mais l'ajout de fonctions pour simplifier l'extraction de données dans les pages est un vrai plaisir. Cela aurait certes pu être découplé de Browser2, mais le changement de navigateur était une bonne occasion pour remettre les choses à plat et profiter de l'expérience accumulée en écriture de modules.

J'aime donc beaucoup les filtres, un ensemble d'outils pour extraire les données d'une page Web. Ils sont construits d'une manière qui me rappelle un peu la programmation fonctionnelle, on applique des compositions de fonctions pour arriver au résultat désiré. Prenons l'exemple du module pour Poivy. Le code ressemble maintenant à ça :


class HistoryPage(LoggedPage, HTMLPage):
    @method
    class get_calls(ListElement):
        item_xpath = '//table/tbody/tr'
        class item(ItemElement):
            klass = Detail
            obj_datetime = Date(CleanText('td[1] | td[2]'))
            obj_price = CleanDecimal('td[7]', replace_dots=False, default=0)
            obj_currency = u'EUR'
            obj_label = Format(u"%s from %s to %s - %s",
                               CleanText('td[3]'), CleanText('td[4]'),
                               CleanText('td[5]'), CleanText('td[6]'))

Avec ce code, on itère automagiquement sur toutes les lignes de l'historique de la page. On signale par l'héritage de LoggedPage que l'on est certain que le login a réussi si on atteint cette page. Il est inutile de créer et de renvoyer l'objet Detail à chaque itération, la ligne klass suffit Et on parse vraiment très facilement les éléments. On transforme ainsi la septième colonne des lignes du tableau en décimal, c'est le prix de la ligne. On spécifie de ne pas remplacer les points (souvent utilisés comme séparateur pour les milliers en France), et le default=0 est une option magique pour dire que si ce n'est pas un décimal, c'est gratuit (cas des appels inclus dans le forfait). Il fallait autrement vérifier à la main le contenu et gérer si nécessaire les exceptions.

Les fonctions DateTime, Time et Date sont également assez magiques, transformant du texte pas toujours bien ordonné en un objet correspondant python. Par rapport au code précédent, c'est une division par deux du nombre de lignes. Et par beaucoup plus de la lisibilité. Les filtres définis sont très nombreux, permettant l'utilisation d'expression rationnelle, de formater des chaînes, de récupérer très facilement les attributs d'une balise html, etc. Comme ils se combinent, on applique ce dont on a besoin en une seule fois.
Il y a beaucoup d'autres fonctionnalités magie dans Browser2, dont notamment la pagination. Je n'avais jamais ajouté la pagination de l'historique au module poivy, car la pagination n'était pas toujours très pratique sur l'ancien navigateur. À présent, c'est fait en quelques lignes. En ajoutant à la classe get_calls ces quelques lignes :


    next_page = Link("//div[@class='date-navigator center']/span/a[contains(text(), 'Previous')]",
                     default=None)

On va donc chercher le lien vers la page suivante, et on rend un objet Link s'il faut itérer, None si on ne trouve rien. Le navigateur se charge ensuite d'aller sur les pages au fur et à mesure si c'est nécessaire.

En bilan chiffré, la partie navigateur et extraction des données du module Poivy est passé de 125 à 85 lignes (sans copyright, commentaires et lignes vides). En gagnant au passage à la fois en fonctionnalité et en lisibilité du code. Browser2 est vraiment une étape importante pour la simplicité des modules Weboob.

jeudi 20 février 2014

Rapports de bugs tout simplement avec Weboob

Un des paradoxe du projet Weboob, c'est la création de ticket qui passe surtout par l'interface Web du gestionnaire de tickets Redmine. Bien entendu, il existe un module Redmine, bien pratique pour les développeurs. Mais pour les utilisateurs, configurer le module juste pour ouvrir un rapport de bug était un peu compliqué, alors que cela devrait être une action simple.
Cependant, tout était déjà presque là pour faire un système agréable. Nous avons le module capable de créer des tickets, et une application pour utiliser le module. Afin de pouvoir facilement importer/exporter des bugs, cette application a été améliorée dans la branche de développement pour être capable de lire un ticket à partir d'un pipe reçu. Concrètement, un simple cat ticket.txt | boobtracker post weboob suffit à envoyer un ticket. De la même façon, un bug peut-être transformé en format texte.
Améliorons encore l'idée. On veut fournir un service simple pour les utilisateurs afin d'ouvrir un bug. Un moyen standard de transférer du texte, c'est l'email. On peut donc un peu modifier la configuration de postfix pour y ajouter un truc comme ça dans le fichier master.cf
weboobreport     unix -        n       n       -       -       
pipeflags=FR user=toto
argv=/usr/local/bin/boobtracker post weboob

Et hop, à la réception d'un mail, on envoie un ticket sur le gestionnaire de tickets. C'est ainsi que les utilisateurs de Weboob peuvent désormais ouvrir des bugs très simplement en envoyant un mail à nomdumodule@issues.weboob.org. Cela évite également de publier les adresses mails des mainteneurs des paquets lors d'un crash, et évitera de perdre des rapports de bugs envoyés directement aux mainteneurs (qui peuvent avoir délaissés le projet depuis). Cette fonctionnalité sera mise en avant dans la prochaine version publiée.

mardi 15 octobre 2013

SSD m4 de Crucial : le bug de l'obsolescence programmée

J'ai la chance d'avoir un SSD dans mon ordinateur de travail, ce qui permet de gagner énormément de temps par rapport à un disque dur. Ça c'est pour la théorie, car j'ai perdu des heures la semaine dernière sur un bug assez curieux. Les symptômes étaient assez simples : le système perdait le contact avec le disque, rendant l'ordinateur totalement inutilisable et forçant un redémarrage électrique.

J'ai d'abord cru à un problème matériel, la connexion entre le disque et la carte mère n'étant pas très solide sur mon ordinateur portable. Un faux contact est vite arrivé (et s'était déjà produit), et j'ai ouvert et nettoyé tout ça. Sans changement. J'étais d'autant plus circonspect qu'un démarrage se déroulait toujours parfaitement bien, alors qu'un faux contact devrait se manifester dans toutes les situations.

J'ai donc ensuite songé à un problème logiciel, en constatant au passage que mon ordinateur plantait après 3600 secondes d'utilisation environ, soit une heure. Mais revenir sur un ancien noyau ne changeait rien, hormis que le système plantait encore plus violemment. Rien du côté de l'historique SMART, rien de clair dans les logs systèmes, aucun programme qui se lance une heure après le démarrage. J'ai testé beaucoup de choses.

Cette piste logicielle était pourtant la bonne, mais à un niveau en-dessous. Les SSD de Crucial sont en effet victimes d'un bug des 5184 heures. Il n'est pas précisé pourquoi 5184 heures (c'est 3 au cube multiplié par 2 puissance 6). Il est bien entendu impossible de savoir s'il s'agit de réelle incompétence, ou d'une volonté d'obsolescence programmée. Après tout, qui parmi le grand public va penser à aller chercher sur le site du constructeur les correctifs ? D'autant plus qu'aucun historique des versions n'est disponible, et que le site actuel du fabricant ne mentionne absolument pas ce bug ? Il faut fouiller les forums obscurs pour reconstruire l'historique des versions, et trouver l'annonce de la mise à jour 0309 (version qui suit la 0009, et précède la version 000F, histoire vraie...). Après avoir trouvé ça, il faut suivre la procédure de mise à jour qui est bien entendu surtout prévue pour un système WIndows. Quelle est donc la proportion de mise à jour par rapport au nombre de SSD vendus ?

C'est typique pour moi du risque de l'ajout d'intelligence dans les composants matériels. On se met à la merci du constructeur, qui fait ce qu'il veut dans son coin, avec du code complètement obscur. En allant chercher les annonces de chaque nouvelle version, c'est édifiant de voir des améliorations de performances et des corrections de bugs, pour un matériel qui lui ne change évidemment pas. Le genre de lignes d'historique que j'aimerai voir dans une nouvelle version du noyau Linux, pas sur le forum d'un fabricant de matériel. Jugez-vous même :

0309

  • Correct a condition where an incorrect response to a SMART counter will cause the m4 drive to become unresponsive after 5184 hours of Power-on time. The drive will recover after a power cycle, however, this failure will repeat once per hour after reaching this point. The condition will allow the end user to successfully update firmware, and poses no risk to user or system data stored on the drive.

000F

  • Improved compatibility with certain SAS expanders and peripheral RAID cards.
  • Improved throughput stability under extremely heavy workloads.
  • Improved data protection in the event of unexpected, asynchronous power loss.

010G

  • Improved Trim response time
  • Improved power-on-to-ready time (known as POR, or TTR for Time-to-ready)
  • Improved resume-time from low power modes, and improved reliability of warm reboot
  • Improved power consumption by disabling HIPM (Host Initiated Power Management)

040H

  • Improved robustness in the event of an unexpected power loss. Significantly reduces the incidence of long reboot times after an unexpected power loss.
  • Corrected minor status reporting error during SMART Drive Self Test execution (does not affect SMART attribute data).
  • Streamlined firmware update command for smoother operation in Windows 8.
  • Improved wear leveling algorithms to improve data throughput when foreground wear leveling is required.

070H

  • Resolved a power-up timing issue that could result in a drive hang, resulting in an inability to communicate with the host computer. The hang condition would typically occur during power-up or resume from Sleep or Hibernate. Most often, a new power cycle will clear the condition and allow normal operations to continue. The failure mode has only been observed in factory test. The failure mode is believed to have been contained to the factory. This fix is being implemented for all new builds, for all form factors, as a precautionary measure. The fix may be implemented in the field, as desired, to prevent occurrence of this boot-time failure. To date, no known field returns have been shown to be related to this issue. A failure of this type would typically be recoverable by a system reset.

mardi 3 septembre 2013

Weboob dans Linux Pratique

Weboob fait la une du magazine Linux Pratique (même si ce n'est pas précisé, c'est bien de ça dont parle l'encart Web). À l'intérieur, 6 pages parlant du logiciel, ainsi qu'une mention dans l'édito.

Hormis une étape bizarre dans la description de l'installation, le contenu est bon. On regrettera cependant que l'auteur n'ait pas pris contact avec les développeurs, on aurait peut-être pu aider (ou au moins ne pas le découvrir par hasard).

vendredi 19 juillet 2013

J'ai découvert git-annex

C'est en lisant d'un œil discret le Planet Debian que j'ai entendu parler du logiciel git-annex. En version courte, l'idée de ce logiciel est de pouvoir synchroniser/partager/déplacer géographiquement/sauvegarder des fichiers, en utilisant git en arrière plan pour stocker l'état et la localisation des différents fichiers (d'où le nom, c'est vu comme un plugin de git). Les fichiers en eux-mêmes, potentiellement très lourds, sont stockés à l'extérieur du dépôt git.

Quand on le dit comme ça, c'est clairement pas gagné pour le commun des utilisateurs. De base, git-annex est fait pour être utilisé massivement avec de la ligne de commande. C'est déjà pas mal du tout, j'ai synchronisé ainsi quelques dossiers sur différents PC, et j'en suis très satisfait (c'est bien mieux qu'Unison pour mon usage). Dans ce que j'aime beaucoup, il y a la possibilité de voir ou est stocké un fichier et de demander qu'il existe au moins X copies. On peut également définir des niveaux de confiance pour les copies, et bien entendu automatiser le tout. Et il gère très bien les dépôts déconnectés/indisponibles. Pas forcément simple à comprendre au premier coup d'œil, mais très puissant et bien pensé.

Cependant, le meilleur reste à venir. Le développeur du logiciel a obtenu l'an dernier suffisamment d'argent pour travailler à temps plein sur le projet, à travers un projet kickstarter. Cela lui a permis de développer un « assistant » graphique qui s'occupe de toutes les tâches de synchronisation en arrière plan. Pour l'utilisateur, il suffit d'une étape de configuration pour que tout le reste soit complètement transparent (on met les fichiers dans un dossier, on supprime, on vit sa vie en gros, et ça se réplique partout). On a déjà quelque chose pour synchroniser avec un disque de sauvegarde, ou bien entre deux ordinateurs sur le réseau local, ainsi qu'entre plusieurs serveurs pouvant parler en SSH.

Ensuite, on a en bonus la synchronisation par « le nuage », qui permet de synchroniser des dossiers entre des équipements distants et de partager des fichiers avec des amis. J'ai été bluffé par la simplicité. Le système de synchronisation utilise le protocole XMPP. Il suffit de configurer son identifiant XMPP et son mot de passe (en bonus : il insiste bien sur le fait que cela marche aussi avec un compte GMail...), et c'est presque parti. Il faut un serveur « tampon » dans les nuages, pour sauvegarder ce qui doit être synchronisé entre les ordinateurs. Ça tombe bien, git-annex permet d'utiliser un nombre relativement important de plugin (Amazon, rsync.net, un serveur perso avec un SSH, etc). Ce serveur tampon n'a pas forcément besoin d'être énorme, puisque seuls les fichiers à synchroniser sont par défauts stockés (une fois que tout les ordinateurs sont synchronisés, le tampon du serveur est effacé). En bonus, tout est bien évidemment chiffré le temps de passer sur le serveur « dans le nuage ».

On peut aussi utiliser le serveur « tampon » comme un serveur de sauvegarde ou d'archivage. L'interface graphique propose de base de nombreux profils selon ce qu'on veut faire. On peut aussi passer en mode manuel pour ne télécharger que les fichiers que l'on souhaite (très pratique par exemple sur un équipement avec peu de disque. On peut demander les fichiers nécessaires à la demande). L'auteur a d'ailleurs publié plusieurs vidéos de démonstrations, par exemple sur la première approche de l'assistant.

Pour partager avec des amis, c'est peu envahissant. L'assistant détecte la présence de git-annex automatiquement dans la liste des contacts jabber. Cela oblige cependant d'avoir une ressource XMPP connectée, heureusement configurée en indisponible et avec une priorité négative (les messages normaux ne lui seront donc pas adressés). Aucun message n'est d'ailleurs envoyé par git-annex, tout passe par l'assistant. Cette ressource connectée mais indisponible ne me semble pas très gênante à l'usage.

Pour le serveur tampon, je me suis laissé avoir par les arguments marketings. Je pensais au départ utiliser mon serveur habituel, mais il manque parfois d'espace disque. C'est là que j'ai vu que rsync.net proposait une offre pour les utilisateurs de git-annex, en proposant 50Go d'espace disque pour 60$ l'année. C'est trois fois moins cher que leurs tarifs habituels. Leur argument est que les utilisateurs de git-annex demandent beaucoup moins de service de support technique que les autres, ils peuvent donc faire un prix. On verra l'an prochain si c'était vraiment utile. Comme les fichiers synchronisés sont chiffrés, j'ai pas de remords à les laisser là-bas. Et vu la simplicité de git-annex, migrer vers un autre serveur tampon sera trivial si c'est pertinent.

Pour ma part, je pense m'en servir pour :

  • Synchroniser certains fichiers entre le travail et la maison ;
  • Partager des documents avec ma famille plus facilement qu'auparavant (et potentiellement avec des amis) ;
  • Gérer la réplication des sauvegardes. Grâce à l'affichage de la localisation des fichiers, c'est vraiment très pratique.

J'ai été suffisamment convaincu pour faire un modeste don au développeur, qui souhaite travailler un an supplémentaire sur le projet. À noter qu'il ne demande que 1000$ par mois de travail, ce qui est ridiculement bas pour quelqu'un avec ses compétences. Après un fignolage de l'application Android, il prévoit de développer le logiciel pour Windows. Ce serait une bonne nouvelle pour le côté « partage avec les amis ».

P.S. : attention par contre à prendre la toute dernière version. L'assistant a connu de très nombreuses corrections de bugs, qui sinon peuvent être très déconcertants.

mardi 15 janvier 2013

Munin, retour à la normale

J'avais critiqué la nouvelle version de Munin car elle supprimait la possibilité de générer des graphiques par cron. Je n'étais probablement pas le seul à considérer que c'était une régression, car :

  • Il est maintenant de nouveau possible de générer les graphiques par cron
  • C'est redevenu le mode par défaut du paquet Debian, avec la justification : « switching back to cron graphing (as it better for small setups) ».

Je ne peux qu'applaudir des deux mains. J'ai de nouveau mes graphiques en direct quand je vais les voir, je ne suis plus obligé d'attendre un temps assez important qu'ils se génèrent (sur une machine avec un petit processeur, ça se sent vraiment). Et la configuration est bien plus simple en cron qu'en CGI, notamment car ça fonctionne très facilement avec n'importe quel serveur Web.

Edit : c'était évidemment trop beau pour être vrai. On commence par rire devant ce bug, qui provoque l'écriture de milliers de lignes toutes les 5 minutes pour ne rien dire. On continue avec celui-là. Essayer d'écrire à la racine du système de fichier, c'est tout de même peu courant.

lundi 23 juillet 2012

Raccourcir les commandes sur Weboob

Dans l'utilisation quotidienne de Weboob, il peut parfois devenir lassant de taper des commandes, qui sont relativement longues. Quelques exemples, taper "subscriptions" dans boobill, "transfer" dans boobank, "forecasts" dans wetboobs. Bien sur on peut activer l'auto-complétion, mais ça reste relativement peu optimal.

Suite à des discussions sur IRC, une nouvelle méthode pour réduire la longueur des commandes a été ajoutée. Le principe est de ne taper que les premières lettres de la commande, comme peut le permettre la commande "ip" (une ou deux lettres sont habituellement suffisantes pour supprimer les ambiguïtés). Si plusieurs solutions existent, une erreur est renvoyée à l'utilisateur avec une liste de suggestions de commandes possibles commençant par le préfixe indiqué.

Du coup, on peut maintenant faire des choses comme :

$ boobill su
* (0177-XXXXXX@nettokom) 0177-XXXXXX - 27,33 € - 14.06.2013 - Einheitstarif
* (06XXXXXXXX@freemobile) 06XXXXXXXX - Forfait 60mn/60SMS à 2 euros

$ wetboobs fore dresde
* Aujourd'hui:    (27C - 27C) Nuit claire
* Mardi 24:       (29C - 29C) Soleil
* Mercredi 25:    (30C - 30C) Soleil
* Jeudi 26:       (23C - 23C) Soleil

$ boobill d
Unknown command: "d"
Do you mean: download, details?

Comme les alias peuvent changer lors d'ajouts de fonctions aux applications, il n'est pas recommandé de les utiliser dans les scripts. Mais au quotidien, ça permet d'utiliser plus rapidement Weboob.

Cela va d'ailleurs dans le même sens qu'une autre optimisation, cette fois-ci dans boobill uniquement, qui permet de ne pas taper l'identifiant de compte dans les commandes usuelles si le compte est unique. On peut ainsi taper :

$ boobill de

Plutôt que :

$ boobill details 0177-XYGHZF@nettokom

mercredi 30 mai 2012

Faire marcher Munin 2.0 avec Ocsigen

La nouvelle version de Munin vient d'arriver dans les dépôts testing de Debian. Cette version à le mauvais goût de désactiver la génération des graphiques par cron, seul le mode « CGI » marche encore.

J'utilise un serveur Web un peu alternatif, Ocsigen, dont j'ai d'ailleurs déjà parlé ici. Pour faire marcher le mode CGI de Munin il faut :

  • Rajouter le module CGI dans la configuration d'ocsigen si ce n'est pas encore fait :
<extension findlib-package="ocsigen.ext.cgimod"/>
  • Rajouter la configuration qui va bien dans la déclaration des sites :
        <site path="">
           <cgi regexp="munin-cgi/munin-cgi-graph/" dir="/usr/lib/cgi-bin/" script="munin-cgi-graph"/>
        </site>
  • Mettre les droits en écriture pour l'utilisateur Ocsigen sur le dossier /var/lib/munin/cgi-tmp
  • Vérifier les droits sur les logs du CGI, situés dans /var/log/munin/munin-cgi-graph.log

J'ai mis un peu de temps à réussir à le faire marcher, notamment car la documentation sur le module CGI d'Ocsigen est relativement incomplète (j'ai été obligé d'aller voir le code pour comprendre comment ils définissaient les variables d'environnement au script CGI). Autre point noir, le mode FastCGI n'existe pas.

Je suis assez déçu de cette évolution de Munin, la méthode par cron étant très pratique pour éviter des temps de chargement de pages longs. Les fichiers étaient générés de temps en temps en arrière plan, et le serveur HTTP ne transmettait que des fichiers statiques. Maintenant, il faut patienter que les graphes veuillent bien terminer de ce régénérer. Mais il y a l'air d'avoir des bonnes nouveautés, j'espère qu'elles compenseront à l'usage.

Mise à jour le 9 novembre 2012 : remplacement de "cgi-bin/munin-cgi-graph/" par "munin-cgi/munin-cgi-graph/"

jeudi 26 avril 2012

Weboob, ou comment se passer de navigateur Web (1/2)

Qui me fréquente un peu a déjà entendu parler d'un logiciel nommé Weboob, pour Web Out Of Browser. Il est donc naturel d'en parler un jour ou l'autre sur ce blog.

Concrètement, ce logiciel permet d'aller chercher des informations sur des sites Web sans utiliser un navigateur traditionnel. Dans un monde idéal, Weboob n'existerait pas et les données seraient facilement exportables sur tout site Web. Ce n'est cependant que rarement le cas, et Weboob a l'ambitieuse mission de pallier aux carences des sites Web. Cela le rend forcément très riche, car le Web regorge de fonctionnalités... Par une petite suite de billets (probablement deux, ou trois, selon l'humeur) je vais présenter tout ce dont je me sers au quotidien (dans un ordre historique d'utilisation), et ce qui me fait gagner un temps relativement important tous les jours.

Relevés de compte

C'est par boobank que j'ai commencé à utiliser (et contribuer à) Weboob. L'application permet d'aller chercher le solde de ses comptes, l'historique des opérations, les opérations à venir, et même d'exporter les données pour l'intégration à un logiciel de comptabilité. J'étais très demandeur de cette fonctionnalité pour les banques françaises, qui contrairement aux banques allemandes forcent la connexion à leur site bourré de publicités plutôt que de permettre un simple export par des protocoles bien connus. Concrètement, avec le clavier virtuel, le changement régulier obligatoire de mots de passe, le site plutôt lent, je passais un temps fou à suivre mes comptes sur la BNP. Alors qu'en deux clics c'était fait pour la Deutsche Bank.

J'ai donc été bluffé quand j'ai utilisé pour la première fois Weboob et le module de la BNP. En une commande dans le terminal je pouvais enfin vérifier que je n'étais pas dans le rouge. Ça m'a tellement plu que j'ai contribué pour la première fois aux alentours d'août 2010 avec quelques patchs pour la BNP.

Depuis, boobank n'a fait que s'améliorer. L'application permet notamment de faire des virements de compte à compte et l'export en .qif. C'est toujours plus long que de passer par aqbanking à la mode allemande, mais le bénéfice est plus qu'appréciable. Autre chose que j'ai pu apprécier lors de mon changement de banque, c'est l'agrégation des données de toutes les banques configurées. J'avais à ce moment là deux banques, et je pouvais suivre le solde des deux au même endroit.

En cerise sur le gâteau, un script existe pour faire des graphiques des comptes à travers munin. Complètement inutile, donc parfaitement indispensable.

En conclusion, Boobank est l'archétype de « Weboob ne devrait pas exister ». Si les banques françaises arrêtaient de se moquer de leurs clients en forçant des accès à travers leur site Web ou des applications spéciales pour Smartphone (et je ne parle même des options payantes à des prix scandaleux pour recevoir des « alertes »), Boobank disparaîtrait immédiatement. Des solutions existent, comme les banques allemandes le prouvent.

Surveillance de l'Elbe

Vivre à Dresde, c'est vivre dans une ville au niveau du fleuve bien changeant. Ce n'est heureusement pas souvent comme en 2002, mais les variations peuvent tout de même être spectaculaires. Je ne suis pas ultra fan du site officiel (notamment car il ne publie pas un réel historique des données), et j'avais donc programmé un petit module Weboob pour suivre cette évolution, et faire des jolis graphiques comme celui-ci :

elbooc_dresden-year.png

(des observateurs un peu curieux pourront détecter une anomalie en décembre, mon serveur étant en panne...).

J'ai longtemps gardé dans mon coin ce module, qui était vraiment peu configurable et écrit (trop) rapidement pour mes besoins spécifiques. J'ai cependant fini par le proposer dans Weboob, et il est présent depuis la version 0.b dans la version officielle et utilisable à travers Wetboobs. Pour savoir le niveau de l'Elbe (ou de tout autre cours d'eau en Saxe), une commande très simple est maintenant disponible :

$ wetboobs gauges Elbe

On peut aussi aller chercher l'historique d'une sonde, ou bien juste la dernière valeur connue. Bien entendu, si je l'ai fait pour la Saxe, on peut imaginer écrire le même module pour la France entière via Vigicrue. Et coupler Weboob à un petit script pour recevoir un mail en cas d'alerte de crue, c'est assez simple. Le tout en attendant que les autorités publiques allemandes et françaises commencent à publier des Données ouvertes.

La suite

Dans un autre billet... Avec notamment la récupération des articles de journaux, le téléchargement de vidéos, et bien d'autres trucs.

mardi 26 octobre 2010

Le RFC 2410

Dans la catégorie RFC amusant, je connaissais déjà le très classique RFC 1149, décrivant la transmission de paquets IP par des pigeons voyageurs (version anglaise, version française).

J'ai découvert aujourd'hui le RFC 2410, qui décrit l'algorithme de chiffrement "NULL". Ce chiffrement, ne fait tout simplement rien. Il est pourtant étudié de bout en bout, que ce soit par un cours historique, des vecteurs de tests pour vérifier que l'algorithme fonctionne, etc.

Je ne dis pas que c'est la lecture du siècle, mais c'est sympa pour comprendre la structure d'un RFC, sans avoir à se prendre la tête pour comprendre le contenu.

dimanche 7 juin 2009

Mais arrête de m'interrompre un peu !

Le noyau 2.6.30 n'est pas encore sorti en version finale mais c'est déjà trop la fête. J'ai testé le noyau 2.6.30-rc8 mis en paquet par un développeur Debian pour l'architecture ARM (oui faut le faire à la main car ARM n'est pas compilé par défaut sur le dépôt experimental des noyaux Debian...). Et le moins que l'on puisse dire c'est que les résultats sont impressionnants. Je me plaignais depuis longtemps du débit avec les disques durs, et je fais donc les tests à chaque installation d'un nouveau noyau (à tout autre logiciel égal, le serveur étant laissé en Debian Lenny depuis sa sortie).

Résultats avant le changement de noyau :

(en raid5) Timing buffered disk reads:   46 MB in  3.00 seconds =  15.31 MB/sec
(en raid10) Timing buffered disk reads:   36 MB in  3.08 seconds =  11.68 MB/sec

Résultats après le changement de noyau :

(en raid5) Timing buffered disk reads:  110 MB in  3.04 seconds =  36.14 MB/sec
(en raid10)  Timing buffered disk reads:   96 MB in  3.01 seconds =  31.86 MB/sec

Plus du double, ça fait beaucoup de différence. Comme hier soir c'était également « jour de vérification du raid » (premier samedi du mois quoi...) j'ai pu sentir la différence. Si par exemple au mois d'avril les logs indiquaient :

 
Apr  5 18:51:31 floolf kernel: md: md2: data-check done. 

Aujourd'hui j'ai eu le droit avant le réveil à ceci :

 
Jun  7 09:15:18 floolf kernel: md: md2: data-check done. 

Dans les deux cas même heure de départ vers 1h du matin :)

L'explication de cette énorme amélioration se trouve en surveillant les interruptions. Sur les noyaux précédents j'obtenais des graphiques avec munin de plus de 1500 interruptions par seconde lors de la reconstruction du raid. Désormais ça plafonne à 150, réduisant énormément la part du processeur utilisée pour les traiter. Dix fois moins d'interruptions pour un travail supérieur, je ne dis pas non. Reste à savoir ce qui coinçait exactement et pourquoi cette optimisation possible n'avait pas été repérée avant... En attendant je remercie mille fois la qualité de l'équipe Debian en ARM et les développeurs du noyau.

mercredi 20 mai 2009

L'anonymat n'est pas un crime

Non ce titre un peu racoleur n'a pas de rapports avec l'évolution législative récente et à venir française concernant les télécommunications. Ça en est loin, mais c'est plus ou moins le fond d'un des cours que je suis à la faculté de Dresde, dont le thème est la protection des données personnelles et de la vie privée en générale. Vaste sujet en Allemagne, ou des scandales à répétitions n'en finissent plus d'apparaître.

L'ensemble des enseignants de ce cours sont forcément très engagés sur le sujet, mais également reconnus dans toute l'Allemagne pour leurs connaissances. Le cours de ce mardi commençait par des évidences toujours bonnes à rappeler sur la facilité de fichage grandissante. Deux exemples grands publics, la télévision et les journaux. Si la diffusion « à l'ancienne » par satellite ou hertzienne ne permet pas de savoir qui regarde quoi (et conduit à des instituts de sondages plus ou moins fiables, dont l'excellent film Free Rainer traite un peu), la télévision par IP permet très facilement d'établir un profil d'utilisateur et des émissions favorites, tout comme la télévision à la demande quel qu'en soit le genre. De la même façon, un acheteur de journaux en kiosque fournira bien moins d'informations sur ces goûts qu'un utilisateur de journaux sur Internet. Et ainsi de suite...

La suite était un peu plus technique avec la présentation du logiciel JAP, projet de recherche de la TU-Dresden. À la base c'était une preuve de la faisabilité de l'anonymisation des communications, désormais on peut je pense le considérer comme un logiciel complet. Contrairement à Tor ou l'utilisateur ne sait pas le chemin de ses paquets, JAP est plutôt déterministe, et il faut faire confiance aux serveurs intermédiaires qui s'ils s'associent peuvent bien évidemment retrouver qui fait quoi.

La partie la plus intéressante était pour moi la question du droit. Ils sont très pointus sur le sujet, et la loi allemande actuelle (bien qu'évoluant régulièrement...)leur permet en toute légalité de fournir le service sans conserver les données, hormis ce qui est explicitement mentionné. La bonne nouvelle c'est ça :

According to §113a Section 8 of the German Telecommunications Act it is forbidden to log any information about destinations and requested Internet pages. Therefore neither IP-addresses of contacted servers nor requested URLs will be logged.

Ils ont dans le passé déjà reçu des injonctions de la police leurs demandant des informations pour retracer les agissement de certains utilisateurs, jamais avec succès. Le logiciel est multiplateforme et devrait marcher sans trop de soucis un peu partout. Bien entendu, si comme Tor il permet un certain dégré d'anonymat, il ne protège en rien de l'utilisation des données volontairement publiées sur l'internet, et ne garanti aucune sécurité en dehors de la « zone de Mix ». Et en cas d'utilisation de protocoles en clairs, il suffit de se mettre en sortie du système pour attraper les mots de passe.

Mais ça c'est le sujet des cours de cryptographie. :)

lundi 23 février 2009

Brücke

Sur le pont d'avignon, on y danse... Euh nan c'est pas ça.

Dans ma petite maison, le réseau n'est pas très très complexe. Nous avons une box au milieu du couloir, pour envoyer du WiFi dans les quatre chambres. Et hop, ça fait un réseau qui convient globalement à tout le monde. De mon côté ensuite, j'ai deux ordinateurs portables avec une connexion WiFi et filaire, un « serveur » avec une antenne WiFi externe (une clef USB quoi...), et une imprimante qui n'a pas accès au WiFi. En résumé, un superbe schéma :

reseau_dresde.png

Comme l'imprimante n'a pas le WiFi, et que le serveur fourni des fichiers en NFS aux deux portables (ouais le film en WiFi, c'est pas top top...), la connexion filaire est obligatoire. Par simplicité et pour conserver la configuration existante auparavant dans mon précédent logement, je n'utilisais pas le WiFi sur les deux portables et utilisait le serveur comme passerelle. Le tout de la façon la plus moche possible, avec du NAT.

  • Avantages ;
    • Ben ça marchait
    • J'avais rien à changer ou presque, juste brancher et configurer le WiFi sur le serveur,
    • Pas de questions de gestion des droits sur le NFS,
    • Je pouvais faire ce que je voulais avec les annonces DHCP sur mon réseau.
  • Inconvénients ;
    • Imprimante non accessible depuis le réseau WiFi,
    • Aucune mobilité (quand je déplace un portable, je passe en WiFi, et l'accès aux autres machines devient chiant),
    • Solution très moche.

J'ai récemment voulu changé pour une solution plus « propre », en unifiant les réseaux filaires et WiFi. Ma motivation principale était de pouvoir imprimer depuis le salon ou la cuisine, et ne pas être obligé de reconfigurer le réseau à chaque déplacement. Objectif donc faire un pont avec brctl, le serveur aurait retransmis tous les paquets qu'il était nécessaire de retransmettre sur les deux interfaces.

  • Avantages ;
    • Techniquement le plus simple (genre 3 commandes),
    • Le plus beau :)
  • Inconvénients ;
    • Ça justepasmarche...

J'ai tenté de le mettre en place, mais malheureusement sans succès. Après analyse, en fait l'arp ne passait que dans un sens du réseau. Ma carte WiFi USB ne semble pas capable d'émettre de paquets avec une adresse MAC qui n'est pas la sienne, ce qui est très balaud pour un pont.

En gardant plus ou moins le même plan, si la carte refuse d'utiliser une MAC qui n'est pas la sienne, et bien faisons lui émettre la sienne ! Un logiciel tout simple permet de le faire, parprouted.

  • Avantages ;
    • Pas besoin de sortir l'artillerie lourde,
    • Ça fait ce que je voulais,
  • Inconvénients ;
    • Publicité mensongère...

Ce que fais techniquement ce programme, c'est que lorsqu'il voit passer une requête arp, il rajoute une route vers cet host sur la bonne interface, et transmet la requête. Malheureusement, deux gros défauts. Le premier, pas forcément si grave, d'après ce que j'en ai vu il ne répond pas « proprement » lorsqu'il transmet une réponse arp. Plutôt que de répondre en unicast, il le fait en broadcast pour dire « titi à l'adresse toto ». C'est pas glop. Le second, bien plus chiant, les interfaces réseaux du « pont de niveau 3 » ne répondait plus aux requêtes arp qui leurs étaient adressées directement. Pas de bol... On oublie donc.

Du coup, par dépit, je l'ai fait à la main. J'ai décidé unilatéralement que les adresses ip finissant par 200 jusqu'à 210 seraient pour le réseau filaire. Les autres laissées pour le réseau filaire. J'ai ensuite mit la même adresse IP sur les deux interfaces du serveur. Le tout résumé dans un énorme /etc/network/interfaces :

auto lo
iface lo inet loopback
  # On réécrit l'arp qui doit l'être des deux côtés
  up echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp

auto eth0
iface eth0 inet static
  # .34 est l'adresse IP donnée côté WiFi par la box
  address 192.168.178.34
  netmask 255.255.255.0
  # La liste des IP côté filaire
  up route add -host 192.168.178.200 dev eth0
  up route add -host 192.168.178.201 dev eth0
  up route add -host 192.168.178.202 dev eth0
  up route add -host 192.168.178.203 dev eth0
  up route add -host 192.168.178.204 dev eth0
  up route add -host 192.168.178.205 dev eth0
  up route add -host 192.168.178.206 dev eth0
  up route add -host 192.168.178.207 dev eth0
  up route add -host 192.168.178.208 dev eth0
  up route add -host 192.168.178.209 dev eth0
  up route add -host 192.168.178.210 dev eth0
  # Tout ce qui n'est pas dans cette liste doit passer par l'autre côté
  up route del -net 192.168.178.0 netmask 255.255.255.0 dev eth0

# Configuration automatique du WiFi
auto wlan0
iface wlan0 inet dhcp
        wpa-conf /etc/wpa_supplicant.conf

Cette solution ne propage que l'unicast. Pour le DHCP, il fallait donc soit faire un dhcp-relay sur le serveur, soit reconfigurer le serveur DHCP. J'ai choisi la seconde solution, car la box ne permet aucune configuration des adresses distribuées. Ainsi côté fil, les IP attribuées sont bien entre 200 et 210.

  • Avantages ;
    • Une solution qui marche...
    • Elle permet la mobilité, je peux imprimer, y'a plus de NAT, la vie est belle
    • Je vois pas passer tout le broadcast bizarre des voisins :)
  • Inconvénients ;
    • Une configuration chiante. Mais très fortement facilité néanmoins par le /etc/network/interfaces et les outils Debian associés (et je les remercie vraiment...)
    • Les portables ne peuvent pas avoir la même IP sur l'interface WiFi et filaire
    • Sûrement pas la solution dont je rêvais.

Si jamais vous avez d'autres idées pour faire plus propre et qui fonctionne avec mon matériel, n'hésitez pas à le signaler...

Sans transition aucune, petit bulletin météo. Depuis une semaine, c'est assez marrant à Dresde. Il neige beaucoup durant la nuit, et tout les matins c'est tout blanc partout. Par contre la journée, tout fond progressivement, ce qui rend la vie des piétons affreuse. J'en ai d'ailleurs conclu qu'il y avait pire que le gel, c'était le dégel. Dommage que tout ça ne soit pas resté, on en aurait une belle quantité maintenant.

mardi 17 février 2009

Dépendances

Un peu par hasard je me suis demandé à quoi pouvait bien ressembler l'arbre de dépendance des paquets sur mes machines. Aptitude why et consort, c'est bien joli, mais visuellement, ça donne quoi ? KiBi m'a fait gagné énormément de temps en m'indiquant l'existence de debtree, qui fait presque ce que je voulais, mais paquet par paquet, et non pas l'ensemble du système.

Pour contourner le problème sans trop réfléchir, j'ai créé un paquet dépendant de tous les paquets installés manuellement, et ceci tout d'abord sur un serveur avec très peu de paquets installés (300 paquets au total, 80 installés « manuellement »). Je suis très content du résultat, même s'il faudrait un écran énorme pour le visualiser entièrement tout en restant lisible. Petit extrait du graphique :

floolf-extrait.jpg

Et comme c'est trop gros pour ressembler à quelque chose, la version réduite et en jpg (1,4Mo), l'originale en png (6,4 Mo).

debtree supprime naturellement les paquets comme libc6 dont beaucoup trop de paquets dépendent, ce qui a le bon goût d'éviter les points d'agglomérations évidents. Je n'ai pas encore testé toutes les options de debtree, mais il est probable qu'il soit possible de faire plus clair encore (l'option --condense par exemple...).

vendredi 19 décembre 2008

VLC de noël

vlc.png À gauche, une icône de vlc lancé avant minuit. À droite, un VLC lancé depuis moins de deux heures.

J'aime bien, je trouve que ça change agréablement, dommage que plus de programmes ne fassent pas pareil.

vendredi 28 novembre 2008

OCaml schnellste

Tous ceux qui touchent un peu trop à l'informatique ont tendances à devenir amoureux des graphiques et des statistiques, surtout peut-être quand ils ont étudiés quelques matières scientifiques auparavant. Or, dans un article du dernier Linux Magazine version allemande, un petit article bien sympa compare les performances de différents langages de programmation, par des programmes écrits par les lecteurs.

Pour bien comprendre, il faut dire que cette histoire traîne depuis plusieurs numéros. Dans le numéro d'octobre, ils publiaient plusieurs articles de comparaisons de langages. L'un d'entre eux était un test grandeur nature, dont les règles du jeu étaient assez simples. On prend en entrée un texte rempli de références, sous la forme X. Ces références sont non triées, bordéliques à souhait. Le programme doit donc chercher tout ces références, les trier, et modifier la bibliographie en fin d'article en conséquence. Le texte en question est de 55Mo, avec un million de notes de bas de page, autant dire que c'est conséquent.

L'article du mois d'octobre demandait à des « noms » de certains langages d'écrire une solution à ce problème. Cela pouvait par exemple être quelqu'un qui a écrit un livre sur le langage considéré. Les résultats étaient décevant et surprenant, Java FX était ainsi avec ses 30 secondes plus rapide que le Perl s'exécutant en 52s. Le php était bien classé en 36s, et le python consommait trop de mémoire et ne finissait pas, bref c'était pas la joie. En conséquence on pouvait lire dans le numéro du mois de novembre une solution en python fonctionnelle, et une annonce d'un nouvel article pour décembre.

Et que nous dit le numéro de décembre ? Que le OCaml est le plus rapide. Ils ont reçus plus de 50 contributions des lecteurs, dans de nombreux langages, du C au java, en passant par awk. Les résultats par rapport aux « personnes connues » sont impressionnants, OCaml s'exécute en 6s, une solution en Java en 6,8s, et le perl en 7,7s. Bref rien à voir, et le nombre de lignes des programmes diminue lui aussi fortement.

OCaml a donc je pense encore une fois montré ses qualités, grâce à Rörd Hinrichsen qui semble manger du fonctionnel à tout les petits déjeuner, sa solution en Haskell étant aussi pas trop mal classée (et il a l'air aussi de faire du Lisp...).

Au niveau popularité par contre Python et Perl mènent de loin. Au niveau nombre de lignes, la solution en Java est assez catastrophique avec 365 lignes, là ou en perl ou en Ruby il n'en faut pas plus de 15. Le C n'est pas ultra rapide avec 8,3s, il faut dire qu'a priori il n'est pas très naturel d'effectuer de telles opérations en C (une solution en C++ par contre pointe en troisième position en 7,5s).

Tout ces petits programmes sont disponibles sur le site de Linux Magazine, et je dois avouer qu'il est assez rigolo d'en regarder certains. Bien entendu, ce test vaut ce qu'il vaut, un langage n'étant classé que par les performances des différents programmeurs et lecteurs du magazine. Mais il en ressort tout de même quelques tendances que je trouve intéressantes.

  • Remarque inutile 1 : marrant personne n'a tenté de faire mieux en php
  • Remarque inutile 2 : la solution en awk est peut-être lente mais je trouve qu'elle a trop la classe
  • Remarque inutile 3 : y'a même eu des (3) contributions en Tcl... Étrangement, ben elles sont trop lentes pour avoir été classées, faut chercher en fin du fichier avec tout les résultats pour les trouver.
  • Remarque inutile 4 : écrire un livre de référence sur le Perl ne suffit apparemment pas pour l'utiliser au mieux
  • Remarque inutile 5 : l'enchaînement de trois articles sur OCaml n'était pas prémédité, ce n'est pas que je deviens mono-maniaque

mercredi 26 novembre 2008

Algorithmus (2)

Reprise de l'article précédent sur le sujet, après avoir fortement amélioré les temps de calculs par un changement d'algorithme, voici quelques améliorations basées uniquement sur des modifications d'implémentations. En effet le lecteur attentif aura par exemple pu remarquer quelques lignes assez jolies, comme :

let cache_chemin = Array.make (power 2 n_nageurs) (0,[]) in

Ça commence bien, un "petit" tableau de taille 2 puissance n, avec à l'intérieur une liste de taille moyenne n/2. Ça fait beaucoup de mémoire. De plus, la récurrence est mal construite et on va chercher les résultats jusqu'en bas de l'arbre pour ensuite "dépiler" les résultats; Du coup on parcourt le tout deux fois, c'est un peu dommage.

Mais donc, situation initiale, pour n=20 le programme s'exécute en 6 minutes et prend jusqu'à 90Mo de mémoire. Maintenant améliorons tout ça ;

  • Changeons de compilateur, cool, plus que 45s. Assez logiquement cependant la mémoire n'évolue pas.
  • Procédons niveau par niveau. Si vous vous souvenez de ce schéma, il suffit de calculer une ligne puis la suivante, et de ne conserver en mémoire qu'au maximum deux lignes (une ligne ou l'on effectue les calculs, la ligne précédente pour chercher les meilleurs chemins déjà calculés). Cela implique pas mal de changements, mais ça vaut le coup. On arrive à 40Mo et 23s. Ce résultat est assez logique et prévu, on ne parcourt l'arbre qu'une fois à la place de deux pour le temps d'exécution. Pour la mémoire au pire moment on conserve les deux lignes centrales, qui représentent (de loin dans le brouillard breton) en terme de nœuds la moitié du total dans le triangle de pascal).
  • Quelques optimisations plus tard (utilisation du tri rapide à la place du tri classique, diminution du nombre d'affectations de variables dans la boucle principale, insertion propre d'un élément dans une liste triée plutôt que la retrier entièrement, quelques trucs que j'ai peut-être oubliés) on arrive à 19s. Merveilleux n'est-ce pas ?
  • Reste la mémoire, qui est toujours problématique. Pour les listes d'entiers représentant le chemin, j'utilisais le type "int" de OCaml. Soit 32 ou 64 bits, selon l'architecture. Pourtant je ne dépasse jamais 30 nageurs, donc la taille de l'entier est disproportionnée. Il n'existe pas de type "short" en OCaml, le mieux que l'on puisse faire c'est utiliser le type Int32 quand on est en architecture 64bits, mais c'est pas la joie. Mais désormais Batterie fournit facilement un petit module appelé BigArray. Ce module permet d'utiliser des entiers de 8bit, de manière indirecte. Ils ne sont utilisables que pour le « stockage » dans un tableau, quand on lit et quand on écrit on doit utiliser le type Int. Le reste après, c'est un tableau en C, mais c'est transparent pour le programmeur. Chouette, c'est juste pour le stockage que j'ai des problèmes. Donc je convertis tout ça (cela n'a pas été si simple, mais bref), peut-être pas de la façon la plus élégante mais en conservant au maximum ce qui était déjà fait (quitte à faire du fonctionnel, autant que ce soit utile). Et zioupla plus que 8Mo de mémoire occupée, et on gagne en moyenne une demi seconde en 18,5s.
  • L'implémentation précédente considérait que pour calculer une solution ou le nombre de nageurs étaient supérieurs au nombre de courses, il suffisait de rajouter des nages "virtuelles" qui rapportaient 0 point. C'est vrai, ça marche. Mais on peut faire mieux, en s'arrêtant à la N_ième ligne du parcours. Ensuite on prend le meilleur résultat parmi les noeuds de la ligne, et on aura le bon résultat. On y gagne encore un peu, mais comme on quitterait le cadre de "20 nageurs pour 20 courses" étudié depuis le début il n'est pas vraiment pertinent de le chiffrer.

Enfin voilà encore une belle victoire de canard. À compilateur constant on a divisé plus que par deux le temps d'exécution, et par plus de 10 la mémoire utilisée. L'intérêt n'est pas vraiment le gain de temps, qui reste dans des échelles raisonnables de mon point de vue. Par contre la diminution d'occupation mémoire permet de calculer des valeurs encore plus hautes de n, typiquement jusqu'à 28x28 sur mon ordinateur en 2h et 1,6Go de mémoire (pour 29x29 on peut l'imaginer en moins d'un jour, le swap dégradera fortement les performances mais tout de même. Par contre pour 30x30 on oublie, il faut changer l'algorithme ou m'acheter une machine avec plus de mémoire). Mais honnêtement on s'en fou vu qu'il n'est pas très utile d'atteindre ces valeurs :)

Note : j'ai volontairement négligé quelques aspects, comme la consommation de mémoire de la matrice des nageurs, ce genre de trucs, car leur complexité est négligeable devant celle de l'algorithme (même pour l'occupation mémoire). En vérité, les gains pour des n > 20 est encore plus grand que ce qui est présenté ici.

mardi 25 novembre 2008

Moi aussi je lis la doc

En cherchant comment peut-être faire un jour un paquet OCaml dans Debian, j'ai finit par lire la doc, en particulier la page sur la compilation. J'avais l'habitude d'utiliser ocamlc, que j'avoue avoir trouvé en tapant ocaml{tab} dans un terminal un jour ou je me suis dit que compiler mon truc serait mieux que de le lancer manuellement.

Et bien j'avoue avoir été bluffé par le résultat. Le temps de compilation est certes plus long (mais honnêtement je m'en fou vu que mes programmes en OCaml sont rarement très volumineux), mais le résultat en terme de performance est impressionnant, entre 6 et 7 fois plus rapide sur ce que j'utilise. Malheureusement ce n'est pas disponible pour les processeurs ARM, mais bon, c'est pas tout les jours noël...

samedi 22 novembre 2008

Les joies du passage en 64bit

Il y a désormais quelques semaines, j'ai rapidement réinstallé mon dernier portable en 64bit, ce que j'aurais du faire depuis longtemps vu qu'il n'y avait aucun raison de rester en 32. Bref bref, quelques constatations :

  • Le pilote libre "nv" est plus de deux fois plus rapide pour lire un film, c'est plus qu'impressionnant (avant ce n'était pas possible de lire un film en grand écran sans saccade, maintenant si). Tellement plus rapide que j'ai redémarré sur l'ancienne installation pour vérifier que c'était bien la même configuration et la même version de pilote.
  • Le pilote "nouveau" plante par contre toujours autant sur ma machine
  • # max_int ;; - : int = 4611686018427387903 (ça fait toujours plaisir)

Autrement à Dresde c'est aujourd'hui journée sous la neige, on rentre dans l'hiver pour de vrai. Pourtant je demande à chaque allemand que je croise, Dresde est beaucoup moins touchée par la neige que le reste de la Saxe, notamment grâce à l'Elbe.

vendredi 7 novembre 2008

Mise à jour

Grâce à Jeb le blog a été mis à jour, en passant à une version Dotclear2. Pas grand chose de nouveau du côté utilisateur (hormis peut-être le nouveau design, toujours celui par défaut, un jour j'en chercherais un mieux), par contre du côté de l'administration les changements sont assez impressionnants. J'ai pas encore compris l'utilité de tout, mais bon pourquoi pas (genre protéger des articles par des mots de passe, youhou).

Normalement ça devrait être un peu comme avant, sauf des changements volontaires. Mais si par hasard vous croisez des bugs faut pas hésiter à les signaler :)

- page 1 de 2