[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.

Unity3D : gestion des bords de l’écran

Définition du problème

J’ai passé quelques temps à comprendre comment gérer la détection des bords de l’écran pour ne pas que mon gameobject en sorte.

Dans mon cas le gameobject dirigé par le joueur est un cube auquel on ajoute un BoxCollider, la caméra est fixe.

Dans Unity on gère la position d’un objet par son attribut position (un Vector3 donnant le positionnement du centre de l’objet).

Malheureusement pour moi le composant camera de Unity permet seulement de trouver la taille en pixels de l’écran (maCamera.pixelHeight et maCamera.pixelWidth) et donc je me suis mis à chercher un moyen de déterminer en pixel l’endroit où se trouve mon cube afin de savoir si celui-ci est en dehors ou en dedans de l’écran. En gros si mon cube est entièrement visible ou non !

De l’intérêt d’utiliser un BoxCollider

Pour déterminer le centre de mon cube ainsi que sa taille j’utilise les valeurs récupérables dans l’attribut bounds du composant :

//dans start()
joueurX = this.GetComponent<Collider>().bounds.size.x/2;
joueurY = this.GetComponent<Collider>().bounds.size.y/2;

//dans update()  centreJoueurX = this.GetComponent<Collider> ().bounds.center.x; centreJoueurY = this.GetComponent<Collider> ().bounds.center.y; 

Aux tests à effectuer

if (maCamera.WorldToScreenPoint(new Vector3(0,(centreJoueurY+joueurY),0)).y > pixelHeight) {
//on stop le déplacement
directionJoueur = 0;
this.gameObject.transform.localPosition += (-mouvementY * speed * Time.deltaTime);
} 
else if (maCamera.WorldToScreenPoint(new Vector3(0,(centreJoueurY-joueurY),0)).y  < 0) {
directionJoueur = 0;            this.gameObject.transform.localPosition += (mouvementY * speed * Time.deltaTime);
} 
else if (maCamera.WorldToScreenPoint(new Vector3((centreJoueurX+joueurX),0,0)).x > pixelWidth) {
directionJoueur = 0;             this.gameObject.transform.localPosition += (-mouvementX * speed * Time.deltaTime);
}
else if (maCamera.WorldToScreenPoint(new Vector3((centreJoueurX-joueurX),0,0)).x < 0) {
directionJoueur = 0;                                           this.gameObject.transform.localPosition += (mouvementX * speed  * Time.deltaTime);
}


Voilà pour le système utilisé actuellement, on peut bien entendu imaginer un système pour ne pas refaire les tests à chaque update() mais uniquement au moment voulu.

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