Comments on Il faudrait faire une analyse statistique des bugs dans Linux

Il me semble avoir justement entendu parler de ce genre de choses. Le problème est que je ne me rappelle pas par qui, seulement que j'allais prendre le métro pour aller à l'EPFL et que le type était d'une fac américaine style Iowa. Donc il faut que je ressorte mes déplacements à Lausanne, voir qui était invité en même temps, etc. ;-)

> pour ma part, je serais certainement intéressé par un projet comme celui que je décris ci-dessus, mais pas au point de passer le temps délirant en écriture de rapports en tout genre qu'il faut soumettre pour obtenir quoi que ce soit de qui que ce soit.

Est-ce que tu n'exagères pas un peu la situation ? le temps passé à écrire un tel rapport ne serait pas perdu puisqu'il inclurait un premier travail de recherche. Et même sans financement particulier, j'imagine que ça doit être possible pour toi de poursuivre cette idée, éventuellement aidé d'un collègue ou d'un étudiant.

Soit
k1 le nombre moyen de bugs par nouvelle ligne de code,
k2 la probabilité qu'un bug soit corrigé par unité de temps
nl(t) le nombre de lignes de code à t,
a(t) le nombre de lignes supprimées par unité de temps hors correction de bug,
b(t) le nombre de lignes ajoutées par unité de temps hors correction de bug,
c(t) le nombre de bugs corrigés par unité de temps,
nb(t) le nombre de bugs à t.

On suppose pour simplifier que la correction de bugs est à nombre de lignes constant, et que la probabilité de correction d'un bug k2 est constante.
K1 et k2 sont les paramètres du modèle, nb(t) est ce qu'on souhaite estimer. Les autres fonctions nl, a, b et c sont postulées mesurables

On a :
c(t) = k2nb(t)
dnb(t)/dt = k1b(t) - a(t)nb(t)/nl(t) - c(t)

Alors en inectant (1) dans (2) :
dc(t)/dt = k1k2b(t) - a(t)c(t)/nl(t) - c(t)k2
Les données devraient permettre d'estimer k1 et k2 et de confirmer le modèle.

Les institutions rechignent à financer (voire interdisent) les recherches sur ce qui ne devrait dans l'idéal pas exister ou qu'on ne voudrait pas reconnaître. Ex: le plagiat universitaire (surtout en «sciences humaines»).

N'empêche, ce serait chouette: on installerait un système version N+2^(-B)
où B est le nombre de bugs estimé, un moyen simple, enfin, pour numéroter les versions continûment. Après le MTBF du disque dur, le système donnerait son MTBGPF…

Mais, bon, si on peut évaluer le nombre de bug précisément, on peut aussi en profiter pour signaler la probabilité de bug au programmeur? Un grand nombre de bugs n'ont rien de subtil et relèvent de la faute de frappe ou d'étourderie, et seraient aisément détectables. Le problème est l'utilisation d'outils standard comme YACC qui sont aveugles sur tout ce qui ne sert pas leur algorithme ; une erreur d'accolade ne sera détectée que 200 lignes plus loin en dépit des incohérences manifestes des tabulations. Et s'il y a une autre erreur d'accolade, inverse, ce sera un bug.

Au-delà du typage qui apporte un test de cohérence minimale (en principe ; un typage impuissant signale des faux positifs/erronés), aucun langage ne semble permettre de définir systématiquement des conditions de cohérence plus restrictives. Par exemple, il serait intéressant, dans les applications techniques, de surtyper suivant l'analyse dimensionnelle.