[Raw Nerve 3] S’examiner objectivement

En janvier 2014, je publiais la traduction de l’article « Lean into the pain » d’Aaron Swartz sous le titre « Plongez dans la douleur« , quatrième article d’une série intitulée Raw Nerve. Deux années plus tard, voici la traduction du troisième article « Look at yourself objectively ». Le style y étant particulier, l’exercice n’est pas des plus aisés. J’espère néanmoins avoir réussi à conserver la pensée de l’auteur dans ce texte que je vous laisse découvrir.

S’examiner objectivement

Cet article est la 3e partie de la série Pensée Sensible.

Dans les années 1840, les hôpitaux étaient des endroits dangereux. Les mères qui y entraient pour y donner naissance ne s’en sortaient souvent pas. Par exemple, au premier service d’obstétrique de l’Hôpital Général de Vienne, 10% des mères mourraient de fièvre puerpérale après avoir donné naissance. Mais, bonne nouvelle: dans la seconde clinique, ce nombre n’était que de 4 %. Les futures mères remarquèrent cela – certaines se seraient mises à genoux et auraient supplié pour être admise dans la seconde clinique. D’autres, en entendant que les nouveaux patients allaient être admis dans la première clinique ce jour-là, préféraient donner la vie dans la rue.

Ignaz Semmelweis, assistant à la première clinique, ne pouvait le supporter. Il commença à chercher désespérément une quelconque explication de cette différence. Il essaya plusieurs choses sans succès. Puis en 1847, un ami de Semmelweis, Jakob Kolletschka était en train de réaliser une autopsie, quand un étudiant le coupa accidentellement avec un scalpel. C’était une blessure bénigne, mais Kolletschka fut terriblement malade et mourut, avec des symptômes similaires à ceux des mères. Cela amena Semmelweis à s’interroger: des « substances mortelles » sur les corps sont-elles responsables de ces morts?

Pour tester cela, il insista pour que les docteurs commencent à se laver les mains avec du chlorure de chaux (qui enlevait le mieux l’odeur de la mort), avant de s’occuper des femmes enceintes. Les résultats furent bouleversants. En avril 1847, le taux de mortalité était de 18,3 %. Semmelweis institua le lavage des mains à la mi-mai et dès juin, le taux de mortalité s’était écroulé à 2,2 %. Le mois suivant, il était encore inférieur et plus tard dans l’année, celui-ci atteignit zéro – pour la toute première fois.

Vous devez penser que les docteurs auraient été emballés par cette incroyable découverte. À la place, Semmelweis fut attaqué et ridiculisé. Il fut renvoyé de l’hôpital et expulsé de Vienne. « Dans les publications de travaux médicaux, mes enseignements sont soit ignorés, soit attaqués », se plaignait-il. « La faculté médicale de Würzburg récompensa d’un prix une monographie écrite en 1859 dans lequel mes enseignements étaient rejetés ». Même dans sa Vienne natale, des centaines de mères continuaient de mourir chaque année.

Semmelweis se tourna vers l’alcool et son comportement devint de plus en plus changeant. En 1865, il fut interné dans un asile psychiatrique. Là-bas, il fut brutalisé par les gardes, placé en camisole (de force), et enfermé dans une cellule sombre. Il mourut peu après, à l’âge de 47 ans, d’une blessure infectée.[1]

Pourquoi les médecins rejetèrent-ils Ignaz Semmelweis si obstinément ? Eh bien, imaginez qu’on vous explique que vous êtes responsable de la mort de centaines de vos patients. Que vous avez tué les gens que vous étiez sensés protéger. Que vous étiez tellement mauvais dans votre travail, que vous faisiez moins bien que juste donner la vie dans la rue.

Nous savons tous que les gens n’aiment pas entendre de critiques sur eux-mêmes. En effet, nous faisons tout pour l’éviter – et quand nous nous y confrontons, nous tentons de minimiser cela ou de nous justifier. Des psychologues en science cognitive l’ont prouvé dans une douzaine d’expériences: forcez des étudiants à suivre un cours avec une initiation embarrassante, et ils insisteront pour dire que le cours est bien plus intéressant. Faites leur faire une faveur à quelqu’un qu’ils haïssent, et ils commenceront à insister pour dire qu’il l’apprécie. Faites leur faire une petite entorse à l’éthique et ils seront prêts à en faire de plus en plus grande. Au lieu d’accepter que nous avons fait une erreur, et que nous n’aurions pas dû faire d’entorse ou faire une faveur, ou suivre le cours, nous commençons par nous dire que la compromission n’est pas si terrible – et quand la prochaine arrive, nous croyons aux mensonges que nous nous sommes dit, et bondissons vers une nouvelle erreur. Nous haïssons entendre des mauvaises choses à notre propos, donc nous préférons changer notre comportement plutôt que d’admettre simplement que nous avons foiré.[2]

