La presse s’inquiète de plus en plus de l’impact des bloqueurs de publicités sur leurs sources de revenus et condamne, plus ou moins ouvertement, leur utilisation par les internautes.

Le débat se polarise alors entre :

• ceux qui considèrent qu’ils n’ont pas à se voir imposer des publicités, et qui donc les bloquent ;
• ceux qui pensent que les internautes ne devraient pas bloquer les publicités car elles financent les sites où elles sont affichées, en particulier ceux de journalistes.

La seconde catégorie avance un argument simple et de bon sens : le contenu produit nécessite du travail, et leurs auteurs ont évidemment besoin de se loger, de se nourrir, et bien d’autres choses encore… Ce qui implique, dans notre société, d’avoir de l’argent. Ce que rapporte un peu la publicité.

Les autres sont des pirates sans conscience désirant tout gratuitement, à qui il faut expliquer qu’une attitude responsable consiste à ne pas bloquer les publicités. À moins que…

Hadopi

Des auteurs qui proposent du « contenu » difficilement vendable à un public qui y accède sans le payer, ça ne vous rappelle rien ?

L’un des fondements de l’idéologie répressive d’Hadopi est qu’il faut éduquer et contraindre les utilisateurs, sans quoi les « créateurs » ne pourront plus « vivre de leur travail », et donc ne pourront plus « créer ».

Faut-il établir un cadre psychologique incitant à accepter l’intrusion de publicités afin que les journalistes puissent « gagner leur vie » ?

De la même manière qu’il faut dépasser l’opposition entre le partage de la culture et son financement par la vente de copies, je pense qu’il faut dépasser celle entre la liberté de (non) réception (appliquée au web) et le financement par la publicité.

Les discussions portant sur la négociation d’un compromis entre les deux positions, comme l’acceptation de publicités moins intrusives, paraissent vaines.

Valeur et financement

Ne pas pouvoir vendre un contenu ne signifie pas qu’il n’a pas de valeur : un article rendu accessible à tous n’a pas moins de valeur que le même article restreint par un accès payant.

Par contre, y ajouter de la publicité diminue la valeur que leur attribuent les lecteurs, mais aussi les auteurs eux-mêmes : tous préféreraient ne pas la subir. La publicité agit donc comme un parasite.

Et pour les journalistes, ce parasite engendre une dépendance financière pouvant influencer le fond du discours. D’une manière générale, les sources de financement ont souvent tendance à réduire l’indépendance, pierre angulaire du journalisme.

C’est la raison pour laquelle certains essaient de ne dépendre que de leurs lecteurs. Mais, pour la plupart d’entre eux (pas tous), cela signifie limiter le contenu aux seuls abonnés. En effet, si tout est déjà accessible, pourquoi payer ?

Cependant, en pratique, seuls quelques gros sites peuvent se permettre cette restriction (les internautes ne vont pas s’abonner aux milliers de sites qu’ils visitent). Et au fond, est-ce bien le web que nous voulons, cloisonné par des barrières à péages ?

Du côté des lecteurs, la publicité ralentit la navigation, impose une pollution visuelle et collecte certaines données personnelles ; pas étonnant qu’ils cherchent à s’en prémunir !

Monnaie, revenu et travail

Dans le monde de la rareté, l’échange monétaire provient de la rencontre de l’offre et de la demande. Dans le monde de l’immatériel, l’offre et la demande se rencontrent déjà parfaitement sans monnaie, qui ne joue alors plus le rôle de facilitateur d’échange, mais au contraire d’obstacle : il est nécessaire de restreindre ou dégrader le résultat du travail pour pouvoir « gagner sa vie ».

Le métier de certains journalistes, dont personne ne conteste l’utilité, est menacé, car nous avons intégré le fait que le revenu devait provenir exclusivement du travail. Mais si ce travail ne génère pas d’argent, doit-il disparaître ?

La publicité est omniprésente car il faut absolument gagner de l’argent autrement, l’information en elle-même n’en rapportant pas. Pourtant, les internautes vont bien sur les sites de presse pour l’information, pas pour la publicité.

Revenu de base

Et si une partie du revenu était indépendante du travail ? Dissocier le revenu et l’emploi n’améliorerait-il pas la situation, pour tout le monde et en particulier pour les journalistes ?

Le revenu de base augmente la possibilité d’activités non rentables, sans ajouter de dépendances (car inconditionnel).

La rentabilité ayant tendance à entraver et dénaturer le journalisme, ne devrions-nous envisager sérieusement cette proposition dans les débats sur le financement de la presse, et plus généralement sur les productions potentiellement non-marchandes ?

Le revenu de base n’interdirait bien sûr pas les autres sources de financement : il s’y ajouterait. Simplement, il augmenterait la capacité à refuser des financements contraignants, tels que ceux provenant de la publicité…

Supposons que je souhaite ajouter une fonctionnalité à un projet sur GIT.

Je prends la version actuelle de la branche master (A), puis ajoute sur ma branche topic les commits X et Y.

    X---Y  topic
   /
--A  master

Je propose la fonctionnalité upstream (par un git request-pull ou une pull request), qui met un peu de temps à être revue.

Pendant ce temps, la branche master a avancé, et malheureusement les modifications effectuées entrent en conflit avec mon travail sur topic.

    X---Y  topic
   /
--A---B---C  master

Une fois mon code revu et accepté, les mainteneurs vont alors me demander de résoudre les conflits avec la branche master avant de merger ma branche topic.

Si j’avais eu à prendre en compte les mises à jour de master avant d’avoir rendu public mon topic, j’aurais simplement rebasé mon travail par-dessus master. Mais là, impossible.

Je dois donc merger. Très bien. Je merge et je résous les conflits.

    X---Y---M  topic
   /       /
--A---B---C  master

Mais, alors que je n’ai pas encore rendu M public, je m’aperçois qu’il y a un nouveau commit D sur master, que je veux intégrer dans topic.

    X---Y---M  topic
   /       /
--A---B---C---D  master

La solution la plus évidente est de merger à nouveau.

    X---Y---M---N  topic
   /       /   /
--A---B---C---D  master

Mais je voudrais éviter un commit de merge inutile. Pour un seul, ce n’est pas très gênant, mais si on maintient une branche suffisamment longtemps avant qu’elle ne soit mergée, ces commits inutiles vont se multiplier.

Une solution serait de revenir à Y et de le merger avec D :

git checkout topic
git reset --hard Y
git merge master

    X---Y---M'  topic
   /         \
--A---B---C---D  master

Mais dans ce cas, pour créer M', je vais devoir résoudre à nouveau les conflits que j’avais déjà résolu en créant M.

Comment éviter ce problème ?

rerere

Une solution est d’avoir activé rerere avant d’avoir résolu les conflits de M :

git config rerere.enabled true

Ainsi, lorsque je tenterai de merger à nouveau Y et D, les conflits entre Y et C seront automatiquement résolus de la même manière que précédemment.

Cependant, cette méthode a ses inconvénients.

Tout d’abord, il ne s’agit que d’un cache local de résolutions des conflits, stocké pendant une durée déterminée (par défaut à 60 jours pour les conflits résolus), ce qui est peu pratique si on clone son dépôt sur plusieurs machines (les conflits ne seront résolus automatiquement que sur certaines).

Ensuite, elle est inutilisable lorsqu’on souhaite squasher un merge conflictuel alors que rerere était désactivé lors de sa création.

Enfin, cette fonctionnalité est encore récente, et la fonction git rerere forget (pour permettre de résoudre autrement des conflits déjà résolus), a la fâcheuse tendance à segfaulter (un patch a été proposé).

Rebranchement

La solution que j’utilise est donc la suivante.

    X---Y---M---N  topic
   /       /   /
--A---B---C---D  master

Une fois obtenus les deux merges M et N, le principe est de remplacer le parent de N, qui était M, par Y, sans rien changer d’autre au contenu.

          -----
         /     \
    X---Y---M   N' topic
   /       /   /
--A---B---C---D  master

Ainsi, M devient inatteignable, et c’est exactement le résultat souhaité :

    X---Y-------N' topic
   /           /
--A---B---C---D  master

Pour faire cela, il faut déplacer le HEAD (pointant vers topic) sur Y, faire croire à GIT qu’on est en phase de merge avec D en modifiant la référence MERGE_HEAD, puis commiter :

git checkout N
git reset --soft Y
git update-ref MERGE_HEAD D
git commit -eF <(git log ..N ^D --pretty='# %H%n%s%n%n%b')

Il n’y a plus qu’à éditer le message de commit de merge.

La fin de la ligne du git commit permet de concaténer l’historique des commits intermédiaires (a priori uniquement des merges) comme lors d’un squash avec git rebase (pour pouvoir conserver les messages de merges intermédiaires, contenant nontamment les conflits).

En utilisant les références plutôt que les numéros de commit, cela donne :

git checkout feature
git reset --soft HEAD~2
git update-ref MERGE_HEAD master
git commit -eF <(git log ..HEAD@{1} ^master --pretty='# %H%n%s%n%n%b')

Si vous avez plus simple, je suis preneur…

Merci aux membres de stackoverflow.

Dans la réalité, ce que nous entendons est la somme de chacun des signaux.

