> Dans la pratique, de nombreux logiciels libres sont aussi, voire plus bogués que des logiciels propriétaires.
Super.
> Dans le monde du Libre, deux comportements sont fréquents parmi les développeurs :
Comme dit De Gaulle :
- "Dans la vie il y a deux catégorie. Ceux qui pensent qu'il y a deux catégories et les autres".
> Comme pour la documentation, on touche ici à une des limites du Logiciel Libre : les développeurs sont pour une grande majorité bénévoles, et ne veulent pas s'embêter avec tout ce qui n'est pas fun : documentation, tests, ...
Pour la documentation, c'est globalement vrai. Mais notes aussi que la documentation des logiciels proprios n'est pas toujours top non plus. De plus avec le logiciel proprio il manque une doc souvent indispensable :
- les sources
Certe on peut documenter exhausivement chaque fonctionnalité et chaqu'un de ses comportements en fonction de l'environnement, mais ça coûte très cher pour certains projets.
> Mais la plupart des logiciels libres ignorent totalement cette démarche, et se basent sur une démarche qualité incomplète
Le problème est qu'il n'y a AUCUNE bonne méthode. Linux (via OSDL) avait bosser sur la question et pour finir ... c'est toujours les tests "grandeurs natures" qui marche le mieux. C'est toujours les tests avec l'expertise de bons utilisateurs qui marchent le mieux.
> Ce bug très gênant de gconfd est un bon exemple : un bug dans un algorithme de gestion d'arbre présent depuis GNOME 2.0 (juin 2002), signalé fin septembre 2004, corrigé début février.
Cool, un bug. Avec une bonne requête bugzilla on doit pouvoir en remonter une centaine. C'est à croire que MS (le roi du proprio et de la communication sur les divers tests/méthodes qu'ils utilisent) corrige rapidement ses bugs. Tout le monde ici connais des bug dans les produits MS qu'ils ont mis des années a être corriger.
Combien a coûté la mauvaise qualité (donc test) en sécurité des produits MS ?
C'est absolument énorme. Aussi bien du côté des utilisateurs que du côté de MS.
J'ai bossé sur les unix proprio et ce n'est pas toujours rose. Entre autre le compilateur HPUX était bien buggué. Certain source pour des raisons que j'ignore totalement ne marchait bien qu'avec "-O0" et jamais avec "-O2". Pourquoi ? Aucune idée. Mais je n'ai jamais eu ce type de problème avec gcc.
> Et même si un développeur de Logiciels Libres voulait tester son code, avec quoi le ferait-il ?
C'est une phrase d'une grande naïveté.
Comment tu fais pour tester le noyau Linux ou gtk ?
Il y a des "trucs" qui supporte bien les tests et d'autres non. Linux est un enfer à tester systématiquement.
Faire des procédures pour Perl, python, etc est plus facile. Notons que ce sont souvent des tests de non-regression et que passer les tests ne signifie pas qu'il n'y a aucun bug. Ça marche uniquement si le bug est reproductible et celà s'appuis aussi sur un bon retour des utilisateurs.
> Du côté des langages de script, c'est un peu mieux
Normal, c'est plus facile.
> Alors que les logiciels propriétaires populaires deviennent de plus en plus robustes
Tu l'as dis. Prends les logiciels libres populaires et ils sont tout aussi robustes et parfois plus que les logiciels propriétaires.
> il est important d'augmenter la qualité des Logiciels Libres.
On ne peut pas être contre.
> Cela passe par l'utilisation massive de techniques ayant fait leurs preuves dans l'industrie, mais mal maîtrisées dans la communauté.
D'où tu sors cette conclusion ?
Le logiciel libre n'a pas de "déficite" de fiabilité par rapport au logiciel propriétaire. Le logiciel libre gagne sur le logiciel propriétaire et singer le logiciel propriétaire uniquement pour avancer la même pub que le propriétaire (test et "toussa") n'est pas à priori ce qu'il faut faire.
> On peut aussi se poser une question plus profonde : Alors qu'avec Perl, Python, Ruby et C#, nous avons des langages permettant de développer efficacement des applications de haut-niveau, pourquoi continuer à développer majoritairement en C/C++, avec lesquels il est nettement plus facile d'introduire des bugs ?
C'est un excellent troll.
Recodes mplayer ou gtk ou Xorg en perl et tu constateras qu'il faut un Pentium XIII à 800THz et 256To de mémoire vive.
Il y a beaucoup de code en C/C++ et dont le niveau de qualité est absolument remarquable. Regardes dans ta distribution préférée pour t'en convaincre.
Si on regarde le nombre de programme en scripts rapporté au nombre de leurs bugs, le score ne doit pas être aussi bon que pour le C/C++.
> Pourquoi ne pas limiter l'utilisation de ces langages aux librairies ?
Tu comprends ce que veut dire le mot "libre" ?
Tu ne sais pas qu'il y a beaucoup beaucoup plus de codes dans les librairies que dans les programmes ?
Si tu ne sais pas ça ...
> Qu'en pensez-vous ?
Comment dire honnètement le fond de ma pensée.
Cette article est une grosse m....
> Testez-vous vos applications ?
Oui.
> Avec quoi ?
Mon cerveau et ça marche assez bien.
Plus sérieusement, les tests ne sont qu'une toute petite partie d'un processus qualité global.
La conception du logiciel est souvent l'élément clef de la qualité.
Le qualité du codage, le soucis du développeur de "bien faire" est aussi extrèmement important.
Les tests c'est pour récupérer ce que les cerveaux des concepteurs et développeurs ont introduit.
Prends des concepteurs nuls et des développeurs nuls.
Tu auras beau blinder les tests, la qualité globale sera minable. Et si la qualité est formidable, le logiciel est nul.
On sait depuis _très_ longtemps qu'un bug découvert en phase de test coûte _très_ cher. Donc depuis bien longtemps, les bons chefs de projets mise à 90 % sur la conception et le développement.
C'est comme ça que le logiciel libre fait globalement. Voir par exemple Linus Torvalds qui est très "chiant" sur la qualité du code ou la conception d'une fonctionnalité. Il a entièrement raison.
Un bon code a peu de bug. Un bon code se debuggue facilement. Il y a toujours quelques exceptions pour confirmer la règle.
Le logiciel libre est "mauvais" quand il n'est pas assez soutenu (manque de testeurs ou développeurs, etc). Si tu veux bien payer des testeurs (car ils ne veulent pas bosser gratuitement) je t'invite vivement dans cette démarche.
Mais le logiciel libre est "bon" et même excellent quand le modèle du libre est pleinement appliqué :
- les meilleurs concepteurs/développeurs et motivés
- grosse base de testeurs qui remontent les bugs
J'ai rien contre les tests, les outils, etc.
Mais je préfère laisser la décision d'utiliser ces outils/méthodes a ceux qui ont l'expertise.
Personnellement, j'insiste sur la conception, le codage et le "soucis de la qualité" à chaque étage (et pas uniquement en phase de test). L'idéal est de "bétonner" en amont au maximum afin que les tests finaux soient le moins nécessaire possible.
QUESTIONS :
Pourquoi linuxfr laisse passer ce genre de troll en première page ?
Le troll il faut le "combattre" et ça bouffe du temps. Je m'en passerais bien.
# ???
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 8.
Super.
> Dans le monde du Libre, deux comportements sont fréquents parmi les développeurs :
Comme dit De Gaulle :
- "Dans la vie il y a deux catégorie. Ceux qui pensent qu'il y a deux catégories et les autres".
> Comme pour la documentation, on touche ici à une des limites du Logiciel Libre : les développeurs sont pour une grande majorité bénévoles, et ne veulent pas s'embêter avec tout ce qui n'est pas fun : documentation, tests, ...
Pour la documentation, c'est globalement vrai. Mais notes aussi que la documentation des logiciels proprios n'est pas toujours top non plus. De plus avec le logiciel proprio il manque une doc souvent indispensable :
- les sources
Certe on peut documenter exhausivement chaque fonctionnalité et chaqu'un de ses comportements en fonction de l'environnement, mais ça coûte très cher pour certains projets.
> Mais la plupart des logiciels libres ignorent totalement cette démarche, et se basent sur une démarche qualité incomplète
Le problème est qu'il n'y a AUCUNE bonne méthode. Linux (via OSDL) avait bosser sur la question et pour finir ... c'est toujours les tests "grandeurs natures" qui marche le mieux. C'est toujours les tests avec l'expertise de bons utilisateurs qui marchent le mieux.
> Ce bug très gênant de gconfd est un bon exemple : un bug dans un algorithme de gestion d'arbre présent depuis GNOME 2.0 (juin 2002), signalé fin septembre 2004, corrigé début février.
Cool, un bug. Avec une bonne requête bugzilla on doit pouvoir en remonter une centaine. C'est à croire que MS (le roi du proprio et de la communication sur les divers tests/méthodes qu'ils utilisent) corrige rapidement ses bugs. Tout le monde ici connais des bug dans les produits MS qu'ils ont mis des années a être corriger.
Combien a coûté la mauvaise qualité (donc test) en sécurité des produits MS ?
C'est absolument énorme. Aussi bien du côté des utilisateurs que du côté de MS.
J'ai bossé sur les unix proprio et ce n'est pas toujours rose. Entre autre le compilateur HPUX était bien buggué. Certain source pour des raisons que j'ignore totalement ne marchait bien qu'avec "-O0" et jamais avec "-O2". Pourquoi ? Aucune idée. Mais je n'ai jamais eu ce type de problème avec gcc.
> Et même si un développeur de Logiciels Libres voulait tester son code, avec quoi le ferait-il ?
C'est une phrase d'une grande naïveté.
Comment tu fais pour tester le noyau Linux ou gtk ?
Il y a des "trucs" qui supporte bien les tests et d'autres non. Linux est un enfer à tester systématiquement.
Faire des procédures pour Perl, python, etc est plus facile. Notons que ce sont souvent des tests de non-regression et que passer les tests ne signifie pas qu'il n'y a aucun bug. Ça marche uniquement si le bug est reproductible et celà s'appuis aussi sur un bon retour des utilisateurs.
> Du côté des langages de script, c'est un peu mieux
Normal, c'est plus facile.
> Alors que les logiciels propriétaires populaires deviennent de plus en plus robustes
Tu l'as dis. Prends les logiciels libres populaires et ils sont tout aussi robustes et parfois plus que les logiciels propriétaires.
> il est important d'augmenter la qualité des Logiciels Libres.
On ne peut pas être contre.
> Cela passe par l'utilisation massive de techniques ayant fait leurs preuves dans l'industrie, mais mal maîtrisées dans la communauté.
D'où tu sors cette conclusion ?
Le logiciel libre n'a pas de "déficite" de fiabilité par rapport au logiciel propriétaire. Le logiciel libre gagne sur le logiciel propriétaire et singer le logiciel propriétaire uniquement pour avancer la même pub que le propriétaire (test et "toussa") n'est pas à priori ce qu'il faut faire.
> On peut aussi se poser une question plus profonde : Alors qu'avec Perl, Python, Ruby et C#, nous avons des langages permettant de développer efficacement des applications de haut-niveau, pourquoi continuer à développer majoritairement en C/C++, avec lesquels il est nettement plus facile d'introduire des bugs ?
C'est un excellent troll.
Recodes mplayer ou gtk ou Xorg en perl et tu constateras qu'il faut un Pentium XIII à 800THz et 256To de mémoire vive.
Il y a beaucoup de code en C/C++ et dont le niveau de qualité est absolument remarquable. Regardes dans ta distribution préférée pour t'en convaincre.
Si on regarde le nombre de programme en scripts rapporté au nombre de leurs bugs, le score ne doit pas être aussi bon que pour le C/C++.
> Pourquoi ne pas limiter l'utilisation de ces langages aux librairies ?
Tu comprends ce que veut dire le mot "libre" ?
Tu ne sais pas qu'il y a beaucoup beaucoup plus de codes dans les librairies que dans les programmes ?
Si tu ne sais pas ça ...
> Qu'en pensez-vous ?
Comment dire honnètement le fond de ma pensée.
Cette article est une grosse m....
> Testez-vous vos applications ?
Oui.
> Avec quoi ?
Mon cerveau et ça marche assez bien.
Plus sérieusement, les tests ne sont qu'une toute petite partie d'un processus qualité global.
La conception du logiciel est souvent l'élément clef de la qualité.
Le qualité du codage, le soucis du développeur de "bien faire" est aussi extrèmement important.
Les tests c'est pour récupérer ce que les cerveaux des concepteurs et développeurs ont introduit.
Prends des concepteurs nuls et des développeurs nuls.
Tu auras beau blinder les tests, la qualité globale sera minable. Et si la qualité est formidable, le logiciel est nul.
On sait depuis _très_ longtemps qu'un bug découvert en phase de test coûte _très_ cher. Donc depuis bien longtemps, les bons chefs de projets mise à 90 % sur la conception et le développement.
C'est comme ça que le logiciel libre fait globalement. Voir par exemple Linus Torvalds qui est très "chiant" sur la qualité du code ou la conception d'une fonctionnalité. Il a entièrement raison.
Un bon code a peu de bug. Un bon code se debuggue facilement. Il y a toujours quelques exceptions pour confirmer la règle.
Le logiciel libre est "mauvais" quand il n'est pas assez soutenu (manque de testeurs ou développeurs, etc). Si tu veux bien payer des testeurs (car ils ne veulent pas bosser gratuitement) je t'invite vivement dans cette démarche.
Mais le logiciel libre est "bon" et même excellent quand le modèle du libre est pleinement appliqué :
- les meilleurs concepteurs/développeurs et motivés
- grosse base de testeurs qui remontent les bugs
J'ai rien contre les tests, les outils, etc.
Mais je préfère laisser la décision d'utiliser ces outils/méthodes a ceux qui ont l'expertise.
Personnellement, j'insiste sur la conception, le codage et le "soucis de la qualité" à chaque étage (et pas uniquement en phase de test). L'idéal est de "bétonner" en amont au maximum afin que les tests finaux soient le moins nécessaire possible.
QUESTIONS :
Pourquoi linuxfr laisse passer ce genre de troll en première page ?
Le troll il faut le "combattre" et ça bouffe du temps. Je m'en passerais bien.