1. # 3045

    Paul d'Ivoi - Jud Allan, roi des Lads

     
    Pour les gens pressés ou ceux que la technique n'amuse pas, la version courte est visible sur le blog du bookscanner

    Prenez:

    * Un doux dingue qui construit une machine "infernale" dans un garage
    * Une oeuvre de 1909, dans le domaine public, qui n'est plus éditée
    * Un peu de temps et d'astuce
    * Beaucoup de logiciel libre et d'envie

    Vous obtiendrez deux epub, gratuits naturellement, et je l'espère parfaits !

    2 mois

    Cela aura été la durée, estimée, nécessaire pour reconstituer l'ouvrage après numérisation par le bookscanner.

    2 séances

    Il aura fallu deux séances de numérisation: la première avait mis en évidence un bug dans le logiciel embarqué dans les appareils photos qui corrompait certaines photos, les rendant inexploitables.

    2 moines copistes

    C'est ce travail de reconstitution qui a été le plus long bien entendu.

    L'objectif est simple: extraire et reformater le texte en Markdown de manière à faciliter la génération dans différents formats: epub, PDF, html, etc.
    Il s'agit également d'extraire les images d'illustration du livre
    original, tout en trouvant un compromis entre définition de l'image et poids final du livre en version numérique.

    Pour corser la difficulté, nous étions deux moines copistes. Il a fallu se synchroniser.

    Heureusement pour nous, et contrairement aux moines copistes,
    l'informatique et notamment le logiciel libre apporte son lot d'outils permettant cela.

    Nous avons donc utilisé:

    * Un bête éditeur de texte. Seule excentricité le concernant: la
    visualisation en temps réel de la conversion Markdown vers HTML
    * Git pour le suivi de version et l'intégration des
    corrections & images
    * Gimp pour le travail sur les images
    * pandoc pour la génération de l'epub final

    Le tout réalisé sur des machines équipées de GNU/Linux, avec une dose de ligne de commande pour "industrialiser" les corrections les plus courantes.

    2 epub

    Le livre original a été séparé en 2, pour conserver une taille de
    fichier raisonnable, et donc permettre la lecture sur un maximum
    d'appareils.

    Les epub sont disponibles sur le dépôt GitHub. Vous y trouverez:

    * la partie 1 Idylle en modern-sorcellerie
    * la partie 2 Lads’s king, le Roi des gamins

    Attention, les liens changeront à chaque nouvelle version de l'epub.

    2 doigts de technique

    Les fichiers de reconstitution de l'œuvre sont disponibles dans un dépôt GitHub.

    Préparation

    Le travail de numérisation vous donne une collection de photos prises par deux appareils photos, nommés right et left.

    Vous obtenez donc les pages paires dans le dossier right et les pages impaires dans le dossier left.
    Les photos sont de plus nommées automatiquement par les appareils
    suivant le format IMG_<num>.JPG. Naturellement, <num> ne correspond pas au numéro de page.

    Il faut donc commencer par réconcilier tout cela. Les pages de
    couverture sont renommées à la main, elle sont peu nombreuses.

    Il reste les pages paires

    PAGE=2
    for file in IMG_*.JPG;
    do
    mv right/${file} page-${PAGE}.JPG
    PAGE=$((PAGE+2))
    done


    et impaires

    PAGE=1
    for file in IMG_*.JPG;
    do
    mv left/${file} page-${PAGE}.JPG
    PAGE=$((PAGE+2))
    done


    Une fois toutes les pages rassemblées, il faut également leur appliquer une rotation de 90° vers la droite pour les pages impaires et 90° vers la gauche, ou 270° vers la droite, pour les pages paires.

    for file in page-*.JPG;
    do
    PAGE=${file#page-*}
    PAGE=${PAGE%.JPG}
    MODULO=$((PAGE % 2))
    ROTATE=$((270-MODULO*180))
    convert -rotate ${ROTATE} ${file} ${file%.*}.jpg
    mv ${file%.*}.jpg ${file}
    done


    Corrections du texte

    La partie reconnaissance de caractères ne sera pas détaillée ici (ce n'est pas moi qui l'ai faite), mais mes quelques essais avec Tesseract OCR ont été relativement satisfaisants.
    Benjamin, de son côté, a obtenu de meilleurs résultats avec ScanTailor et Tesseract.

    Néanmoins, on obtient dans tous les cas un fichier texte par page.
    On peut alors commencer les corrections.

    Dans mon cas, j'ai choisi le format Markdown. Couplé à pandoc, cela permettra d'avoir un format pivot à partir duquel il sera possible de générer le livre dans différents formats tels que PDF, epub, HTML, texte ou encore LaTeX par exemple.

    Il est également important de se préoccuper de la typographie. Cela améliore grandement le résultat final, mais pose parfois quelques soucis de compatibilité avec les liseuses.

    Au fur et à mesure, on devine que certaines corrections reviennent très souvent, trop pour ne pas être automatisées

    sed -i 's/fl/fl/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/fi/fi/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/ ?/ ?/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/ !/ !/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/ ;/ ;/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/ :/ :/g' 2-markdown_chapitres/part-*/*.md
    sed -i "s/'/’/g" 2-markdown_chapitres/part-*/*.md
    sed -i 's/‘/’/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/oe/œ/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/ae/æ/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/.../…/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/?../?…/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/!../!…/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/« /« /g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/ »/ »/g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/Mme /M^me^ /g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/Mmes /M^mes^ /g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/Mlle /M^lle^ /g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/Mlles /M^lles^ /g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/M. /M. /g' 2-markdown_chapitres/part-*/*.md
    sed -i 's/A /À /g' 2-markdown_chapitres/part-*/*.md


    Attention, n'exécutez ces commandes que sur une page corrigée pour limiter au maximum les effets de bord.

    Les images

    Le livre original étant illustré, il me paraissait naturel d'intégrer les illustrations au livre final.

    Il faut donc dégaîner GIMP pour:

    * Extraire l'illustration de l'image d'origine (et non de la version
    traitée par ScanTailor)
    * Convertir les images en "nuances de gris"
    * Exporter au format .jpg, qualité 90
    * Redimensionner l'image obtenue pour limiter le poids final de l'epub

    SIZE=480
    for file in *.JPG; do
    echo -n Converting ${file}...
    convert -resize ${SIZE}x${SIZE} -quality 60 "$file"
    "little/${file%.*}.jpg"
    echo done
    done


    Enfin, l'on peut générer l'epub lui-même. Je vous laisse étudier le fichier utilities/makefile du dépôt.

    Personnalisation de l'epub

    L'epub n'étant qu'un container
    zip
    , il est évidemment possible de la modifier avant de le reconstituer.

    unzip -d Jud_Allan-partie-1 Jud_Allan-partie-1.epub


    Dans mon cas, j'ai adapté le formatage des titres de chapitre et la feuille de style, puis reconstitué l'epub.

    cd Jud_Allan
    FILE="../output/Jud_Allan-part-1.epub"
    rm -f "$FILE"
    zip -X0 "$FILE" mimetype
    zip -X9Dr "$FILE" META-INF images *.*


    2 mercis

    Je ne peux évidemment terminer sans remercier Benjamin Sonntag pour sa "drôle de machine", mais également Agnès pour son aide pour la correction et sa patience dans l'apprentissage de Git !

    Voilà, si cela peut servir à d'autres, c'est tant mieux :)
  2. # 3044

    Adieu StatusNet, bonjour Gnu Social

     
    J'ai réalisé hier soir la migration de mon instance StatusNet vers GNU-Social. GNU-Social est le remplaçant officiel de StatusNet et, à ce titre, est 100% compatible.

    Pas de grosse surprise à attendre donc...

    La mise à jour s'est effectuée de manière très simple: cloner le
    dépôt GIT de Gnu-Social, vérifier que tous les correctifs que j'ai fait et utilise ont été intégrés, les ajouter le cas échéant, et pousser le code sur le serveur.

    Il ne manquaient que 2 correctifs, cosmétiques en plus, rien de grave.

    Une fois en place, lancer quelques scripts de mise à jour

    php scripts/updateurls.php
    php scripts/upgrade.php
    php scripts/checkschema.php


    Patienter (c'est un peu long de vérifier une base de 2Go sur un serveur n'ayant que 1Go de RAM)...

    Ré-ouvrir les accès web préalablement coupés, redémarrer les processus d'import Twitter...

    et pourtant...

    Et là, c'est le drame. Une trentaine de tweets ont été récupérés suite à l'interruption pour migration. Sauf qu'ils sont restés bloqués en file d'attente :-/

    15 minutes plus tard, 11 tweets seulement étaient importés, là où StatusNet faisait le boulot en quelques secondes. Un truc génial dans StatusNet, pour qui dispose d'un accès shell au serveur, c'est de pouvoir utiliser les processus de gestion de la file d'attente, afin de pouvoir effectuer les opérations d'envoi et d'import de messages en tâche de fond, plutôt que lors d'un appel HTTP.

    Sauf que, dans GNU-Social, le service de gestion de la file d'attente a (par défaut) purement et simplement disparu, au profit d'un gestionnaire "opportuniste".
    Celui-ci profite justement de chaque connexion HTTP pour traiter toute ou partie de la file d'attente...

    Sauf que sur un petit serveur un poil optimisé, par exemple en réduisant le temps d'exécution maximum de PHP, ben ça ne fonctionne plus. Le gestionnaire "opportuniste" n'a plus beaucoup d'opportunité, et il le dit en plus...

    Bon, je vous rassure, j'ai vite trouvé la solution...

    En l'occurrence, il faut d'abord réactiver l'ancien gestionnaire de file d'attente:

    --- a/scripts/getvaliddaemons.php
    +++ b/scripts/getvaliddaemons.php
    @@ -37,7 +37,7 @@ require_once INSTALLDIR.'/scripts/commandline.inc';

    $daemons = array();

    -#$daemons[] = INSTALLDIR.'/scripts/queuedaemon.php';
    +$daemons[] = INSTALLDIR.'/scripts/queuedaemon.php';

    if (Event::handle('GetValidDaemons', array(&$daemons))) {
    foreach ($daemons as $daemon) {


    Forcer son utilisation dans le fichier config.php

    $config['queue']['subsystem']     = 'db';


    Et enfin, éventuellement, supprimer le plugin en question qui risque de rentrer en conflit avec l'ancien gestionnaire. Là encore, dans le fichier config.php

    unset($config['plugins']['core']['OpportunisticQM']);
    unset($config['plugins']['core']['Cronish']);


    J'en ai profité pour désactiver également un autre plugin qui prétend faire "des choses" en profitant d'un appel HTTP.

    J'ai pas l'air comme ça, mais j'aime bien

    Bref, indéniablement du mieux.

    Beaucoup de correction de bug (parfois très vieux), incorporation de plusieurs correctifs qui attendaient chez StatusNet depuis plusieurs mois (années ?), mise à niveau de la compatibilité PHP & support de l'API witter 1.1 par exemple.

    Mais bon sang, pourquoi diable vouloir changer un truc qui marche comme le gestionnaire de file d'attente ? Parfois je ne comprends pas les développeurs...

    Merci à Postblue qui m'a fait gagner du temps pour la migration :)
  3. # 3043

    Tout est une question d'équilibre...

     

    Obi-Wan Kenobi à Dark Vador :
    « Tu devais amener l'équilibre dans la force, pas la condamner à la nuit ! »

    in « Star Wars, épisode III : La Revanche des Sith », source Wikipedia


    La surveillance de masse des citoyens par les États est un fait. Auparavant reléguée au rang de crainte émise par des paranoïaques, elle est aujourd’hui cruellement mise au jour par les révélations, entre autres, d’Edward Snowden.
    La nécessité de surveillance d’une société par l’État relève du besoin, simple à comprendre au demeurant, de protéger la-dite société. Il s’agit d’un moyen d’assurer la sécurité de la population qui la compose, des dangers et agresseurs intérieurs (ça c’est la police). Il s’agit également de pouvoir retrouver et punir ceux des citoyens qui décideraient de s’affranchir des règles en vigueur (ça c’est la justice). Les dangers extérieurs sont gérés par les forces armées.

    Elle relève donc d’un équilibre entre la protection de la vie privée et des libertés des citoyens et la nécessité de donner aux forces de l’ordre les capacités dont ils ont besoin pour assurer leurs missions. Cet équilibre a, toujours, été extrêmement délicat à trouver.

    Il faut se souvenir de la redoutable efficacité des services de Joseph Fouché durant le Directoire ou l’Empire pour comprendre que, même avec des moyens « restreints » comme ceux de l’époque, il est possible d’être particulièrement efficace.

    Ces moyens ont évolué bien sûr. Nous sommes passés des fiches cartonnées aux ordinateurs et c’est là une partie du problème. Il est non seulement possible de surveiller de manière beaucoup plus efficace, comprendre rentable, mais également de faire des choses jusqu’alors impensables, par exemple croiser les informations très rapidement.
    Si l’on considère que l’équilibre entre la vie privée et la nécessaire mission des forces de l’ordre était respecté il y a une trentaine d’années, il convient également de constater que cet équilibre a été rompu depuis, au bénéfice quasi exclusif des forces de l’ordre. Contre cela, pas grand-chose au profit des citoyens.

    Par exemple, si l’on savait il y a 30 ans que 2 personnes avaient échangé des informations puis qu’elles s’étaient rencontrées, il était en revanche potentiellement plus complexe d’affirmer l'existence d'un rapport de cause à effet entre ces 2 informations.
    Savoir que 2 personnes s’étaient rencontrées nécessitait au mieux d’avoir un indicateur sur place, au pire d’y envoyer quelques personnels de la préfecture de Police ou de la DST (à l’époque).

    Aujourd’hui, si l’on détecte un échange de mail et que la géolocalisation de leurs téléphones portables montre que 2 personnes étaient au même endroit en même temps, il est raisonnable de conclure que l’échange de mail pouvait bien concerner le rendez-vous. Ça paraît anodin, c’est au contraire tout:

    * la récupération de l’information est de plus en plus simple et coûte de moins en moins cher. Dit autrement, pour le même prix vous pouvez récupérer et stocker infiniment plus d’informations qu’il y a 30 ans.
    * l’analyse de cette masse d’information est également plus simple et efficace. La puissance des outils informatiques aujourd’hui permet d’obtenir une information en quasi temps réel, chose impensable il y a 30 ans, sauf à disposer d’une troupe nombreuse (la mémoire humaine est stupéfiante en termes de capacité de stockage et de traitement) mais évidemment chère et complexe à organiser.

    Bref, la surveillance généralisée est devenue la norme car elle est devenue bon marché.

    Suite aux révélations sur l’étendue de cette surveillance par les services secrets Américains, mais également Européens et notamment Français, une solution vite trouvée repose sur l’utilisation massive et généralisée du chiffrement. Le principe est simple: si la population a massivement recours au chiffrement, la surveillance généralisée va prendre du plomb dans l’aile.

    La généralisation du chiffrement empêchera les forces de l’ordre de travailler

    Aujourd’hui, selon les dires publics du directeur technique de la DGSE, la France joue en première division en ce qui concerne le recueil et l’analyse des métadonnées.
    Il n’est pas ici question du contenu des communications, simplement des metadonnées soit: qui communique avec qui, quand et pendant quelle durée.

    La généralisation du chiffrement ne devrait pas perturber tant que cela cette capacité. Il y aura néanmoins un impact comme l’explique Stéphane Bortzmeyer: par exemple pour le mail, l’utilisation de TLS masque les adresses mail source et destination. Seules subsisteront encore les adresses IP des machines qui acheminent le trafic.

    On sait également que des entreprises comme VUPEN Security font de la recherche de failles de sécurité un business. Elles sont très en pointe dans le domaine, gardent ces failles secrètes, pour les revendre aux services de sécurité, par exemple à la NSA.
    Il ne fait aucun doute que les services français ont un accès — contre espèces sonnantes et trébuchantes, business is business — à ces failles « 0-day ». Il est raisonnable de penser qu’ils les utilisent. Ils pourront continuer à les utiliser.

    Et, de toute façon, il y a de très grandes chances pour que les vrais méchants utilisent déjà massivement le chiffrement ou d’autres dispositifs de dissimulation.

    En passant, suggéreriez-vous de supprimer Tor ?
    Pourtant c’est du chiffrement, ça fonctionne et c’est utilisé par Silk-Road, que le FBI n’a réussi à stopper qu’après une boulette de son créateur.

    Le seul impact vraisemblable d’un chiffrement généralisé serait alors de noyer les communications des méchants dans la masse ? Voire, car les principaux services Internet aujourd’hui, de Google à Facebook en passant par Twitter ou Netflix, utilisent déjà le chiffrement.

    Ce que l’utilisation massive du chiffrement risque de changer en revanche, c’est que la surveillance généralisée redeviendra non rentable car beaucoup trop chère pour être réellement efficace.
    L’utilisation massive du chiffrement provoquera un ré-équilibre des pouvoirs entre État et citoyens.

    Jusqu'à ce qu'un jour, l’État obtienne un moyen simple de casser les clefs de chiffrement. On sera alors revenus à la case départ, l'équilibre sera à nouveau rompu jusqu'à ce que l'on trouve une autre solution.

    Une réponse technique à un problème politique

    Le chiffrement généralisé est en effet une solution non satisfaisante, plus exactement incomplète. Il est a priori nécessaire de compléter la réponse technique par une réponse politique. À mon grand regret cependant, je crains que cette réponse ne soit, au mieux, que partielle.

    Entendons-nous: même insuffisants, les garde-fous légaux existent déjà. Sauf que, comme souvent, la tentation est forte de tordre les grands principes pour arriver à ses fins.
    Une fois pris, bien entendu, il convient de s'excuser platement, de promettre la main sur le cœur et la larme à l'œil qu'on ne nous y reprendra plus… jusqu'à la prochaine fois…

    Ce n’est pas autrement que les différents services, US pour la NSA comme Européens pour la DGSE, parviennent à espionner leur propre population alors que la loi le leur interdit en théorie. Selon la rédaction de Reflets, il existe même de drôles de coïncidences entre les endroits où la France a vendu les systèmes d’Amesys ou de Qosmos et les points d’arrivée des câbles sous-marins d’Alcatel

    Au vu de tout cela, et connaissant nos politiques comme on les connait aujourd’hui, croyez-vous sincèrement qu’ils renonceront à pouvoir, un jour ou l’autre, refoutre la main dans le pot de confiture ?

    Le chiffrement devient de plus en plus une arme de protection massive du citoyen contre son propre État.

    L'État a eu en main tous les leviers de contrôle de la surveillance. Il a prouvé n'en être pas digne. Il est temps de lui en retirer une partie.

    Chiffrez… tout… en cas de besoin, vous devrez de toute façon donner la phrase de passe de votre clef aux forces de l'ordre lorsqu'elles sont mandatées par un juge et uniquement dans ce cas là.

    C'est aussi ça la séparation des pouvoirs. Reprenez le vôtre. La seule réponse à apporter consiste à utiliser les technologies de chiffrement à votre disposition et à expliquer au politique que, si on en est là, c’est de sa faute.
  4. # 3042

    L'« homme-masse »

     

    Partout l'homme-masse a surgi [...] un type d'homme hâtivement bâti, monté sur quelques pauvres abstractions et qui pour cela se retrouve identique d'un bout à l'autre de l'Europe. [...] Cet homme-masse, c'est l'homme vidé au préalable de sa propre histoire, sans entrailles de passé, et qui, par cela même, est docile à toutes les disciplines dites « internationales ». [...] Il lui manque un « dedans », une intimité inexorablement, inaliénablement sienne, un moi irrévocable. Il est donc toujours en disponibilité pour feindre qu'il est ceci ou cela. Il n'a que des appétits ; il ne se suppose que des droits ; il ne se croit pas d'obligations. C'est l'homme sans la noblesse qui oblige — sine nobilitate — le snob.

    Jose Ortega Y Gasset, La révolte des masses (1929), via Theatrum Belli
  5. # 3041

    Ivre, il décide de se mettre au C...

     
    en développant un module Nginx. Vous me direz qu'il y a plus simple, et vous n'aurez pas tort :)

    Ça faisait un bail que je voulais m'y mettre, sans trouver le courage de le faire, faute entre autre d'un objectif tangible et motivant.

    J'écris pas mal de doc. En markdown, parce que c'est plus rapide, et lisible, en l'état. Au boulot notamment, je prends des note sur l'architecture que nous utilisons, sur les recherches et travaux que je peux mener, des aides-mémoire des différents logiciels en production. Tout y passe... Tout en markdown.

    Utilisant Geany sous Debian Wheezy, j'ai naturellement installé le plugin markdown en backportant le paquet sid. Il me permet d'avoir le rendu HTML en direct, ce qui est bien pratique. Mais, histoire de partager mes notes avec mes collègues, l'idée a germé de pouvoir pousser les fichiers en markdown dans une arborescence web afin de pouvoir les consulter via un navigateur.

    Problème: il faut pouvoir convertir le markdown en HTML.

    Vous me direz que plein de scripts en python (voire même en Ruby pour les fous comme @Keltounet) font le job et le font bien, voire mieux. Là encore, vous n'aurez pas tord, mais il faut bien trouver un prétexte pour faire "des trucs" rigolos.

    Donc voilà. J'ai écris un module Nginx, en fait 2, qui transforment à la volée un document Markdown en HTML pour l'afficher dans le navigateur.

    Ils sont perfectibles bien sûr. Je n'ai pas la prétention de "savoir" programmer en C. Mais le défi m'a beaucoup plu, même s'il a fallu que @shtouff vienne à ma rescousse pour m'expliquer 2-3 bases quand même :) Merci à lui !

    En tout cas, ça m'a permit de démystifier, en partie, la programmation en C ainsi que le développement de module Nginx.

    Non, l'un comme l'autre ne sont pas si compliqués que cela... enfin... bon bref quoi...

    Le code est dispo, sous licence GPLv3, sur Github: https://github.com/jbfavre/ngx-markdown-module

    Happy Hacking !
  6. # 3040

    Le dilemme du prisonnier français

     
    Dans la théorie des jeux, le dilemme du prisonnier décrit une situation dans laquelle 2 joueurs ont intérêt à coopérer mais dans laquelle le choix rationnel pousse à trahir l’autre.

    En pratique, il s’agit de 2 prisonniers isolés, sans moyen de communication donc de concertation, qui se voient proposer un marché par l’administration pénitentiaire :

    Les options des prisonniers sont les suivantes:

     — si un des deux prisonniers dénonce l’autre, il est remis en liberté alors que le second obtient la peine maximale (10 ans) ;
     — si les deux se dénoncent entre eux, ils seront condamnés à une peine plus légère (5 ans) ;
     — si les deux refusent de dénoncer, la peine sera minimale (6 mois), faute d’éléments au dossier.


    D’une manière générale, le prisonnier a donc intérêt à dénoncer l’autre de manière à minimiser sa propre peine. Il s’agit d’un choix rationnel qui, pourtant, n’est pas optimal : si les deux choisissent de se taire, ils ne feront que 6 mois de prison contre 5 ans s’ils se dénoncent mutuellement.

    Oui mais voilà, comment s’assurer que l’autre fera le même choix ? Il n’existe aucun moyen de s’en assurer, tout repose sur la confiance mutuelle.

    Avec 2 prisonniers, c’est assez simple. Imaginez maintenant le même genre de problème avec... 60 millions de personnes.

    Et si la situation actuelle de la France pouvait être comparée à un dilemme du prisonnier géant ?

    La logique rationnelle voudrait que les Français acceptent le changement, porteur d’amélioration pour tout le monde.

    Mais chacun estime que l’autre va « gruger » et tirer la couverture à lui.

    Dans le principe, chacun est prêt aux efforts, sous réserve que ce soit l’autre qui les supporte.

    C’est bien connu, l’herbe est plus verte dans le pré d’à côté. Il est donc « normal » que l’effort soit porté par d’autres que soi.

    Pour certains, les politiques ne joueront pas le jeu (chat échaudé craint l’eau froide), pour d’autres, l’autre, l’étranger par exemple, est responsable de tous les maux. Pour d’autres enfin, une catégorie de la population, au hasard les fonctionnaires, ne fait aucun effort.

    Je n’oublie évidemment pas les patrons qui pensent que les salariés sont trop protégés et coûtent trop cher, pas plus que les salariés qui pensent que les patrons veulent juste les exploiter pour faire toujours plus de fric.

    Bref, tout le monde est à peu près d’accord pour constater le blocage et réclamer du changement, mais personne n’accepte de faire le premier pas, de peur d’être tout seul à en supporter les conséquences.

    Là encore, la confiance n’y est pas. Il est donc plus « confortable » de ne rien changer, plutôt que d’accepter un changement qui pourrait nous être défavorable.

    Avec ce type de raisonnement, on va tous prendre la peine maximum.

    Sauf... si « ça pète ».

    Dans ce cas là, les données du problème changent: la question ne sera plus de savoir quoi sacrifier ou quoi protéger. Si ça pète, nous seront au pied du mur.

    Dit autrement, nous risquons d’avoir le choix entre perdre beaucoup, ou perdre énormément, voire tout. En tout état de cause, si l’on va jusqu'au clash, il paraît illusoire d’espérer sauver les meubles. Ce sera la peine maximum pour tout le monde, plutôt que quelques efforts permettant de conserver un ensemble finalement pas si mal que ça.

    Ceci étant, le choc d’une révolte de grande ampleur pourrait également avoir pour effet de souder à nouveau la population, par delà les clivages traditionnels. Ce rapprochement pourrait alors déboucher sur un consensus pour faire évoluer le système (je sais, c'est très optimiste… mais c'est au conditionnel aussi hein…).

    En attendant, il paraît urgent de ne rien faire car, c'est bien connu:

    C'est au pied du mur qu'on voit le mieux le mur...

  7. # 3039

    Gestion des exceptions & Python

     
    Tout à la découverte de Python, j'ai besoin d'exécuter ceci:

    Essaie:
    mon bout de code
    Si ça merde:
    essaie ça plutôt
    Si ça merde toujours:
    laisse tomber


    Intuitivement, on voit ce dessiner un joli "if else else".
    Sauf que, en l'occurence, ça ne convient pas car "Si ça merde" & "Si ça merde toujours" correspondent en fait à des exceptions Python que je veux bien entendu gérer.

    En gros n00b à peine bourrin, je fais donc:

    try:
    mon code qui peut merder
    except:
    mon autre code qui peut merder aussi
    except:
    bon là ça va aller, je laisse tomber


    Évidemment, ça ne le fait pas:

    SyntaxError: default 'except:' must be last


    En fait, le mécanisme de gestion d'exception convient, mais il faut l'utiliser "convenablement", c'est-à-dire en imbriquant les try/except:

    try:
    try:
    mon code qui peut merder
    except:
    mon autre code qui peut merder aussi
    except:
    bon là ça va aller, je laisse tomber


    Merci à @pbeyssac, @guiguiabloc et @gordontesos pour le coup de main sur Twitter :)

    Le détail de la conversation se trouve ici

    Update
    L'ami @gordontesos s'est même fendu d'un billet pour (m')expliquer la gestion des exceptions en Python.
  8. # 3038

    Pour avoir préféré le crime de l’illégalité au crime de l’inhumanité

     

    Nous nous souvenions de quinze années de sacrifices inutiles, de quinze années d’abus de confiance et de reniement.
    Nous nous souvenions de l’évacuation de la Haute-Région, des villageois accrochés à nos camions, qui, à bout de forces, tombaient en pleurant dans la poussière de la route.
    Nous nous souvenions de Diên Biên Phû, de l’entrée du Vietminh à Hanoï.
    Nous nous souvenions de la stupeur et du mépris de nos camarades de combat vietnamiens en apprenant notre départ du Tonkin.
    Nous nous souvenions des villages abandonnés par nous et dont les habitants avaient été massacrés.
    Nous nous souvenions des milliers de Tonkinois se jetant à la mer pour rejoindre les bateaux français.
    Nous pensions à toutes ces promesses solennelles faites sur cette terre d’Afrique.
    Nous pensions à tous ces hommes, à toutes ces femmes, à tous ces jeunes qui avaient choisi la France à cause de nous et qui, à cause de nous, risquaient chaque jour, à chaque instant, une mort affreuse.
    Nous pensions à ces inscriptions qui recouvrent les murs de tous ces villages et mechtas d’Algérie : ‘L’Armée nous protégera, l’armée restera’.

    Nous pensions à notre honneur perdu


    Extrait de la plaidorie du commandant Hélie Denoix de Saint Marc devant le haut tribunal militaire, 5 juin 1961.
  9. # 3037

    Enlarge your RSS... la suite, mais pas la fin

     
    Le filtre bayésien ne fonctionne pas comme espéré. C'est sûrement de ma faute, j'ai dû rater un truc, mais en attendant je suis toujours bien embêté pour effectuer ma veille de manière plus efficace.

    Du coup, j'envisage à présent une solution intermédiaire: utiliser mon propre comportement pour calculer la pertinence des articles.
    Ceci ne m'empêchera pas de continuer mes recherches et tests concernant le filtre bayésien, dont je reste persuadé qu'il peut fonctionner, mais il faut bien avancer, d'une manière ou d'une autre.

    Petite consolation quand même, ces informations pourront être utilisées pour affiner l'analyse du filtre bayésien, lorsqu'il j'aurai réussi à le comprendre suffisamment pour le faire fonctionner proprement o/

    Quand ça veut pas...
    L'idée est donc la suivante: SelfOSS affiche les articles de manière "condensée", c'est à dire que seul le titre est visible. Si l'on veut voir le corps de l'article, on utilise la souris ou le raccourci clavier adéquat pour le faire. Il s'agit donc d'un événement au sens javascript du terme, événement que l'on peut également communiquer au serveur, même s'il ne l'est pas normalement.

    Outre l'ouverture de l'article, il est possible de sauvegarder l'article à l'aide, là encore, d'un clic ou d'un raccourci clavier. Dans ce cas-ci, le serveur est obligatoirement notifié (il faut bien enregistré l'état sauvegardé). On peut donc enrichir cette notification.

    Enfin, il est possible de partager l'article. Dans mon cas, ce partage s'effectue via mon instance Statusnet. L’événement n'est pas notifié au serveur, tout s'effectue en javascript, mais il reste possible de le faire.

    Nous avons donc 3 événements qui caractérisent ce que l'on pourrait appeler un intérêt croissant pour l'information. On peut trivialement attribuer une valeur à ces événements:
    * ouverture: 1
    * sauvegarde: 2
    * partage: 4

    Si cela vous rappelle les permissions d'un système de fichier Ext, c'est tout à fait normal :)

    Un article peut donc avoir une note maximale de 7, lorsqu'il a été ouvert, sauvegardé et partagé, ou toute combinaison d'action auxquelles correspondrait la somme des valeurs. Cette note peut et doit bien sûr être stockée dans la base de donnée. À partir du moment où les articles sont notés, on peut du coup envisager de calculer la note de la source (le flux donc).

    Ce calcul peut se faire avec une moyenne arithmétique, mais aussi avec une moyenne pondérée (plus un article est vieux moins sa note compte) ou encore d'une moyenne glissante, pour tenir compte d'une éventuelle évolution de nos centres d'intérêts.

    La note du flux peut alors être utilisée comme note des futurs articles, selon le principe que plus une source est jugée intéressante, plus il y a de chances que son prochain article le soit.

    Bien entendu, le calcul n'est nécessaire qu'au moment de la mise à jour du flux. Dans le cas de SelfOSS, cette mise à jour est précédée de la suppression des articles les plus anciens (par défaut 3 mois), à l'exception bien sûr des articles sauvegardés. Cela étant, on peut également considérer qu'un article de plus de 3 mois, fût-il sauvegardé, ne représente plus un intérêt tel qu'il faille le prendre en compte.
    Une fois le ménage fait, il est donc simple de calculer la note du flux et d'utiliser cette valeur comme note de départ des articles.

    Ceux-ci sont alors stockés en base avec la note. Cette dernière sera mise à jour en fonction des actions effectuées et la nouvelle note sera alors prise en compte à la mise à jour suivante.

    La boucle est bouclée, on repart pour un tour.
    Pour la mise en place de la chose, on ne dispose que des articles sauvegardés, les autres événements n'étant pas communiqués au serveur. Ceci permet toutefois un premier classement des sources, et donc un premier filtre des articles.

    Et... ça marche ?
    Ça c'est le principe. Sauf qu'en fait, on risque d'avoir au choix, une dispersion importante (c'est-à-dire que une ou plusieurs sources vont voir leur score s'envoler) ou au contraire une concentration importante qui perturberont le classement.

    Il ne s'agit que d'une intuition de ma part, mes compétences en maths étant... ahem... ce qu'elles sont, mais je vais essayer de faire quelques simulations pour voir.

    En attendant, je suis preneur de tous conseils, solutions miracles et autres artefacts pour gagner du temps (et des connaissances) :)

    Réactions possibles sur StatusNet, ou Twitter ou encore par mail: webmaster chez jbfavre point org
  10. # 3036

    Enlarge your RSS...

     
    Le spam est un fléau tel que de nombreuses recherches ont été effectuées pour le combattre.
    Parmi les découvertes réalisées, les filtres bayésiens figurent en bonne place des plus efficaces.

    Les RSS sont une bénédiction (si, si). Google s'en fout, mais pas moi.
    Je suis actuellement plus de 330 flux RSS, ce qui fait au-moins-tout-ça de nouveaux articles à consulter quotidiennement.
    Je pourrais en suivre davantage, mais je manque de temps pour tout lire.

    Il faut donc que je trouve une solution pour effectuer un premier tri.

    Il faut bien entendu que mon agrégateur de flux RSS réalise ce tri et me propose les articles susceptibles de m'intéresser en tête.
    Les autres sont toujours affichés bien sûr, mais en seconde partie de liste.

    Je passe sur les modifications nécessaires au moteur d'affichage, c'est trivial et sans grand intérêt ici.

    Le tri, en revanche, est beaucoup plus intéressant: on peut en effet faire un parallèle avec les filtres anti-spam.
    Schématiquement cela donnerait:
    * SPAM: l'article n'est pas intéressant
    * NON SPAM: l'article est intéressant

    Reste à l'implémenter...

    L'outil
    Mon agrégateur de flux RSS, SelfOSS, est écrit en PHP. La mise à jour des flux est également réalisée via PHP.
    Il paraît donc raisonnable de trouver un filtre lui aussi écrit en PHP. C'est le cas de php-classifier.

    L'apprentissage
    Une fois l'outil trouvé, il faut lui apprendre à distinguer le bon grain de l'ivraie.
    Pour cela, je dispose de la base existante de mon agrégateur, soit:
    * 20037 articles lus au total
    * 2296 articles lus et marqués ("starred" dans le jargon Selfoss)

    J'ai donc marqué un peu plus de 11% des articles lus.

    J'ai de plus, réalisé manuellement le travail de tri pour pouvoir tester le filtre.
    Parmi les articles dénombrés au dessus, on trouve donc:
    * 330 articles non lus
    * 133 articles non lus et marqués

    J'ai donc marqué un peu plus de 40% des articles non lus (Ceci pourrait me jouer des tours quant à la qualité de détection lors des tests).

    Le test
    L'idée est ici de construire un index à partir des articles lus en indiquant la catégorie (marqués ou non marqués).
    Ensuite, l'outil classifiera chacun des articles non lus comme "starred" ou "normal", sans savoir s'il a, ou non, été marqué au préalable.

    Il sera alors possible de vérifier l'acuité du filtre.

    Utiliser le titre
    En se basant sur le titre de l'article, on trouve:
    # time php examples/basic_title.php 
    Should be starred - Total: 133
    not found: 92
    found: 41
    error: 69.17%
    Should be normal - Total: 197
    not found: 31
    found: 166
    error: 15.74%

    real 0m6.735s
    user 0m6.604s
    sys 0m0.084s


    Comme on le voit, on obtient un taux d'erreur de détection des articles intéressants de près de 70%.
    Le taux d'article "normaux", mais détectés comme intéressant est lui de 15%.
    Néanmoins, les filtres bayésiens peuvent être entraînés.
    Il est donc envisageable de réduire le taux d'erreur au fil du temps.

    70% de non détection des articles intéressants peut paraître beaucoup.
    C'est sans compter sur le fait que le corpus est sans doute incomplet.
    Je ne sauvegardais pas tous les articles que je jugeais intéressant par exemple.

    A priori, on peut se dire que la classification basée sur le titre est un peu limitée.
    Il paraît évident qu'utiliser le contenu de l'article est plus pertinent.

    Utiliser le contenu
    Testons.En se basant sur le contenu de l'article, on trouve:
    # time php examples/basic_content.php 
    Should be starred - Total: 133
    not found: 133
    found: 0
    error: 100%
    Should be normal - Total: 197
    not found: 0
    found: 197
    error: 0%

    real 1m21.964s
    user 1m19.432s
    sys 0m0.708s


    Le script est évidemment plus long, mais ce qui surprend surtout, c'est le taux de détection des articles intéressant: 0%.

    Conclusion
    Quelques pistes de réflexion, qui pourraient expliquer l'échec de l'utilisation du contenu:
    * Flux RSS incomplets (merci la presse hein... entre autres)
    * Flux RSS d'images/BD. Pas ou très peu de texte, sans doute trop peu.
    * Problème de langue (flux RSS en anglais ou en français pour moi)
    * Pourcentage d'articles intéressants très différent entre le corpus de test et le corpus d'apprentissage

    Il convient également de regarder le détails des scores obtenus.
    Il est en effet possible que certains articles soient à la limite du seuil de détection.
    Mais, pour cela, il va me falloir quelque chose de plus souple, 'R' par exemple.

    À suivre donc...
  11. # 3035

    RTFM, encore et toujours tu appliqueras...

     
    Wireshark est très pratique.

    Mais sous Linux, par défaut, vous devez être root pour pouvoir intercepter le trafic sur une interface réseau.


    Wireshark dispose de beaucoup de filtres & de décodeurs. Ils sont extrêmement puissants et pratiques. Mais ils sont parfois boggués.

    Du coup, faire tourner Wireshark en tant que root devient potentiellement dangereux... mais tellement pratique.

    Sous GNU/Linux Debian, je ne sais pas comment cela se passe avec d'autres distributions, il existe pourtant une solution. Elle est décrite dans le fichier /usr/share/doc/wireshark/README.Debian


    Members of the wireshark group will be able to capture packets on network interfaces.


    Arf... on devrait toujours RTFM toujours... surtout quand on pense ne pas en avoir besoin :)
  12. # 3034

    L'auto-hébergement, ou le risque de Loto-hébergement ?

     
    Disclaimer: je pratique l'auto-hébergement «tout seul dans mon coin»™ depuis plus de 5 ans. Vous avez donc le droit de ne pas me trouver crédible :)

    L'auto-hébergement a, à nouveau, le vent en poupe. Même Stéphane Bortzmeyer le dit: l'auto-hébergement, c'est bien, c'est même LA solution pour ne même pas avoir mal quand Google ferme GReader !

    La définition de l'auto-hébergement choisie par Stéphane, que je rejoins sur ce point, est simple:

    on prend une machine chez soi, ou bien hébergée chez un professionnel, on y met les logiciels nécessaires (il en existe plein, souvent sous une licence libre) et on a son petit nuage à soi


    Pourquoi ça ne marche pas ?
    Là encore, je rejoins Stéphane pour expliquer le constat d'échec: les gens ne s'auto-hébergent pas car cela demande des compétences techniques que tous n'ont pas. À ceux qui seraient tenter d'objecter que "ça s'apprend", je leur répondrai que j'ai l'exemple vivant, et du reste adorable, du contraire à la maison :)

    De plus, et c'est là que mon opinion diverge de celle de Stéphane, la solution selon moi ne réside pas dans le développement d'une n-ième interface qui masquera les difficultés, d'autant que ces interfaces existent déjà, et l'interface universelle n'est pas pour demain, quoique.
    L'idée sous-jacente à cela me semble être que chacun peut, au sens de "capacité à" et pas de "droit à", être présent en ligne. Et cette présence est vue comme individuelle, tout seul dans son coin.

    L'une des principales raisons du succès des services centralisateurs est simple: l'individu est, par défaut et sans considérations particulières, paresseux. Il va donc aller au plus simple. Selon les points de vue, "là où les autres sont" ou encore "là où l'utilisation est la plus intuitive". Parfois, cela rejoint également "là où c'est le moins cher".

    C'est également cet individualisme qui constitue l'un des gros dangers de l'auto-hébergement. Techniquement, c'est la meilleure solution, car cette diversité renforcera la résilience de l'ensemble, en revanche, je suis moins certain de ses bénéfices sur le plan de la sécurité:
    - Comment expliquer à monsieur "tout le monde" pourquoi il aura besoin de sauvegardes (et comment les restaurer d'ailleurs...) ?
    - Comment expliquer à madame "n'importe qui" qu'elle n'est plus présente en ligne car son disque dur a lâché sans préavis ?

    Vouloir un outil unique qui couvre l'intégralité des problématiques liées à l'hébergement est illusoire. Non, les interfaces de gestion ne résoudront pas tous les problèmes, ni même les systèmes déjà configurés et prêts à l'emploi. Les briques existent, on peut éventuellement améliorer leur intégration, mais on va se heurter à la règle des 80/20: 80% du besoin d'intégration sera réalisé avec 20% des efforts, les 20% restants nécessiteront 80% des efforts. Le jeu en vaut-il la chandelle ? Ces produits résisteront-ils à la pression des mise à jour de plus en plus rapide des applications web ?

    Selon moi, la réelle solution réside dans la mutualisation (qui risque bien de ne pas régler le problème des trolls, bien au contraire ;) ).
    Comprenons-nous bien, je ne parle pas de mutualisation façon Google ou Facebook ou encore Twitter. Je ne parle pas non plus d'hébergement mutualisé au sens classique du terme. Je ne parle pas, enfin, d'hébergement mutualisé au sens moderne du terme (oui, je parle bien du cloud).

    Je parle de mutualisation "à la FDN", en mode associatif.

    Les FAI "DIY" représentent la voie à suivre & à investiguer pour la fourniture du service de présence en ligne. Je ne connais personne qui soit son propre FAI individuel, pour des raisons techniques et financières. Il s'agit à chaque fois ou presque d'une association proposant un service d'accès mutualisé au réseau. Pourquoi n'en serait-il pas de même pour l'hébergement ?

    Évidemment, dans n'importe quelle association, il arrive fréquemment qu'un petit nombre s'investisse au profit d'une majorité. Il n'en serait pas autrement dans le cas de l'auto-hébergement.
    Évidemment, comme dans n'importe quelle association, chacun voudra apporter son troll^W^W sa pierre à l'édifice, sur un mode:

    <Serveur web A> sucks, il faut intégrer <Serveur web B>... Nan c'est un truc de <OS_en_bois>ien, y faut un truc velu avec des poils autour, qui tourne que sous <seul_vrai_OS_serveur_sans_corne_ni_fourche>


    ce qui risque de compliquer un peu la mise en place.

    Mais, magie des associations à taille humaine, le consensus devrait se dégager relativement facilement car les adhérents auraient un objectif commun: gérer eux-même leur présence en ligne et ce, normalement, le plus rapidement possible. Dans le même esprit, chacun apportant ses compétences, on pourrait voir surgir une sorte de troc: "échange administration du blog contre graphisme", ou encore "Offre images de chatons (originales) contre backup & optimisation SQL", etc...

    La solution à la présence en ligne n'est pas individuelle. L'auto-hébergement subsistera bien sûr, mais restera un truc de techniciens pour les techniciens. Pour les autres, le modèle associatif devrait être recherché.
    Il s'agit du seul modèle qui permette une adéquation entre le besoin de contrôle des données et la mutualisation de l'expertise technique nécessaire.

    Accessoirement, cela aurait aussi l'avantage de mettre en contact 2-3 geeks pas trop associaux et des gens normaux. Ça pourrait donner des trucs rigolo pour la défense de la neutralité des réseaux, non ?
  13. # 3032

    Gestion d'agendas et auto-hébergement

     
    En bon adepte de l'auto-hébergement, je gère mon propre serveur web. Parmi les services que l'on souhaite pouvoir auto-héberger, les agendas arrivent en bonne place.

    Ne dérogeant pas à la règle, j'utilisais depuis longtemps "PHP iCalendar". Mes agendas sont disponibles sous Thunderbird, que j'utilise à la fois à la maison et au boulot.
    Tout va bien, tout le monde est content.

    Quelques temps plus tard, je décide de tester un module Roundcube pour bénéficier de l'intégration au webmail (pratique en déplacement). Je migre donc un agenda sous ce module.
    Ça fonctionne "à peu près", puis plus possible de modifier l'agenda autrement que via le webmail (j'ai dû toucher un truc, mais quoi... mystère).

    Malheureusement, n'ayant pas le temps de me pencher sur le sujet, je me contente donc de ce fonctionnement boiteux.

    Pas dramatique, mais néanmoins embêtant, je ne suis pas parvenu à importer les agendas sur mon téléphone Android.
    De plus, "PHP iCalendar" ne semble plus mis à jour et le module Roundcube n'est pas compatible avec les nouvelles versions du webmail.
    Enfin, l'installation du module Roundcube ayant été pour le moins chaotique, je ne me sens pas de recommencer à tâtonner pendant des heures.

    Pour faire court, il était temps de refaire un point sur le sujet.
    Le besoin, histoire de savoir où on met les pieds:

    Impératif
    - Synchro Thunderbird, Gnome (Evolution) & Android
    - Léger (petit serveur)

    Souhaitable
    - Préférence pour PHP, déjà utilisé sur le serveur, évitant ainsi un empilement de technos différentes.
    - Backend MySQL ou SQLite (même raison que le point précédent)

    Un rapide inventaire des solutions existantes (et maintenues) plus tard me donne notamment:
    - OwnCloud: boite à outils, sorte de couteau suisse de l'auto-hébergement.
    - Baïkal: interface HTML basée sur Twitter bootstrap (donc dans l'air du temps)
    - SabreDAV: librairie PHP qui implémente le protocole WebDAV et ses extensions CalDAV et CardDAV

    Détail amusant, les 2 premiers utilisent le 3ème :)
    J'écarte rapidement OwnCloud, trop riche pour mon besoin et les retours d'utilisateurs ne sont pas folichons: mise à jour qui marche (ou pas), régressions, …
    Bref, pas très envie de me lancer.

    Restent SabreDAV et Baïkal, le second étant une surcouche du premier.

    Baïkal sera finalement écarté également, essentiellement pour des raisons pratiques, liées à mon environnement et au manque de temps pour adapter le tout:
    - Il compte plusieurs points d'entrée (un par défaut, un pour calDAV et un pour CardDAV), chacun embarquant les même options de configuration. Autant de modifications à gérer et à ne pas oublier sous peine de comportement "étranges"
    - La structure du code rend délicate la séparation code/ressources. De fait, il est compliqué d'avoir les images et CSS dans l'arborescence web tout en maintenant le code PHP "à l'abri" en dehors de celle-ci.

    Bref, les captures d'écran ont l'air bien sympa, la gestion des utilisateurs et agendas s'effectue via une interface HTML… mais je n'arrive pas à l'intégrer simplement à ma configuration.

    Reste SabreDAV. Le code est livré avec des exemples documentés (si si, ça existe ;) ), le tout était prêt en 10 minutes.
    Quelques tests plus tard (merci flink), le bon fonctionnement de tout ça est validé sous Android avec l'application CalDAV Sync.
    Il me paraissait indispensable de tester le tout, dans la mesure où l'application CalDAV Sync est payante.

    Il existe bien une application libre et gratuite (aCal) mais celle-ci rencontre quelques soucis avec l'authentification HTTP Digest.
    La seule recommandation disponible est de ne pas utiliser l'authentification Digest et de se contenter de l'authentification Basic. Il s'agit certes d'une solution, mais baisser le niveau de sécurité pour pouvoir utiliser une application ne me plaît pas du tout.

    Bref, j'ai donc installé SabreDAV derrière Nginx, PHP-FPM (en chroot) et tout fonctionne bien.
    J'ai également acheté l'application CalDAV Sync et j'ai maintenant accès à mes agendas personnels depuis mon téléphone Android (en lecture/écriture bien entendu).
    Cerise sur le gâteau, ils sont disponibles dans l'application Agendas Google et non pas via une n-ième interface. Extrêmement pratique ;)

    <EDIT>Les détails techniques de l'installation sont disponibles en français et en anglais</EDIT>
  14. # 3031

    Louvois, scandale d'État

     
    Je ne reviendrai pas sur le déroulé de ce scandale, d'autres l'ont fait, et bien mieux que je ne saurais le faire moi-même.
    Néanmoins, le sujet me paraît suffisamment grave et préoccupant pour que j'y ajoute mon grains de sel (pour ceux qui ne me connaissent pas, jetez donc un oeil à mon CV, vous comprendrez sans doute mieux pourquoi je me permets de donner mon avis)

    10% d'erreurs dans l'Armée de Terre
    Cette information vient du ministre lui-même, lors d'une conférence de presse rapportée par le Mamouth.
    10% d'erreurs... Si je conçois que pour un projet de cette ampleur le sans faute ne puisse être atteint, ce pourcentage me laisse pantois.
    10%, ce n'est plus du niveau du bug, c'est juste abyssal. Qu'il y ai des soucis "techniques", des bugs des vrais, est une évidence, mais il me semble qu'à un tel niveau d'erreur le problème est nécessairement plus profond.

    Et la Marine ?
    10% d'erreur dans l'Armée de Terre. Mais, la Marine n'avait-elle pas migré vers Louvois un peu plus tôt ?
    Il aurait dû y avoir, là encore, un grand nombre d'erreurs (au hasard: 10% ?).
    Il semble au contraire que les erreurs soient concentrées au niveau de l'Armée de Terre.

    Pourquoi tout ce temps
    Cela fait des mois que l'on parle, pas à très grande échelle certes, de ce scandale. Et ce n'est que maintenant que le Mr le Ministre sort de son chapeau 30M€ ?
    Et il l'annonce en conférence de presse ? Fort bien... sauf que cet argent est d'ors et déjà dû, donc le côté "fond d'urgence"... comment dire... Accessoirement, rien que le terme "urgence" m'amuse lorsque l'on sait que certains personnels touchent des soldes incomplètes depuis plus de 6 mois.

    On aurait dû garder les 2 systèmes en parallèle
    Cette affirmation me paraît totalement aberrante, pour 2 raisons:
    - garder 2 systèmes impose une double saisie des éléments comptables entrant dans le calcul de la solde.
    - une double saisie impose d'avoir les petites mains pour le faire.

    Il est illusoire de croire que garder 2 systèmes en parallèle peut fonctionner correctement sur le long terme. De plus, à peine l'Armée de Terre avait-elle basculée vers Louvois que la chaîne administrative était visiblement réorganisée.
    Adieu donc les petites mains pour effectuer les opérations de double saisie.
    Adieu donc également la voie "classique" de remontée d'information en cas de dysfonctionnements administratifs.

    Il faut des sanctions
    Oui. Là encore, c'est une évidence.

    Et pourtant, je pense qu'il n'y en aura pas.

    On sacrifiera éventuellement quelques lampistes, officiers subalternes sous contrat pourquoi pas ou sous-officiers, histoire de faire retomber la pression si d'aventure elle ne retombait pas toute seule.
    Mais je suis persuadé qu'aucun chef de projet ou directeur de je ne sais quel bureau de la DGSIC, du ministère ou des États-Major ne sera inquiété.

    Et Pourtant
    À un tel niveau d'erreur, il faut impérativement regarder du côté du pilotage du projet.
    Dans ce type de projet, les arbitrages sont une nécessité, tant pour le client que pour le prestataire.
    Néanmoins, ils doivent être fait après une analyse de risque et , généralement, des indicateurs de suivi de projet permettent, tôt, de détecter "les points durs", doux euphémisme pour désigner les loupés du projet.

    Aurait-on "sacrifié" telle ou telle fonctionnalité, ou bâclé les tests pour tenir les délais, pour la plupart sans doute imposés par le politique ?
    Les règles de gestion ont-elles été correctement étudiées, définies, validées ?
    Le prestataire était-il soumis au versement de pénalité en cas de retard ?
    Un "bug" ne provoque pas 10% d'erreurs sans que cela soit détecté lors de la phase de recette fonctionnelle et de tests.
    Encore faut-il la mener à bien.

    C'est là qu'il faut regarder, la technique suit si le pilotage est bien fait.

    Bien entendu, le projet n'a pas été initié par la majorité actuelle. Pour autant, elle ne saurait se prévaloir de ce fait pour s'exonérer de toute responsabilité.
    Après tout, l'équipe en place a tout fait pour s'y retrouver, il faut bien qu'elle assume. De plus, elle a disposé de 6 mois pour débloquer la situation.
    Au lieu de cela, il a fallu attendre que les épouses de militaires, pour certains en opération en Afghanistan se fassent entendre.

    On a en fait assisté à un naufrage pur et simple de la chaîne de commandement.
    On parle même de militaires ayant été sanctionnés à cause de ce problème. Sanctionnés pour quoi ? Avoir réclamé son dû ? Réclamé sa solde réglementaire ? Mais quelle blague !

    Dans le même registre, les instances de concertations, Conseils de la Fonction Militaire d'Armée et, surtout, Conseil Supérieur de la Fonction Militaire ont totalement échoués.
    En dernier ressort, il leur appartenait de faire remonter l'information. Il est impossible que personne n'ai su, au plus haut niveau, ce qui se passait.
    Une lecture attentive des compte-rendu de session pourrait être particulièrement éclairante tant je ne peux croire, pour en avoir fait partie, que ce "truc" soit passé à la trappe.

    Dans ce scandale, il ne peut pas ne pas y avoir de sanction. C'est humainement inacceptable et surtout cela serait extrêmement mal perçu par ceux qui ont souffert de cette situation.
    Comment partir en mission l'esprit libre après cela ?
    Comment continuer à avoir une confiance aveugle envers sa hiérarchie ?

    Pour finir
    C'est donc ça le respect qu'un militaire obtient de l'État qu'il sert avec abnégation ?
    C'est donc ça la juste rétribution pour fermer sa gueule, pour être disponible au "coup de sifflet" (article L4111-1 du code de la défense, anciennement Status Général des Militaires) ?

    Je ne ferai pas d'explication de texte, mais il me semble que les politiques souhaitant s'intéresser à la Défense seraient bien avisés de lire et de méditer ceci:

    L'état militaire exige en toute circonstance esprit de sacrifice, pouvant aller jusqu'au sacrifice suprême, discipline, disponibilité, loyalisme et neutralité. Les devoirs qu'il comporte et les sujétions qu'il implique méritent le respect des citoyens et la considération de la Nation.


    Un dernier point, sous forme de devoir à la maison: pensez-vous franchement qu'un tel fiasco aurait pu arriver dans un ministère "normal", par exemple à l'Éducation Nationale ?

    Personnellement, j'ai ma réponse.
  15. # 3030

    StatusNet updates

     
    A long time since my last post. No so much to say indeed.

    Anyway, I recently get back into StatusNet code, trying to do some enhancements and fixing some bug, at least those which affect me.

    I have made merge-requests for some of them and wait a little bit for others, time for me to intensively test them.

    If you are interested, you can have a look on my master branch and use it for your own instance.

    Here is the summary of changes to my repository compared to current statusnet mainline master.

    Enjoy :)

    897fe9e Replace t.co links with expanded one provided by Twitter. Can still be a shortened one & will be done only for HTML view, but still a start. Backport of merge_requests/205.
    5f374a0 Fix common_shorten_url which redefine 'user' even if given as argument. Makes API calls fails when shorten is needed.
    f6e546f Fix introduced bug, trying to shorten an empty status.
    1d83b11 Add queue support for Twiiter status fetcher daemon. QueueManager is called only when needed (ie timeline not empty). Commit 3 of 3 to make TwitterBridge use queueing system.
    601a247 Fix bad Foreign_link call preventing inbox notice insert because profile was never found. Commit 2 of 3 to make TwitterBridge use queueing system.
    1e792b3 Add support for TweetInQueueHandler in TwitterBridge. Commit 1 of 3 to make TwitterBridge use queueing system.
    3024629 Code cleaning and refactoring. Same function is now able to handle both home_timeline & mentions.
    11a3743 Remove trailing slashes to simplify robotstxt usage.
    f8fb3c5 You need an API key when using embed.ly. Unfortunatly oembedhelper.php does not support it. This commit aims to fix it.
    94bb59b Add configuration check. Need 'server', 'port', 'user' and 'password' to be defined (not valid, just defined).
    b1d7c81 Remove static definition of imdaemon.php as valid daemon.
    fb0bc55 Add basic support for GetValidDaemon event. Shall be extended with configuration check.
    b34cd28 Fix INSTALLDIR constant definition.
    5fb3bdc Makes autocomplete plugin look in all profiles instead of only local users. Ref: stream.macno.org/notice/36812
    3d04ab3 Code cleaning. Do call shortenLinks only once, right before saving new notice.
    908ec40 Code cleaning, remove 'TEST' tags.
    92a0282 Notice update with media attachment may fail through API when status text + attachment length get higher than max notice length. Calling URL shortener can make global length less than maxlength, though allowing notice
    5940769 Code cleaning, remove 'TEST' tags.
    f5645db Fix URL shortener call for mediafile class. Now use user's preference instead of default function.
    f15c507 Fix for #3651: oAuth apps list does only show the latest registered application
    c5b7e8a Add mentions timeline support for TwitterBridge.
    be5e6f1 Fix for #3649 issue.
    fcb1b11 MIME type for jpeg is with an e
    bd81785 adding the odd but reported Twitter avatar .jpeg file extension
    b2a9194 retaining compatibility with previous TwitterBridge getMediatype
    4c853f8 Fixes issue #3612 with Twitter avatars that lack extension
    a6f94e0 Fix for #3463. Make InfiniteScroll plugin use config['plugins']['server'] if defined to build ajax-loader.gif URL
    7e8b2c3 Fix missing variable in InfiniteScrollPlugin class. Fix issue #3525
    9b22835 Makes ClientSideShorten loading shorten.js from config['plugins']['server'] if setted. Fix #3528