Mais si nous voulons mélanger plusieurs pistes audio numériques, nous rencontrons un problème : chaque échantillon d’un signal audio est compris entre une valeur min et une valeur max, disons entre -1 et 1. Pour les mixer, nous ne pouvons donc pas sommer plusieurs signaux comme dans la réalité : le signal résultant doit aussi être compris entre -1 et 1. Comment faire alors ?

En théorie

Les graphes présentés dans les sections suivantes ont été créés avec gnuplot, et les définitions de fonctions sont écrites dans la syntaxe correspondante. Les sources (.gnu) sont disponibles pour chacun des graphes, vous permettant de les manipuler en 3D.

Somme tronquée

La première idée est de sommer les signaux en tronquant le résultat dans l’intervalle [-1; 1]. Pour le mixage de deux sources audio x et y :

mix_sum(x, y) = min(1, max(-1, x + y))

Le résultat sera parfait lorsque |x + y| <= 1. Par contre, dans le reste des cas, nous obtenons du clipping, désagréable à l’oreille.

Visualisons cette fonction :

Les axes horizontaux correspondent à un échantillon de chacune des deux sources audio ; l’axe vertical représente la valeur résultant de la combinaison des deux en utilisant la somme tronquée.

Le clipping correspond aux deux paliers horizontaux du haut et du bas.

Moyenne

Pour éviter tout clipping, il suffirait de moyenner les deux sources audio :

mix_mean(x, y) = (x + y) / 2;

Effectivement, ça fonctionne bien. Mais ce n’est pas forcément le meilleur choix.

Le son résultant va toujours être plus faible que le plus fort des deux sources, et souvent de manière significative. En particulier, si nous mélangeons une source audio quelconque avec un silence, l’amplitude va être divisée par deux.

De plus, la définition va également être divisée par deux : si l’amplitude est codée sur 8 bits, elle peut prendre 256 valeurs. En divisant les signaux par deux, chaque signal aura une définition de 7 bits (128 valeurs).

Ces inconvénients s’agravent lorsqu’il y a plus de deux sources à mélanger.

k × somme

Nous pouvons alors chercher un compromis entre conserver l’amplitude et éviter le clipping. En fait, les fonctions de somme tronquée et de moyenne ne sont que deux cas particuliers de cette fonction :

mix_ksum(k, x, y) = min(1, max(-1, k * (x + y)))

En effet :

mix_sum(x, y) = mix_ksum(1, x, y)
mix_mean(x, y) = mix_ksum(0.5, x, y)

Nous pouvons choisir n’importe quel k entre 0.5 et 1 : plus k est faible, moins le clipping sera probable ; plus k est élevé, plus l’amplitude sera conservée.

Voici le graphe pour k = 0.7 :

Cette méthode est très utile si nous connaissons à l’avance les sources audio. Par exemple, pour mélanger deux fichiers son, nous pouvons effectuer une première passe pour analyser le max m de la somme des deux signaux, et choisir k < 1/m : cela garantit qu’il n’y aura pas de clipping, et nous pouvons conserver l’amplitude dans la mesure du possible, sans distorsion.

Si ces sources audio nous parviennent en direct (streaming, conversation audio…), nous pouvons choisir un nombre arbitrairement (plus ou moins basé sur l’expérience). Choisir k > 0.5 se justifie car si deux sources audio sont indépendantes, les ajouter ne provoque pas des pics deux fois plus importants (les pics d’un signal vont souvent être compensés par les creux de l’autre).

Fonction non-linéaire

Mais nous pouvons trouver un meilleur compromis grâce à des fonctions non-linéaires.

Dans la première partie de son billet Mixing digital audio, Viktor T. Toth présente une stratégie très intéressante. Il part du principe que le mixage de deux sources audio doit respecter les règles suivantes :

• si l’une des sources est silencieuse, alors nous voulons entendre l’autre inaltérée ;
• si les signaux sont de même signe, l’amplitude du résultat (en valeur absolue) doit être supérieure à celle des sources.

Et si les signaux prennent valeur dans [0, 1], la fonction suivante respecte ces contraintes :

vtt(x, y) = x + y - x * y

Cependant, en réalité, les signaux prennent valeur dans [-1, 1], et cette fonction ne convient pas. L’auteur s’en est rendu compte, mais malheureusement la solution qu’il propose n’est pas appropriée (par exemple, le mixage ne se comporte pas symétriquement si nous inversons le signal).

Nous pouvons extrapoler son idée originale pour la faire fonctionner sur [-1, 1] :

mix_vtt(x, y) = \
    x >= 0 && y >= 0 ? x + y - x * y \
  : x <= 0 && y <= 0 ? x + y + x * y \
  : x + y

Le principe est d’utiliser le symétrique de sa fonction pour la partie négative, et ajouter deux bouts de plans pour les raccords :

Mais quelque chose saute aux yeux : sa représentation n’est pas lisse (la fonction n’est pas continûment dérivable (C¹)). Cela signifie que les variations du résultat en fonction des variations des sources changent brutalement en certains endroits.

Ce n’est pas satisfaisant mathématiquement.

Surface lisse

Et en effet, en y réfléchissant, la fonction souffre de quelques défauts.

Par exemple, si l’une des deux sources audio est à 1, alors si l’autre est positive, elle n’a aucun impact, si elle est négative, elle a un impact linéaire important. Ce n’est rien d’autre qu’un clipping de l’une des deux sources.

Par ailleurs, dans la réalité, le mixage de deux signaux est simplement leur addition. Le résultat est donc invariant si nous ajoutons une constante à une source et la soustraions à l’autre :

mix(x, y) = mix(x + k, y - k) = x + y

Cette propriété me semble importante : peu importe que le son provienne d’une source ou d’une autre, cela n’intervient pas dans le mixage.

Or, dans la fonction précédente, ce n’est pas le cas. Par exemple :

mix_vttx(0.5, 0.5) = 0.75
min_vttx(0, 1) = 1

Afin de dépasser ce problème, posons cette propriété comme principe : puisque l’identification de l’apport individuel de chaque signal ne compte pas, considérons uniquement leur somme (ou leur moyenne). Ainsi, au lieu d’une fonction à deux variables x et y, nous pouvons utiliser une fonction à une seule variable z = (x + y) / 2 (la moyenne).

Remarquons que nous pouvions déjà exprimer les fonctions linéaires vues précédemment en fonction d’une seule variable. En effet, en posant z = (x + y) / 2, nous obtenons :

sum(z) = max(-1, min(1, 2 * z))
mean(z) = z
ksum(z) = max(-1, min(1, 2 * k * z))

Dans le fond, nous cherchons une fonction qui s’approche de sum pour les amplitudes faibles (pour conserver l’amplitude au mieux) et de mean pour les amplitudes élevées (pour éviter le clipping).

Avec un peu d’imagination, nous pouvons trouver une fonction qui convient parfaitement (pour 2 pistes audio) :

g(z) = z * (2 - abs(z))

Elle se généralise pour n pistes audio :

g(z) = sgn(z) * (1 - (1 - abs(z)) ** n)

abs(x) désigne la valeur absolue de x (|x|), et ** est la fonction puissance (a ** n signifie aⁿ)

Cette fonction a plein de propriétés intéressantes :

∀x, |g(x)| <= 1

dans le bon intervalle

g(-1) = -1, g(0) = 0 et g(1) = 1

résultats cohérents

∀x (|x| < 1), g’(x) > 0

pas de clipping

∀x, |g(x)| ≤ |sum(x)|

l’amplitude ne dépasse jamais la somme de celle des sources

∀x, |g(x)| ≥ |mean(x)|

l’amplitude est toujours supérieure à la moyenne des sources

∀x, g’(0) = sum’(x) = n

g se comporte comme sum lorsque l’amplitude est faible (elle varie de la même manière)

∀x≠0, x.g’‘(x) < 0

la croissance de g ralentit lorsque l’amplitude augmente (en valeur absolue), donc les fortes amplitudes sont plus compressées que les faibles

∀x, g(-x) = -g(x) (impaire)

comportement symétrique sur un signal inversé

g ∈ C¹ (continûment dérivable)

parfaitement lisse

Passons alors en 3 dimensions, et posons :

mix_f(x, y) = g((x + y) / 2)

Nous nous apercevons que c’est une version lissée de la fonction précédente :

Cette fonction me semble donc pertinente pour mixer plusieurs flux audio.

En pratique

Bon, jusqu’ici nous avons fait de beaux dessins, c’était rigolo. Maintenant, passons à la pratique, et implémentons les fonctions de mixage en C.

Nous manipulerons uniquement des flux audio brut (des wav sans en-tête), contenant uniquement des échantillons encodés par des entiers signés sur 16 bits, en little endian. Ça peut paraître compliqué comme ça, mais c’est juste le format utilisé pour les cd audio.

Le programme est indifférent au nombre de canaux ou à la fréquence (il mixe les échantillons les uns à la suite des autres), mais bien évidemment les différentes pistes mixées doivent avoir ces paramètres identiques.

Implémentation

Bien que nous n’ayons vu jusqu’ici que le mixage de deux pistes audio (au-delà c’était compliqué de les visualiser sur des graphes), l’implémentation permet de mixer n pistes audio.

Le mixage s’effectue sur un échantillon de chaque piste audio à la fois (il est indépendant des échantillons précédents et suivants). Les fonctions de mixage ont toutes la même signature :