Cela n’aide pas quand nos amis pointent ce que nous avons mal fait. Si nous avons tant peur de nous entendre dire que nous avons fait une erreur, imaginez comme nous haïssons l’entendre venant de quelqu’un d’autre. Et nos amis le savent: la réponse à « Est-ce que cette tenue me boudine? » n’est pas supposé être « oui ». Nous pouvons blaguer à propos de ce que disent nos amis dans notre dos, mais nous le leur disons rarement en face. Même au travail, beaucoup d’effort sont fait pour être sûr que les employés sont isolés des jugements les plus négatifs de leurs supérieurs. Voici ce qu’on nous apprend : faire cinq compliments pour chaque critique, entourer les retours négatifs de retours positifs, la chose la plus importante étant de garder intact l’estime de soi de la personne.

Mais, comme l’a montré Semmelweis, ceci est une habitude dangereuse. Bien sûr, c’est horrible d’entendre que vous êtes en train de tuer des gens – mais c’est bien pire de continuer dans cette voie ! Ce ne doit pas être drôle d’apprendre que vous êtes paresseux, mais c’est mieux de l’apprendre maintenant que de le découvrir une fois viré. Si vous voulez travailler à devenir meilleur, vous devez commencer par savoir où vous en êtes.

Semmelweis fut défait autant qu’un homme peut l’être. Mais rien de ce que les autres docteurs pouvaient lui faire n’aurait changé les faits. Finalement, les scientifiques prouvèrent la théorie de contamination par les germes et Semmelweis fut disculpé. Aujourd’hui, c’est un héros international: universités et hôpitaux portent son nom, sa maison a été transformé en musée, l’Autriche a même mis sa tête sur une pièce en or de 50 €. Pendant ce temps-là, les docteurs qui s’étaient opposés à lui sont maintenant vu comme des meurtriers bornés.

Continuer la lecture de « [Raw Nerve 3] S’examiner objectivement »

[NAS 1/x] NAS, c’est parti !

La gestion des données numériques peut vite devenir un véritable casse-tête. Dans mon cas, cela se traduit souvent par l’accumulation de plusieurs versions d’un même fichier sur plusieurs supports, parfois par mégarde, parfois pour prévenir la perte de la donnée. Ajouter à cela plusieurs disques externes, d’âges différentes, nécessitant une alimentation externe ou pas et il devient facile de s’y perdre, de ne plus savoir où se situe quelle donnée.

Dans un premier temps, j’ai donc commencé par réaliser un inventaire rapide de mes disques, en triant par type de données, afin d’avoir une idée de la volumétrie. Pas d’outils particuliers à part un bon explorateur de fichiers pour cette étape. Les résultats sont ceux que je pressentais, beaucoup de fichiers vidéo, de nombreux fichiers audio, puis d’autres fichiers comme des photos; en nombre important, mais en plus faible volumétrie.

Après cette étape d’inventaire, c’est posé la question de la pertinence des données. Est-il judicieux de conserver ce film récupéré sur le disque dur d’un ami, en 480 pixels et au son horrible ? De garder cette vidéo d’un court métrage des années 2000 trouvé sur Youtube ? Bref, introduire une étape de nettoyage en même temps que l’inventaire, et en profiter pour supprimer les doublons n’ayant pas lieux d’être. On peut ensuite s’intéresser à la hiérarchisation de la donnée.

Sur l’ensemble de mes données numériques, certaines vont avoir une valeur plus importante que d’autres. C’est le cas notamment des photos numériques prises à divers occasions au fil des ans, des fichiers audio correspondant à l’ensemble de la bibliothèque musicale CD de mes proches, fruit d’un travail de longue haleine passé à extraire chaque disque et à l’ajouter dans la base MusicBrainz lorsque celui-ci n’existait pas. Tout ça pour dire que la perte de certains fichiers est acceptable, tandis que d’autres fichiers se doivent d’être protégé des éventuels problèmes du support.

