(gdb) break *0x972

Debugging, GNU± Linux and WebHosting and ... and ...

What I Like with *nix OSes, II : Free and Open Source Software

Wednesday, March 04, 2015 - No comments

In my previous post on what I like with *nix OSes, programmability and composability, I didn't mention one point that is globally orthogonal, but still participates to programmability aspect: the is a very large set of Free, Libre and Open Source Software (FLOSS). I don't contribute much to these projects (I'd like to but I lack time, I already spend too much time working on my own projects), but in "exchange", I do my best to show (to myself mainly) that the FLOSS ecosystem is mature enough to use it daily. I won't say I use it exclusively, but anytime I can choose, I favor FLOSS software and FLOSS-friendly hardware.

Why would I crack (or pay for) an application when someone happily made it for free? Nowadays, after quite a longtime in this mindset, I'm honestly surprised and astonished when I hear someone saying, "I use a cracked version; I can find you a crack for that tool". In my computing world this doesn't make sense anymore!

At the end of my PhD thesis redaction, I tried to enumerate the FLOSS tools I used my research work, and during the redaction of the manuscript:

Let me also give a practical example of why I FLOSS tools:

Simple/single SSH-based Sign-on

One month ago, I read this article on Hacker News: Signing in to websites with SSH. Although what they discuss is too advanced for my needs, I loved the idea, and I wanted it in some the tools I use.

Step 1: ssh connection

cat >> ~/.bashrc << EOF
ssh_connect_me () {
    ssh 0x972.info /home/kevin/.ssh_log_me
}
EOF

Step 2: remember ssh connection

cat > ~/.ssh_log_me << EOF
#!/bin/bash

WHERE=/var/www/alternc/k/kevin/.ssh_autologin
echo $SSH_CONNECTION | cut -d" " -f1 > $WHERE
echo 'Logged in !' $(cat $WHERE)
EOF
chmod u+x ~/.ssh_log_me

Step 3: adapt tools for autologin

Blogotext:

// autologin for SSH authenticated ips
$AUTOLOGIN_FILE = "/var/www/alternc/k/kevin/.ssh_autologin";
$autologin = FALSE;
if (file_exists($AUTOLOGIN_FILE)
    //&& (time() - filemtime($AUTOLOGIN_FILE)) < 60*60*12 // file is newer than 12h
    && $_SERVER["REMOTE_ADDR"] == str_replace("\n", "", file_get_contents($AUTOLOGIN_FILE))) {
    $autologin = TRUE;
    touch($AUTOLOGIN_FILE);
    $_POST['nom_utilisateur'] = $GLOBALS['identifiant'];
    $_POST['mot_de_passe'] = $GLOBALS['mdp'];
}

Selfoss:

// autologin for SSH authenticated ips
$AUTOLOGIN_FILE = "/var/www/alternc/k/kevin/.ssh_autologin";
if (file_exists($AUTOLOGIN_FILE)
   // && (time() - filemtime($AUTOLOGIN_FILE)) < 60*60*12 // file is newer than 12h
   && $_SERVER["REMOTE_ADDR"] == str_replace("\n", "", file_get_contents($AUTOLOGIN_FILE)))
{
    touch($AUTOLOGIN_FILE);
    $this->loggedin = true;
}

That's nothing complicated, but quite convenient for me! Each time my IP changes, I run ssh_connect_me, and I'm logged in immediately. I'm not sure how secure it is, I'm got daily backups for both databases and nothing confidential accessible to them, so I guess this is safe enough. I initially put a time limit, but I don't see any real interest after all.

Gérard Berry : « L’ordinateur est complètement con » [Entretien Rue89]

Monday, February 02, 2015 - No comments

Extrait de l'entretien de Rue89 avec Gérad Berry du CNRS, une partie sur les bugs:

Gérard Berry est un des plus grands informaticiens français. Ancien élève de Polytechnique, il est professeur au Collège de France, membre de l’Académie des sciences et de l’Académie des technologies.

Et vous avez beaucoup travaillé sur le bug. Une question bête : comment est-il encore possible qu’il y ait des bugs ?

La question serait plutôt : comment est-il possible qu’il n’y en ait pas ?

Au départ, on a toujours la même opposition : l’homme qui va penser le programme, l’écrire et le tester. Et l’ordinateur qui va l’exécuter. L’homme est incomplet, incapable d’examiner les conséquences de ce qu’il fait. L’ordinateur, au contraire, va implémenter toutes les conséquences de ce qui est écrit. Si jamais, dans la chaîne de conséquences, il y a quelque chose qui ne devrait pas y être, l’homme ne s’en rendra pas compte, et l’ordinateur va foncer dedans. C’est ça le bug.

Un homme n’est pas capable de tirer les conséquences de ses actes à l’échelle de milliards d’instructions. Or c’est ça que va faire le programme, il va exécuter des milliards d’instructions.

Mais il existe des méthodes mathématiques, et informatisées, qui permettent de faire des calculs dont le principe est proche de celui de raisonnements humains, avec en plus les caractéristiques de l’informatique, c’est-à-dire sans aucun humour, sans aucune fatigue, et sans aucune erreur.

Zététique et debugging: le rasoir d'Occam

Monday, December 01, 2014 - No comments

Aujourd'hui, je fais le lien entre le cours de zététique que j'ai suivi il y a 3 ans (cours de culture générale pour le doctorat), et mon travail de recherche: le rasoir d'Occam :

Ça dit en substance : Pluralitas non est ponenda sine necessitate. Et en compréhensible : Pourquoi faire compliqué quand on peut faire simple ? En gros, ce que dit ce rasoir, c’est que lorsqu’il y a plusieurs hypothèses en compétition, il vaut mieux prendre les moins « coûteuses » cognitivement.

Ou avec une exemple :

Ce coupe-chou peut s’avérer aussi utile pour l’analyse des théories dites du complot. Il n’est pas impossible que le 11 septembre soit le fruit d’une orchestration planifiée par les services secrets, moyennant une grande discrétion des complices, tout un tas de précautions et l’effacement de toutes les preuves, ceci afin de déclarer le combat contre l’Axe du Mal et déclencher la deuxième guerre du golfe. C’est un scénario séduisant, surtout quand on est anti-Bush. Mais un peu de culture historique rend assez coûteuse cette hypothèse.

Appliqué au debugging, on peut aussi trouver des hypothèses « coûteuses » à oublier, comme les bugs du compilateur, de l'OS ou du processeur (ou du débogueur :-).

Et ce que ça donne quand on utilise pas le rasoir: :-)