int mix(int n, int samples[])

n

le nombre de pistes audio

samples

le tableau des n échantillons à mixer

La valeur du retour ainsi que celles des samples[i] tient sur 16 bits (compris entre -32768 et 32767).

À titre d’exemple, voici l’implémentation de la fonction f (celle qui est lisse) :

int
mix_f(int n, int samples[])
{
  double z = _dsum(n, samples) / n;
  int sgn = z >= 0 ? 1 : -1;
  double g = sgn * (1 - pow(1 - sgn * z, n));
  return to_int16(g);
}

avec _dsum une fonction qui somme les n samples et to_int16 une fonction qui convertit un flottant compris entre -1 et 1 vers un entier compris entre -32768 et 32767.

Une fonction main s’occupe d’ouvrir les fichiers dont les noms sont passés en paramètres et d’appliquer pour chaque échantillon la fonction de mixage désirée.

Sources

Les sources complètes sont gitées :

git clone http://git.rom1v.com/mixpoc.git

(ou sur github).

Le projet contient :

• le code du PoC (mixpoc.c) ;
• un makefile minimaliste (Makefile) ;
• les sources des graphes gnuplot (*.gnu) ;
• des scripts utilitaires (voir ci-dessous l’utilisation).

Utilisation

Fichiers raw

Le PoC ne manipule que des fichiers raw. Il est peu probable que vous ayez de tels fichiers sur votre ordinateurs, vous devez donc pouvoir en créer à partir de vos fichiers audio habituels.

Vous aurez besoin de sox et éventuellement avconv ou ffmpeg.

./toraw file.wav file.raw
./toraw file.ogg file.raw
./toraw file.flac file.raw

Pour l’opération inverse :

./rawtowav file.raw file.wav

Si le format n’est pas supporté par sox (comme le mp3), convertissez-le en wav d’abord :

avconv -i file.mp3 file.wav
ffmpeg -i file.mp3 file.wav

Lecture et enregistrement

Il est possible de lire des fichiers raw directement et d’en enregistrer de nouveaux à partir du microphone (pratique pour essayer de mixer une musique avec une conversation).

Le paquet alsa-utils doit être installé (vérifiez que le microphone est bien activé dans alsamixer).

Pour enregistrer :

./record file.raw
./record > file.raw

Pour lire :

./play file.raw
./play < file.raw

Pour lire en direct le son provenant du microphone (à tester avec un casque pour éviter l’effet Larsen) :

./record | ./play

Mixpoc

Pour compiler mixpoc (nécessite make et un compilateur C comme gcc) :

make

Pour l’utiliser, la syntaxe est la suivante :

./mixpoc (sum|mean|ksum|vttx|f) file1 [file2 [...]]

Le résultat sort sur la sortie standard. Ainsi :

./mixpoc f file1.raw file2.raw filen.raw > result.raw

écrit le fichier result.raw.

Pour lire en direct le résultat :

./mixpoc f file1.raw file2.raw filen.raw | ./play

ou plus simplement (grâce au script mix) :

./mix f file1.raw file2.raw filen.raw

Pour ajouter une source silencieuse, vous pouvez utiliser /dev/zero :

./mix f file.raw /dev/zero

Vous avez maintenant tout ce dont vous avez besoin pour tester.

Gnuplot

Pour visualiser les graphes gnuplot, je vous conseille le paquet gnuplot-qt.

Pour les ouvrir :

gnuplot -p file.gnu

La souris ou les flèches du clavier permettent de tourner le graphe en 3 dimensions.

Les commandes nécessaires pour générer une image .png sont écrites en commentaire à l’intérieur du fichier. Je les ai fait commencer par ## pour pouvoir les décommenter automatiquement (sans décommenter le reste) avec un script.

Ainsi, pour générer les fichiers .png :

./gg file.gnu
./gg *.gnu

Conclusion

Pour mixer plusieurs pistes son, la fonction f me semble très bonne, à la fois en théorie et en pratique. Sur les exemples que j’ai testés, le résultat était celui attendu.

Cependant, je n’ai ni du matériel audio ni des oreilles de haute qualité, et mes connaissances en acoustique sont très limitées.

Les critiques sont donc les bienvenues.

Ce sont des cas d’école, mais j’adore ces quelques paradoxes. La simplicité de leurs énoncés et l’évidence de leur solution nous permettent de répondre en quelques secondes, sans aucune hésitation. Mais en nous trompant.

Deux enfants

Un couple a deux enfants dont l’un d’eux (au moins) est une fille. Quelle est la probabilité que l’autre soit (aussi) une fille ?

Par hypothèse, la probabilité à chaque naissance d’avoir un garçon est égale à celle d’avoir une fille (50%), et les naissances sont indépendantes.

La réponse 1/2 est évidente. Mais fausse. La bonne réponse est 1/3.

En effet, un couple ayant deux enfants a 4 possiblités équiprobables :

1. garçon-garçon
2. garçon-fille
3. fille-garçon
4. fille-fille

Sachant que l’un des deux est une fille, le cas 1 est exclu : il reste trois possibilités équiprobables, dont une seule correspond au cas fille-fille. Il y a donc une chance sur trois que les deux enfants soient des filles. CQFD

Pour vous en convaincre, considérez les deux phrases équivalentes suivantes :

• Un couple a deux enfants, dont l’un d’eux (au moins) est une fille.
• Un couple a deux enfants qui ne sont pas deux garçons.

Pour chacune d’elles, demandez-vous quelle est la probabilité que les deux enfants soient des filles.

Attendez d’être convaincus de ce résultat avant de passer à la suite.

Fausse implication

Une fois ce résultat compris, considérons l’énoncé suivant :

Un couple a deux enfants. Je le croise dans la rue avec l’un de ses enfants, qui est une fille. Quelle est la probabilité que l’autre enfant (celui qui est absent) soit (aussi) une fille.

Il est possible de répondre avec certitude : s’il est absent, c’est un garçon, si elle est absente, c’est une fille. (Ça, c’est fait !)

Alors vous appliquez le même raisonnement, et répondez 1/3.
Après tout, nous sommes exactement dans le cas de l’énoncé précédent : un couple a deux enfants et je sais que l’un d’eux (au moins) est une fille.

Mais non, c’est faux. Ici, la réponse est 1/2.

Pour le comprendre, il faut voir que le raisonnement menant à la réponse 1/3 n’est en fait tout-à-fait valide qu’en levant une légère ambiguïté de l’énoncé, celle de l’acquisition de l’information : comment savons-nous que le couple ayant deux enfants a au moins une fille (pour déterminer la probabilité qu’il en ait deux) ?

Si nous avons demandé à l’un des parents « avez-vous (au moins) une fille ? » et qu’il a répondu « oui », alors la probabilité que les deux soient des filles est bien 1/3.

Par contre, si nous lui avons demandé « indiquez-moi le sexe de l’un de vos enfants » et qu’il a répondu « j’ai (au moins) une fille », alors la probabilité que les deux soient des filles est 1/2. En effet, le fait que le parent puisse répondre garçon à cette question lorsqu’il a deux enfants de sexes différents fait baisser la probabilité conditionnelle des cas 2 et 3, et une fois le cas 1 exclu, l’union des 2 et 3 et le cas 4 sont équiprobables. Relisez la phrase précédente plusieurs fois. Comme elle n’est pas claire, consultez le calcul sur Wikipedia.

Le fait de rencontrer un enfant de ce couple (ici, une fille) s’apparente à ce dernier cas (car pour deux enfants de sexes différents, nous aurions pu rencontrer le garçon). Ainsi, la probabilité que l’autre soit une fille est 1/2.

Si ce n’est pas clair, continuez, j’en reparle un peu plus loin lorsque j’évoque la particularisation.

Deux enfants, un jour

Un couple a deux enfants dont l’un d’eux (au moins) est une fille née un mardi. Quelle est la probabilité que l’autre soit (aussi) une fille ?

La réponse n’est ni 1/2, ni 1/3, mais 13/27.

Un bash vaut mieux qu’un long discours :

printf '%s\n' {G,F}{0..6}-{G,F}{0..6} | grep F1 | wc -l
printf '%s\n' {G,F}{0..6}-{G,F}{0..6} | grep F1 | grep F.-F. | wc -l

(Nous supposons avoir obtenu l’information en demandant à l’un des parents « avez-vous une fille née un mardi ? ». Comme dans le premier exemple, si nous lui avions demandé « indiquez-moi le sexe d’un de vos enfants ainsi que son jour de naissance », la probabilité que l’autre soit une fille serait 1/2.)

Il est également possible de différencier par autre chose qu’un jour de la semaine, par exemple faire la différence entre matin (entre minuit et midi) et après-midi (entre midi et minuit) :

Un couple a deux enfants dont l’un d’eux (au moins) est une fille née un matin. Quelle est la probabilité que l’autre soit (aussi) une fille ?

La réponse est 3/7 :

printf '%s\n' {G,F}{M,A}-{G,F}{M,A} | grep FM | wc -l
printf '%s\n' {G,F}{M,A}-{G,F}{M,A} | grep FM | grep F.-F. | wc -l

Deux enfants, un prénom

Supposons maintenant qu’aucun couple n’appelle deux de ses enfants par le même prénom, et considérons l’énoncé suivant :

