> Je ne comprends pas pourquoi il n'en irait pas de meme de mes pairs developpeur.
Une critique avec des arguments d'accord. Mais là il n'y a rien ou presque. Il y a quelques personnes qui se plaignent de quelques bugs sur des applis mineurs et un bug dans gconf. C'est maigre.
Imaginons que tu développes pour KDE.
Imagines que je fasse une news avec :
1- KDE n'est pas aussi fiable qu'on le dit.
2- Gnome fait mieux.
3- KDE devrait avoir une démarche qualité éprouvée comme Gnome.
4- KDE ne devrait pas seulement compter que les utilisateurs pour faire les tests sinon KDE va avoir un retard insurmontable sur Gnome.
6- dejagnu
7- et définition de "test unitaire" pour les abrutis
Évidement tout ça sans le moindre argument si ce n'est une "impression générale".
Si t'apprécie ce genre de truc, très bien.
Moi pas.
> si on pouvait deboguer directement du code optimise sur les distrib majeurs
On peut déjà. Fedora le fournissait mais ça bouffe trop de place (un gros problème pour les mirroirs).
Suffit de recompiler le paquet et tu obtient un toto-debuginfo-*.rpm.
Tu l'installes puis :
$ gdb /usr/bin/toto
> - confondent tests unitaires et leurs pratiques de bricoleurs (#ifndef, tester les valeurs en entrée de fonction, tester l'application dans leur coin, ...)
Développer, coder n'est pas du bricolage. Un "#ifdef" n'est pas du bricolage. Il a un fonction très précise. Un "p++" n'est pas du bricolage. C'est du code ! C'est du bricolage si c'est du code mal foutu. Coder demande beaucoup de réflexion. Quand on développe, on ne pense pas seulement à "pisser du code". On se demande si ça va marcher ! C'est l'objectif non ? Quand on développe (et surtout dans le libre) on n'a pas avis d'avoir des utilisateurs sur le dos qui se plaignent de bugs.
On n'attent pas les test du département QA pour prendre en compte la qualité. Dans la majorité des projets libres, le développeur c'est aussi le département QA.
Toi tu penses que le codeur n'apporte aucune valeur à la qualité et que tout ce qui compte c'est ces "foutus" test.
Regardes Linux, la qualité est assuré à 90 % par les développeurs et pas par des tests unitaire ou autres trucs funants.
J'espère que tu apprécies leur "bricolage".
> Quand on critique MS qui prend ses utilisateurs pour des testeurs tout le monde trouve ça normal, mais quand c'est pour un logiciel libre, tout le monde dit : "envoie un rapport de bug et un patch si possible"...
Tu mélanges tout. Le logiciel libre est gratuit. Pour MS, ce que n'aiment pas les gens, c'est payer pour être testeur (et sans avoir la possibilité de fouiller les sources et avoir la satisfaction de fixer un bug).
Tu comprends la nuance ?
Le libre c'est libre et personne te demande de faire des rapports bugs. On te le conseille, on t'y invite, mais tu n'a pas d'obligation.
Je vois un truc "marrant". Les "fans" des tests unitaires, qui semblent nombreux, font rarement du logiciel libre sinon il y aurait plus de tests unitaires dans le logiciel libre.
> Si t'as une phase de test qui vient plusieurs annees apres la phase de developpement, c'est du suicide.
Mais ça arrive. Je l'ai vécu et ce n'est pas du suicide.
Puis les tests unitaires quand t'as 300 paramètres d'exécutions et tu dépends d'un automate qui t'envois 200 autres paramètres,etc c'est impossible à réaliser. Au mieux tu couvres quelques cas d'utilisations en lancant des tests qui représentent des utilisations "typiques". Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
> Donc on peut reformuler ta phrase "dans le cas ou un projet ne respecte aucune methodologie qualite et fait des tests 3 ans apres le dev, on sait depuis tres longtemp qu'un bug decouvert en phase de test coute tres cher".
Dans certain cas tu n'as pas le choix. Une équipe développe l'applis, une autre bosse sur un automate qui va utiliser des appareils à plusieurs millions d'euro qui sera disponible que lorsque les développements sont terminés.
Certe tu peux toujours faire des tests unitaires etc. Mais je ne me vois pas demander au boss d'avoir 6 mois de plus pour faire des tests unitaires exautifs sans que ça apporte un réel intérêt.
Dans ces cas, il faut s'appuier sur une bonne architecture. Il faut alors que les éléments critiques soient simples. Ainsi tu peux "blinder" les tests unitaires et faire des tests exautifs sur les éléments critiques.
J'utilise les tests unitaires. Mais les tests unitaire systématique et pour tout c'est l'enfer.
"Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Je te donne une mission :
- Faire un (ou des) test unitaire complet pour gecko
Combien de temps il te faut ?
Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire de l'audit de code n'est pas un meilleur investissement.
> Donc il faut tester tres tot et plutot que de sortir une anerie pour decredibiliser les tests (les bugs decouverts en phase de test coutent cher)
Tu le fais exprès ?
Si je fais un module et que je le teste dans la semaine il n'y effectivement pas de problème pour corriger les bugs. Mais parfois un module développé n'est utilisé que bien des mois après.
Si les tests ont été exautifs (impossible sauf pour des trucs simples) il n'y a effectivement pas de problème. Mais suppose que les formats d'entrés aient légèrement changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Ça arrive car les tests peuvent être erronés ou incomplet, car il y a eu un manque communication lors de l'évolution d'un module, etc.
C'est _courrant_.
Toi t'es dans le rève ou il n'y a pas d'erreurs de conception, il n'y a pas de manque de communication, le projet est parfaitement géré, les tests sont tous exautifs et parfait, les spécifications sont complètes et n'ont raté aucuns scénarios, etc.
Voilà pour ton rève.
Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Dans la "vraie vie" ça ne se passe pas comme ça.
> je pense que tu devrais integrer cette notion de tester le plus tot possible dans une demarche de qualite globale
T'es gentil.
Mais je vais te montrer un cas "spécial" et qui va te montrer que je ne suis pas contre les tests unitaires lorsque ça a un sens.
J'avais un projet sur 8 mois et ça me semblait impossible à tenir (je n'étais pas le seul à le penser). Heureusement tous les données étaient disponibles (ficher de test, moyen pour les générer, etc).
J'ai fait la conception du programme sur papier.
J'ai réalisé les procedures de tests exautives (car c'était possible et ça permettait aussi de faire le recette auprès du client).
J'ai fait validé les procédures de tests par le client.
J'ai réalisé les fichiers .h.
J'ai fait audité la conception et les fichiers .h.
J'ai "pissé" du code durant 6 mois sans rien compiler/exécuter ! Le code était blindé d'assert.
J'était en retard sur le planning car les 8 mois était écoulé. J'ai compilé, corrigé les tonnes d'erreur de syntaxe, etc qui restait.
J'ai exécuté. Corrigé les cas où le programme plantait sur les asserts.
J'ai passé les tests exautifs, corrigé les bugs. L'applis a été recetté par le client. Retard : 15 jours. Le client ne s'est jamais plaint d'un bug. Tous les tests ont été réalisés à la *fin* car pour *ce* projet c'était une bonne méthode.
Il n'y a pas de démarche qualité universel et il faut bien faire avec les ressources disponibles.
> On ne peut pas dire : "le libre c'est super stable et de super bonne qualité" et deux lignes plus loin : "parce que tous les utilisateurs testent".
On ne peut pas dire que le LL est mal testé ou n'a pas assez de démarche qualité en disant seulement que les tests unitaires c'est bien(tm).
Lorsqu'on critique le logiciel libre dans un domaine où il a bonne réputation, il faut des arguments.
> - dans le libre certains projets phare sont de mauvaise qualités et ça craint
Exemple ?
Nautilus ?
> - dans le libre, en tant qu'utilisateur, il faut lire les changelog et autres README pour mesure éventuellemetn la qualité de la version qu'on s'apprête à installer, pour être sûr que ce n'est pas une version de test, une RC, et au final on peut faire des boulettes pas drôle, et c'est un peu le bordel
C'est le LIBRE. Prends une distribution "entreprise" et ne te pose pas de question.
C'est dingue ça, les gens "gueules" car lorsqu'il récupérère le premier logiciel venu sur le net (gentiment contributé, gratuit, etc) il n'est pas à leur gout et il pense que ça leur donne le droit de critiquer le libre dans son ensemble.
> OK, ils sont bien codés puisque tu le dis, mais ça veut dire quoi?
Les sources sont dispos, alors fait un petit effort.
> Ils sont bogués comme tous les softs, sauf que les bugs de ces deux là sont des nids à pirates. Moi j'en étais venu à considérer sendmail et bind comme dangereux (et pénibles).
C'est marrant car les histoires où un serveur sendmail ou bind ont été cracké sont rares. Très rare alors qu'ils sont très utilisés et depuis très longtemps.
> Je ne sais pas ou tu as vu qu'un bug decouvert en phase de test coutait cher, mais c'est n'importe quoi.
En phase de test ça coute cher car la phase de test (je ne parle pas de test unitaire) peut venir bien après la phase de développement. Donc le développeur il ne sait plus exactement ce qu'il a fait et si c'est un projet sur plusieurs mois/années il est même possible que le développeur qui a fait une code/module coupable ne soit plus disponible.
> Une erreur de conception en revanche, ca coute tres cher, je suis d'accord.
Idem pour un bug. Mais pour un bug c'est moins cher.
Pour les bugs "=" à la place de "==" c'est vraiment "petit". Il y a des bugs où il faut réécrire plusieurs centaines de lignes de code même si la conception est parfaite.
> On ne parle pas non plus des mêmes tests. Tu parles des tests par des utilisateurs finaux, je parle des tests unitaires ou d'intégration.
J'ai donné un exemple de démarche qualité. Exemple tiré sur les distributions.
J'ai donné un réponse à ta question :
- pourquoi il y a plus de tests par les utilisateurs/testeurs dans le LL que dans le LP
J'ai indiqué que les démarches qualités varient beaucoup entre projet.
Par exemple subversion utilise massivement les test de non regression. PostgreSQL aussi. Par contre dans la bureautique ce n'est pas ou peut utilisé.
Ailleur, j'ai mis un lien sur les tests automatisés mis en place par OSDL et indiqué que les développeurs Linux n'y sont pas très attachés. Que Linux préfère l'audit et un code bien fait.
> Bref, mon pauvre, t'es complètement à coté de la plaque.
Toi, t'as toujours rien donnée comme info. Il y a un vague lien sur dejagnu et "impression général".
C'est maigre pour une news.
Désolé d'essayer de tenter de t'expliquer pourquoi le logiciel libre a une bonne qualité même pour des projets qui ne te satisfont pas intellectuellement dans leur démarche qualité.
> Plutot que de poster 20 commentaires pour dire la même chose
Fais déjà un commentaire avec un contenu intéressant dedans avant de critiquer mes 20 commentaires qui sont là pour compenser une news de merde.
Il y a Andrew et Linux qui c'étaient exprimés sur ça dans une interview que j'ai perdu. En gros, ils ne sont pas contre mais ce n'est pas le coeur de leur démarche qualité.
Linus insiste toujours sur le code. Par exemple il n'est pas emballé par les débuggueur.
> Maintenant, 99% des logiciels libres sont encore bancals, mal codés, bourrés de bugs divers et variés.
Tu mélanges tous. T'as quoi comme programme "bancal" ?
Des bricoles ici et là. Ce n'est vraiment pas représentatif du libre.
De plus, et ça a déjà été dit, le libre donne aussi la liberté de faire des merdes faitent par de mauvais développeurs. T'es pas obligés de "faire les poubelles".
> des démineurs, des calculatrices, des petits outils, des jeux, etc.
Ça c'est claire que globalement les développeurs s'en foutent un peu.
> Par contre, dire qu'en moyenne les LL sont fiables, c'est quand même gonflé.
Ce n'est pas gonflé. Les jeux en logiciel libre, c'est rien ou presque. Faire des conclusion sur la fiabilité du libre en ne considérant que les jeux est ridicule. Regardes le "poid" que fait les jeux dans une distribution "normal" (évites debian pour les stats ils accèptent de tout :-) ; ce qui est normal compte-tenu de sa "philosophie"), c'est ridicule par rapport à tout le reste qui marche bien.
Exemple pour FC3 :
[root@one tmp]# rpm -q --queryformat "%{GROUP} %{NAME} %{SIZE}\n" --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ -a | sort | uniq | grep -i game
Amusements/Games bzflag 5638217
Développement/Bibliothèques kdegames-devel 423773
Divertissements/Jeux gnome-games 18501643
Divertissements/Jeux kdegames 16085867
Moins de 1 % par rapport à l'ensemble.
> Bref, tant que le système n'est pas plus au point, seulement quelques % des milliers de bugs existants pourront être correctement reportés et corrigés.
Je pratique aussi les tests unitaires mais il n'en demeure pas moins que je trouve c'est news <bip> (pour ne facher personne).
Faire une news :
- le libre devrait faire ci ou ça
est naze (surtout avec aussi peu d'argument). Le libre est libre. T'es libre de faire des tests unitaires et je le suis aussi et je ne m'en prive pas.
S'il avait fait un article sur les avantages du test unitaire ou de la méthodologie "bidule" et la conseillait aux développeurs libres ce serait beaucoup plus "accèptable". Mais là on apprend rien.
Pour revenir au test unitaire, il y a différente catégorie de test unitaire. Lorsque je fais une fonction par exemple, je fais un test unitaire assez exhautif avec gdb ou autre.
Mais je mets plus rarement en place un test unitaire automatisé pour un module.
À ça, une bonne raison :
- c'est parfois le bordel à réaliser et si on a pris soin dans les unitaires lors du développement, les choses se passent bien.
Je suis un "accros" des :
#ifdef DEBUG
assert (....)
#endif
Je teste ainsi pratiquement toutes les entrées de fonction. Si la fonction a été bien testé durant le développement, c'est une aide plus que précieuse.
Fichtre ça mérite une première page. T'es une vedette, une star ? :-)
> Quand je parle de retard, je parlais de retard dans la DEMARCHE qualité, pas dans la QUALITE.
Car tu ne connais pas la démarche qualité. Car il n'y a pas un page de pub pour te la décrire.
Voilà un explication :
* les logiciels upstream : on trouve de tous et dans tous les états. C'est normal, c'est le libre, on ne cache rien. Ici il y a des tests en tout genre. Test unitaire, test de régression, branche de développement et branche stable, retour utilisateurs, etc. C'est très variable. Il y a aussi le "test suprême", c'est la communauté qui décide quand une applis est stable (mérite un 1.0). Ce n'est pas un planning ou l'équipe marketing qui fait pression.
* les betas des distributions : on ne trouve pas de tous mais ce qui reste est dans des états variables. C'est un lieux parfais pour les testeurs (surtout pour les gros trucs style gnome ou KDE). Prends Fedora ou Gentoo, la branche de développement ou les betas utilisent souvent des versions de développement. Chaque bug/correction sera remonté en upstream. Beaucoup de développeurs du libre bossent aussi sur une distribution et sont donc particulièrement à l'écoute des remontées des testeurs. C'est aussi ici qu'un distributeur peut décider de virer une fonctionnalité car elle est insatisfesante. Ça arrive assez souvent.
* les distributions "bleeding-edge" : là on a un état moins "bizarre". Il peut rester des bugs et ça peut être insatisfesant en entreprise. Il y a encore plus de remontée de bugs pour traquer les cas rares.
* les distributions "enterprise" : en général basée sur une distribution "bleeding-edge" (donc déjà massivement testé). Certaines distributions sont aussi testé par des acteurs commerciaux (Dell, Ibm, Oracle, etc) durant la phase beta.
Exemple :
- Après des tests sommaires dans Rawhide, FC3 test1 sort le 13 juillet 2004.
- Après de nombreux tests, FC3 sort le 8 novembre (plus de 3 mois et demi de test et correction de bug preque exclusivement).
À la sortie de FC3, il n'y a plus grand chose à faire, il faut "attendre" les retours d'expérience (comme le logiciel proprio fait).
En parallèle à FC3, la RHEL 4 est en préparation. Elle profite des corrections de FC3 en phase beta et finale. Elle profite aussi de test auprès d'autres sociétés qui "valident" le produit.
- Courant fevrier ou mars 2005, RHEL 4 sort.
Soit 7 mois (!) après la première mise à disposition. Et ceci est "plannifier". Ça fait parti d'une démarche qualité. Plus "fort". RHEL 4 va avoir SeLinux par défaut. C'est passé par :
- FC2 avec SeLinux désactivé par défaut
- FC3 avec SeLinux activé par défaut
Un an de test pour SeLinux.
Voilà un exemple de démarche qualité pour une distribution.
Pourquoi ce "bordel" marche. Simple : la communauté *aime* ça !
Elle aime jouer avec les dernières versions. Elle aime voir si la dernière version lui fait un joli "kernel panic". Elle aime donner un coup de main en corrigeant un bug, etc.
Pourquoi s'en priver ?
Tu planques à la communauté un soft en phase beta et elle se fache. Donc c'est très naturellement que le logiciel libre s'appuis plus sur les testeurs que le logiciel proprio. De même, c'est très naturellement que les distributeurs proposent des distributions gratuites ou accessible à un coût modique.
> Tu devrais savoir qu'ici, il est interdit de dire du mal du LL , c'est comme ça.
Il y a critique et critique.
Si je critique le propriétaire car il n'y a pas les sources, c'est une critique nulle.
De plus Lucas ne donne pas d'argument. Le libre fait parmis les logiciels les plus fiables et Lucas critique sans avancer de réel argument à part de trucs qu'on trouve dans des discours marketeux bien rodés.
J'ai critiqué le logiciel libre dans ce thread. Je dis par exemple qu'au niveau bureautique le libre n'a jamais eu d'avance sur MS et que le libre en est encore au stade ou la principale préoccupation est de rattraper le retard (ce qui ne veut pas dire copier :-)).
Les critiques sont admises lorsqu'elles ont du sens.
On ne sait toujours pas sur quoi concrêtement tu te base.
> Le test par des utilisateurs-testeurs est une démarche qualité incomplète.
j'aimerais savoir depuis combien de temps tu utilises le libre. Car parfois on a l'impression que tu es un "petit nouveau".
Si tu ne veux pas être testeur, utilise une distribution qui répond à ce besoin.
Si tu veux donner un coup de main au libre et que tu as du temps pour faire des tests, alors fait des tests et remontes des bugs. Tu peux aussi rédiger des tests de non régression, personne n'est contre et ta contribution sera apprécié. Il n'y a pas que les tests pas les utilisateurs qui sont pris en compte.
Dans libre il y a libre. Les testeurs, les développeurs, les concepteurs etc sont libres de participer.
Regardes du côté de Windows qui sort des versions beta et Sun avec Solaris qui fait de même.
Pourquoi ils le font à ton avis alors que selon toi ils bétonnent en test unitaire et autres trucs fumants ?
Pourquoi tu ne veux pas que le libre fasse de même ?
De nombreux projets ont eu un "coup de fouet" en adoptant le model du "bazard" et en abandonnant la méthode de la cathédrale qui fait si bon effet dans les discours marketing.
> Beaucoup d'éditeurs de LP l'ont compris
Ce n'est pas récent. Ça remonte pratiquement au début de l'informatique. Apparament t'as jamais utilisé Unix.
> donc la communauté du Libre prend du retard qui ne sera pas évident à rattraper.
Quel retard ? En fiabilité/qualité et pour les serveurs, le libre est OK.
Pour la bureautique, le libre n'a plus qu'un concurrent : MS.
Actuellement le but est de rattraper le retard en fonctionnalité car le libre n'a jamais eu d'avance sur MS dans ce domaine. Après ce retard rattrapé, on verra pour le reste.
Le "truc" que je ne comprend pas (et sûrement d'autres) est sur quoi tu bases ton raisonnement.
Dire "le proprio fait aussi des logiciels fiables" est très maigre comme argument. Actuellement (et depuis longtemps) et terme de fiabilité/qualité il n'y a que Unix qui arrive au niveau de Linux (et vice versa). Ce n'est pas nouveau, surtout lorsqu'on regarde du côté d'Unix, que le logiciel propriétaire peut faire du faible.
Windows commence à arriver au niveau de Unix/Linux. Et encore, côté qualité dans le domaine de la sécurité il reste encore du boulot.
Tu parles des applis propriétaires "populaires" qui sont fiables. Mais les applis "populaires" du logiciel libre sont fiables aussi. C'est indiscutable.
Si tu bases ton raisonnement sur la partie bureautique, il faut avoir en tête un élément important :
1- Le libre n'est pas "populaire" pour la bureautique.
Le libre fait son introduction petit à petit dans la bureautique (via firefox, OpenOffice, etc).
Le libre n'est pas au stade ou il peut prendre significativement en compte la fiabilité pour la partie bureautique (sauf pour les navigateurs web, les clients mails, etc).
Pour la partie bureautique, la "mission" principale est de faire évoluer vite. Actuellement la cible est le geek plus que les entreprises. Quand il y aura une solide base d'utilisateur bureautique alors un effort significatif sera mis en fiabilisation/qualité. L'utilisation bureautique du libre est encore marginale.
Regardes Mozilla/Firefox. Avant Mozilla n'était pas toujours au top côté fiabilité. Maintenant que Firefox est très populaire, la qualité est un enjeux majeur et il est pris en compte plus que sérieusement.
Si t'as gedit qui t'exploise à gueule une fois tous les semaines, les développeurs Gnome regarderons ça en fonction des disponibilités. Par contre avec vim, la base d'utilisateur étant importante, si tu remontes un bug il sera corrigé assez vite. Pour la partie bureautique il y a encore plein de chantier et il faut "profiter" du relativement faible taux d'utilisation pour faire évoluer vite avec les ressources disponibles (qui n'ont rien à voir avec la puissance de feu de MS). Si Gnome ou KDE change de version tout les 6 mois, ce n'est pas pour rien. Mais il est claire que lorsque la base d'utilisateur sera aussi importante que dans le domaine des serveurs le rythme va se calmer et la qualité fera parti des enjeux prioritaires.
Certe, on peut demander toujours plus. Plus fiable, plus de fonctionnalité, plus "budile".
Mais ça ne mène à rien et c'est ignorer le fonctionnement du libre qui fait en fonction des ressources (bonnes âmes) disponibles.
Si t'as downloadé la dernière version de "bidule" et que ça plante, c'est presque "normal". Pas de quoi faire un scandale. Compares Mandrake CS, ou SuSE Enterprise, ou RHEL etc à des OS propriétaire et pas en utilisant le derner coincoin à la mode fraichement downloadé.
Apparament t'as été déçu avec quelques logiciels. Mais lesquels ?
Des logiciels ou la qualité est un enjeux majeur ou avec gedit ?
Pour ton débat "C/C++ c'est mal, ça fait des bugs", c'est totalement nul et c'est le réveil d'un troll qu'on a trop vu. Il y a des programmes en perl ou python qui ne sont pas formidables et il y en a même beaucoup. Fais les rapports suivant :
- programmes/librairies en language au niveau qui sux sur l'ensemble des programmes haut niveau
- programmes/librairies en C/C++ qui sux sur l'ensemble des programmes en C/C++
Je ne serait pas étonné que les languages haut niveau l'emportent haut la main (comprendre qu'ils sont globalement de moins bonne qualité).
Notons que beaucoup de librairies de language haut niveau sont souvent des wrappeurs de librairie C/C++ et guère plus.
Il y a des tonnes de programmes et librairies C/C++ qui roxent des ours.
Oui, parfois les programmes en perl/python/java/C# plantent car le développeur a fait une connerie. Pareil avec C/C++. Rien de mistérieux. Le language qui permet de corriger les conneries des développeurs ça n'existe pas.
De plus tu ignores totalement les problèmes de ressources lors de l'utilisation de languages de haut niveau. Eclipse c'est bien beau mais c'est un gouffre à mémoire vive (et heureusement gtk+ est en C).
Images tout le bureau en java ou python et t'as une truc qui ne peut pas tourner sur une architecture 32 bits.
Slack a commencé avec la version 1.0, Mandrake la 5.1 et Red Hat la 0.9.
Sinon on peut dire que Mandrake n'a pas commencé à la 5.1, Red Hat à la 0.9 etc...
Sinon je peux chipoter et dire que Red Hat a commencé bien avant la 0.9 car ils ont développé RPP (l'ancètre de rpm), car il y avait un "noyau dur" avant la création de la boîte Red Hat, etc.
> Oh que non, plein de gros projets libres ont du code pourri, OpenSSH, sendmail., bind, ... sont des gros projets
OpenSSh est effectivement un peu pourri dans la façon dont c'est codé. Par contre pour sendmail et bind, il semble que tu n'as jamais regardé et te bases uniquement sur les ragots. Ces deux projets sont extrèmement bien codés.
J'invite tout le monde à regarder les sources de sendmail et bind avant de troller.
Et par pitié ne compares pas les trous de sécurité de sendmail ou bind aux trous de sécurité de IE. Il y a une magnitude de 1000.
> et ils sont plein de bugs(comme IE oui)
T'es charmant.
Dis combien de bugs connus (via un équivalent de bugzilla que tu as cher MS) il y a dans IE, et je te dis combien de bugs connus il y a dans OpenSSH, SendMail, Bind.
N'oublies pas que tu as un avantage : tout le monde ne peut pas ajouter un rapport de bug pour IE.
> Explique moi alors pourquoi ces distrib ont OpenSSH, sendmail et autres sur leurs CD
Déjà openssh est petit. Le src.rpm fait ici : 906 Ko. C'est petit. Nombre de ligne de code "*.[ch]" : 71 670. C'est très petit et gérable même si c'est mal codé.
Pour info, sendmail : 1.9 Mo
bind : 4.3 Mo
A titre de comparaison, gtk2 : 8.9 Mo (sans glib , sans pango), firefox : 31 Mo, KDE 3.3.1 : 330 Mo (dont 180 de i18n).
> C'est un peu facile ca de prendre uniquement les meilleurs softs du LL(bref ceux choisis par une distrib selon toi) et les comparer a tous les softs proprios. Dans le proprio aussi il y a du bon et du mauvais, je vais pas m'amuser a faire une selection pour dire que le proprio c'est Mieux(TM)
Quand tu compares le libre avec le proprio, ne prends que du libre qui pourrait être du proprio et ne prend pas le "tout venant". Pour ton info, ça fait depuis très longtemps que les unix propriétaires fournissent sendmail et bind. Ces deux projets sont d'exellente qualité et font références dans leur domaine.
Donc, t'as trouvé openssh de mal codé. Il fait moins de 1 Mo en src.rpm. Les src.rpm d'une distribution type RHEL (basé sur FC) pèse plus de 2 Go. Tu parles de moins de 0.05 % du code qui constitue une distribution généraliste.
> j'ai fait l'experience avec Mozilla il y a qqe annees de cela
<mode="ma vie">
J'ai repris une applis proprio car les utilisateurs n'étaient pas contents. L'applis (une grosse) représentait 10 années homme. J'ai mis 2 ans (!) pour la rendre satisfesante en terme de qualité (je faisais aussi les demandes d'évolution à la volée au cas par cas) et que l'utilisateur valide la recette de l'applie.
Pourtant il y avait une conception formalisé et "tout le bordel" (doc développeur d'environ 400 pages). Mais je suis par exemple tombé sur une fonction de 2 600 lignes (!) et avec un niveau d'intentation for-mi-da-ble (le tab=8 est inutilisable même avec une petite police de caractère).
</mode="ma vie">
> La doc pour developpeurs dans les projets libres c'est dramatiquement inexistant.
Le ticket d'entré dans un programme est toujours élevé.
Mets le code IE que je regarde s'il est facile de corriger tous ses bugs de non respect des standards. Même s'il est bien documenté, je vais ramer.
> CVS n'a rien d'obligatoire dans les LL, plein de projets en font un usage intensif, mais plein de projets ne le font pas
Troll detected : Trop vague.
La majorité des projets libres ont un CVS ou équivalent.
> la difference etant que dans qqe cas du libre il est ouvert
Troll detected : c'est tout simplement faux.
Dans la très grande majorité des cas c'est ouvert. Et s'il n'y a pas de bugzilla il y a une mailing public.
> cf. le bugzilla de Mozilla qui contient des bugs datant de plus d'un an ou deux
Troll detected : Aucun élément de comparaison disponible (Le bugzilla de IE n'est pas ouvert et IE n'est pas un modèle de qualité (ceux qui font des pages web peuvent le confirmer)).
Combien de développeurs il y a sur Mozilla ?
Combien de développeurs il y a sur IE ?
> d) Demandes aux dev de LL ici combien de gens se sont joints a leurs projets, tu vas etre decu du resultat.
Tu croyais qu'avec le logiciel libre il suffisait de "claquer des doigts" et "plop" t'as plein de développeurs/testeurs ?
La réponse va varier énormément. Linus Torvalds doit être très très satisfait. D'autres sont moins satisfaits.
Mais ce modèle marche extrèmement bien pour les projets "populaires". Évidemment, pour les projets peu populaire, peu demandé ou mal foutu, tu n'obtiendras pas beaucoup de testeurs/développeurs.
Encore une bien médiocre tentative de troller.
Si ça ne présentait pas un intérêt d'être "ouvert", pourquoi tant de gens le font ?
Pour la frime ? Pour que ton projet soit noyé parmis des milliers d'autres dans freshmeat ?
> En plus, je crois que le simple fait qu'un developpeur sache que l'on puisse lire son code le pique dans son amour propre et le force a produire plus propre que s'il a l'assurance que seuls des binaires seront distribués.
Juste pour dire que Nicolas Barcet a parfaitement raison. D'ailleur c'est aussi parfois utilisé en logiciel propriétaire (l'audite par un autre).
Personnellement, je fais plus attention à ce que je vais publier qu'à ce que je fais dans mon coin.
> mais ici il s'agit de cibler un probleme qui affecte le libre et qui est en directe contradiction avec le mythe qui veut que les LL soient mieux codes que des equivalents proprios.
Ce "mythe" n'en est pas un car c'est une réalité !
Prend une distribution généraliste typique (3 à 4 Go) 80 % du code vient de gros projets (Linux, libc, xorg, gnome, KDE, mozilla, tetex, etc). 95 % du code est d'exellente qualité.
Tu fais une fixation sur les 5 % restant pour faire une généralité (bref, un troll de plus).
Tu ignores une caractéristique du libre : libre
Donc chaqu'un est libre de faire un projet pourri et de le rendre public. Et chaqu'un est libre (notament ceux qui font des distributions) de ne pas l'utiliser.
Avec le proprio, n'est visible que ce qui "flatteur" ou vendeur de présenter.
Enfin, le libre ne "vend"/propose pas uniquement du "out of the box". Le libre propose de tout. Des projets finalisés, des projets en beta, des projets solides mais encore en beta (version < 1.0), etc. Par contre les distributions (et notament les distributions orienté entreprise) prendront soit a ne sélectionner que de bon projet et pas le "tout venant". Un petit exemple. Sur mailing Fedora était proposé un serveur de son pour remplacer esd (j'ai oublié le nom du projet). Le code a été rapidement audité et notament par Alan Cox. Conclusion: même si esd n'est pas actuellement activement maintenu, le petit nouveau bien que prometteur a été refusé car insuffisant en terme de qualité.
Compares Solaris à une distribution GNU/Linux "enterprise" et tu verras grosso-modo la même chose en terme de qualité. Pourtant une distribution GNU/Linux est composé à 99 % de logiciel libre minimum. Pourtant un distributeur GNU/Linux "enterprise" n'a pas l'infrastructure QA de Sun.
Et notes aussi que Solaris fournit aussi plein du logiciel libre (OOo évidemment, mais aussi emacs, Gnome, Mozilla, etc).
Tu trolles en comparant ce qui n'est pas comparable. Par essence Le libre (sans passer par le filtre d'un distributeur) propose de tout. Le proprio ne propose que ce qui est "présentable"/"vendable".
Il n'y a aucun critère de qualité dans la qualification libre d'un projet.
Compare le libre une fois filtré (par un distributeur) et le proprio (qui est filtré puisque pas toujours disponible).
> 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.
> RedHat 1.0 est sortie en mai 1995, Slackware 1.0 en juillet 1993
C'est bien. Ça démontre pour la "petite histoire" que Red Hat aurait dû commencer avec la version 1.0 (bref, faire comme Slack).
Sinon Mandrake à commencé à la version 5.2 je crois. Tu conclus quoi ? Tu vas comparer Mandrake 5.2 avec Slack 5.2 pour conclure que Mandrake est aussi vieux que Slack ?
[^] # Re: ha ?!??
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
Bravo.
> Je ne comprends pas pourquoi il n'en irait pas de meme de mes pairs developpeur.
Une critique avec des arguments d'accord. Mais là il n'y a rien ou presque. Il y a quelques personnes qui se plaignent de quelques bugs sur des applis mineurs et un bug dans gconf. C'est maigre.
Imaginons que tu développes pour KDE.
Imagines que je fasse une news avec :
1- KDE n'est pas aussi fiable qu'on le dit.
2- Gnome fait mieux.
3- KDE devrait avoir une démarche qualité éprouvée comme Gnome.
4- KDE ne devrait pas seulement compter que les utilisateurs pour faire les tests sinon KDE va avoir un retard insurmontable sur Gnome.
6- dejagnu
7- et définition de "test unitaire" pour les abrutis
Évidement tout ça sans le moindre argument si ce n'est une "impression générale".
Si t'apprécie ce genre de truc, très bien.
Moi pas.
[^] # Re: Droit de réponse
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
On peut déjà. Fedora le fournissait mais ça bouffe trop de place (un gros problème pour les mirroirs).
Suffit de recompiler le paquet et tu obtient un toto-debuginfo-*.rpm.
Tu l'installes puis :
$ gdb /usr/bin/toto
[^] # Re: (HS) Re: Ah oui mais...
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
Y en a. Pour info c'est "kernel panic".
[^] # Re: ha ?!??
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
Il y a plein d'attaque sur les serveurs apaches et ce n'est pas pour autant qu'apache n'est pas sûr.
> tous régulièrement patchés heureusement (et c'était casse-pied!).
Les distributions font ça. Pour bind et sendmail t'as une à deux mise à jours par an maxi en correction de sécurité.
[^] # Re: Stop !
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 0.
Développer, coder n'est pas du bricolage. Un "#ifdef" n'est pas du bricolage. Il a un fonction très précise. Un "p++" n'est pas du bricolage. C'est du code ! C'est du bricolage si c'est du code mal foutu. Coder demande beaucoup de réflexion. Quand on développe, on ne pense pas seulement à "pisser du code". On se demande si ça va marcher ! C'est l'objectif non ? Quand on développe (et surtout dans le libre) on n'a pas avis d'avoir des utilisateurs sur le dos qui se plaignent de bugs.
On n'attent pas les test du département QA pour prendre en compte la qualité. Dans la majorité des projets libres, le développeur c'est aussi le département QA.
Toi tu penses que le codeur n'apporte aucune valeur à la qualité et que tout ce qui compte c'est ces "foutus" test.
Regardes Linux, la qualité est assuré à 90 % par les développeurs et pas par des tests unitaire ou autres trucs funants.
J'espère que tu apprécies leur "bricolage".
> Quand on critique MS qui prend ses utilisateurs pour des testeurs tout le monde trouve ça normal, mais quand c'est pour un logiciel libre, tout le monde dit : "envoie un rapport de bug et un patch si possible"...
Tu mélanges tout. Le logiciel libre est gratuit. Pour MS, ce que n'aiment pas les gens, c'est payer pour être testeur (et sans avoir la possibilité de fouiller les sources et avoir la satisfaction de fixer un bug).
Tu comprends la nuance ?
Le libre c'est libre et personne te demande de faire des rapports bugs. On te le conseille, on t'y invite, mais tu n'a pas d'obligation.
Je vois un truc "marrant". Les "fans" des tests unitaires, qui semblent nombreux, font rarement du logiciel libre sinon il y aurait plus de tests unitaires dans le logiciel libre.
[^] # Re: ???
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
Mais ça arrive. Je l'ai vécu et ce n'est pas du suicide.
Puis les tests unitaires quand t'as 300 paramètres d'exécutions et tu dépends d'un automate qui t'envois 200 autres paramètres,etc c'est impossible à réaliser. Au mieux tu couvres quelques cas d'utilisations en lancant des tests qui représentent des utilisations "typiques". Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
> Donc on peut reformuler ta phrase "dans le cas ou un projet ne respecte aucune methodologie qualite et fait des tests 3 ans apres le dev, on sait depuis tres longtemp qu'un bug decouvert en phase de test coute tres cher".
Dans certain cas tu n'as pas le choix. Une équipe développe l'applis, une autre bosse sur un automate qui va utiliser des appareils à plusieurs millions d'euro qui sera disponible que lorsque les développements sont terminés.
Certe tu peux toujours faire des tests unitaires etc. Mais je ne me vois pas demander au boss d'avoir 6 mois de plus pour faire des tests unitaires exautifs sans que ça apporte un réel intérêt.
Dans ces cas, il faut s'appuier sur une bonne architecture. Il faut alors que les éléments critiques soient simples. Ainsi tu peux "blinder" les tests unitaires et faire des tests exautifs sur les éléments critiques.
J'utilise les tests unitaires. Mais les tests unitaire systématique et pour tout c'est l'enfer.
"Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Je te donne une mission :
- Faire un (ou des) test unitaire complet pour gecko
Combien de temps il te faut ?
Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire de l'audit de code n'est pas un meilleur investissement.
> Donc il faut tester tres tot et plutot que de sortir une anerie pour decredibiliser les tests (les bugs decouverts en phase de test coutent cher)
Tu le fais exprès ?
Si je fais un module et que je le teste dans la semaine il n'y effectivement pas de problème pour corriger les bugs. Mais parfois un module développé n'est utilisé que bien des mois après.
Si les tests ont été exautifs (impossible sauf pour des trucs simples) il n'y a effectivement pas de problème. Mais suppose que les formats d'entrés aient légèrement changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Ça arrive car les tests peuvent être erronés ou incomplet, car il y a eu un manque communication lors de l'évolution d'un module, etc.
C'est _courrant_.
Toi t'es dans le rève ou il n'y a pas d'erreurs de conception, il n'y a pas de manque de communication, le projet est parfaitement géré, les tests sont tous exautifs et parfait, les spécifications sont complètes et n'ont raté aucuns scénarios, etc.
Voilà pour ton rève.
Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Dans la "vraie vie" ça ne se passe pas comme ça.
> je pense que tu devrais integrer cette notion de tester le plus tot possible dans une demarche de qualite globale
T'es gentil.
Mais je vais te montrer un cas "spécial" et qui va te montrer que je ne suis pas contre les tests unitaires lorsque ça a un sens.
J'avais un projet sur 8 mois et ça me semblait impossible à tenir (je n'étais pas le seul à le penser). Heureusement tous les données étaient disponibles (ficher de test, moyen pour les générer, etc).
J'ai fait la conception du programme sur papier.
J'ai réalisé les procedures de tests exautives (car c'était possible et ça permettait aussi de faire le recette auprès du client).
J'ai fait validé les procédures de tests par le client.
J'ai réalisé les fichiers .h.
J'ai fait audité la conception et les fichiers .h.
J'ai "pissé" du code durant 6 mois sans rien compiler/exécuter ! Le code était blindé d'assert.
J'était en retard sur le planning car les 8 mois était écoulé. J'ai compilé, corrigé les tonnes d'erreur de syntaxe, etc qui restait.
J'ai exécuté. Corrigé les cas où le programme plantait sur les asserts.
J'ai passé les tests exautifs, corrigé les bugs. L'applis a été recetté par le client. Retard : 15 jours. Le client ne s'est jamais plaint d'un bug. Tous les tests ont été réalisés à la *fin* car pour *ce* projet c'était une bonne méthode.
Il n'y a pas de démarche qualité universel et il faut bien faire avec les ressources disponibles.
[^] # Re: ha ?!??
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
On ne peut pas dire que le LL est mal testé ou n'a pas assez de démarche qualité en disant seulement que les tests unitaires c'est bien(tm).
Lorsqu'on critique le logiciel libre dans un domaine où il a bonne réputation, il faut des arguments.
> - dans le libre certains projets phare sont de mauvaise qualités et ça craint
Exemple ?
Nautilus ?
> - dans le libre, en tant qu'utilisateur, il faut lire les changelog et autres README pour mesure éventuellemetn la qualité de la version qu'on s'apprête à installer, pour être sûr que ce n'est pas une version de test, une RC, et au final on peut faire des boulettes pas drôle, et c'est un peu le bordel
C'est le LIBRE. Prends une distribution "entreprise" et ne te pose pas de question.
C'est dingue ça, les gens "gueules" car lorsqu'il récupérère le premier logiciel venu sur le net (gentiment contributé, gratuit, etc) il n'est pas à leur gout et il pense que ça leur donne le droit de critiquer le libre dans son ensemble.
[^] # Re: ha ?!??
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
Les sources sont dispos, alors fait un petit effort.
> Ils sont bogués comme tous les softs, sauf que les bugs de ces deux là sont des nids à pirates. Moi j'en étais venu à considérer sendmail et bind comme dangereux (et pénibles).
C'est marrant car les histoires où un serveur sendmail ou bind ont été cracké sont rares. Très rare alors qu'ils sont très utilisés et depuis très longtemps.
Tu t'es fait abusé par les ragots.
[^] # Re: ???
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
En phase de test ça coute cher car la phase de test (je ne parle pas de test unitaire) peut venir bien après la phase de développement. Donc le développeur il ne sait plus exactement ce qu'il a fait et si c'est un projet sur plusieurs mois/années il est même possible que le développeur qui a fait une code/module coupable ne soit plus disponible.
> Une erreur de conception en revanche, ca coute tres cher, je suis d'accord.
Idem pour un bug. Mais pour un bug c'est moins cher.
Pour les bugs "=" à la place de "==" c'est vraiment "petit". Il y a des bugs où il faut réécrire plusieurs centaines de lignes de code même si la conception est parfaite.
[^] # Re: Droit de réponse
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à -4.
Ça vole haut comme argument.
[^] # Re: Droit de réponse
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
J'ai donné un exemple de démarche qualité. Exemple tiré sur les distributions.
J'ai donné un réponse à ta question :
- pourquoi il y a plus de tests par les utilisateurs/testeurs dans le LL que dans le LP
J'ai indiqué que les démarches qualités varient beaucoup entre projet.
Par exemple subversion utilise massivement les test de non regression. PostgreSQL aussi. Par contre dans la bureautique ce n'est pas ou peut utilisé.
Ailleur, j'ai mis un lien sur les tests automatisés mis en place par OSDL et indiqué que les développeurs Linux n'y sont pas très attachés. Que Linux préfère l'audit et un code bien fait.
> Bref, mon pauvre, t'es complètement à coté de la plaque.
Toi, t'as toujours rien donnée comme info. Il y a un vague lien sur dejagnu et "impression général".
C'est maigre pour une news.
Désolé d'essayer de tenter de t'expliquer pourquoi le logiciel libre a une bonne qualité même pour des projets qui ne te satisfont pas intellectuellement dans leur démarche qualité.
> Plutot que de poster 20 commentaires pour dire la même chose
Fais déjà un commentaire avec un contenu intéressant dedans avant de critiquer mes 20 commentaires qui sont là pour compenser une news de merde.
[^] # Re: ???
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
http://www.osdl.org/lab_activities/kernel_testing/(...)
Il y a Andrew et Linux qui c'étaient exprimés sur ça dans une interview que j'ai perdu. En gros, ils ne sont pas contre mais ce n'est pas le coeur de leur démarche qualité.
Linus insiste toujours sur le code. Par exemple il n'est pas emballé par les débuggueur.
[^] # Re: Droit de réponse
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 0.
Tu mélanges tous. T'as quoi comme programme "bancal" ?
Des bricoles ici et là. Ce n'est vraiment pas représentatif du libre.
De plus, et ça a déjà été dit, le libre donne aussi la liberté de faire des merdes faitent par de mauvais développeurs. T'es pas obligés de "faire les poubelles".
> des démineurs, des calculatrices, des petits outils, des jeux, etc.
Ça c'est claire que globalement les développeurs s'en foutent un peu.
> Par contre, dire qu'en moyenne les LL sont fiables, c'est quand même gonflé.
Ce n'est pas gonflé. Les jeux en logiciel libre, c'est rien ou presque. Faire des conclusion sur la fiabilité du libre en ne considérant que les jeux est ridicule. Regardes le "poid" que fait les jeux dans une distribution "normal" (évites debian pour les stats ils accèptent de tout :-) ; ce qui est normal compte-tenu de sa "philosophie"), c'est ridicule par rapport à tout le reste qui marche bien.
Exemple pour FC3 :
[root@one tmp]# rpm -q --queryformat "%{GROUP} %{NAME} %{SIZE}\n" --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ -a | sort | uniq | grep -i game
Amusements/Games bzflag 5638217
Développement/Bibliothèques kdegames-devel 423773
Divertissements/Jeux gnome-games 18501643
Divertissements/Jeux kdegames 16085867
Moins de 1 % par rapport à l'ensemble.
> Bref, tant que le système n'est pas plus au point, seulement quelques % des milliers de bugs existants pourront être correctement reportés et corrigés.
Fichtre, on est foutu.
[^] # Re: Ah oui mais...
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à -1.
Faire une news :
- le libre devrait faire ci ou ça
est naze (surtout avec aussi peu d'argument). Le libre est libre. T'es libre de faire des tests unitaires et je le suis aussi et je ne m'en prive pas.
S'il avait fait un article sur les avantages du test unitaire ou de la méthodologie "bidule" et la conseillait aux développeurs libres ce serait beaucoup plus "accèptable". Mais là on apprend rien.
Pour revenir au test unitaire, il y a différente catégorie de test unitaire. Lorsque je fais une fonction par exemple, je fais un test unitaire assez exhautif avec gdb ou autre.
Mais je mets plus rarement en place un test unitaire automatisé pour un module.
À ça, une bonne raison :
- c'est parfois le bordel à réaliser et si on a pris soin dans les unitaires lors du développement, les choses se passent bien.
Je suis un "accros" des :
#ifdef DEBUG
assert (....)
#endif
Je teste ainsi pratiquement toutes les entrées de fonction. Si la fonction a été bien testé durant le développement, c'est une aide plus que précieuse.
[^] # Re: Droit de réponse
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
Fichtre ça mérite une première page. T'es une vedette, une star ? :-)
> Quand je parle de retard, je parlais de retard dans la DEMARCHE qualité, pas dans la QUALITE.
Car tu ne connais pas la démarche qualité. Car il n'y a pas un page de pub pour te la décrire.
Voilà un explication :
* les logiciels upstream : on trouve de tous et dans tous les états. C'est normal, c'est le libre, on ne cache rien. Ici il y a des tests en tout genre. Test unitaire, test de régression, branche de développement et branche stable, retour utilisateurs, etc. C'est très variable. Il y a aussi le "test suprême", c'est la communauté qui décide quand une applis est stable (mérite un 1.0). Ce n'est pas un planning ou l'équipe marketing qui fait pression.
* les betas des distributions : on ne trouve pas de tous mais ce qui reste est dans des états variables. C'est un lieux parfais pour les testeurs (surtout pour les gros trucs style gnome ou KDE). Prends Fedora ou Gentoo, la branche de développement ou les betas utilisent souvent des versions de développement. Chaque bug/correction sera remonté en upstream. Beaucoup de développeurs du libre bossent aussi sur une distribution et sont donc particulièrement à l'écoute des remontées des testeurs. C'est aussi ici qu'un distributeur peut décider de virer une fonctionnalité car elle est insatisfesante. Ça arrive assez souvent.
* les distributions "bleeding-edge" : là on a un état moins "bizarre". Il peut rester des bugs et ça peut être insatisfesant en entreprise. Il y a encore plus de remontée de bugs pour traquer les cas rares.
* les distributions "enterprise" : en général basée sur une distribution "bleeding-edge" (donc déjà massivement testé). Certaines distributions sont aussi testé par des acteurs commerciaux (Dell, Ibm, Oracle, etc) durant la phase beta.
Exemple :
- Après des tests sommaires dans Rawhide, FC3 test1 sort le 13 juillet 2004.
- Après de nombreux tests, FC3 sort le 8 novembre (plus de 3 mois et demi de test et correction de bug preque exclusivement).
À la sortie de FC3, il n'y a plus grand chose à faire, il faut "attendre" les retours d'expérience (comme le logiciel proprio fait).
En parallèle à FC3, la RHEL 4 est en préparation. Elle profite des corrections de FC3 en phase beta et finale. Elle profite aussi de test auprès d'autres sociétés qui "valident" le produit.
- Courant fevrier ou mars 2005, RHEL 4 sort.
Soit 7 mois (!) après la première mise à disposition. Et ceci est "plannifier". Ça fait parti d'une démarche qualité. Plus "fort". RHEL 4 va avoir SeLinux par défaut. C'est passé par :
- FC2 avec SeLinux désactivé par défaut
- FC3 avec SeLinux activé par défaut
Un an de test pour SeLinux.
Voilà un exemple de démarche qualité pour une distribution.
Pourquoi ce "bordel" marche. Simple : la communauté *aime* ça !
Elle aime jouer avec les dernières versions. Elle aime voir si la dernière version lui fait un joli "kernel panic". Elle aime donner un coup de main en corrigeant un bug, etc.
Pourquoi s'en priver ?
Tu planques à la communauté un soft en phase beta et elle se fache. Donc c'est très naturellement que le logiciel libre s'appuis plus sur les testeurs que le logiciel proprio. De même, c'est très naturellement que les distributeurs proposent des distributions gratuites ou accessible à un coût modique.
[^] # Re: Droit de réponse
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
Il y a critique et critique.
Si je critique le propriétaire car il n'y a pas les sources, c'est une critique nulle.
De plus Lucas ne donne pas d'argument. Le libre fait parmis les logiciels les plus fiables et Lucas critique sans avancer de réel argument à part de trucs qu'on trouve dans des discours marketeux bien rodés.
J'ai critiqué le logiciel libre dans ce thread. Je dis par exemple qu'au niveau bureautique le libre n'a jamais eu d'avance sur MS et que le libre en est encore au stade ou la principale préoccupation est de rattraper le retard (ce qui ne veut pas dire copier :-)).
Les critiques sont admises lorsqu'elles ont du sens.
[^] # Re: Droit de réponse
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
> Le test par des utilisateurs-testeurs est une démarche qualité incomplète.
j'aimerais savoir depuis combien de temps tu utilises le libre. Car parfois on a l'impression que tu es un "petit nouveau".
Si tu ne veux pas être testeur, utilise une distribution qui répond à ce besoin.
Si tu veux donner un coup de main au libre et que tu as du temps pour faire des tests, alors fait des tests et remontes des bugs. Tu peux aussi rédiger des tests de non régression, personne n'est contre et ta contribution sera apprécié. Il n'y a pas que les tests pas les utilisateurs qui sont pris en compte.
Dans libre il y a libre. Les testeurs, les développeurs, les concepteurs etc sont libres de participer.
Regardes du côté de Windows qui sort des versions beta et Sun avec Solaris qui fait de même.
Pourquoi ils le font à ton avis alors que selon toi ils bétonnent en test unitaire et autres trucs fumants ?
Pourquoi tu ne veux pas que le libre fasse de même ?
De nombreux projets ont eu un "coup de fouet" en adoptant le model du "bazard" et en abandonnant la méthode de la cathédrale qui fait si bon effet dans les discours marketing.
> Beaucoup d'éditeurs de LP l'ont compris
Ce n'est pas récent. Ça remonte pratiquement au début de l'informatique. Apparament t'as jamais utilisé Unix.
> donc la communauté du Libre prend du retard qui ne sera pas évident à rattraper.
Quel retard ? En fiabilité/qualité et pour les serveurs, le libre est OK.
Pour la bureautique, le libre n'a plus qu'un concurrent : MS.
Actuellement le but est de rattraper le retard en fonctionnalité car le libre n'a jamais eu d'avance sur MS dans ce domaine. Après ce retard rattrapé, on verra pour le reste.
[^] # Re: Droit de réponse
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
Dire "le proprio fait aussi des logiciels fiables" est très maigre comme argument. Actuellement (et depuis longtemps) et terme de fiabilité/qualité il n'y a que Unix qui arrive au niveau de Linux (et vice versa). Ce n'est pas nouveau, surtout lorsqu'on regarde du côté d'Unix, que le logiciel propriétaire peut faire du faible.
Windows commence à arriver au niveau de Unix/Linux. Et encore, côté qualité dans le domaine de la sécurité il reste encore du boulot.
Tu parles des applis propriétaires "populaires" qui sont fiables. Mais les applis "populaires" du logiciel libre sont fiables aussi. C'est indiscutable.
Si tu bases ton raisonnement sur la partie bureautique, il faut avoir en tête un élément important :
1- Le libre n'est pas "populaire" pour la bureautique.
Le libre fait son introduction petit à petit dans la bureautique (via firefox, OpenOffice, etc).
Le libre n'est pas au stade ou il peut prendre significativement en compte la fiabilité pour la partie bureautique (sauf pour les navigateurs web, les clients mails, etc).
Pour la partie bureautique, la "mission" principale est de faire évoluer vite. Actuellement la cible est le geek plus que les entreprises. Quand il y aura une solide base d'utilisateur bureautique alors un effort significatif sera mis en fiabilisation/qualité. L'utilisation bureautique du libre est encore marginale.
Regardes Mozilla/Firefox. Avant Mozilla n'était pas toujours au top côté fiabilité. Maintenant que Firefox est très populaire, la qualité est un enjeux majeur et il est pris en compte plus que sérieusement.
Si t'as gedit qui t'exploise à gueule une fois tous les semaines, les développeurs Gnome regarderons ça en fonction des disponibilités. Par contre avec vim, la base d'utilisateur étant importante, si tu remontes un bug il sera corrigé assez vite. Pour la partie bureautique il y a encore plein de chantier et il faut "profiter" du relativement faible taux d'utilisation pour faire évoluer vite avec les ressources disponibles (qui n'ont rien à voir avec la puissance de feu de MS). Si Gnome ou KDE change de version tout les 6 mois, ce n'est pas pour rien. Mais il est claire que lorsque la base d'utilisateur sera aussi importante que dans le domaine des serveurs le rythme va se calmer et la qualité fera parti des enjeux prioritaires.
Certe, on peut demander toujours plus. Plus fiable, plus de fonctionnalité, plus "budile".
Mais ça ne mène à rien et c'est ignorer le fonctionnement du libre qui fait en fonction des ressources (bonnes âmes) disponibles.
Si t'as downloadé la dernière version de "bidule" et que ça plante, c'est presque "normal". Pas de quoi faire un scandale. Compares Mandrake CS, ou SuSE Enterprise, ou RHEL etc à des OS propriétaire et pas en utilisant le derner coincoin à la mode fraichement downloadé.
Apparament t'as été déçu avec quelques logiciels. Mais lesquels ?
Des logiciels ou la qualité est un enjeux majeur ou avec gedit ?
Pour ton débat "C/C++ c'est mal, ça fait des bugs", c'est totalement nul et c'est le réveil d'un troll qu'on a trop vu. Il y a des programmes en perl ou python qui ne sont pas formidables et il y en a même beaucoup. Fais les rapports suivant :
- programmes/librairies en language au niveau qui sux sur l'ensemble des programmes haut niveau
- programmes/librairies en C/C++ qui sux sur l'ensemble des programmes en C/C++
Je ne serait pas étonné que les languages haut niveau l'emportent haut la main (comprendre qu'ils sont globalement de moins bonne qualité).
Notons que beaucoup de librairies de language haut niveau sont souvent des wrappeurs de librairie C/C++ et guère plus.
Il y a des tonnes de programmes et librairies C/C++ qui roxent des ours.
Oui, parfois les programmes en perl/python/java/C# plantent car le développeur a fait une connerie. Pareil avec C/C++. Rien de mistérieux. Le language qui permet de corriger les conneries des développeurs ça n'existe pas.
De plus tu ignores totalement les problèmes de ressources lors de l'utilisation de languages de haut niveau. Eclipse c'est bien beau mais c'est un gouffre à mémoire vive (et heureusement gtk+ est en C).
Images tout le bureau en java ou python et t'as une truc qui ne peut pas tourner sur une architecture 32 bits.
Je repose ma question :
- Sur quoi tu te bases ?
[^] # Re: Et pouf !
Posté par fabb . En réponse à la dépêche Slackware 10.1 est sortie. Évalué à 0.
Slack a commencé avec la version 1.0, Mandrake la 5.1 et Red Hat la 0.9.
Sinon on peut dire que Mandrake n'a pas commencé à la 5.1, Red Hat à la 0.9 etc...
Sinon je peux chipoter et dire que Red Hat a commencé bien avant la 0.9 car ils ont développé RPP (l'ancètre de rpm), car il y avait un "noyau dur" avant la création de la boîte Red Hat, etc.
L'activité des dirigeants de Red Hat dans le logiciel libre remonte à 1989 :
http://www.redhat.com/about/corporate/timeline.html(...)
[^] # Re: ha ?!??
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
OpenSSh est effectivement un peu pourri dans la façon dont c'est codé. Par contre pour sendmail et bind, il semble que tu n'as jamais regardé et te bases uniquement sur les ragots. Ces deux projets sont extrèmement bien codés.
J'invite tout le monde à regarder les sources de sendmail et bind avant de troller.
Et par pitié ne compares pas les trous de sécurité de sendmail ou bind aux trous de sécurité de IE. Il y a une magnitude de 1000.
> et ils sont plein de bugs(comme IE oui)
T'es charmant.
Dis combien de bugs connus (via un équivalent de bugzilla que tu as cher MS) il y a dans IE, et je te dis combien de bugs connus il y a dans OpenSSH, SendMail, Bind.
N'oublies pas que tu as un avantage : tout le monde ne peut pas ajouter un rapport de bug pour IE.
> Explique moi alors pourquoi ces distrib ont OpenSSH, sendmail et autres sur leurs CD
Déjà openssh est petit. Le src.rpm fait ici : 906 Ko. C'est petit. Nombre de ligne de code "*.[ch]" : 71 670. C'est très petit et gérable même si c'est mal codé.
Pour info, sendmail : 1.9 Mo
bind : 4.3 Mo
A titre de comparaison, gtk2 : 8.9 Mo (sans glib , sans pango), firefox : 31 Mo, KDE 3.3.1 : 330 Mo (dont 180 de i18n).
> C'est un peu facile ca de prendre uniquement les meilleurs softs du LL(bref ceux choisis par une distrib selon toi) et les comparer a tous les softs proprios. Dans le proprio aussi il y a du bon et du mauvais, je vais pas m'amuser a faire une selection pour dire que le proprio c'est Mieux(TM)
Quand tu compares le libre avec le proprio, ne prends que du libre qui pourrait être du proprio et ne prend pas le "tout venant". Pour ton info, ça fait depuis très longtemps que les unix propriétaires fournissent sendmail et bind. Ces deux projets sont d'exellente qualité et font références dans leur domaine.
Donc, t'as trouvé openssh de mal codé. Il fait moins de 1 Mo en src.rpm. Les src.rpm d'une distribution type RHEL (basé sur FC) pèse plus de 2 Go. Tu parles de moins de 0.05 % du code qui constitue une distribution généraliste.
[^] # Re: Je ne suis pas d'accord
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
Pas d'accord. Je vais du test unitaire pour toutes les "unités" que je viens de faire. Quelles fasses 20 lignes ou 20 000 lignes.
[^] # Re: ha ?!??
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 8.
<mode="ma vie">
J'ai repris une applis proprio car les utilisateurs n'étaient pas contents. L'applis (une grosse) représentait 10 années homme. J'ai mis 2 ans (!) pour la rendre satisfesante en terme de qualité (je faisais aussi les demandes d'évolution à la volée au cas par cas) et que l'utilisateur valide la recette de l'applie.
Pourtant il y avait une conception formalisé et "tout le bordel" (doc développeur d'environ 400 pages). Mais je suis par exemple tombé sur une fonction de 2 600 lignes (!) et avec un niveau d'intentation for-mi-da-ble (le tab=8 est inutilisable même avec une petite police de caractère).
</mode="ma vie">
> La doc pour developpeurs dans les projets libres c'est dramatiquement inexistant.
Le ticket d'entré dans un programme est toujours élevé.
Mets le code IE que je regarde s'il est facile de corriger tous ses bugs de non respect des standards. Même s'il est bien documenté, je vais ramer.
> CVS n'a rien d'obligatoire dans les LL, plein de projets en font un usage intensif, mais plein de projets ne le font pas
Troll detected : Trop vague.
La majorité des projets libres ont un CVS ou équivalent.
> la difference etant que dans qqe cas du libre il est ouvert
Troll detected : c'est tout simplement faux.
Dans la très grande majorité des cas c'est ouvert. Et s'il n'y a pas de bugzilla il y a une mailing public.
> cf. le bugzilla de Mozilla qui contient des bugs datant de plus d'un an ou deux
Troll detected : Aucun élément de comparaison disponible (Le bugzilla de IE n'est pas ouvert et IE n'est pas un modèle de qualité (ceux qui font des pages web peuvent le confirmer)).
Combien de développeurs il y a sur Mozilla ?
Combien de développeurs il y a sur IE ?
> d) Demandes aux dev de LL ici combien de gens se sont joints a leurs projets, tu vas etre decu du resultat.
Tu croyais qu'avec le logiciel libre il suffisait de "claquer des doigts" et "plop" t'as plein de développeurs/testeurs ?
La réponse va varier énormément. Linus Torvalds doit être très très satisfait. D'autres sont moins satisfaits.
Mais ce modèle marche extrèmement bien pour les projets "populaires". Évidemment, pour les projets peu populaire, peu demandé ou mal foutu, tu n'obtiendras pas beaucoup de testeurs/développeurs.
Encore une bien médiocre tentative de troller.
Si ça ne présentait pas un intérêt d'être "ouvert", pourquoi tant de gens le font ?
Pour la frime ? Pour que ton projet soit noyé parmis des milliers d'autres dans freshmeat ?
> En plus, je crois que le simple fait qu'un developpeur sache que l'on puisse lire son code le pique dans son amour propre et le force a produire plus propre que s'il a l'assurance que seuls des binaires seront distribués.
Juste pour dire que Nicolas Barcet a parfaitement raison. D'ailleur c'est aussi parfois utilisé en logiciel propriétaire (l'audite par un autre).
Personnellement, je fais plus attention à ce que je vais publier qu'à ce que je fais dans mon coin.
> mais ici il s'agit de cibler un probleme qui affecte le libre et qui est en directe contradiction avec le mythe qui veut que les LL soient mieux codes que des equivalents proprios.
Ce "mythe" n'en est pas un car c'est une réalité !
Prend une distribution généraliste typique (3 à 4 Go) 80 % du code vient de gros projets (Linux, libc, xorg, gnome, KDE, mozilla, tetex, etc). 95 % du code est d'exellente qualité.
Tu fais une fixation sur les 5 % restant pour faire une généralité (bref, un troll de plus).
Tu ignores une caractéristique du libre : libre
Donc chaqu'un est libre de faire un projet pourri et de le rendre public. Et chaqu'un est libre (notament ceux qui font des distributions) de ne pas l'utiliser.
Avec le proprio, n'est visible que ce qui "flatteur" ou vendeur de présenter.
Enfin, le libre ne "vend"/propose pas uniquement du "out of the box". Le libre propose de tout. Des projets finalisés, des projets en beta, des projets solides mais encore en beta (version < 1.0), etc. Par contre les distributions (et notament les distributions orienté entreprise) prendront soit a ne sélectionner que de bon projet et pas le "tout venant". Un petit exemple. Sur mailing Fedora était proposé un serveur de son pour remplacer esd (j'ai oublié le nom du projet). Le code a été rapidement audité et notament par Alan Cox. Conclusion: même si esd n'est pas actuellement activement maintenu, le petit nouveau bien que prometteur a été refusé car insuffisant en terme de qualité.
Compares Solaris à une distribution GNU/Linux "enterprise" et tu verras grosso-modo la même chose en terme de qualité. Pourtant une distribution GNU/Linux est composé à 99 % de logiciel libre minimum. Pourtant un distributeur GNU/Linux "enterprise" n'a pas l'infrastructure QA de Sun.
Et notes aussi que Solaris fournit aussi plein du logiciel libre (OOo évidemment, mais aussi emacs, Gnome, Mozilla, etc).
Tu trolles en comparant ce qui n'est pas comparable. Par essence Le libre (sans passer par le filtre d'un distributeur) propose de tout. Le proprio ne propose que ce qui est "présentable"/"vendable".
Il n'y a aucun critère de qualité dans la qualification libre d'un projet.
Compare le libre une fois filtré (par un distributeur) et le proprio (qui est filtré puisque pas toujours disponible).
# ???
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.
[^] # Re: Et pouf !
Posté par fabb . En réponse à la dépêche Slackware 10.1 est sortie. Évalué à 0.
C'est bien. Ça démontre pour la "petite histoire" que Red Hat aurait dû commencer avec la version 1.0 (bref, faire comme Slack).
Sinon Mandrake à commencé à la version 5.2 je crois. Tu conclus quoi ? Tu vas comparer Mandrake 5.2 avec Slack 5.2 pour conclure que Mandrake est aussi vieux que Slack ?
[^] # Re: compromis
Posté par fabb . En réponse au journal Brevets: tout n'est pas fini. Évalué à 3.
Tu te trompes. Aucun amendement du parlement n'est pris en compte.
Tout et n'importe quoi est brevetable.
En huit mots comme en cent :