Kaamelott (Saison 4 Episode 6 – Les pisteurs) © CALT / DIES IRAE / SHORTCOM – 2006

L'informatique et les standards et les formats ouverts

Monday, November 24, 2014 - No comments

Ce weekend j'ai signé l'Appel pour l'interopérabilité dans l'Éducation nationale, et avant de faire suivre le lien je voulais revenir sur les raisons pour lesquelles cela me semble important.

Déjà, c'est quoi un format ouvert, et un standard ?

c'est un protocole d'échanger ou de communiquer. In real life (IRL), on peut comparer ça à ...

  • les clés à pans et les têtes de vis qui vont avec,
    • la taille et l'angle des pans est clairement spécifié, à travers le monde ça sera tout le temps les mêmes
  • les culots des ampoules
  • la langue utilisée pour discuter
    • si on ne parle pas la même langue, on ne se comprend pas

En informatique, c'est un peu pareil. Quand vous allez sur une page web, votre ordinateur ne connait pas le serveur web, mais s'ils parlent la même langue, ils vont pouvoir se parler et récupérer la page web. Pareil pour ouvrir un document, tant que la clé correspond à la tête de vis, on s'en sort.

Pourquoi il faut que cela soit "ouvert" ?

"Ouvert", ici, ça veut dire que les spécifications (taille et angle des pans) sont publiques et utilisables/consultables librement, sans avoir a payer des millions. Imaginez une route, faîtes par l’État, sur laquelle seulement des voitures Chevrolet (™) puissent rouler, parce que tout le monde utilise ces voitures. Ou bien Renault ou Peugeot c'est pareil, mais on pourrait penser que c'est par préférence nationale. Non, Chevrolet fait des roues carrés, donc l’État fait des routes arrondies (comme ça le carré peut tourner librement).

C'est pas possible que l'État fasse ça ? IRL, non ... en informatique, si !

Microsoft fait des roues carrés (Word et .doc-x, Excel et .xsl-x), et il ne veut pas faire de roues rondes (les format de OpenDocument .odt .odc, utilisées par LibreOffice par exemple). Quand l’Éducation Nationale signe des accords avec MS, ils acceptent et promeuve leur situation de monopole, on garde les roues carrés et les routes arrondies ! On donne des millions de dollar à MS, qui en échange nous donne Windows à prix réduit. Qu'est-ce qu'on peut trouver comme comparaison cette fois ... un nouveau système de visserie :

Voilà donc quelques éléments sur pourquoi il faut signer Appel pour l'interopérabilité dans l'Éducation nationale, pour éviter les roues carrés ! Ou au moins pour aider l'informatique à se détacher de la main mise des monopoles/multinationales, qui empêchent le développement des alternatives (libres ou non) en forçant l'utilisation de format non libres.