Un couple a deux enfants dont l’un d’eux (au moins) est une fille prénommée Sophie. Quelle est la probabilité que l’autre soit (aussi) une fille ?

La réponse ici est 1/2.

Si vous avez compris le résultat du script bash précédent, cela revient à supposer que les enfants ne peuvent pas être nés le même jour de la semaine (ce qui est absurde pour un jour de la semaine, mais pas pour un prénom).

printf '%s\n' {G,F}{0..6}-{G,F}{0..6} | grep -v '^.\(.\)-.\1' | grep F1 | wc -l
printf '%s\n' {G,F}{0..6}-{G,F}{0..6} | grep -v '^.\(.\)-.\1' | grep F1 | grep F.-F. | wc -l

Synthèse et particularisation

Résumons. Sachant que l’un des deux enfants est une fille, la probabilité que les deux soient des filles dépend de la capacité à particulariser l’enfant dont on connaît le sexe. Sans aucune information supplémentaire, la probabilité est 1/3.

Mais si nous savons par exemple que l’enfant en question est l’aîné, nous le particularisons complètement : nous sommes sûrs que l’autre n’est pas l’aîné, et donc la probabilité devient 1/2 (évidemment, puisque par hypothèse, les naissances sont indépendantes). De même, si nous supposons qu’un couple ne donne pas le même prénom à plusieurs de ses enfants, alors préciser le prénom particularise complètement l’enfant dont on parle. Il en va de même si nous rencontrons l’un des enfants dans la rue : c’est de celui qui est présent dont on parle, pas n’importe lequel.

Et il existe des cas intermédiaires, où nous ne particularisons que partiellement. Par exemple, en précisant que l’enfant est né un mardi, dans certains cas l’information est différenciante (l’autre enfant n’est pas né un mardi), dans certains cas non (les deux enfants sont nés un mardi). Le résultat n’est donc ni 1/3, ni 1/2, mais entre les deux (13/27 ici).

Si vous avez du mal à vous convaincre que rencontrer l’un des enfants dans la rue le particularise (et donc donne une probabilité de 1/2 que l’autre soit une fille ou un garçon), je vous propose l’expérience de pensée suivante (par l’absurde). Vous rencontrez le couple avec l’un de ses enfants, qui est une fille. D’après le tout premier raisonnement, vous en concluez que la probabilité que l’autre soit une fille est 1/3. Vous lui parlez, et vous lui demandez quel jour de la semaine elle est née, elle vous répond mardi. Vous savez maintenant que c’est une fille née un mardi. D’après ce que nous venons de voir, vous en concluez que la probabilité que l’autre soit une fille est 13/27. Mais le résultat aurait été le même si elle avait répondu n’importe quel autre jour de la semaine. Le fait d’avoir posé la question a donc changé la probabilité, et ceci, indépendemment de sa réponse. Comment pourrait-elle dépendre du simple fait de poser la question ? C’est incohérent.

Cette particularisation me fait d’ailleurs beaucoup penser au phénomène de décohérence quantique.

Monty Hall

Il s’agit jeu télévisé avec trois portes, dont voici les règles :

• Derrière chacune des trois portes se trouve soit une chèvre, soit une voiture, mais une seule porte donne sur une voiture alors que deux portes donnent sur une chèvre. La porte cachant la voiture a été choisie par tirage au sort.
• Le joueur choisit une des portes, sans que toutefois ce qui se cache derrière (chèvre ou voiture) ne soit révélé à ce stade.
• Le présentateur sait ce qu’il y a derrière chaque porte.
• Le présentateur doit ouvrir l’une des deux portes restantes et doit proposer au candidat la possibilité de changer de choix quant à la porte à ouvrir définitivement.
• Le présentateur ouvrira toujours une porte derrière laquelle se cache une chèvre, en effet :
  • Si le joueur choisit une porte derrière laquelle se trouve une chèvre, le présentateur ouvrira l’autre porte où il sait que se trouve également une chèvre.
  • Si le joueur choisit la porte cachant la voiture, le présentateur choisit au hasard parmi les deux portes cachant une chèvre. (on peut supposer qu’un tirage au sort avant l’émission a décidé si ce serait la plus à droite ou à gauche)
• Le présentateur doit offrir la possibilité au candidat de rester sur son choix initial ou bien de revenir dessus et d’ouvrir la porte qui n’a été choisie ni par lui-même, ni par le candidat.

La question qui se pose alors est : le joueur augmente-t-il ses chances de gagner la voiture en changeant son choix initial ?

Vu qu’il reste deux portes, nous pourrions nous dire que garder son choix initial ou le changer n’a pas d’incidence sur les probabilités. Ce qui évidemment est faux (sinon nous n’en parlerions pas). En réalité, il a une probabilité de 1/3 de gagner s’il conserve son choix initial et 2/3 s’il en change.

Lors de son choix initial, le joueur a une chance sur trois de sélectionner la porte gagnante. S’il décide de toujours garder sa porte, il a donc une chance sur trois de gagner. Comme à la fin il n’a que deux choix (garder ou changer), il aurait eu deux chances sur trois de gagner en changeant de porte.

Pour mieux comprendre, généralisons le principe du jeu :

• Il y a 1 million de portes, avec une seule porte gagnante.
• Le joueur sélectionne une porte.
• Le présentateur retire 999 998 portes perdantes parmi les portes restantes.
• Le joueur doit-il changer de porte ?

La réponse devient évidente, non ?

Si vous n’êtes pas convaincus, développeur et que vous connaissez la loi des grands nombres, ce programme devrait vous aider :

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(int argc, char *argv[])
{
  int i, winning, choice, elim, change;
  int keepwin = 0, changewin = 0;

  /* Initialise le seed pour la génération aléatoire */
  srand(time(NULL));

  for (i = 0; i < 10000; i++) {
    /* Tire au sort une porte gagnante et un choix du joueur */
    winning = rand() % 3;
    choice = rand() % 3;

    /* Présentateur */
    if (choice == winning)
      /* Choisit aléatoirement d'éliminer l'une des deux autres portes */
      elim = ~winning & (rand() % 2 + 1);
    else
      /* Désigne la porte restante perdante */
      elim = 3 - choice - winning;

    /* Compte les choix vainqueurs */
    change = 3 - choice - elim;
    keepwin += choice == winning;
    changewin += change == winning;
  }

  printf("Victoires en gardant son choix   : %d\n", keepwin);
  printf("Victoires en changeant son choix : %d\n", changewin);
  return 0;
}

Ce problème est similaire au paradoxe des prisonniers.

Variante

Changeons un peu les règles : maintenant, le présentateur ne sait pas où se trouve la porte gagnante.
Du coup, une fois que le joueur a choisi sa porte, le présentateur indique une porte au hasard parmi les deux restantes. Si malheureusement il tombe sur la porte gagnante, la partie est annulée et on recommence.

Ainsi nous retirons toutes les parties où le présentateur a ouvert la porte gagnante. Il ne reste donc plus que les parties où il désigne une porte perdante, et nous nous retrouvons dans le même cas que précédement.

Eh bien, en fait, non. Ce n’est pas le même cas que précédemment, car maintenant le joueur va gagner avec un probabilité est de 1/2 qu’il garde sa porte ou qu’il en change. La preuve :

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
  int i = 0, winning, choice, elim, change;
  int keepwin = 0, changewin = 0;

  /* Initialise le seed pour la génération aléatoire */
  srand(time(NULL));

  while (i < 10000) {
    /* Tire au sort une porte gagnante et un choix du joueur */
    winning = rand() % 3;
    choice = rand() % 3;

    /* Présentateur */
    elim = ~choice & (rand() % 2 + 1);
    if (elim == winning)
      continue;

    /* Compte les choix vainqueurs */
    change = 3 - choice - elim;
    keepwin += choice == winning;
    changewin += change == winning;
    i++;
  }

  printf("Victoires en gardant son choix   : %d\n", keepwin);
  printf("Victoires en changeant son choix : %d\n", changewin);
  return 0;
}

Intuitivement, si c’est le hasard qui détermine à la fois la porte choisie par le joueur et la porte laissée par le présentateur, et que nous supprimons toutes les parties où le présentateur a éliminé la porte gagnante (en moyenne 1 partie sur 3), tout se passe comme s’il n’y avait que 2 portes dès le début du jeu.

Dissonance

« sonance »

Nous disposons de pastilles de 3 couleurs (disons rouge, bleu et vert).
Nous proposons à un singe de choisir parmi 2 de ces couleurs (par exemple rouge et bleu) celle qu’il préfère (par une méthode quelconque). Il répond « rouge ».
Nous lui demandons alors laquelle il préfère parmi la couleur qu’il n’a pas choisie la première fois (bleu) et celle qui reste (vert). Et le plus souvent (environ 2 fois sur 3), les chercheurs ont observé qu’il rejetait encore la couleur qu’il n’avait pas choisie la première fois (bleu).

Cela montre qu’une fois que nous rejetons quelque chose, nous le dévaluons, ce qui nous amène à le rejeter de nouveau lors d’un second choix.

Ou pas. En réalité, ce raisonnement souffre de la même erreur de raisonnement qui nous induit en erreur dans le problème de Monty Hall.