Toutes ces réflexions m’ont donc conduit à m’intéresser au serveur de données personnelles ou NAS. L’avantage premier étant de pouvoir bénéficier d’une redondance simple des données en utilisant du RAID. J’ai eu à cette occasion la chance de tomber par hasard sur l’article Un NAS 4 baies de qualité et évolutif pour 250€ de L’Atelier du Geek. Pour moi, l’attrait principale de cette machine, outre son prix attractif par rapport au marché des NAS, réside dans la présence de 4 baies de disque dur, ainsi que dans la possibilité d’y installer le système d’exploitation de son choix. De plus, l’article permet de savoir à quoi s’attendre.

C’est donc en toute logique, que je me suis tourné vers un HP Proliant MicroServer Gen8.

WordPress, xmlrpc et déni de service

Certains d’entre vous l’ont peut-être constaté, il était plutôt compliqué d’accéder à unicoda.com durant les dernières 48h. En effet, il se trouve que le site a été la cible d’une attaque de type brute force qui l’a mis à mal. Résultat, un processus apache qui décolle et accapare toutes les ressources de la machine jusqu’au déni de service. Retour sur la folle vie d’un serveur attaqué.

Tout commence le 25 août 2016 aux alentours de 19h, la première requête de la série apparaît à 18 heures 46 minutes et 25 secondes pour être précis.

191.96.249.54 - - [25/Aug/2016:18:46:25 +0200] "POST /xmlrpc.php HTTP/1.0" 200 579 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
191.96.249.54 - - [25/Aug/2016:18:46:25 +0200] "POST /xmlrpc.php HTTP/1.0" 200 579 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
191.96.249.54 - - [25/Aug/2016:18:46:25 +0200] "POST /xmlrpc.php HTTP/1.0" 200 579 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

À cette heure-là, pas de problème, le serveur fonctionne correctement. La première alerte sera levée par le système de monitoring d’OVH à 22h54 ce même jour. Le serveur a déclaré forfait et ne répond plus au ping. Quelques minutes plus tard, le support intervient et redémarre le serveur. Une nouvelle alerte sera levée vers 4h du matin, avec intervention du support. En découvrant les mails le matin, je ne flaire pas immédiatement l’attaque. Le support est intervenu, il n’y a pas de précision indiquant si le problème vient du logiciel ou du matériel côté hébergeur, le site ne s’affichant pas, j’effectue à mon tour un redémarrage du serveur et m’assure que les différents services sont bien repartis. Tout semble fonctionner… Pourtant, même scénario dans la nuit de vendredi à samedi avec deux interventions du support. Quelque chose cloche, je continue de vaquer à mes occupations lorsque le serveur devient une nouvelle fois inaccessible samedi vers midi. Pas doute il y a un problème, je vais devoir effectuer des vérifications dès que possible.

Continuer la lecture de « WordPress, xmlrpc et déni de service »

dd ? Et pourquoi pas, dcfldd ?

Si vous avez un peu joué avec le Raspberry Pi, vous êtes certainement familier avec la commande dd, en particulier si vous avez installé l’OS sur carte SD depuis GNU/Linux. Peut-être avez-vous même effleuré sa consœur, j’ai nommé: dcfldd.

J’ai découvert cette version du programme dd lors de ma dernière installation de Raspbian. Bien que celle-ci soit un peu ancienne et peu mise à jour, nous pouvons tout de même parler de version améliorée du programme d’origine. L’outil est développé par le « laboratoire des investigations informatiques » américain (Defense Computer Forensics Lab), aussi abrévié DCFL, d’où le nom de l’outil: dcfldd.

Du côté des fonctionnalités, on notera la possibilité d’effacer un disque en utilisant des motifs connus, ou encore celle de vérifier qu’une image est identique à l’originale bit à bit. dcfldd propose également un suivi de la quantité de donnée traitée au fur et à mesure de son avancement.

La dernière version stable date du 19 décembre 2006. Les dernières modifications sont à peine plus récentes et datent quant à elle du 4 décembre 2007. En comparaison, les dernières modifications du programme original ont eu lieu en janvier 2016, dcfldd ne dispose donc pas de toutes les améliorations qui ont pu être apportées à dd depuis 2008. Une mise à jour du code serait donc appréciable, mais l’opération ne serait pas forcément aisée.

Ces derniers temps, j’ai principalement utilisé dcfldd plutôt que dd afin de profiter de l’information d’avancement du travail en cours donnée par défaut par la commande. Néanmoins, à l’avenir, dd devrait faire l’affaire, puisqu’il existe une option status=progress permettant de suivre l’avancement de l’opération. Le comportement par défaut de dd étant de ne rien afficher avant que la tâche soit terminée. Ce sera donc un retour probable à dd pour les prochaines opérations.

