Bon, c'est moi qui ai posté la news. Je vais répondre en bloc à pas mal de remarques vues dans les commentaires. Mais d'abord, le but de la news est de faire prendre conscience que tout n'est pas parfait au royaume du libre. Et les commentaires ne m'ont pas fait changer d'avis.
Exemples donnés : Mozilla, GCC
Oui, à mon avis, Mozilla est peut-être un peu moins buggé que IE. Oui, il y a des logiciels libres qui sont très fiables (j'en cite d'ailleurs dans la news). Souvent, ils sont testés correctement (cf Gcc). Mais la très grande majorité des LL ne sont pas d'une fiabilité irréprochable (loin de là)
Java
Pour Java, c'est vrai que j'ai oublié de le citer (mea culpa). Mais l'utilisation de Java dans la communauté (pour produire des logiciels libres) reste assez anecdotique.
Outils de test pour C/C++
Après, j'ai eu droit à une liste exhaustive de moyens de tester du C, du C++. Oui, bien sûr, ca existe. Mais le problème, c'est que leur existence ne suffit pas à rendre tous les pgmes C/C++ moins buggés d'un seul coup. Il faut les utiliser. Et y a pas grand monde qui le fait.
Le bug de gconfd
L'exemple du bug de gconfd était intéressant car il s'agissait d'un bug enfoui très loin dans le code. C'est le genre de bugs très difficile à faire remonter par un utilisateur, car il peut être rencontré de manières très différentes et pas forcément fréquentes. De plus, c'est typiquement le genre de bugs qui est facile à détecter avec des tests.
"Certains logiciels propriétaires sont buggés eux aussi"
Ca, c'est le raisonnement le pire. "On fait du code pourri, mais c'est pas grave, les autres aussi !" Dans la dépeche, je disais "Logiciels propriétaires populaires", pas "Tous les softs proprios". Tout ce que je veux dire, c'est que les softs propriétaires ont fait (pour beaucoup) de gros efforts côté qualité ces derniers temps, et que l'argument des logiciels libres plus fiables ne tient plus vraiment. La qualité des LL et des LP devient (à la louche) égale. Et pour que les LL reprennent la tête, il faudrait que beaucoup de développeurs acceptent de voir leur code d'une manière un peu moins biaisée, et se rendent compte qu'il contient des bugs et que le tester peut améliorer les choses.
# Droit de réponse
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 9.
Exemples donnés : Mozilla, GCC
Oui, à mon avis, Mozilla est peut-être un peu moins buggé que IE. Oui, il y a des logiciels libres qui sont très fiables (j'en cite d'ailleurs dans la news). Souvent, ils sont testés correctement (cf Gcc). Mais la très grande majorité des LL ne sont pas d'une fiabilité irréprochable (loin de là)
Java
Pour Java, c'est vrai que j'ai oublié de le citer (mea culpa). Mais l'utilisation de Java dans la communauté (pour produire des logiciels libres) reste assez anecdotique.
Outils de test pour C/C++
Après, j'ai eu droit à une liste exhaustive de moyens de tester du C, du C++. Oui, bien sûr, ca existe. Mais le problème, c'est que leur existence ne suffit pas à rendre tous les pgmes C/C++ moins buggés d'un seul coup. Il faut les utiliser. Et y a pas grand monde qui le fait.
Le bug de gconfd
L'exemple du bug de gconfd était intéressant car il s'agissait d'un bug enfoui très loin dans le code. C'est le genre de bugs très difficile à faire remonter par un utilisateur, car il peut être rencontré de manières très différentes et pas forcément fréquentes. De plus, c'est typiquement le genre de bugs qui est facile à détecter avec des tests.
"Certains logiciels propriétaires sont buggés eux aussi"
Ca, c'est le raisonnement le pire. "On fait du code pourri, mais c'est pas grave, les autres aussi !" Dans la dépeche, je disais "Logiciels propriétaires populaires", pas "Tous les softs proprios". Tout ce que je veux dire, c'est que les softs propriétaires ont fait (pour beaucoup) de gros efforts côté qualité ces derniers temps, et que l'argument des logiciels libres plus fiables ne tient plus vraiment. La qualité des LL et des LP devient (à la louche) égale. Et pour que les LL reprennent la tête, il faudrait que beaucoup de développeurs acceptent de voir leur code d'une manière un peu moins biaisée, et se rendent compte qu'il contient des bugs et que le tester peut améliorer les choses.