Supposons que le singe sache trier les trois couleurs par ordre de préférence. Nous lui en montrons deux. Cela revient à choisir au premier tour celle que nous ne lui montrons pas.

Cette couleur non choisie peut être :

1. celle que le singe préfère ;
2. la deuxième ;
3. celle qu’il aime le moins.

Parmi ces 3 possibilités équiprobables, seule la position 3 lui fera la rejeter lors du second choix (c’est la seule moins bonne que la moins bonne du premier choix).

Test positif

Une maladie X touche 1 personne sur 100 000 dans une population. Un test de la maladie X est fiable à 99%. Il se révèle positif pour vous. Quelle est la probabilité que vous soyez infecté ?

Aussi surprenant que cela puisse paraître, la réponse est 0,1%.

Faisons le calcul sur une population de 10 millions de personnes. La maladie touche 1 personne sur 100 000, donc 100 personnes en moyenne.

Le test est fiable à 99%, donc il provoque 1% d’erreur. Sur les 9 999 900 personnes non malades, il y a donc 99 999 erreurs (faux-positifs). Sur les 100 malades, il y a 1 erreur (faux-négatif).

En tout, en moyenne 99 999 + 99 = 100 098 personnes seront testées positives, alors que seules 99 seront malades. Donc si votre test est positif, vous avez 99 chances sur 100 098 d’être malade, soit moins de 0,1%.

Le fait que ce résultat soit surprenant pour notre cerveau provient d’un biais cognitif appelé l’oubli de la fréquence de base.

Conclusion

Méfiez-vous de vos intuitions en probabilités.

Pour suivre des règles de codage et s’y tenir, rien de tel qu’un outil qui formate automatiquement le code (c’est plus rapide et sans erreurs). Sous Eclipse par exemple, la combinaison de touches Ctrl+Shift+F est indispensable. Mon but est d’obtenir la même fonctionnalité sous Vim pour le langage C.

indent

L’outil indent permet de formater un source C selon des règles définies par des paramètres en ligne de commande. Ces options sont très nombreuses. Heureusement, il y a quelques styles bien connus prédéfinis, comme le style K&R (option -kr).

Pour illustrer son fonctionnement, voici un code source écrit n’importe comment (et qui fait n’importe quoi) :

#include <stdio.h>

void f (  int* x  )
  {
 *x=4;}

void g(int x)
{goto mylabel;
        /* my comment */
    if(x>10)x=10;
       mylabel:
    printf ("%d\n",x *2);
switch(x){case 1  =4;break;case 2  =1;}
    while   ( * ( &x ) <10)x++; /* what? */
}

void h(char ( * ( * x ( ) ) [ ] ) ( ) ) {
char ( * ( * y ) [ ] ) ( ) = \
x ( ) ; char ( * z ) ( ) = * \
( * y ) ; char c = z ( ); putchar \
(c);
}

int main(){
int i=  2;  f(&i);
  g(i);

        return    0;
}

Pour formater :

indent -st -kr -ts4 file.c

• -st affiche le résultat sur la sortie standard au lieu de modifier le fichier ;
• -kr utilise le style K&R ;
• -ts4 considère 4 espaces comme une tabulation.

Voici le résultat :

#include <stdio.h>

void f(int *x)
{
    *x = 4;
}

void g(int x)
{
    goto mylabel;
    /* my comment */
    if (x > 10)
        x = 10;
  mylabel:
    printf("%d\n", x * 2);
    switch (x) {
    case 1:
        x = 4;
        break;
    case 2:
        x = 1;
    }
    while (*(&x) < 10)
        x++;                    /* what? */
}

void h(char (*(*x())[])())
{
    char (*(*y)[]) () = x();
    char (*z) () = *(*y);
    char c = z();
    putchar(c);
}

int main()
{
    int i = 2;
    f(&i);
    g(i);

    return 0;
}

C’est plus joli, non ?

vim

Pour pouvoir reformater directement dans Vim, il suffit d’ajouter dans ~/.vimrc la ligne suivante :

autocmd BufNewFile,BufRead *.c set formatprg=indent\ -kr\ -ts4

Ensuite, la commande gq formate (u annule).

Par exemple, sur le fichier source malformaté ci-dessus :

• placer le curseur sur la ligne 7 ;
• appuyer sur V ;
• descendre avec j (ou la flèche du bas) jusqu’à la ligne 15 ;
• taper gq.

Ainsi, seule la fonction g est formatée.

À partir de la ligne 7, le même résultat est obtenu en tapant directement gq8j (descendre de 8 lignes) ou gq15G (jusqu’à la ligne 15).

Pour reformater un bloc, le plus simple est de se placer sur une accolade { ou } et de taper gq% (% navigue entre les {}, () et [] ouvrant et fermant).

Pour reformater tout le fichier, il faut taper gggqG :

• gg amène le curseur au début du fichier ;
• gq formate jusqu’à… ;
• G va à la fin du fichier.

:wq

Sur un serveur hébergé chez moi sur une ligne Free ADSL (maximum ~120Ko/s en upload), je crée un fichier totalement aléatoire dans un répertoire accessible en HTTP, avec plusieurs extensions :

# crée un fichier de 2Mio
dd if=/dev/urandom of=random count=4000
# crée plusieurs liens avec des extensions différentes
for ext in avi ogg oga webm pdf mp4 mov; do ln -s random{,.$ext}; done

Sur mon téléphone avec Android 4.11, connecté au réseau Free Mobile (sur une antenne d’Orange), je partage la connexion avec mon PC (Paramètres, Connexion, Sans fil et réseaux, Plus…, Partage de connexion, Via USB). Avec mon PC (sous Debian testing), je m’y connecte.

Je télécharge alors chacun des fichiers :

for ext in avi ogg oga webm pdf mp4 mov; do wget monserveur/random.$ext; done

Le résultat est sans appel.

Pour les fichiers portant l’extension .avi, .ogg, .mp4, .mov (et sans doute d’autres), le débit ne dépasse pas 5Ko/s et est même souvent en dessous d’1Ko/s :

requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 2048000 (2,0M) [video/x-msvideo]
Sauvegarde en : «random.avi»

 1% [                                       ] 34 486       757B/s  eta 43m 6s 

Par contre, pour les fichiers portant l’extension .oga, .webm, et .pdf, ça fonctionne parfaitement :

requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 2048000 (2,0M) [audio/ogg]
Sauvegarde en : «random.oga»

27% [=========>                             ] 570 300      104K/s  eta 14s    

Cette limite ne vient pas de ma ligne Free ADSL (qui fonctionne parfaitement par ailleurs).
Free Mobile filtre donc les fichiers sur HTTP en fonction de leur extension.

Il reste à vérifier si cela se produit aussi sur une antenne Free (mais je n’en capte jamais).

Le problème ne se produit que sur une antenne Orange ; sur une antenne Free, ça fonctionne normalement.

Mais j’envisage depuis longtemps de passer à WebM (le format libéré par Google il y a un peu plus de deux ans), plus performant, lui aussi lu nativement par Firefox (et par d’autres). Pour cela, je vais utiliser avconv.

avconv

Qu’est-ce qu’avconv ? Le meilleur moyen de le savoir est d’exécuter ffmpeg sans arguments :

$ ffmpeg
…
*** THIS PROGRAM IS DEPRECATED ***
This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.

En fait, c’est plus compliqué que ça.

J’ai précisé « ffmpeg » dans le titre du billet car je pense que c’est encore sous ce nom que l’outil est le plus connu. Le contenu de ce billet s’applique aussi bien à ffmpeg qu’à avconv.

Filtres

Il m’arrive d’avoir besoin d’appliquer des filtres très simples ; typiquement, augmenter la luminosité d’une vidéo. ffmpeg2theora permet de le faire directement grâce à l’option -B. Mais on a beau chercher dans le man d’avconv, on ne trouve rien.

frei0r

C’est là qu’intervient le projet frei0r. Il s’agit d’une API permettant d’appliquer des filtres vidéo que chaque application pourra utiliser. Et ça tombe bien, l’application avconv peut l’utiliser si elle a été compilée avec l’option --enable-frei0r.

La bonne nouvelle, c’est que la version distribuée par Debian wheezy est compilée avec cette option. La mauvaise, c’est que celle fournie dans Ubuntu 12.04 ne l’est pas.

frei0r a besoin de plugins permettant d’appliquer les filtres. Il est nécessaire pour cela d’installer frei0r-plugins :

sudo apt-get install frei0r-plugins

avconv + frei0r

La syntaxe pour utiliser frei0r dans avconv est la suivante :

-vf frei0r=<filter_name>[{:|=}<param1>:<param2>:...:<paramN>]

Mais comment connaître les filter_names disponibles et leurs paramètres ?
Je n’ai trouvé aucune documentation à ce sujet. J’ai donc consulté les sources.

À partir de là, on comprend facilement que la luminosité est modifiée par le filtre brightness comportant un paramètre de type double (voir notamment la fonction f0r_get_param_info) compris entre 0 (sombre) et 1 (clair) (0.5 étant la luminosité de la vidéo d’origine).

En respectant la syntaxe, cela donne par exemple :

avconv -i video.mts -s 640x360 -ac 1 -q:a 2 -b:v 600k -vf frei0r=brightness:0.6 output.webm

