OoO En ce début d'après-midi ensoleillé du samedi 08 novembre 2003, vers 15:07, Misterjack disait:
Je te convie à te renseigner sur la qualité logicielle. Si tu développes réellement des logiciels de la manière dont tu le dis, tu pourras toujours courir pour être certifié qualité.
Aucun des grands logiciels que nous utilisons tous les jours (par exemple ceux liés à Internet) n'ont de certification. Il faut savoir faire la part entre la qualité reconnue par sélection naturelle et ceux à coup de normes ISO. Et je fais de la recherche en vérification. -- panic("IRQ, you lose..."); 2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c
OoO En ce début d'après-midi ensoleillé du samedi 08 novembre 2003,
vers 15:07, Misterjack <stock@mjcie.info> disait:
Je te convie à te renseigner sur la qualité logicielle. Si tu
développes réellement des logiciels de la manière dont tu le dis, tu
pourras toujours courir pour être certifié qualité.
Aucun des grands logiciels que nous utilisons tous les jours (par
exemple ceux liés à Internet) n'ont de certification. Il faut savoir
faire la part entre la qualité reconnue par sélection naturelle et
ceux à coup de normes ISO. Et je fais de la recherche en vérification.
--
panic("IRQ, you lose...");
2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c
OoO En ce début d'après-midi ensoleillé du samedi 08 novembre 2003, vers 15:07, Misterjack disait:
Je te convie à te renseigner sur la qualité logicielle. Si tu développes réellement des logiciels de la manière dont tu le dis, tu pourras toujours courir pour être certifié qualité.
Aucun des grands logiciels que nous utilisons tous les jours (par exemple ceux liés à Internet) n'ont de certification. Il faut savoir faire la part entre la qualité reconnue par sélection naturelle et ceux à coup de normes ISO. Et je fais de la recherche en vérification. -- panic("IRQ, you lose..."); 2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c
Laurent Wacrenier
Misterjack écrit:
Un logiciel ne peut pas être reconnu comme fiable uniquement s'il fait ce qu'on lui demande. Le code est maintenable s'il est maintenu ? Original comme concept.
Des qualités qui s'aquièrent avec l'usage ? Donc on sort un code non fiable, et on corrige au fur et à mesure que les problèmes sont découverts ?
S'il est fiable, il n'y a pas à le corriger. Le fait qu'il soit maintenable permet de le faire évoluer.
Quand on me dit "Microsoft c'est de la m**** parce que failles, patchs, etc.",
Un problème de Microsoft, c'est que les patchs ne font que changer les bugs, entre autre parce qu'il n'y a pas vraiment de patchs qui ne corrigent que les bugs sans ajouter des fonctionalités. Les logiciels ne sont pas stables. C'est une caracteristique du modèle commercial, ils ont plus interêt à créer de la demande pour de nouvelles fonctionalités qu'à créer des logiciels fiables.
et qu'après on me dit "je fais du code fiable avec le temps qui passe : problème alors on patche...", et bien je me pose des questions...
Qui ça "on" ?
Misterjack <stock@mjcie.info> écrit:
Un logiciel ne peut pas être reconnu comme fiable uniquement s'il fait
ce qu'on lui demande.
Le code est maintenable s'il est maintenu ? Original comme concept.
Des qualités qui s'aquièrent avec l'usage ? Donc on sort un code non
fiable, et on corrige au fur et à mesure que les problèmes sont découverts ?
S'il est fiable, il n'y a pas à le corriger. Le fait qu'il soit
maintenable permet de le faire évoluer.
Quand on me dit "Microsoft c'est de la m**** parce que failles, patchs,
etc.",
Un problème de Microsoft, c'est que les patchs ne font que changer les
bugs, entre autre parce qu'il n'y a pas vraiment de patchs qui ne
corrigent que les bugs sans ajouter des fonctionalités. Les logiciels
ne sont pas stables. C'est une caracteristique du modèle commercial,
ils ont plus interêt à créer de la demande pour de nouvelles
fonctionalités qu'à créer des logiciels fiables.
et qu'après on me dit "je fais du code fiable avec le temps qui
passe : problème alors on patche...", et bien je me pose des questions...
Un logiciel ne peut pas être reconnu comme fiable uniquement s'il fait ce qu'on lui demande. Le code est maintenable s'il est maintenu ? Original comme concept.
Des qualités qui s'aquièrent avec l'usage ? Donc on sort un code non fiable, et on corrige au fur et à mesure que les problèmes sont découverts ?
S'il est fiable, il n'y a pas à le corriger. Le fait qu'il soit maintenable permet de le faire évoluer.
Quand on me dit "Microsoft c'est de la m**** parce que failles, patchs, etc.",
Un problème de Microsoft, c'est que les patchs ne font que changer les bugs, entre autre parce qu'il n'y a pas vraiment de patchs qui ne corrigent que les bugs sans ajouter des fonctionalités. Les logiciels ne sont pas stables. C'est une caracteristique du modèle commercial, ils ont plus interêt à créer de la demande pour de nouvelles fonctionalités qu'à créer des logiciels fiables.
et qu'après on me dit "je fais du code fiable avec le temps qui passe : problème alors on patche...", et bien je me pose des questions...
Qui ça "on" ?
JacK
sur les news:, Nicob signalait:
On Sat, 08 Nov 2003 15:17:57 +0100, Olivier Aichelbaum wrote: Bon, je vais me la jouer grand prince, je vais faire remonter ça à McAffe France où j'ai de bons contacts. Mais s'ils ne répondent pas à mon mail ou me disent de contacter untel aux US, je laisse tomber.
Good luck, j'ai déjà signalé ce genre de truc chez MacAfee il y a plus d'un
an : jamais eu de feedback. Notamment posté ici un vieil exemple il y a un mois ou deux permettant de faire croire à un virus au choix. De mémoire, j'avais donné ici une URL avec un virus du nom de J0keuse, toujours pas corrigé et remonté il y a un an... -- JacK
sur les news:pan.2003.11.08.22.56.29.807510@nicob.net,
Nicob <usenet@nicob.net> signalait:
On Sat, 08 Nov 2003 15:17:57 +0100, Olivier Aichelbaum wrote:
Bon, je vais me la jouer grand prince, je vais faire remonter ça à
McAffe France où j'ai de bons contacts. Mais s'ils ne répondent pas à
mon mail ou me disent de contacter untel aux US, je laisse tomber.
Good luck, j'ai déjà signalé ce genre de truc chez MacAfee il y a plus d'un
an : jamais eu de feedback.
Notamment posté ici un vieil exemple il y a un mois ou deux permettant de
faire croire à un virus au choix.
De mémoire, j'avais donné ici une URL avec un virus du nom de J0keuse,
toujours pas corrigé et remonté il y a un an...
--
JacK
On Sat, 08 Nov 2003 15:17:57 +0100, Olivier Aichelbaum wrote: Bon, je vais me la jouer grand prince, je vais faire remonter ça à McAffe France où j'ai de bons contacts. Mais s'ils ne répondent pas à mon mail ou me disent de contacter untel aux US, je laisse tomber.
Good luck, j'ai déjà signalé ce genre de truc chez MacAfee il y a plus d'un
an : jamais eu de feedback. Notamment posté ici un vieil exemple il y a un mois ou deux permettant de faire croire à un virus au choix. De mémoire, j'avais donné ici une URL avec un virus du nom de J0keuse, toujours pas corrigé et remonté il y a un an... -- JacK
Ewa \(siostra Ani\) N.
Dans la news:, Olivier Aichelbaum a écrit:
Nicob wrote: (...)
Conclusion : c'est *vraiment* un site de merde !
Certes.
Combien de temps avant publication ici ils ont été prévenus ? (pour pouvoir corriger avant qu'une personne mal intentionnée n'exploite cela)
Ils ont été prévenus il y a plus d'un an: (news:bok2lg$1ft5gq$)
PS Ce post a été refusé sur fcs...
Pourquoi ?
Ewcia
-- Niesz !
Dans la news:3FACFB15.74C068C7@acbm.com,
Olivier Aichelbaum <acbm@acbm.com> a écrit:
Nicob wrote:
(...)
Conclusion : c'est *vraiment* un site de merde !
Certes.
Combien de temps avant publication ici ils ont été prévenus ?
(pour pouvoir corriger avant qu'une personne mal intentionnée
n'exploite cela)
Ils ont été prévenus il y a plus d'un an:
(news:bok2lg$1ft5gq$1@ID-204425.news.uni-berlin.de)
Combien de temps avant publication ici ils ont été prévenus ? (pour pouvoir corriger avant qu'une personne mal intentionnée n'exploite cela)
Ils ont été prévenus il y a plus d'un an: (news:bok2lg$1ft5gq$)
PS Ce post a été refusé sur fcs...
Pourquoi ?
Ewcia
-- Niesz !
Laurent Wacrenier
AMcD écrit:
La maintenance n'est pas forcémment assurée par la personne qui a écrit le code original. Je souhaite bien du courage à quelqu'un qui doit reprendre ton code.
Vous sautez du coq à l'âne. Pourquoi vous parliez d'un an, alors ?
Visiblement tu as des problèmes pour écrire du code que tu peux relire toi même et tu généralises ton problème.
On peut passer sans problème après moi sur mon code. Suivant le type de code, ça peut aller juqu'à plusieurs lignes de commentaires par ligne d'instruction.
Ouaip... je vois, ça peut aller jusqu'à noyer le code dans un flot de commentaires. On comprend peut être chaque ligne, mais on n'a pas de vue globale.
Je comprends le fond de ton analyse, mais tel n'était pas le sujet. Le sujet, et tu en es la preuve, c'est que les méthodes employées "en production" comme tu dis, ne sont pa sfiables, malgré les beaux discours. Dont le tien.
Pas fiable ? Ma foi, ça fait plus de deux ans que ça tourne en dépis de vos preuves.
Vous avez oublié de recopier les indentations.
Pas faux. Le copier-coller à effectivement fait voler en éclats la mini-indentation de ton code. Mais comme tu es loin d'être un idiot, tu sais très bien ce que ma remarque signifiait : qu'elle ne vaux rien.
C'est celle par défaut de mon éditeur, donc celle de tous un tas de gens. Ils vons être contents d'apprendre ça.
C'est illisible! Exemples :
- char *key est plus souvent recommandé d'être écrit en char* key. On comprend que le type est char* du premier coup.
Je le vois comme un pointeur sur un "char", pas comme un objet de type "char*". C'est des question de style. Personnelement, je suis assez ouvert pour ne pas systématiquement qualifier d'illisible le code de quelqu'un qui n'a pas le même que le mien.
Variables non initialisées,
ha ?
Eh oui, c'est nul car dangereux. Déjà ça prouve que tu débuggues pas ton code, puisque tout bon débuggeur brame après ça et ensuite c'est très risqué car suivant la qualité de code, tu peux très bien engendrer des crashes avec un pointeur non initialisé (par exemple).
Je sais que c'est nul, c'est pour ça que toutes les variables sont initialisées avant d'être utilisées.
noms de variables absolument pas explicite,
La longueur du nom d'une variable est proportionnelle à sa portée.
MDR. C'est du n'importe quoi là.
Bizzare cette abréviation "MDR" chez quelqu'un qui lutte pour des nom explicites.
Si vous déclarez char *une_chaine_dans_laquelle_je_fais_la_copie;
pour une variable qui ne sert que sur deux lignes, tant mieux pour vous. Moi j'écris
char *cp;
Un tas de gens font pareil et ils ont le droit de vote.
Non Monsieur 100% sûr. Je pense surtout à la portabilité ou à la mise à jour. Si dans ton fratras tu écris mal "crypt" tu risques de ne aps t'en apercevoir.
Heu, si. Parce que ça ne marchera pas dès le premier test.
Via une constante, une macro : 1) tu évites les erreurs (d'autant plus que codé en chaîne le compilo bronchera pas).
Ha oui ? à la place de
int deux = 1 + 1;
vous écrivez
#define UN 1 int deux = UN + UN;
C'est vachement plus clair !
2) tu permets un mis à jour facile le jour ou tu dois remplacer une valeur par une autre...
Ça ne risque pas. La fonction fait un truc en fonction de spécifications.
Oops, oui j'ai écrit NULL qui vaut 0 sous Windows au lieu de NUL. Il n'en reste pas moins que je maintiens que ton emploi de strncpy() est étrange. Mettre des -1 partout est certainement génial, oui...
strncpy copie au plus autant d'octets que sont troisième argument. Si la chaîne source est plus longue, elle est tronquée et la chaine destination n'est pas terminée par NUL. D'où la bonne habitude de forcer ce NUL. Et ceci, même quand on a des raisons de croire que ce n'est pas nessesaire.
Dis, tu me prends pour un con ? entre salt == NULL et salt = NULL il y a un gouffre non ? Tu te ridiculises tout seul mon pauvre ami.
C'est quoi l'"affectation à l'enver" là dedans ?
Il y a certe une erreur, mais,
Oui, et une lamentable !
si vous aviez lu le programme, ce morceau est sans incidence,
Ben voyons ! Dans un débat sur le code sûr ! LOL. Tu es ridicule.
Le code est sûr car une erreur de ce type est sans incidence, justement. C'est une n-ième vérification d'un truc qui ne doit pas arriver.
AMcD <arnold.mcdonald@free.fr> écrit:
La maintenance n'est pas forcémment assurée par la personne qui a écrit le
code original. Je souhaite bien du courage à quelqu'un qui doit reprendre
ton code.
Vous sautez du coq à l'âne. Pourquoi vous parliez d'un an, alors ?
Visiblement tu as des problèmes pour écrire du code que tu peux relire
toi même et tu généralises ton problème.
On peut passer sans problème après moi sur mon code. Suivant le type de
code, ça peut aller juqu'à plusieurs lignes de commentaires par ligne
d'instruction.
Ouaip... je vois, ça peut aller jusqu'à noyer le code dans un flot de
commentaires. On comprend peut être chaque ligne, mais on n'a pas de
vue globale.
Je comprends le fond de ton analyse, mais tel n'était pas le sujet. Le
sujet, et tu en es la preuve, c'est que les méthodes employées "en
production" comme tu dis, ne sont pa sfiables, malgré les beaux discours.
Dont le tien.
Pas fiable ? Ma foi, ça fait plus de deux ans que ça tourne en dépis
de vos preuves.
Vous avez oublié de recopier les indentations.
Pas faux. Le copier-coller à effectivement fait voler en éclats la
mini-indentation de ton code. Mais comme tu es loin d'être un idiot, tu sais
très bien ce que ma remarque signifiait : qu'elle ne vaux rien.
C'est celle par défaut de mon éditeur, donc celle de tous un tas de
gens. Ils vons être contents d'apprendre ça.
C'est
illisible! Exemples :
- char *key est plus souvent recommandé d'être écrit en char* key. On
comprend que le type est char* du premier coup.
Je le vois comme un pointeur sur un "char", pas comme un objet de type
"char*". C'est des question de style. Personnelement, je suis assez
ouvert pour ne pas systématiquement qualifier d'illisible le code de
quelqu'un qui n'a pas le même que le mien.
Variables non initialisées,
ha ?
Eh oui, c'est nul car dangereux. Déjà ça prouve que tu débuggues pas ton
code, puisque tout bon débuggeur brame après ça et ensuite c'est très risqué
car suivant la qualité de code, tu peux très bien engendrer des crashes avec
un pointeur non initialisé (par exemple).
Je sais que c'est nul, c'est pour ça que toutes les variables sont
initialisées avant d'être utilisées.
noms de variables absolument pas explicite,
La longueur du nom d'une variable est proportionnelle à sa portée.
MDR. C'est du n'importe quoi là.
Bizzare cette abréviation "MDR" chez quelqu'un qui lutte pour des nom
explicites.
Si vous déclarez
char *une_chaine_dans_laquelle_je_fais_la_copie;
pour une variable qui ne sert que sur deux lignes, tant mieux pour
vous. Moi j'écris
char *cp;
Un tas de gens font pareil et ils ont le droit de vote.
Non Monsieur 100% sûr. Je pense surtout à la portabilité ou à la mise à
jour. Si dans ton fratras tu écris mal "crypt" tu risques de ne aps t'en
apercevoir.
Heu, si. Parce que ça ne marchera pas dès le premier test.
Via une constante, une macro :
1) tu évites les erreurs (d'autant plus que codé en chaîne le compilo
bronchera pas).
Ha oui ? à la place de
int deux = 1 + 1;
vous écrivez
#define UN 1
int deux = UN + UN;
C'est vachement plus clair !
2) tu permets un mis à jour facile le jour ou tu dois remplacer une valeur
par une autre...
Ça ne risque pas. La fonction fait un truc en fonction de spécifications.
Oops, oui j'ai écrit NULL qui vaut 0 sous Windows au lieu de NUL. Il n'en
reste pas moins que je maintiens que ton emploi de strncpy() est étrange.
Mettre des -1 partout est certainement génial, oui...
strncpy copie au plus autant d'octets que sont troisième argument. Si
la chaîne source est plus longue, elle est tronquée et la chaine
destination n'est pas terminée par NUL. D'où la bonne habitude de
forcer ce NUL. Et ceci, même quand on a des raisons de croire que ce
n'est pas nessesaire.
Dis, tu me prends pour un con ? entre salt == NULL et salt = NULL il y a un
gouffre non ? Tu te ridiculises tout seul mon pauvre ami.
C'est quoi l'"affectation à l'enver" là dedans ?
Il y a certe une erreur, mais,
Oui, et une lamentable !
si vous aviez lu le programme, ce
morceau est sans incidence,
Ben voyons ! Dans un débat sur le code sûr ! LOL. Tu es ridicule.
Le code est sûr car une erreur de ce type est sans incidence,
justement. C'est une n-ième vérification d'un truc qui ne doit pas
arriver.
La maintenance n'est pas forcémment assurée par la personne qui a écrit le code original. Je souhaite bien du courage à quelqu'un qui doit reprendre ton code.
Vous sautez du coq à l'âne. Pourquoi vous parliez d'un an, alors ?
Visiblement tu as des problèmes pour écrire du code que tu peux relire toi même et tu généralises ton problème.
On peut passer sans problème après moi sur mon code. Suivant le type de code, ça peut aller juqu'à plusieurs lignes de commentaires par ligne d'instruction.
Ouaip... je vois, ça peut aller jusqu'à noyer le code dans un flot de commentaires. On comprend peut être chaque ligne, mais on n'a pas de vue globale.
Je comprends le fond de ton analyse, mais tel n'était pas le sujet. Le sujet, et tu en es la preuve, c'est que les méthodes employées "en production" comme tu dis, ne sont pa sfiables, malgré les beaux discours. Dont le tien.
Pas fiable ? Ma foi, ça fait plus de deux ans que ça tourne en dépis de vos preuves.
Vous avez oublié de recopier les indentations.
Pas faux. Le copier-coller à effectivement fait voler en éclats la mini-indentation de ton code. Mais comme tu es loin d'être un idiot, tu sais très bien ce que ma remarque signifiait : qu'elle ne vaux rien.
C'est celle par défaut de mon éditeur, donc celle de tous un tas de gens. Ils vons être contents d'apprendre ça.
C'est illisible! Exemples :
- char *key est plus souvent recommandé d'être écrit en char* key. On comprend que le type est char* du premier coup.
Je le vois comme un pointeur sur un "char", pas comme un objet de type "char*". C'est des question de style. Personnelement, je suis assez ouvert pour ne pas systématiquement qualifier d'illisible le code de quelqu'un qui n'a pas le même que le mien.
Variables non initialisées,
ha ?
Eh oui, c'est nul car dangereux. Déjà ça prouve que tu débuggues pas ton code, puisque tout bon débuggeur brame après ça et ensuite c'est très risqué car suivant la qualité de code, tu peux très bien engendrer des crashes avec un pointeur non initialisé (par exemple).
Je sais que c'est nul, c'est pour ça que toutes les variables sont initialisées avant d'être utilisées.
noms de variables absolument pas explicite,
La longueur du nom d'une variable est proportionnelle à sa portée.
MDR. C'est du n'importe quoi là.
Bizzare cette abréviation "MDR" chez quelqu'un qui lutte pour des nom explicites.
Si vous déclarez char *une_chaine_dans_laquelle_je_fais_la_copie;
pour une variable qui ne sert que sur deux lignes, tant mieux pour vous. Moi j'écris
char *cp;
Un tas de gens font pareil et ils ont le droit de vote.
Non Monsieur 100% sûr. Je pense surtout à la portabilité ou à la mise à jour. Si dans ton fratras tu écris mal "crypt" tu risques de ne aps t'en apercevoir.
Heu, si. Parce que ça ne marchera pas dès le premier test.
Via une constante, une macro : 1) tu évites les erreurs (d'autant plus que codé en chaîne le compilo bronchera pas).
Ha oui ? à la place de
int deux = 1 + 1;
vous écrivez
#define UN 1 int deux = UN + UN;
C'est vachement plus clair !
2) tu permets un mis à jour facile le jour ou tu dois remplacer une valeur par une autre...
Ça ne risque pas. La fonction fait un truc en fonction de spécifications.
Oops, oui j'ai écrit NULL qui vaut 0 sous Windows au lieu de NUL. Il n'en reste pas moins que je maintiens que ton emploi de strncpy() est étrange. Mettre des -1 partout est certainement génial, oui...
strncpy copie au plus autant d'octets que sont troisième argument. Si la chaîne source est plus longue, elle est tronquée et la chaine destination n'est pas terminée par NUL. D'où la bonne habitude de forcer ce NUL. Et ceci, même quand on a des raisons de croire que ce n'est pas nessesaire.
Dis, tu me prends pour un con ? entre salt == NULL et salt = NULL il y a un gouffre non ? Tu te ridiculises tout seul mon pauvre ami.
C'est quoi l'"affectation à l'enver" là dedans ?
Il y a certe une erreur, mais,
Oui, et une lamentable !
si vous aviez lu le programme, ce morceau est sans incidence,
Ben voyons ! Dans un débat sur le code sûr ! LOL. Tu es ridicule.
Le code est sûr car une erreur de ce type est sans incidence, justement. C'est une n-ième vérification d'un truc qui ne doit pas arriver.
AMcD
Tu es parfait, tes sources font pleurer d'admiration tous les esthètes du code et tu es l'inventeur du code 100% secure.
C'est bon, laisse tomber. Fin du débat en ce qui me concerne.
-- AMcD
http://arnold.mcdonald.free.fr/
Tu es parfait, tes sources font pleurer d'admiration tous les esthètes du
code et tu es l'inventeur du code 100% secure.
C'est bon, laisse tomber. Fin du débat en ce qui me concerne.
C'est bon, laisse tomber. Fin du débat en ce qui me concerne.
Super, je ne me ferais plus traiter d'hérétique parce que je n'indente pas comme vous.
Misterjack
Salut !
Vincent Bernat a tapoté :
Aucun des grands logiciels que nous utilisons tous les jours (par exemple ceux liés à Internet) n'ont de certification.
Oui. Justement depuis mon premier post, j'essaie d'expliquer la différence entre un code de qualité industrielle et le code des logiciels grand public. Le débat est sans cesse déplacé.
Je recadre : - Microsoft et cie : code peu sûr, pas le temps de faire un code sûr car ça coute trop cher - Industrie : code sûr, on prend le temps de valider le code, mais ça revient très cher.
Mon post initial voulait simplement dire que l'industrie du logiciel grand public ne peut pas (financièrement parlant) faire un code sûr comme on le ferait en milieu industriel. C'est tout !
Il faut savoir faire la part entre la qualité reconnue par sélection naturelle et ceux à coup de normes ISO. Et je fais de la recherche en vérification.
Oui. Je répète ce que j'ai dis. En général on entend le discours selon lequel Microsoft se fiche des utilisateurs en sortant des logiciels verminés et en corrigeant plus tard. Est-ce ce que tu appelles la "sélection naturelle" ? Il me semble difficile dans ce cas de critiquer Microsoft et faire le même code...
Qualité reconnue par norme ISO et cie : il s'agit surtout pour le client d'avoir le maximum d'assurances sur la qualité du travail des développeurs. Ca ne garantie pas un code de qualité mais garantie que toutes les précautions ont été prises pour qu'il le soit.
La qualité (sûreté, fiabilité) du code est assurée par les méthodes de codage mises en place pour respecter les exigences qualité des normes.
Amicalement, -- Mister Jack (MJ) Pour me répondre souriez et cliquez sur "Répondre".
Salut !
Vincent Bernat a tapoté :
Aucun des grands logiciels que nous utilisons tous les jours (par
exemple ceux liés à Internet) n'ont de certification.
Oui. Justement depuis mon premier post, j'essaie d'expliquer la
différence entre un code de qualité industrielle et le code des
logiciels grand public. Le débat est sans cesse déplacé.
Je recadre :
- Microsoft et cie : code peu sûr, pas le temps de faire un code sûr car
ça coute trop cher
- Industrie : code sûr, on prend le temps de valider le code, mais ça
revient très cher.
Mon post initial voulait simplement dire que l'industrie du logiciel
grand public ne peut pas (financièrement parlant) faire un code sûr
comme on le ferait en milieu industriel. C'est tout !
Il faut savoir
faire la part entre la qualité reconnue par sélection naturelle et
ceux à coup de normes ISO. Et je fais de la recherche en vérification.
Oui. Je répète ce que j'ai dis. En général on entend le discours selon
lequel Microsoft se fiche des utilisateurs en sortant des logiciels
verminés et en corrigeant plus tard. Est-ce ce que tu appelles la
"sélection naturelle" ? Il me semble difficile dans ce cas de critiquer
Microsoft et faire le même code...
Qualité reconnue par norme ISO et cie : il s'agit surtout pour le client
d'avoir le maximum d'assurances sur la qualité du travail des
développeurs. Ca ne garantie pas un code de qualité mais garantie que
toutes les précautions ont été prises pour qu'il le soit.
La qualité (sûreté, fiabilité) du code est assurée par les méthodes de
codage mises en place pour respecter les exigences qualité des normes.
Amicalement,
--
Mister Jack (MJ)
Pour me répondre souriez et cliquez sur "Répondre".
Aucun des grands logiciels que nous utilisons tous les jours (par exemple ceux liés à Internet) n'ont de certification.
Oui. Justement depuis mon premier post, j'essaie d'expliquer la différence entre un code de qualité industrielle et le code des logiciels grand public. Le débat est sans cesse déplacé.
Je recadre : - Microsoft et cie : code peu sûr, pas le temps de faire un code sûr car ça coute trop cher - Industrie : code sûr, on prend le temps de valider le code, mais ça revient très cher.
Mon post initial voulait simplement dire que l'industrie du logiciel grand public ne peut pas (financièrement parlant) faire un code sûr comme on le ferait en milieu industriel. C'est tout !
Il faut savoir faire la part entre la qualité reconnue par sélection naturelle et ceux à coup de normes ISO. Et je fais de la recherche en vérification.
Oui. Je répète ce que j'ai dis. En général on entend le discours selon lequel Microsoft se fiche des utilisateurs en sortant des logiciels verminés et en corrigeant plus tard. Est-ce ce que tu appelles la "sélection naturelle" ? Il me semble difficile dans ce cas de critiquer Microsoft et faire le même code...
Qualité reconnue par norme ISO et cie : il s'agit surtout pour le client d'avoir le maximum d'assurances sur la qualité du travail des développeurs. Ca ne garantie pas un code de qualité mais garantie que toutes les précautions ont été prises pour qu'il le soit.
La qualité (sûreté, fiabilité) du code est assurée par les méthodes de codage mises en place pour respecter les exigences qualité des normes.
Amicalement, -- Mister Jack (MJ) Pour me répondre souriez et cliquez sur "Répondre".
Misterjack
Salut !
Un problème de Microsoft, c'est que les patchs ne font que changer les bugs, entre autre parce qu'il n'y a pas vraiment de patchs qui ne corrigent que les bugs sans ajouter des fonctionalités. Les logiciels ne sont pas stables. C'est une caracteristique du modèle commercial, ils ont plus interêt à créer de la demande pour de nouvelles fonctionalités qu'à créer des logiciels fiables.
Bon, on va en rester là. J'ai dis ce que j'avais à dire, le reste n'est pas mon problème. Il est quand même hallucinant de voir systématiquement chaque discussion dériver vers d'autres sujets.
Je disais juste qu'il ne faut pas blamer Microsoft particulièrement car le mode de développement des logiciels grand public n'est pas fait pour la sûreté. Point.
Cordialement, -- Mister Jack (MJ) Pour me répondre souriez et cliquez sur "Répondre".
Salut !
Un problème de Microsoft, c'est que les patchs ne font que changer les
bugs, entre autre parce qu'il n'y a pas vraiment de patchs qui ne
corrigent que les bugs sans ajouter des fonctionalités. Les logiciels
ne sont pas stables. C'est une caracteristique du modèle commercial,
ils ont plus interêt à créer de la demande pour de nouvelles
fonctionalités qu'à créer des logiciels fiables.
Bon, on va en rester là.
J'ai dis ce que j'avais à dire, le reste n'est pas mon problème. Il est
quand même hallucinant de voir systématiquement chaque discussion
dériver vers d'autres sujets.
Je disais juste qu'il ne faut pas blamer Microsoft particulièrement car
le mode de développement des logiciels grand public n'est pas fait pour
la sûreté. Point.
Cordialement,
--
Mister Jack (MJ)
Pour me répondre souriez et cliquez sur "Répondre".
Un problème de Microsoft, c'est que les patchs ne font que changer les bugs, entre autre parce qu'il n'y a pas vraiment de patchs qui ne corrigent que les bugs sans ajouter des fonctionalités. Les logiciels ne sont pas stables. C'est une caracteristique du modèle commercial, ils ont plus interêt à créer de la demande pour de nouvelles fonctionalités qu'à créer des logiciels fiables.
Bon, on va en rester là. J'ai dis ce que j'avais à dire, le reste n'est pas mon problème. Il est quand même hallucinant de voir systématiquement chaque discussion dériver vers d'autres sujets.
Je disais juste qu'il ne faut pas blamer Microsoft particulièrement car le mode de développement des logiciels grand public n'est pas fait pour la sûreté. Point.
Cordialement, -- Mister Jack (MJ) Pour me répondre souriez et cliquez sur "Répondre".