(parce que bien sur, MS Word pourrait supporter les format OpenDocument, mais ils ne veulent pas, par choix politiques. Depuis quand ils supportent l'export en PDF, sans passer par une imprimante PDF et tout ? ... je ne sais pas en fait, ils le supportent ? ^^)


Plus généralement en informatique, l'ouverture des formats et des protocoles de communication est primordiale, c'est grâce à cela qu'Internet est arrivée à son stade actuel. Par exemple pour afficher cette page, on a eu besoin des standards ...

  • web (HTML et CSS)
  • réseau (HTTP, TCP, IP, Ethernet, ...)
  • bases de donnes (SQL)

Tous ces différents protocoles permettent à Internet de fonctionner. Par contre, quand on enferme ses données chez une seule compagnie, il n'y a plus de besoin de communication ni d’interopérabilité. Les messages Facebook, Tweeter ou Whasapp ne passent pas par Internet, ils restent "chez Facebook", et à plus ou moins long terme, ça cloisonne chacun chez soi, de la même façon que Microsoft et ses roues carrés. Combien de fois on entend à la radio/TV "venez discuter sur notre compte Twitter, #-tag ..... ou sur notre page Facebook ..." ? alors que Twitter est loin d’être adaptée pour des commentaires avec sa limite ~128 caractères, mais non, son interface est fermée, aucune interopérabilité, donc on doit utiliser Twitter pour profiter du réseau ...

Adblock et la Publicité ...

Thursday, October 23, 2014 - No comments

Que ce soit en ville (Arnaud Gaillard / wikimedia),


  • à la TV
  • une page sur deux dans les journaux
  • à la radio, genre **ça** (la pub Matmut avec Chevalier/Laspales), et c'est l'exemple le plus representatif qu'on puisse trouver simplement ...

la pub est chiante ! Et c'est pas une critique, c'est un constat. Il faut qu'on la garde en tète, qu'on pense à eux, c'est tout. Et tous les arguments sont bons pour ça, couleurs flashs, musique simple répétitive, augmentation du volume sonore. C'est assez irrespectueux, ça utilise des faiblesses pour faire passer de mauvais arguments.... enfin vous connaissez tous, ce n'est pas de ça dont je veux discuter.

Là où je veux en venir, c'est que dans ces média, la pub est imposée. On a beau baisser le son de la radio, ou prendre un casse-croûte pendant la pub TV, on ne peut pas y faire grand chose.
Sur Internet c'est différent. Sur un ordi, on peut tout contrôler, à condition d'avoir un peu de connaissances, des logiciels libres (j'en reparlerai), et de la bonne volonté (parce qu'il faut prendre le temps de s'habituer aux logiciels libres).

En l’occurrence, Firefox et AdBlock (entre autres). AdBlock va simplement dire a Firefox de ne pas charger les images qui proviennent de certains sites. C'est pas plus compliqué que ça ! Après toute l’efficacité dépend de la liste des sites qu'on va bloquer, mais c'est un autre problème.


Quand je vois des sites qui expliquent que les bloqueurs de pub cassent leur source de revenu, je repense a toutes les pubs qui nous sont matraquées sans qu'on puisse y faire quoi que ce soit, et je remercie l'informatique de nous donner des moyens de les bloquer !



Il y a quand même quelques exceptions, comme les pubs au cinéma, qui sont assez souvent des mini-films avec de beaux paysages, ou celles de Nespresso, ou sur Internet, des pubs non-intrusives qui sont autorisées par défaut (je crois) dans AdBlock, comme sur Reddit ou Google. On finit donc bien par trouver un terrain d'entente, quand on a les moyens de se faire entendre (l'argent du cinéma / les bloqueurs de pubs).

C'est quoi le debugging, en fait ?

Friday, October 17, 2014 - No comments



Une thèse sur le debugging de machin truc, c'est bien, mais si on ne sait pas ce que c'est du debugging, ça n'avance pas beaucoup. Pourtant ce n'est pas uniquement de l'informatique ... Un exemple :

J'ouvre le frigo et la lumière ne s'allume pas. C'est un bug !
Il faut maintenant résoudre ce problème. Quelles peuvent-être les causes ?

  • 1) l'ampoule est grillée
  • 2) l'interrupteur de la porte de s'active pas
  • 3) le frigo n'est pas branché
  • 4) il n'y a pas d'électricité dans la maison
  • -1) une brique de lait cache l'ampoule
  • 0) il y a trop de lumière dans la maison pour distinguer la lumière du frigo

les causes -1 et 0, c'est l'utilisateur qui s'y prend mal, on y peut rien ==> PEBCAK : Problem exists between chair and keyboard, en français problème avec l'interface chaise-clavier :-)

  • pour 1) ce n'est pas facile à tester, suivant !
  • pour 2) on appuie manuellement sur l’interrupteur, est-ce que ça marche ?
  • pour 3) on regarde si la prise est branchée
  • pour 4) on allume une lumière dans la maison