Il existe plein d’autres filtres. Par exemple pour le contraste, c’est contrast0r :

-vf frei0r=contrast0r:0.4

Pour les combiner, il suffit de concaténer plusieurs blocs -vf :

-vf frei0r=brightness:0.6,frei0r=contrast0r:0.4

Conclusion

Malgré les apparences, avconv permet, pour peu qu’il soit compilé avec l’option-qui-va-bien, d’encoder des vidéos en modifiant la luminosité, le contraste, et d’appliquer bien d’autres filtres… ce qui est très pratique.

Wireshark est un outil incontournable pour connaître les paquets qui transitent sur le réseau. Mais on se retrouve vite bloqué à cause d’un problème de droits.

En effet, en démarrant wireshark avec un compte utilisateur non-root, l’interface graphique s’affiche, mais il est impossible de capturer les trames : aucune interface réseau n’est disponible.

Devant ce problème, que fait l’utilisateur pressé ? Il démarre wireshark en root, bien sûr (c’est ce que je faisais sous Ubuntu) ! Eh bien pas de chance :

$ sudo wireshark
No protocol specified

(wireshark:27210): Gtk-WARNING **: cannot open display: :0

Déjà, c’est bien fait pour lui : on n’essaie pas de démarrer une interface graphique en root !

Mais comment faire alors ? En non-root on ne peut pas capturer, en root on ne peut pas démarrer…

Alors on lit la doc, qui propose deux solutions :

less /usr/share/doc/wireshark/README.Debian

Une troisième solution, donnée en commentaire, me semble encore meilleure :

sudo tcpdump -pni eth0 -s0 -U -w - | wireshark -k -i -

Utiliser dumpcap pour capturer

Avec cette méthode, il faut d’abord capturer les paquets réseau et les sauver dans un fichier, grâce à dumpcat (en root), puis ouvrir ce fichier dans wireshark (non-root).

Pour démarrer la capture de l’interface eth0 dans le fichier /tmp/mycapture :

sudo dumpcap -i eth0 -w /tmp/mycapture

Pour connaître la liste des interfaces réseau capturables :

$ sudo dumpcap -D 
1. eth0
2. wlan0
3. nflog (Linux netfilter log (NFLOG) interface)
4. any (Pseudo-device that captures on all interfaces)
5. lo

Ctrl+C arrête la capture.

Le fichier généré n’est lisible que par root. Avant de l’ouvrir dans Wireshark, il faut donc changer ses droits :

sudo chmod +r /tmp/mycapture

C’est la méthode configurée par défaut sous Debian.

Autoriser les utilisateurs non-root

Si on souhaite à la fois capturer et analyser à partir de Wireshark (et permettre les captures « en live »), sans passer par dumpcap en ligne de commande, il faut autoriser les utilisateur non-root à capturer des paquets.

Pour cela :

sudo dpkg-reconfigure wireshark-common

 ┌─────────────────────┤ Configuration de wireshark-common ├──────────────────────┐  
 │                                                                                │  
 │ Dumpcap peut être installé afin d'autoriser les membres du groupe              │  
 │ « wireshark » à capturer des paquets. Cette méthode de capture est préférable  │  
 │ à l'exécution de Wireshark ou Tshark avec les droits du superutilisateur, car  │  
 │ elle permet d'exécuter moins de code avec des droits importants.               │  
 │                                                                                │  
 │ Pour plus d'informations, veuillez consulter                                   │  
 │ /usr/share/doc/wireshark-common/README.Debian.                                 │  
 │                                                                                │  
 │ Cette fonctionnalité constitue un risque pour la sécurité, c'est pourquoi      │  
 │ elle est désactivée par défaut. En cas de doute, il est suggéré de la laisser  │  
 │ désactivée.                                                                    │  
 │                                                                                │  
 │ Autoriser les utilisateurs non privilégiés à capturer des paquets ?            │  
 │                                                                                │  
 │                      <Oui>                         <Non>                       │  
 │                                                                                │  
 └────────────────────────────────────────────────────────────────────────────────┘  

Après avoir répondu Oui, tous les utilisateurs du groupe wireshark (aucun, par défaut) seront autorisés à capturer les paquets.

Remarque : un programme non-root sera donc en théorie capable de savoir tout ce qui passe sur le réseau (déjà qu’il est capable de connaître tout ce qui est tapé au clavier).

Il ne reste donc plus qu’à ajouter son compte utilisateur au groupe wireshark :

sudo addgroup $USER wireshark

Cette modification ne sera prise en compte qu’après une reconnexion du compte utilisateur (il faut donc fermer la session et en démarrer une nouvelle).

Avec cette méthode, seul le processus de capture aura les droits root, l’interface graphique se contentant de droits non-root (merci la séparation des privilèges).

Pour résumer, il s’agit de créer un fichier /etc/udev/rules.d/51-android.rules contenant :

SUBSYSTEM=="usb", MODE="0666", GROUP="plugdev"

Mais ceci ne fonctionne pas sur Debian (en tout cas ni sur testing ni sur sid) :

$ adb devices
List of devices attached 
????????????    no permissions

En effet, contrairement aux autres distributions, Debian possède un fichier /lib/udev/rules.d/91-permissions.rules qui contient, entre autres :

# usbfs-like devices
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", \
                                MODE="0664"

Comme 91 > 51, ce fichier est parsé après notre fichier 51-android.rules.

La solution est donc très simple : renommer 51-android.rules en 92-android.rules afin que les permissions ne soient pas écrasées :

sudo mv /etc/udev/rules.d/{51,92}-android.rules

(ou en utilisant n’importe quel entier entre 92 et 99)

Après cette modification, udev doit être redémarré :

sudo service udev restart

et le téléphone débranché puis rebranché.

Et là, ça fonctionne :

$ adb devices
List of devices attached 
040140621600C00D        device

Merci à unforgiven512 qui m’a donné la solution (en anglais).

Voici par exemple à quoi ressemble GIMP :

Le problème doit être résolu deux fois : une première pour les applications utilisant GTK2 et une seconde pour celles utilisant GTK3.

GTK2

Pour GTK2, c’est facile. Sous Debian :

sudo apt-get install gtk2-engines-oxygen gtk-chtheme

(le nom des paquets peut varier selon votre distribution)

Il ne reste alors plus qu’à exécuter :

gtk-chtheme

et choisir le thème oxygen-gtk :

Le thème des applications telles que Firefox/Iceweasel, GIMP, Ario ou Eclipse sera alors totalement cohérent avec celui des applications prévues pour KDE :

Pour pousser plus loin l’intégration de Firefox/Iceweasel, il y a même un module complémentaire.

GTK3

Pour GTK3, ce devrait être presque pareil… sauf que le paquet gtk3-engines-oxygen (ou oxygen-gtk3) n’est pas encore dans les dépôts Debian (il est par contre dans d’autres distributions, comme Ubuntu ou Arch Linux).
Il est bien sûr possible de télécharger les sources pour l’installer manuellement.

Mais nous pouvons nous contenter du thème natif de Gnome. Pour le configurer, il suffit d’installer gnome-themes-standard :

sudo apt-get install gnome-themes-standard

et de créer un fichier ~/.config/gtk-3.0/settings.ini contenant :

[Settings]
gtk-theme-name=Adwaita
gtk-fallback-icon-theme=gnome

(voir GtkSettings)

Gedit avant :

Gedit après :

En attendant qu’Oxygen GTK3 soit disponible dans les dépôts, c’est mieux que rien…

Je ne le savais pas jusqu’à aujourd’hui. En fait, c’est possible grâce à des programmes qui écrivent directement dans le framebuffer.

Pour tester les outils suivants, lancez un TTY grâce aux raccourcis Ctrl+Alt+F[1-6]. Pour revenir à votre session graphique, faites Ctrl+Alt+F7 (sur certaines distributions, par défaut la session graphique est plutôt accessible avec Ctrl+Alt+F1, Ctrl+Alt+F8 ou Ctrl+Alt+F9, essayez…).

Images

Pour afficher des images, il faut installer le paquet fbi (framebuffer imageviewer) :

sudo apt-get install fbi

Puis simplement exécuter :

fbi monimage.jpg

ou même

fbi *.jpg

(PgUp et PgDown permettent de naviguer entre les images)

Cet outil est vraiment très rapide (sauf pour le zoom). C’est un peu l’équivalent de feh qui, lui, fonctionne en mode graphique.

Vidéos

Pour les vidéos, nous avons besoin de MPlayer :

sudo apt-get install mplayer

En lançant dans un TTY :

mplayer mavidéo.avi

MPlayer choisit le pilote fbdev. Nous pouvons aussi le choisir explicitement :

mplayer -vo fbdev mavidéo.avi

Par contre, la vidéo s’affiche à sa taille originale, alors que nous la voulons en plein écran. Il faut donc la mettre à l’échelle, grâce aux paramètres de mplayer. Sur un écran 1680×1050 par exemple :

mplayer -fs -vf scale=1680:-3 mavidéo.avi

-3 permet de calculer la seconde composante à partir de la première et de l’aspect-ratio. C’est dans le man :

 0: largeur/hauteur dimmensionnées à d_width/d_height