Voir aussi : http://forensicswiki.org/wiki/Dcfldd

Rafraichir la page parente à la fermeture de la page fille

Derrière ce titre alambiqué se cache un besoin particulier que j’ai cherché (et réussi) à résoudre dernièrement. La situation est la suivante : un utilisateur arrive sur une page, celle-ci effectue un appel ajax afin de connaître l’état d’un paramètre utilisateur. Pour illustrer, nous dirons donc que la page interroge une api pour répondre à la question : l’utilisateur a-t-il une image de profil enregistrée ?

Si l’utilisateur possède une image enregistrée, on la lui affiche ainsi qu’un message pour lui permettre de la supprimer. Si aucune image n’est présente, l’utilisateur peut choisir d’en ajouter une. L’acquisition de l’image s’effectue dans une page dédiée, que nous appellerons la page fille. Cette acquisition est réalisée à l’aide de la bibliothèque Cropper.js.

Une fois l’image acquise, l’utilisateur valide la sélection via un bouton. Au niveau de la page fille, un appel est donc réalisé vers une api pour sauvegarder l’image. Si l’appel est une réussite, nous fermons la page fille. À ce stade, l’utilisateur se retrouve sur la page parente qui lui propose toujours d’ajouter une image, ce qu’il vient de faire, nous allons donc recharger la page parente à la fermeture de la page fille.

J’illustre ce processus dans le code HTML en fin de page. Lorsque la page parente est chargée, celle-ci affiche en alert(), le message « Page chargée ! » afin de matérialiser le rechargement de la page. En cliquant sur le lien, une nouvelle page s’ouvre. Lorsqu’on clique sur le bouton de cette page, on va déclencher la fermeture de la page courante (la page fille) et le rechargement de la page parente. De plus, afin de matérialiser l’action de la page fille dans la page parente, de rendre l’exemple plus intéressant et de matérialiser ce qui correspondrait dans mon cas pratique à la mise à jour de l’information par le premier appel ajax (celui sur la page parente), le texte saisi dans le formulaire sur la page fille est transféré à la page parente et affiché par un alert().

Par ailleurs, le test du booléen pageFille.fermeture dans la fonction de l’événement unload de la page fille permet de s’assurer que la page parente ne sera rechargée que si le traitement est réussi sur la page fille où window.fermeture vaudra alors true. En effet, si on enlève le test du booléen, on constate qu’un événement unload a lieux dès l’ouverture de la page fille, ce qui aurait donc pour effet de recharger immédiatement la page parente. Le test du booléen permet de palier à ce « problème ».

Page Parente (pageParente.html)

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
  </head>
  <body>
    <p>
      <a href="javascript:ouvrirPageFille();">cliquez ici</a>
    </p>

    <script>
      function ouvrirPageFille() {
        var pageFille = window.open('pageFille.html', 'Titre', 'top=42,left=42,height=800,width=600,scrollbars=yes,status=no,toolbar=yes');
        //Recharge la page parente à la fermeture de la page fille 
        pageFille.onunload = function() {
          if(pageFille.fermeture) {
            alert(pageFille.message);
            //Rechargement
            location.reload();
          }
        }
      }

      window.onload = alert('Page chargée !');
    </script>
  </body>
</html>

Page Fille (pageFille.html)

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
  </head>
  <body>
    <form>
      <label for="message">Message :</label>
      <input id="message" type="text" name="message">
      <input type="submit" value="Valider et quitter" onclick="quitterPage();">
    </form>

    <script>
      function quitterPage() {
        window.message = document.getElementById('message').value;
        window.fermeture = true;
        window.close();
      }
    </script>
  </body>
</html>

Voilà pour l’exemple. Il reste maintenant quelques limitations à préciser pour finir cet article. Si l’utilisateur ferme la fenêtre du navigateur via le bouton prévu à cet effet (la croix rouge généralement en haut à droite), la page parente n’est pas rechargée. Dans mon cas pratique, cela fait sens car l’utilisateur n’aura alors pas soumit d’image; il n’y a donc aucun raison de rafraîchir la page. Autre point, si l’utilisateur rafraîchit la page fille, cela a pour effet de casser la liaison existante entre les deux pages et le rechargement de la page parente n’aura pas lieux.

Voici donc une manière de rafraîchir une page parente à la fermeture de sa page fille en restant dans les fonctionnalités de base du navigateur et des langages. D’autres façons de faire sont très certainement possibles (avec des événements) et certains framework js seraient à même de simplifier le problème, en permettant de ne mettre à jour dynamiquement qu’une partie de l’interface.