Ça devrait être suffisant pour cerner le problème.
1/ et 2/ ce sont des problèmes mineurs, non prioritaires.
3/ et 4/ sont plus critiques. Est-ce que c'est grave ?

* 5/ est-ce que le frigo/congel sont toujours froid ?

C'est l'application de la méthode scientifique ! On fait des hypothèses qui pourraient expliquer notre observation, des expérimentations pour les tester, et on tire des conclusions de ces résultats.

Le problème du frigo, c'était cet été, en arrivant en vacances ;-)



En informatique, c'est pareil. Enfin ... sauf que les problèmes ne sont pas toujours aussi simple à décrire, les hypothèses pas faciles à formuler, et les expérimentations pas faciles à réaliser !

Déjà, les programmes ont un état interne (les 4Go de RAM de l'ordi principalement, mais aussi les fichiers du disque dur). On n'a pas beaucoup d'exemple de systèmes à état interne dans la vie de tous les jours, c'est dur de trouver un exemple non informatique ...

On peut prendre ... un enfant qui apprend ! On part de zéro, aucune connaissance (faut pas extrapoler l'exemple hein, c'est juste un support !).

  1. Maternel, on apprend la vie en communauté
  2. Élémentairement, on apprend 1/ le français, 2/ les maths
  3. Collège, on apprend l'anglais à la suite du français, en on renforce les maths
  4. ==> How you solve x = 5x² + 3x + 10 for x ? heu ... se sé pas !

Eh oui, ça bug ! Des hypothèses ?

  • parle pas anglais
  • sait pas résoudre d'équation
  • sourd ! (oui, faut penser à tout :-)

Comment on peut tester ça ? on peut voir s'il parle anglais, pour comprendre la question, ... mais si nous, on ne parle pas anglais ? (on peut voir s'il parle français, si non, il ne peut pas avoir appris l'anglais).
Mais et s'il a planté ? si on a seulement sa feuille d'exercice ? Et ben il faut faire une thèse pour construire de nouveaux outils !



Ces outils, ça peut être un voltmètre pour mesurer la tension aux bornes de l'ampoule du frigo. C'est réaliste cet exemple de voltmètre/ampèremètre/ohmmètre , parce que ça ressemble assez à ce que je fais : on se branche sur un circuit, les outils nous permettent d'observer des paramètres "invisibles" à l’œil nu. C'est du debugging interactif.

Ça peut être aussi le dossier de suivi de l'élève, avec des nôtres prises chaque trimestre, on peut savoir comment s'est déroulée son éducation (à condition d'aller à lire ce que les enseignants ont écrits !). C'est moins mon domaine ça, c'est de l'analyse de trace.

On peut aussi valider à l'avance le programme des enseignements qu'il doit obligatoirement suivre pour être sur de réussir notre test (c'est plus facile en informatique qu'en vrai ça ;-).



Et pour expliquer ma thèse, on peut prendre un dernier exemple.

On se place dans un contexte industriel particulier, par exemple, deux équipes de foot (= une application multicœur) qui doivent faire un match.
Les deux équipes, c'est des applications, et les joueurs, des processeurs.

Dans l'état actuelle de la science, on peut regarder une personne*, suivre ses déplacements, écouter ce qu'elle dit.
On peut aussi regarder plusieurs personnes d'une équipe, mais on regardera chaque personne indépendamment, sans notion d'équipe ou de collaboration.

Essaies de comprendre un match en ne regardant qu'un joueur à la fois ! S'il a le ballon, oui c'est bien, mais il fait une passe. Il faut que tu passes tous les autres joueurs en revu pour voir s'ils on le ballon.
Essaies de comprendre pourquoi Machin a fait la passe à Untel, si tu ne connais pas la tactique de jeu, ni la position du ballon ...

Ma contribution, c'est de montrer qu'on peut faire des outils (et qu'ils sont utiles !) qui vont connaitre les règles du jeu (du foot, du rugby, du hand). Au lieu de montrer des bonshommes qui bougent dans tous les sens sur une pelouse, l'outil montrera des joueurs, avec des numéros, des rôles, des tactiques de jeu, et un ballon. Au lieu de voir une personne qui courre bizarrement et tombe, puis une autre qui se met à faire, on verra un footballer qui drible, se fait tacler et prendre le ballon. Au lieu d’écouter une personne parler toute seule (50% du dialogue), on verra qu'elle échange avec un autre joueur et qu'ils se mettent d'accord sur la prochaine action.

C'est du model-centric debugging for multicore embedded systems !

* une fois, mais est-ce qu'on ne peut déboguer 1000 fois 1000 personnes ?