-1: largeur/hauteur originales
-2: Calcule l/h en utilisant l'autre dimension et le rapport hauteur/largeur redimensionné.
-3: Calcule l/h en utilisant l'autre dimension et le rapport hauteur/largeur original.
-(n+8): Comme -n ci-dessus, mais en arrondissant les dimensions au plus proche multiple de 16.

Sur mon pc portable, j’arrive sans problème à lire dans un TTY une vidéo 1080p (j’ai testé avec Big Buck Bunny en MP4, redimensionnée lors de la lecture à la taille de mon écran, 1680×1050).

Par contre, sur une machine moins puissante (une EeeBox, qui hébergeait ce blog par le passé), MPlayer saccade, même sur des vidéos basse définition, que VLC lit sans problèmes.
Pour améliorer les performances de lecture de MPlayer, il est possible de changer l’algorithme de zoom logiciel, grâce à l’option -sws. Par exemple, pour utiliser bilinéaire rapide au lieu de bicubique :

mplayer -fs -vf scale=1680:-3 -sws 0 mavidéo.avi

Avec ce paramètre, ça ne saccade plus.

Cependant, sur la EeeBox, dans ce cas les couleurs sont incorrectes apparemment à cause d’un bug de pilote vidéo Intel. J’ai donc quand même installé un serveur X avec un gestionnaire de fenêtres minimaliste, awesome. Mais c’est une autre histoire…

ASCII-art

Je vous parlais d’ASCII-art au début du billet, il est également possible de lire les images ou les vidéos en ASCII (c’est juste moins joli), grâce à des commandes d’une élégance toute particulière.

Pour les images, nous pouvons installer le paquet caca-utils 

sudo apt-get install caca-utils

Puis utiliser cacaview :

cacaview monimage.jpg

Pour les vidéos :

mplayer -vo caca mavidéo.avi

Conclusion

Je n’en revenais pas qu’il soit possible de lire des vidéos sans serveur X.
Sur une machine destinée à une utilisation multimédia (branchée sur la TV par exemple), il n’y a donc nullement besoin d’un serveur X (paradoxalement).

J’utilise GIT depuis quelques mois, et je trouve ça vraiment génial. Si vous ne connaissez pas, ou peu, vous ne pouvez pas ne pas lire le livre Pro Git (sous licence cc-by-nc-sa). Les explications très claires permettent en quelques heures de maîtriser toutes les fonctions de base, et d’être à l’aise avec la gestion des branches (et bien plus encore).

Branches visibles

Le but de ce billet est de répondre à un problème particulier : par manque d’attention, il m’est arrivé plusieurs fois de commiter des changements sur une mauvaise branche (j’étais persuadé d’être sur une branche, en fait j’étais sur une autre). Ce n’est pas très grave (on peut s’en sortir), mais c’est pénible.

Je souhaiterais donc avoir le nom de la branche dans le prompt bash.

Des solutions existent déjà : le paquet git embarque même un script qui répond au besoin. Certains utilisent aussi des scripts personnalisés. Mais aucun de ceux que j’ai trouvés ne me convenait. J’ai donc écrit mon propre script.

Mes prompts

Version simple

J’ai commencé par une version simple, qui ajoute en couleur @nomdelabranche à la fin du prompt. Un exemple vaut mieux qu’un long discours :

rom@rom-laptop:~/dev$ cd myproject/
rom@rom-laptop:~/dev/myproject@master$ git checkout testing
Switched to branch 'testing'
rom@rom-laptop:~/dev/myproject@testing$ cd img
rom@rom-laptop:~/dev/myproject/img@testing$ 

Dans une arborescence ayant plusieurs projets GIT imbriqués (dans le cas de l’utilisation de sous-modules), la branche des projets parents n’est pas affichée :

rom@rom-laptop:~/dev$ cd mybigproject/
rom@rom-laptop:~/dev/mybigproject@master$ cd submodule/
rom@rom-laptop:~/dev/mybigproject/submodule@master$ git checkout exp
Switched to branch 'exp'
rom@rom-laptop:~/dev/mybigproject/submodule@exp$ cd ..
rom@rom-laptop:~/dev/mybigproject@master$

Version améliorée

Dans cette version simple, le nom de la branche est toujours affiché à la fin. Cela ne me convient pas, je le voudrais toujours à la racine du projet en question. C’est ce que permet la version améliorée.

Voici le résultat avec les mêmes commandes :

rom@rom-laptop:~/dev$ cd myproject/
rom@rom-laptop:~/dev/myproject@master$ git checkout testing
Switched to branch 'testing'
rom@rom-laptop:~/dev/myproject@testing$ cd img
rom@rom-laptop:~/dev/myproject@testing/img$ 

Et avec des sous-modules, la branche des projets parents est affichée :

rom@rom-laptop:~/dev$ cd mybigproject/
rom@rom-laptop:~/dev/mybigproject@master$ cd submodule/
rom@rom-laptop:~/dev/mybigproject@master/submodule@master$ git checkout exp
Switched to branch 'exp'
rom@rom-laptop:~/dev/mybigproject@master/submodule@exp$ cd ..
rom@rom-laptop:~/dev/mybigproject@master$ 

En image :

Script

Le script, sous licence WTFPL, est disponible sur un dépôt git :

git clone http://git.rom1v.com/gitbashprompt.git

(ou sur github)

Une fois cloné, éditez le fichier ~/.bashrc pour remplacer l’initialisation de la variable PS1 :

    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

par :

    . your_cloned_repo/gitbashprompt

Pour tester, ouvrir un nouveau terminal.

Conclusion

Tout d’abord, je suis content d’avoir exactement le comportement que je souhaitais pour mon GIT.

Ensuite, j’ai découvert le fonctionnement du prompt, avec notamment les subtilités d’échappement de caractères de la variable PS1 et la prise en compte des caractères de contrôle « \[ » et « \] ».

Enfin, je me suis enfin décidé à étudier la gestion des couleurs de Bash (qui, à première vue, est assez repoussante, il faut bien l’avouer). Mes scripts seront donc plus jolis à l’avenir

Je trouve que c’est utile dans certains cas ; par exemple, il vaut mieux utiliser un script de build automatique, que chacun pourra réutiliser, plutôt qu’un wizard sur un IDE particulier.

Installation

Avant tout, nous avons besoin du SDK Android :

wget http://dl.google.com/android/android-sdk_r17-linux.tgz
tar xf android-sdk_r17-linux.tgz
sudo mv /android-sdk-linux /opt

Sur un système 64 bits, ia32-libs est nécessaire (le SDK n’est disponible qu’en 32 bits) :

sudo apt-get install ia32-libs

Java et Ant doivent également être installés :

sudo apt-get install openjdk-6-jdk ant

Pour accéder facilement aux outils du SDK Android, il est préférable de rajouter leurs répertoires dans le PATH, en ajoutant la ligne suivante à la fin de ~/.bashrc :

PATH="$PATH:/opt/android-sdk-linux/tools:/opt/android-sdk-linux/platform-tools"

Configuration et téléchargement des packages

Ouvrir un nouveau terminal, et exécuter :

android

Une fenêtre s’ouvre, permettant d’installer de nouveaux packages.
Sélectionner « Available packages » et installer les « Tools » ainsi que les « SDK Platforms » pour les versions souhaitées, puis cliquer sur Install packages :

Il est aussi possible de créer un AVD (Android Virtual Device) à partir du menu Tools → Manage AVDs…. Dans la fenêtre qui s’ouvre, cliquer sur New…, puis configurer le téléphone et lui donner un nom :

Les AVD sont indifféremment configurables ici ou à partir d’Eclipse (au final, ils seront stockés dans ~/.android/avd).

Projet en ligne de commande

Pour créer un nouveau projet :

android create project \
-p path \
-t target \
-n name \
-k package \
-a activity

Par exemple :

android create project -p HelloWorld -t 1 -n HelloWorld -k com.rom1v.helloworld -a HelloWorld

Le projet généré est un hello world fonctionnel.

Pour connaître la liste des targets disponibles avec leurs ids :

$ android list targets
Available Android targets:
----------
id: 1 or "android-7"
     Name: Android 2.1
     Type: Platform
     API level: 7
     Revision: 3
     Skins: WVGA854, WQVGA432, QVGA, HVGA, WQVGA400, WVGA800 (default)
     ABIs : armeabi
----------
id: 2 or "android-13"
     Name: Android 3.2
     Type: Platform
     API level: 13
     Revision: 1
     Skins: WXGA (default)
     ABIs : armeabi
…

Pour modifier un projet existant :

android update project \
-p path \
-t target \
-n name

Par exemple, pour en changer la target (ici celle qui a pour id 2) :

android update project -p HelloWorld -t 2

Pour le compiler ou l’installer sur le téléphone, toutes les tâches Ant ont été générées (dans un fichier build.xml à la racine du projet). Voici les principales :

Android Ant Build. Available targets:
   help:      Displays this help.
   clean:     Removes output files created by other targets.
   compile:   Compiles project's .java files into .class files.
   debug:     Builds the application and signs it with a debug key.
   release:   Builds the application. The generated apk file must be
              signed before it is published.
   install:   Installs/reinstalls the debug package onto a running
              emulator or device.
              If the application was previously installed, the
              signatures must match.
   uninstall: Uninstalls the application from a running emulator or
              device.

Par exemple, pour générer un APK signé avec une clé de debug :

ant debug

Le fichier sera créé à l’emplacement bin/HelloWorld-debug.apk.

Eclipse ET la ligne de commande

Dans la majorité des cas, nous voulons que le projet soit utilisable à la fois dans Eclipse (pour développer) et en ligne de commande (pour automatiser la compilation, le déploiement…).

Manipuler un projet Eclipse en ligne de commande

Eclipse ne génère pas le script Ant lors de la création d’un projet Android. Heureusement, il est très simple de le générer manuellement :

android update project -t target -n nom_du_projet -p répertoire_du_projet

Importer dans Eclipse un projet créé en ligne de commande

Si vous avez créé un projet entièrement en ligne de commande et que vous décidez de l’importer par la suite dans Eclipse (parce qu’un IDE, c’est quand même bien pratique), c’est possible également.

Le projet restera dans le répertoire où il se trouve, donc si vous le voulez dans votre workspace Eclipse, déplacez-le maintenant.

Ensuite, il ne faut pas importer, mais créer un nouveau projet :
File → New → Android Project, sélectionner Create project from existing source et indiquer le chemin du projet dans Location.

Exécution

Un projet Android s’exécute soit sur un téléphone physique, soit sur un émulateur.

Émulateur

Pour démarrer un émulateur :

emulator -avd NomAVD

Par exemple :

emulator -avd MyPhone

Téléphone

Pour utiliser le téléphone branché en USB plutôt que l’émulateur, il est nécessaire d’activer l’option Paramètres → Applications → Développement → Débogage USB.

S’il n’est pas reconnu, c’est peut-être un problème de droits.
Dans ce cas, trouver le Vendor ID du matériel sur cette page puis créer un fichier /etc/udev/rules.d/51-android.rules (sauf sous Debian) contenant :

SUBSYSTEM=="usb", ATTR{idVendor}=="XXXX", MODE="0666", GROUP="plugdev"

(remplacez XXXX par le Vendor ID)

Alternativement, il est possible de donner les droits à n’importe quel matériel. Pour cela, il suffit de ne pas filtrer par Vendor ID, et d’écrire simplement :

SUBSYSTEM=="usb", MODE="0666", GROUP="plugdev"

Installation et désinstallation

Ant

Il suffit d’utiliser les tâches Ant install et uninstall :

ant install

Dans ce cas, un seul périphérique doit être présent dans la liste :

$ adb devices
List of devices attached 
emulator-5554	device

Adb

adb (Android Debug Bridge) permet de communiquer avec le téléphone ou l’émulateur.
Pour installer une application :

adb install fichier.apk

Si à la fois le téléphone et l’émulateur sont détectés, il faut choisir grâce à -d ou -e (respectivement) :

adb -e install fichier.apk

Pour désinstaller, il faut connaître le nom du package (celui défini dans AndroidManifest.xml).

adb uninstall le.package.de.lapplication

Astuce : Pour extraire le nom du package à partir d’un fichier.apk :

aapt d badging fichier.apk | grep ^package

Signature d’un APK

Pour signer une application, nous avons tout d’abord besoin d’un keystore. Pour en créer un :

keytool -genkey -v -keystore ~/.android/rom.keystore -alias rom -validity 10000

(Google recommande de choisir une validité de plus de 25 ans, d’où les 10000 jours dans la commande ci-dessus)

Pour permettre à Ant de signer, il suffit de lui indiquer la clé à utiliser dans ant.properties (à la racine du projet) :

key.store=/home/rom/.android/rom.keystore
key.alias=rom

Ainsi, il signera automatiquement (en demandant le mot de passe) lors de l’exécution de :

ant release

Signature différée

Il est également possible de générer un APK non signé (par Ant, qui génère un fichier monprojet-unsigned.apk), et de le signer manuellement plus tard :

jarsigner -verbose -keystore ~/.android/rom.keystore monprojet-unsigned.apk rom

Pour vérifier que la signature a bien fonctionné :

jarsigner -verbose -verify -certs monprojet-unsigned.apk

(si c’est le cas, le fichier monprojet-unsigned.apk peut être renommé en monprojet-unaligned.apk)

Il ne reste plus qu’à aligner le fichier final :

zipalign -v 4 monprojet-unaligned.apk monprojet.apk

Sources

Merci aux billets de Freelan et de DMathieu dont je me suis beaucoup inspiré, en plus de la documentation officielle (incontournable).

Posons comme principe que le partage d’œuvres sur Internet sans but de profit ne doit en aucune manière être restreint. Quelles justifications peuvent amener à le rejeter ?

Il n’y en a qu’une, elle est économique : permettre aux auteurs d’être rémunérés. Effectivement, une offre illimitée, accessible à tous (grâce au partage), et un coût marginal nul impliquent un prix nul. Il faudrait alors restaurer une certaine rareté afin de pouvoir vendre.

Mais par ailleurs, l’objectif de l’économie, c’est de surmonter au mieux la rareté. C’est là que la justification économique devient absurde : il s’agirait de restaurer une certaine rareté dans le but de résoudre un problème économique, alors que le but de l’économie est de résoudre les problèmes que pose la rareté. Ce serait lutter contre l’objectif afin de conserver ce contre quoi on lutte.

En clair, l’économie ne peut pas être une justification en soi, en dernier ressort, car elle ne s’applique qu’à la rareté. Tout ce qui est surabondant, non-rival, devrait être hors-marché. Sinon, il faudrait interdire le soleil.

Bien sûr, je ne dis pas qu’il faut supprimer l’économie ; je dis juste qu’elle ne s’applique qu’aux domaines de rareté. Dans le cas limite où tout serait surabondant, n’appliquer l’économie qu’aux domaines de la rareté conduirait effectivement à la suppression totale de l’économie. Dans ce monde imaginaire, ce serait très logique : si chacun pouvait tout avoir sans effort, pourquoi restreindre l’accès aux biens en le conditionnant à une « rémunération » qui n’aurait alors aucun sens ? Tout le monde y serait perdant.

Toute la difficulté est de vivre dans un monde composé à la fois de rareté et d’abondance. Et beaucoup tentent de restaurer la rareté partout uniquement pour faire fonctionner l’économie. Quel paradoxe !

Solutions

Ce billet a pour unique but de rejeter l’argument économique contre le partage sans but de profit, pas de conclure sur une solution définitive.

Selon moi, les solutions à envisager, quelles qu’elles soient, doivent respecter le principe que nous avons posé.

C’est le cas de la contribution créative (ou licence globale). Mais cette proposition amène quelques critiques (ici et là par exemple).

Pour ma part, vous le savez, je suis convaincu que le financement de la création est un cas particulier d’un problème plus général, dont (au moins une partie de) la solution est le dividende universel.

Billets en relation

• Piratage ou usage commun ?
• L’abondance contre l’économie.

J’ai enfin décidé d’héberger mon propre serveur Jabber, pour plusieurs raisons :

• la liste de mes contacts est mieux sur mon serveur que sur un autre ;
• le serveur que j’utilisais (jabber.fr) rencontre parfois quelques difficultés ;
• mon adresse Jabber sera ainsi la même que mon adresse mail (rom suivi de @rom1v.com).

Et c’est simple !

Installation et configuration

Tout d’abord, installer le paquet prosody :

apt-get install prosody

Puis ajouter à la fin du fichier /etc/prosody/prosody.cfg.lua :

Host "nom.de.domaine"

Pour moi :

Host "rom1v.com"

Créer un utilisateur en ligne de commandes et choisir un mot de passe :

prosodyctl adduser user@nom.de.domaine

Certificat

Un certificat TLS/SSL est créé par défaut, mais les champs sont renseignés avec des valeurs non pertinentes (localhost au lieu de nom.de.domaine par exemple). Il est donc préférable d’en générer un nouveau.

Dans le répertoire /etc/prosody/certs, exécuter :

openssl req -new -x509 -nodes -out nom.de.domaine.cert -keyout nom.de.domaine.key -days 1000

Renseigner les champs demandés (« . » pour laisser un champ vide).

Remplacer le certificat dans le fichier de configuration :

ssl = {
        key = "/etc/prosody/certs/nom.de.domaine.key";
        certificate = "/etc/prosody/certs/nom.de.domaine.cert";
}

Empreinte

Comme c’est un certificat auto-signé, les clients Jabber ne lui feront pas confiance : ils demanderont une confirmation, en présentant son empreinte. Il faudra alors vérifier que le certificat présenté est bien le bon, c’est-à-dire que l’empreinte est la même.

Pour la connaître :

openssl x509 -fingerprint -noout -in nom.de.domaine.cert

Par exemple :

$ openssl x509 -fingerprint -noout -in rom1v.com.cert
SHA1 Fingerprint=C3:6D:9B:65:06:55:C4:84:B4:A5:8D:4B:12:68:2F:08:71:7E:AC:DD

Ports

Les ports TCP 5222 et 5269 doivent être ouverts.

Démarrer

Il ne reste plus qu’à démarrer le service.

service prosody start

Clients

Il est maintenant possible de se connecter en utilisant le nom d’utilisateur et le mot de passe créés :

Backup

Les données du serveur sont stockées dans /var/lib/prosody. Il est donc important de ne pas oublier ce répertoire dans le processus de sauvegarde.

Merci à Cyrille Borne et nicolargo.