rustacean.net « La Maison-Blanche exhorte les développeurs à abandonner C et C++ », titre Le Monde Informatique.
Les entreprises IT « peuvent empêcher l’introduction de multiples vulnérabilités dans l'écosystème numérique en adoptant des langages sécurisés », explique en effet l'Office of the National Cyber Director (ONCD) de la Maison-Blanche. Il invite les développeurs à réduire le risque de cyberattaques en utilisant des langages protégés contre les débordements de mémoire tampon, les lectures hors limites (out-of-bounds reads) et les fuites de mémoire.
LMI relève que des études récentes de Microsoft et de Google indiquent en effet « qu'environ 70 % de toutes les failles de sécurité sont dues à des problèmes de sécurité de la mémoire », et qu'une fiche d'information de la NSA sur la cybersécurité datant de novembre 2022 mentionne, en plus de Rust, les langages C#, Go, Java, Ruby et Swift, comme sécurisés.
Dans son rapport de 19 pages, l'ONCD cite le C et le C++ comme deux exemples de langages présentant des vulnérabilités en matière de sécurité de la mémoire, et qualifie Rust comme sûr.
L'un des objectifs du rapport de l’ONCD serait de « transférer la responsabilité de la cybersécurité des particuliers et des petites entreprises vers les grands groupes, les entreprises IT et le gouvernement américain ». Ils sont, souligne le communiqué de presse de la Maison-Blanche, « plus à même de gérer une menace en constante évolution ».
L'abandon du C et du C++ sera « long et difficile », estime Josh Aas, directeur exécutif et cofondateur de l’Internet Security Research Group (ISRG), à l'origine de Let's Encrypt. « Il faut un effort soutenu pour amener les gens à penser autrement, et des communications comme celle-ci contribuent à rappeler l’importance de la sécurité », a ajouté le dirigeant.
« Il est clair que nous devons écrire et déployer de nouveaux codes, mais pour y parvenir, nous avons besoin de ressources et que des dirigeants à tous les niveaux, du gouvernement au secteur privé, en fassent une priorité », a-t-il insisté. « Les dirigeants concernés doivent être sensibilisés à ce problème et savoir qu'ils seront soutenus s'ils cherchent à le résoudre ».
Commentaires (158)
#1
La Maison Blanche devrait aussi mieux trier chiffons et serviettes à mélanger des langages tournant sur des interpréteurs/VM à bytecode/nativement (on écrit comment ce qui permets aux 2 premiers de simplement exister sans avoir les derniers).
Bon, ça serait pas le 1er langage à vouloir bouter le C (le C++ serait sans doute déjà plus réaliste)... l'avenir nous dira ce qu'il en est mais vu la masse de boulot il est en tout cas fort lointain!
Historique des modifications :
Posté le 04/03/2024 à 07h19
Il me semblait pourtant que l'immense majorité des problèmes dans le domaine relevait de l'interface chaise-clavier et/ou de problèmes de configuration. Alors ces 70%, c'est avant ou après que les précédents classiques aient entr'ouvert la porte?
La Maison Blanche devrait aussi mieux trier chiffons et serviettes à mettre sur le même plan des langages tournant sur des interpréteurs/VM à bytecode/nativement.
Bon, ça serait pas le 1er langage à vouloir bouter le C (le C++ serait sans doute déjà plus réaliste)... l'avenir nous dira ce qu'il en est mais vu la masse de boulot il est en tout cas fort lointain!
Posté le 04/03/2024 à 07h20
Il me semblait pourtant que l'immense majorité des problèmes dans le domaine relevait de l'interface chaise-clavier et/ou de problèmes de configuration. Alors ces 70%, c'est avant ou après que les précédents classiques aient (au moins) entr'ouvert la porte?
La Maison Blanche devrait aussi mieux trier chiffons et serviettes à mettre sur le même plan des langages tournant sur des interpréteurs/VM à bytecode/nativement.
Bon, ça serait pas le 1er langage à vouloir bouter le C (le C++ serait sans doute déjà plus réaliste)... l'avenir nous dira ce qu'il en est mais vu la masse de boulot il est en tout cas fort lointain!
Posté le 04/03/2024 à 07h20
Il me semblait pourtant que l'immense majorité des problèmes dans le domaine relevait de l'interface chaise-clavier et/ou de problèmes de configuration. Alors ces 70%, c'est avant ou après que les précédents classiques aient (au moins) entr'ouvert la porte?
La Maison Blanche devrait aussi mieux trier chiffons et serviettes à mélanger des langages tournant sur des interpréteurs/VM à bytecode/nativement.
Bon, ça serait pas le 1er langage à vouloir bouter le C (le C++ serait sans doute déjà plus réaliste)... l'avenir nous dira ce qu'il en est mais vu la masse de boulot il est en tout cas fort lointain!
#1.1
Ça ne résoud pas tous les problèmes induits par l'interface chaise-clavier mais au moins ces problèmes très "technico-techniques" de gestion de mémoire.
#1.2
Ce n'est pas bien compliqué de se représenter les cycles de vie de la donnée et de sa représentation en mémoire. Si tu sais faire ça, il est alors possible d'avoir un binaire opérationnel dès la 1ere compil.
Mais bon, aujourd'hui, on apprend à paramétrer des framework et non à programmer.
#1.3
Je ne vois pas pourquoi il faudrait privilégier Ada plutôt que Rust du coup, j'imagine que les deux ont la même fiabilité, un écosystème similaire et que les devs vont naturellement vers ce qui les effrait le moins (oui, les devs sont des créatures qui ne veulent pas toujours faire de gros efforts d'adaptation, comme les humains en général d'ailleurs).
Historique des modifications :
Posté le 04/03/2024 à 09h55
Rust a une syntaxe qui me semble plus proche des habitudes que celle d'Ada, mais je ne suis pas spécialiste. Quant à traiter les devs de légumes, c'est un peu facile je trouve et je ne viendrais même pas argumenter contre cette pseudo-attaque.
Je ne vois pas pourquoi il faudrait privilégier Ada plutôt que Rust du coup, j'imagine que les deux ont la même fiabilité, un écosystème similaire et que les devs vont naturellement vers ce qui les effrait le moins (oui, les devs sont des créatures qui ne veulent pas toujours faire de gros efforts d'adaptation, comme les humains en général d'ailleurs).
#1.7
#1.9
#1.8
L'utilisation d'ADA n'empêche pas la destruction de fusée(s) Ariane ...
J'ai de bons souvenirs de la fac concernant ADA : rigueur, définition de types au micro poil. Mais aussi des souvenir de "lourdeur", qui s'expliquent par les origines, surtout la syntaxe/structure très Pascal.
Sinon, dites moi les codeurs C/C++, si Rust vous fait le même effet que moi : j'ai commencé deux fois le tuto sans jamais réussir à le terminer. Mon cerveau bloque sur des éléments de syntaxe et fait des nœuds.
Bon, après, faut dire que je suis vieux, je manque de souplesse ...
#1.10
#1.4
-Il est admin, banco dans tous les cas.
-Il ne l'est pas et il faut trouver une faille qui peut permettre de le devenir et pourra exploiter un bug de gestion mémoire ou autre.
Dans le second cas, note que notre étourdi qui clique sur n'importe quoi va en premier lieu se faire poutrer via le programme qu'il installe (imparable) ou des données spécialement construites visant son applicatif (avec une préférence pour ce qui est en frontal réseau: Navigateur, client mail/messageries diverses... oh, tiens-tiens, Rust vient de Mozilla... et ensuite, ce qui permet d'extraire/visualiser ces données, comme une visionneuse d'images).
C'est pourquoi je disais que le C++ (une grande part de l'applicatif compilé) est sans doute plus réaliste que le C (démarrage/OS/drivers-modules). Et en prime cela suffirait sans doute à faire le job.
D'ailleurs la remarque sur l'origine de Rust n'est pas innocente.
Mais même pour de l'applicatif, attention au combo language encore jeune qui évolue/dépendances fondation de pans entiers de nos systèmes/cycles de maintenance de ces derniers:
https://ariadne.space/2021/09/16/the-long-term-consequences-of-maintainers-actions/
C'est de 2021, mais le constat demeure.
Historique des modifications :
Posté le 04/03/2024 à 11h17
J'ai jamais dit que l'utilisateur devait faire attention à la gestion de sa mémoire, juste à ce qu'il fait car dans ce cadre, 2 options:
-Il est admin, banco dans tous les cas.
-Il ne l'est pas et il faut trouver une faille qui peut permettre de le devenir et pourra exploiter un bug de gestion mémoire ou autre.
Dans le second cas, note que notre étourdi qui clique sur n'importe quoi va en premier lieu se faire poutrer via le programme qu'il installe (imparable) ou des données spécialement construites visant son applicatif (avec une préférence pour ce qui est en frontal réseau: Navigateur, client mail/messageries diverses... oh, tiens-tiens, Rust vient de Mozilla... et ensuite, ce qui permet d'extraire/visualiser ces données, comme une visionneuse d'images).
C'est pourquoi je disais que le C++ (une grande part de l'applicatif compilé) est sans doute plus réaliste que le C (démarrage/OS/drivers-modules). Et en prime cela suffirait sans doute à faire le job.
D'ailleurs la remarque sur l'origine de Rust n'est pas innocente.
Mais même pour de l'applicatif, attention au combo language encore jeune qui évolue/dépendances fondation de pans entiers de nos systèmes:
https://ariadne.space/2021/09/16/the-long-term-consequences-of-maintainers-actions/
C'est de 2021, mais le constat demeure.
#1.6
#1.5
#1.11
Sans que ça fasse tout le travail, ça pourrait peut-être en faire 80%, non ?
#1.12
#2
D'un point de vue pratique, ce n'est pas au législateur de s'occuper de ça (coup de bol pour eux, pour une fois, ils n'ont pas dit une grosse connerie). Sinon, en France, tout le monde serait équipé du pare-feu OpenOffice...
#2.1
Je n'ai jamais entendu parler du fait que Rust serait plus rapide que le C !?
Et pour faire plus rapide que le C, c'est l'assembleur ... et là, les « framework for monkeys » y'en a pas.
#2.2
#2.21
#2.3
Pas toujours. En tout cas, pour sur les architectures modernes. Les processeurs sont tellement compliqués, avec les pipelines, et tout le tralala qu'un code C optimisé par compilateur est souvent plus performant qu'un code assembleur écrit à la main.
#2.9
En revanche en code parallèles (type calculs scientifiques/ingé), Rust est jusqu'à x10 (d'après mon expérience) que du C/C++. Non pas en raison du compilateur mais du modèle mémoire qui n'est pas fait pour des tâches de type fork-join de manière efficace.
#2.12
Effectivement, le benchmark que j'avais vu, c'était principalement du code séquentiel (comme la grande majorité des benchmarks)
#2.16
#2.17
#2.18
#2.20
J'ai un client qui a préféré voir sa facture être multiplié par 3 parce qu'il a préféré une lib écrite en C++ qu'en Fortran pour du calcul d'algèbre linéaire. Alors qu'à la fin il ne fait qu'un appel à cette lib (donc il s'en fiche de la techno tant que l'ABI est stable). Mais dans sa tête Fortran sentait les cartes perforées...
Dans le milieu académique, on trouve encore du Fortran (qui plus est sous sa forme moderne). Même si les doctorants ne l’apprennent plus en cours, en général ils deviennent accros une fois qu'ils ont compris que, pour des problèmes s'exprimant avec l'algèbre linéaire, Fortran est génial. J'ai souvenir d'un étudiant de M2 qui ne jurait que par le C++. Et puis, lorsqu'il a découvert Fortran pour ses calculs de mécaniques quantiques en thèse, il a vite changer son fusil d'épaule.
Historique des modifications :
Posté le 05/03/2024 à 10h03
Sans dépend des mondes. Dans l'industrie, tu trouves encore des vieux codes datant de cette époque. Maintenant, avec les logiciels comme Matlab et la tendance à faire du C++/Rust non Fortran n'est plus vraiment utilisé car, pour les managers (même ceux avec soit disant des diplômes d'ingé), Fortran c'est has-been.
J'ai un client qui a préféré voir sa facture être multiplié par 3 parce qu'il a préféré une lib écrite en C++ qu'en Fortran pour du calcul d'algèbre linéaire. Alors qu'à la fin il ne fait qu'un appel à cette lib (donc il s'en fiche de la techno en dessous tant que l'ABI est stable). Mais dans sa tête Fortran sentait les cartes perforées...
Dans le milieu académique, on trouve encore du Fortran (qui plus est sous sa forme moderne). Même si les doctorants ne l’apprennent plus en cours, en général ils deviennent accros une fois qu'ils ont compris que, pour des problèmes s'exprimant avec l'algèbre linéaire, Fortran est génial. J'ai souvenir d'un étudiant de M2 qui ne jurait que par le C++. Et puis, lorsqu'il a découvert Fortran pour ses calculs de mécaniques quantiques en thèse, il a vite changer son fusil d'épaule.
#2.19
OpenMP n'est pas compatible avec Rust nativement en raison de son modèle mémoire. MPI aurait un sens, mais il est souvent implémenté en C. Je ne vois dès lors peu l’intérêt de l'adjoindre à Rust. Un MPI en Rust (je ne sais pas si ça existe) aurait dès lors plus un sens. Mais bon, faire une réduction en Rust avec son modèle mémoire sur un supercalculateur, faut avoir de l'argent à perdre.
#2.5
Faut voir que dans l'industrie, bien souvent un produit tout neuf exploite déjà le matériel à 80% à sa sortie (sinon, on sera mal placé vs concurrence à avoir surdimensionné et on vendra rien). Dès un petit milieu de vie on sera au delà des 95% après l'ajout des features définitives et on cherchera encore à grappiller pour ce qui n'était pas prévu au départ mais que les clients demandent.
Donc les qq % de pénalité de Rust posent déjà problème et comme c'est les industriels qui raquent et/ou contribuent...
#2.10
Après de quelle industrie parle-t-on aussi. Perso, les contrats qu'on me file à exécuter en ce moment, c'est des grands groupes qui ont besoin de ré-optimiser des codes mal écrits ou mal fichus et soit disant vendu pour être performant.
#2.4
#2.6
Là où un remplacement par partie de l'existant peut se faire lors d'une transistion C => Rust, cela sera beaucoup plus difficile à mettre en oeuvre dans le cadre d'une transition C++ => Rust, sauf à remplacer d'un bloc tout un applicatif.
Remplacer un applicatif entier, cela présente de nombreux risques. Le faire uniquement parce que l'applicatif est écrit en C++, c'est une "mauvaise raison". Cela fait prendre d'énormes risques à court, moyen et long terme, pour des avantages qui ne se verraient potentiellement qu'à très très long terme.
#2.7
#2.8
En partant de là, ce genre de recommandation pourrait avancer et venir influencer le cadre décisionnel pour par exemple
- s'intégrer aux critères d'appel d'offre de l'état fédéral
- s'appliquer aux développements faits par des agences fédérales (p.ex. Nasa, les services postaux, ...)
#2.11
Particuliers et PME pouvant se retourner contre leurs fournisseurs... Le pb historique Liability => Foolproof des USA. Et ils sont capables d'y aller très vite, ce ne serait pas une première fois. Seule de grosses faillites induites par une légalité douteuse pouvant alors les arrêter.
#2.13
En U.E. la mozilla foundation, ou dans certains cas des contributeurs, pourraient se faire poursuivre par les utilisateurs lésés par une vulnérabilité.
Il ne sera plus possible de s'abriter derrière une clause de type "ce logiciel est mis à votre disposition tel quel, utilisez-le à vos risques et périls"
De ce que j'ai lu de l'approche US sur la question, on reste dans un cadre moins dangereux pour les petits acteurs, les contributeurs du libre, ...
#2.14
#2.15
Aussi le coup de l'EIDAS où on oblige les navigateurs à faire confiance aux les autorités de certification étatique en mode "tu nous fais confiance, sinon...", au lieu de laisser les navigateurs gérer le sujet avec des critères qualitatifs objectifs, ça ne rassure pas. Ils sont occupés à changer l'U.E. en république ex-soviétique.
Et les projections concernant les votes pour les élections européennes tendent à montrer qu'on ne va pas vers une amélioration de l'intelligence des gens qui nous dirigent... bien au contraire...
Historique des modifications :
Posté le 04/03/2024 à 15h27
C'est clair, sur le plan réglementaire, l'U.E. est une faillite intellectuelle sur le côté cyber sécurité.
Aussi le coup de l'EIDAS où on oblige les navigateurs à faire confiance aux les autorités de certification étatique en mode "tu nous fais confiance, sinon...", au lieu de laisser les navigateurs gérer le sujet avec des critères qualitatifs, ça ne rassure pas. Ils sont occupés à changer l'U.E. en république ex-soviétique.
Et les projections concernant les votes pour les élections européennes tendent à montrer qu'on ne va pas vers une amélioration de l'intelligence des gens qui nous dirigent... bien au contraire...
#3
#4
Moi qui croyait qu'on ne faisait plus que des logiciels inefficients en NodeJS réinventant la roue et empilant les surcouches inutiles pour des fonctions basiques.
Moi ça me rassure pas, car lorsqu'on qualifie un truc comme "sûr", on a tendance à relâcher son attention. Et donc à la fin, à faire de la merde quand même en reposant sur la supposée sûreté by design.
Je ne suis pas développeur et suis incapable de dire si tout ceci est vrai ou pas pour Rust. Peut-être que oui et tant mieux. Mais j'aime pas les arguments du style "utilisez Machin car c'est plus sûr", ça me rappelle trop les "utilisez Linux c'est plus sécurisé" scandé tel un dogme alors que c'est au mieux de la superstition. La sécurité magique by design, à ma connaissance, ça n'existe pas. Ca demande du travail dans tous les cas. Si le produit facilite ce travail et évite de faire des erreurs basiques, tant mieux. Mais perso je considère qu'il ne faut pas non plus trop s'endormir sur ces arguments.
#4.1
Un point que je trouve quand même relativement intéressant c'est que le but pour le gouvernement américain (visiblement) est de déplacer la responsabilité
Je ne sais pas si c'est la meilleure des solutions mais c'est un choix qui s'entend s'ils arrivent à trouver des solutions alternatives qui palient à 99% au problème initiale mentionné dans l'article.
#4.2
Pour ce qui est de Rust, le langage est effectivement memory safe sauf que... pour une raison qui m'échappe, il est prévu des opérations unsafe telles que déréférencer un pointeur.
#4.3
#4.4
#4.6
#4.5
C++ est plus "safe" que C, mais C++ n'empêche pas de faire de la merde non plus avec des cascades de conséquences plus importante.
#4.7
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
Qui ammenait à travers l'exemple du C (et Rust n'y pourrait rien non plus, le pb étant de taper le code généré, y compris le compilo des générations suivantes!) à ce bilan:
"In demonstrating the possibility of this kind of attack, I picked on the C compiler.
I could have picked on any program-handling program..."
Demeure!
Le problème étant que la parade imaginée bien plus tard (au delà du pb de poule et d'oeuf de compilo de confiance posé par la DDC, cf "Here’s Wheeler’s trick" ici: https://www.schneier.com/blog/archives/2006/01/countering_trus.html) ne vise pas les interpréteurs (ou autre bytecode généré à la volée) côté utilisateur.
Décliner le concept du natif/compilé, ce qui est imaginable, poserait en effet un problème existentiel à ce type de langage: Multiplier, à chaque exécution ou 1ère exécution et chez chacun, la pénalité unique de build côté développeur du natif... Ouille!
#4.8
Ton analyse/questionnement est le bon.
Pour simplifier un peu: Rust empêche intrinsèquement les erreurs "non intentionnelles" les plus fréquentes parce que le programmeur est obligé de déclarer son intention de manipuler/partager un espace mémoire.
Rust n'empêche pas les erreurs grossières mais tellement communes "je fais comme ça pour l'instant et je corrigerai plus tard" qui n'est jamais corrigé, ni le fait qu'une bibliothèque vérolée pourrisse un produit, ni une conception trop légère sur la sécu...
#4.9
On pense souvent ça, mais en fait l'architecture de NodeJS est excellente, et permet dans de nombreux cas une meilleure efficacité qu'un programme équivalent en C++.
Par ex. le modèle d'event-loop de NodeJS basé sur libuv permet de meilleurs perfs avec un serveur web NodeJS que Apache.
Il faut vraiment avoir des besoin de calcul à haute performance spécifiques pour que NodeJS ou Python ne conviennent pas.
S'il n'y a pas de besoin de perf en calcul, NodeJS ou Python sont de bien meilleur choix que du code C/C++ pour une application industrielle.
Pour les autres cas il y a Rust ou Go.
Si on se repose sur une peur permanente du dev pour "ne pas relâcher son attention", la partie est déjà perdue. L'attention mise sur des problèmes de gestion mémoire ne sera pas mise sur d'autres aspects.
Par ailleurs, on peut détruire l'efficacité d'un programme C/C++ plus facilement qu'en NodeJS.
Particulièrement en C++, c'est vraiment facile de copier des structures entières et tous leurs enfants en une ligne de code. Comme une std::map(std::string,std::string) passé en argument par valeur.
Ou de rajouter des blocages et des ralentissements significatifs avec des mutex et des locks, alors que NodeJS a une architecture lock-free.
Historique des modifications :
Posté le 04/03/2024 à 15h21
On pense souvent ça, mais en fait l'architecture de NodeJS est excellente, et permet dans de nombreux cas une meilleure efficacité qu'un programme équivalent en C++.
Par ex. le modèle d'event-loop de NodeJS basé sur libuv permet de meilleurs perfs avec un serveur web NodeJS que Apache.
Il faut vraiment avoir des besoin de calcul à haute performance spécifiques pour que NodeJS ou Python ne convienne pas.
S'il n'y a pas de besoin de perf en calcul, NodeJS ou Python sont de bien meilleur choix que du code C/C++ pour une application industrielle.
Pour les autres cas il y a Rust ou Go.
Si on se repose sur une peur permanente du dev pour "ne pas relâcher son attention", la partie est déjà perdue.
L'attention mise sur des problèmes de gestion mémoire ne sera pas mise sur d'autres aspects.
Posté le 04/03/2024 à 15h21
On pense souvent ça, mais en fait l'architecture de NodeJS est excellente, et permet dans de nombreux cas une meilleure efficacité qu'un programme équivalent en C++.
Par ex. le modèle d'event-loop de NodeJS basé sur libuv permet de meilleurs perfs avec un serveur web NodeJS que Apache.
Il faut vraiment avoir des besoin de calcul à haute performance spécifiques pour que NodeJS ou Python ne convienne pas.
S'il n'y a pas de besoin de perf en calcul, NodeJS ou Python sont de bien meilleur choix que du code C/C++ pour une application industrielle.
Pour les autres cas il y a Rust ou Go.
Si on se repose sur une peur permanente du dev pour "ne pas relâcher son attention", la partie est déjà perdue.
L'attention mise sur des problèmes de gestion mémoire ne sera pas mise sur d'autres aspects.
Posté le 04/03/2024 à 15h26
On pense souvent ça, mais en fait l'architecture de NodeJS est excellente, et permet dans de nombreux cas une meilleure efficacité qu'un programme équivalent en C++.
Par ex. le modèle d'event-loop de NodeJS basé sur libuv permet de meilleurs perfs avec un serveur web NodeJS que Apache.
Il faut vraiment avoir des besoin de calcul à haute performance spécifiques pour que NodeJS ou Python ne convienne pas.
S'il n'y a pas de besoin de perf en calcul, NodeJS ou Python sont de bien meilleur choix que du code C/C++ pour une application industrielle.
Pour les autres cas il y a Rust ou Go.
Si on se repose sur une peur permanente du dev pour "ne pas relâcher son attention", la partie est déjà perdue.
L'attention mise sur des problèmes de gestion mémoire ne sera pas mise sur d'autres aspects.
Par ailleurs, on peut détruire l'efficacité d'un programme C/C++ plus facilement qu'en NodeJS.
Particulièrement en C++, c'est vraiment facile de copier des structures entières et tous leurs enfants en un ligne de code. Comme une std::map passé en argument par valeur.
Ou de rajouter des blocages et des ralentissements significatifs avec des mutex et des locks, alors que NodeJS a une architecture lock-free.
Posté le 04/03/2024 à 15h27
On pense souvent ça, mais en fait l'architecture de NodeJS est excellente, et permet dans de nombreux cas une meilleure efficacité qu'un programme équivalent en C++.
Par ex. le modèle d'event-loop de NodeJS basé sur libuv permet de meilleurs perfs avec un serveur web NodeJS que Apache.
Il faut vraiment avoir des besoin de calcul à haute performance spécifiques pour que NodeJS ou Python ne convienne pas.
S'il n'y a pas de besoin de perf en calcul, NodeJS ou Python sont de bien meilleur choix que du code C/C++ pour une application industrielle.
Pour les autres cas il y a Rust ou Go.
Si on se repose sur une peur permanente du dev pour "ne pas relâcher son attention", la partie est déjà perdue. L'attention mise sur des problèmes de gestion mémoire ne sera pas mise sur d'autres aspects.
Par ailleurs, on peut détruire l'efficacité d'un programme C/C++ plus facilement qu'en NodeJS.
Particulièrement en C++, c'est vraiment facile de copier des structures entières et tous leurs enfants en un ligne de code. Comme une std::map(std::string,std::string) passé en argument par valeur.
Ou de rajouter des blocages et des ralentissements significatifs avec des mutex et des locks, alors que NodeJS a une architecture lock-free.
Posté le 04/03/2024 à 15h28
On pense souvent ça, mais en fait l'architecture de NodeJS est excellente, et permet dans de nombreux cas une meilleure efficacité qu'un programme équivalent en C++.
Par ex. le modèle d'event-loop de NodeJS basé sur libuv permet de meilleurs perfs avec un serveur web NodeJS que Apache.
Il faut vraiment avoir des besoin de calcul à haute performance spécifiques pour que NodeJS ou Python ne conviennent pas.
S'il n'y a pas de besoin de perf en calcul, NodeJS ou Python sont de bien meilleur choix que du code C/C++ pour une application industrielle.
Pour les autres cas il y a Rust ou Go.
Si on se repose sur une peur permanente du dev pour "ne pas relâcher son attention", la partie est déjà perdue. L'attention mise sur des problèmes de gestion mémoire ne sera pas mise sur d'autres aspects.
Par ailleurs, on peut détruire l'efficacité d'un programme C/C++ plus facilement qu'en NodeJS.
Particulièrement en C++, c'est vraiment facile de copier des structures entières et tous leurs enfants en un ligne de code. Comme une std::map(std::string,std::string) passé en argument par valeur.
Ou de rajouter des blocages et des ralentissements significatifs avec des mutex et des locks, alors que NodeJS a une architecture lock-free.
Posté le 04/03/2024 à 15h29
On pense souvent ça, mais en fait l'architecture de NodeJS est excellente, et permet dans de nombreux cas une meilleure efficacité qu'un programme équivalent en C++.
Par ex. le modèle d'event-loop de NodeJS basé sur libuv permet de meilleurs perfs avec un serveur web NodeJS que Apache.
Il faut vraiment avoir des besoin de calcul à haute performance spécifiques pour que NodeJS ou Python ne conviennent pas.
S'il n'y a pas de besoin de perf en calcul, NodeJS ou Python sont de bien meilleur choix que du code C/C++ pour une application industrielle.
Pour les autres cas il y a Rust ou Go.
Si on se repose sur une peur permanente du dev pour "ne pas relâcher son attention", la partie est déjà perdue. L'attention mise sur des problèmes de gestion mémoire ne sera pas mise sur d'autres aspects.
Par ailleurs, on peut détruire l'efficacité d'un programme C/C++ plus facilement qu'en NodeJS.
Particulièrement en C++, c'est vraiment facile de copier des structures entières et tous leurs enfants en une ligne de code. Comme une std::map(std::string,std::string) passé en argument par valeur.
Ou de rajouter des blocages et des ralentissements significatifs avec des mutex et des locks, alors que NodeJS a une architecture lock-free.
#4.10
Toujours regarder en détail les benchmarks, sinon, on y voit ce que l'on veut ;)
En l'occurence, je vois 2 gros points noirs qui viennent complètement fausser la comparaison :
- Apache + PHP, et non Apache + FastCGI/PHP (un context PHP est recréé à chaque requête, forcément, ça fait mal)
- A une époque pas si lointaine, les serveur nodeJS n'étaient jamais en front, toujours derrière un reverse proxy comme... Apache (les choses ont peut être changées depuis, d'où l'usage du passé). Quand on commençait à vouloir faire de la mise en cache, de la compression gzip à la volée ou même tout simplement du SSL/TLS, nodeJS était nul, sans compter sur l'explosion de la mémoire nécessaire.
#4.11
Surtout que maintenant on met du WAF devant les applications.
Après, ma remarque trollesque sur NodeJS (mais les explications données ensuite étaient très intéressantes, merci aux intervenants) venait surtout du point de vue de quelqu'un qui ne comprend pas pourquoi il faut démarrer un serveur web qui exécute le moteur Javascript de Chromium pour faire un éditeur de texte sur son PC.
C'est une caricature, mais à un moment, je me dis qu'on a foiré une étape en chemin. Sans parler de la surface d'attaque qui s'élargit forcément car on empile les runtimes et les dépendances.
Certes, ça permet aussi de faire des applications extrêmement portables, VSCode en version Web c'est très pratique (GitHub Codespace reposant là dessus) et Diagram.net est un formidable outil. Mais y'a toujours un truc qui me gêne avec cette techno et la multitude de produits désormais basés dessus. Un peu comme les appImage qui pullulent sous Linux pour compenser la multiplicité des distribs en préférant ramener des bulldozers de 45 tonnes pour le moindre logiciel avec une régression monumentale en terme de gestion de packages (en gros, aucune).
#5
Historique des modifications :
Posté le 04/03/2024 à 08h53
[troll]Biden décide de s'occuper des problèmes de mémoire. Il était temps.[/troll]
#5.1
#6
Non.
La Maison-Blanche exhorte les développeurs à utiliser des langages de programmation "memory safe".
Donc effectivement d'abandonner C/C++ comme à titré le Monde Informatique.
Mais pas de passer à RUST comme titre NXI.
C'est dingue de constater que Le Monde Informatique a mieux compris l'information que NXI.
#6.1
Il y a un paragraphe entier intitulé « Rust cité en exemple », qui précise « Dans son rapport de 19 pages, l'ONCD cite le C et le C++ comme deux exemples de langages présentant des vulnérabilités en matière de sécurité de la mémoire, et qualifie Rust comme sûr. »
La source précise effectivement « there are dozens of memory safe programming languages that can – and should – be used », mais seul Rust est nommément cité.
#6.5
Voila. ni plus ni moins.
Idem dans la note de la NSA:
Les langages sont simplement cités dans l'ordre alphabétique, sans indiquer de préférence. De plus, la note indique que les fabricants doivent en évaluer plusieurs. Donc pas foncer tête baisser vers RUST.
Historique des modifications :
Posté le 04/03/2024 à 09h47
Rust est cité une seule fois dans le rapport de l'ONCD. ici:
Voila. ni plus ni mois.
Idem dans la note de la NSA:
Les langages sont simplement cités dans l'ordre alphabétique, sans indiquer de préférence. De plus, la note indique que les fabricants doivent en évaluer plusieurs. Donc pas foncer tête baisser vers RUST.
#6.10
#6.2
Normalement, un dev sait comment un ordi fonctionne, sait comment un processus vit en mémoire, sait comment le code et les données sont agencées dans l'espace mémoire du process et sait comment le langage ordonne les données en mémoire.
A quoi bon bouffer des perfs en compil et en execution pour faire des contrôles inutiles dans la mesure où le dev a déjà fait le travail ?
#6.6
Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà s'apercevoir que c'en est un) parce qu'on sait qu'elle n'a pas les compétences pour maîtriser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirai pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles, y compris de ceux pour qui on développe quand on doit livrer les sources.
Donc par exemple (choisis vite faits), OK pour mettre du C avec des vrais morceaux d'assembleur dans un encodeur vidéo, mais certainement pas dans un logiciel de gestion de quelque chose en entreprise où on ne mettra sans doute même pas du C++ mais plutôt un des langages "sécurisés" cités dans l'article, quand c'est pas carrément du Web (bon ça c'est surtout pour la facilité d'accès depuis n'importe où).
Historique des modifications :
Posté le 04/03/2024 à 10h07
C'est un vaste débat qui dure depuis la nuit des temps. Au final, au-delà des positions tranchées, je dirais que ça dépend de l'utilisation finale du programme, de ses performances souhaitées, des contraintes techniques (puissance CPU, espace mémoire vive et mémoire programme), du temps de développement disponible et de la compétence des développeurs.
Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà savoir que c'en est un) parce qu'on sait qu'elle n'a pas l'expérience et la rigueur suffisante pour utiliser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirais pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles.
Posté le 04/03/2024 à 10h11
C'est un vaste débat qui dure depuis la nuit des temps. Au final, au-delà des positions tranchées, je dirais que ça dépend de l'utilisation finale du programme, de ses performances souhaitées, des contraintes techniques (puissance CPU, espace mémoire vive et mémoire programme), du temps de développement disponible et de la compétence des développeurs.
Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà savoir que c'en est un) parce qu'on sait qu'elle n'a pas l'expérience et la rigueur suffisante pour utiliser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirais pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles.
Donc par exemple (choisis vite faits), OK pour mettre de l'assembleur dans un encodeur vidéo, mais certainement pas dans un logiciel de gestion de quelque chose en entreprise où on ne mettra sans doute même pas du C++ mais plutôt un des langages "sécurisés" cités dans l'article.
Posté le 04/03/2024 à 10h12
C'est un vaste débat qui dure depuis la nuit des temps. Au final, au-delà des positions tranchées, je dirais que ça dépend de l'utilisation finale du programme, de ses performances souhaitées, des contraintes techniques (puissance CPU, espace mémoire vive et mémoire programme), du temps de développement disponible et de la compétence des développeurs. Sinon on fait tous de l'assembleur en binaire et y a même plus besoin de compiler.
Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà savoir que c'en est un) parce qu'on sait qu'elle n'a pas l'expérience et la rigueur suffisante pour utiliser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirais pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles.
Donc par exemple (choisis vite faits), OK pour mettre de l'assembleur dans un encodeur vidéo, mais certainement pas dans un logiciel de gestion de quelque chose en entreprise où on ne mettra sans doute même pas du C++ mais plutôt un des langages "sécurisés" cités dans l'article.
Posté le 04/03/2024 à 10h13
C'est un vaste débat qui dure depuis la nuit des temps. Au final, au-delà des positions tranchées, je dirais que ça dépend de l'utilisation finale du programme, de ses performances souhaitées, des contraintes techniques (puissance CPU, espace mémoire vive et mémoire programme), du temps de développement disponible et de la compétence des développeurs. Sinon on fait tous de l'assembleur en binaire et y a même plus besoin de compiler.
Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà savoir que c'en est un) parce qu'on sait qu'elle n'a pas l'expérience et la rigueur suffisante pour utiliser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirais pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles, y compris de ceux pour qui on développe quand on doit livrer les sources.
Donc par exemple (choisis vite faits), OK pour mettre de l'assembleur dans un encodeur vidéo, mais certainement pas dans un logiciel de gestion de quelque chose en entreprise où on ne mettra sans doute même pas du C++ mais plutôt un des langages "sécurisés" cités dans l'article.
Posté le 04/03/2024 à 10h14
C'est un vaste débat qui dure depuis la nuit des temps. Au final, au-delà des positions tranchées, je dirais que ça dépend de l'utilisation finale du programme, de ses performances souhaitées, des contraintes techniques (puissance CPU, espace mémoire vive et mémoire programme), du temps de développement disponible et de la compétence des développeurs. Sinon on fait tous de l'assembleur en binaire et y a même plus besoin de compiler.
Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà savoir que c'en est un) parce qu'on sait qu'elle n'a pas l'expérience et la rigueur suffisante pour utiliser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirais pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles, y compris de ceux pour qui on développe quand on doit livrer les sources.
Donc par exemple (choisis vite faits), OK pour mettre de l'assembleur dans un encodeur vidéo, mais certainement pas dans un logiciel de gestion de quelque chose en entreprise où on ne mettra sans doute même pas du C++ mais plutôt un des langages "sécurisés" cités dans l'article, quand c'est pas carrément du Web (bon ça c'est surtout pour la facilité d'accès depuis n'importe où).
Posté le 04/03/2024 à 10h17
C'est un vaste débat qui dure depuis la nuit des temps. Au final, au-delà des positions tranchées, je dirais que ça dépend de l'utilisation finale du programme, de ses performances souhaitées, des contraintes techniques (puissance CPU, espace mémoire vive et mémoire programme), du temps de développement disponible et des compétences des développeurs. Sinon on fait tous de l'assembleur en binaire et y a même plus besoin de compiler.
Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà s'apercevoir que c'en est un) parce qu'on sait qu'elle n'a pas l'expérience et la rigueur suffisante pour utiliser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirais pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles, y compris de ceux pour qui on développe quand on doit livrer les sources.
Donc par exemple (choisis vite faits), OK pour mettre de l'assembleur dans un encodeur vidéo, mais certainement pas dans un logiciel de gestion de quelque chose en entreprise où on ne mettra sans doute même pas du C++ mais plutôt un des langages "sécurisés" cités dans l'article, quand c'est pas carrément du Web (bon ça c'est surtout pour la facilité d'accès depuis n'importe où).
Posté le 04/03/2024 à 10h17
C'est un vaste débat qui dure depuis la nuit des temps. Au final, au-delà des positions tranchées, je dirais que ça dépend de l'utilisation finale du programme, de ses performances souhaitées, des contraintes techniques (puissance CPU, espace mémoire vive et mémoire programme), du temps de développement disponible et des compétences des développeurs. Sinon on fait tous de l'assembleur en binaire et y a même plus besoin de compiler.
Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà s'apercevoir que c'en est un) parce qu'on sait qu'elle n'a pas l'expérience et la rigueur suffisante pour utiliser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirais pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles, y compris de ceux pour qui on développe quand on doit livrer les sources.
Donc par exemple (choisis vite faits), OK pour mettre de l'assembleur dans un encodeur vidéo, mais certainement pas dans un logiciel de gestion de quelque chose en entreprise où on ne mettra sans doute même pas du C++ mais plutôt un des langages "sécurisés" cités dans l'article, quand c'est pas carrément du Web (bon ça c'est surtout pour la facilité d'accès depuis n'importe où).
Posté le 04/03/2024 à 10h19
C'est un vaste débat qui dure depuis la nuit des temps. Au final, au-delà des positions tranchées, je dirais que ça dépend de l'utilisation finale du programme, de ses performances souhaitées, des contraintes techniques (puissance CPU, espace mémoire vive et mémoire programme), du temps de développement disponible et des compétences des développeurs. Sinon on fait tous de l'assembleur en binaire et y a même plus besoin de compiler.
Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà s'apercevoir que c'en est un) parce qu'on sait qu'elle n'a pas les compétences pour maîtriser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirais pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles, y compris de ceux pour qui on développe quand on doit livrer les sources.
Donc par exemple (choisis vite faits), OK pour mettre de l'assembleur dans un encodeur vidéo, mais certainement pas dans un logiciel de gestion de quelque chose en entreprise où on ne mettra sans doute même pas du C++ mais plutôt un des langages "sécurisés" cités dans l'article, quand c'est pas carrément du Web (bon ça c'est surtout pour la facilité d'accès depuis n'importe où).
Posté le 04/03/2024 à 10h19
C'est un vaste débat qui dure depuis la nuit des temps. Au final, au-delà des positions tranchées, je dirais que ça dépend de l'utilisation finale du programme, de ses performances souhaitées, des contraintes techniques (puissance CPU, espace mémoire vive et mémoire programme), du temps de développement disponible et des compétences des développeurs. Sinon on fait tous de l'assembleur en binaire et y a même plus besoin de compiler.
Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà s'apercevoir que c'en est un) parce qu'on sait qu'elle n'a pas les compétences pour maîtriser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirai pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles, y compris de ceux pour qui on développe quand on doit livrer les sources.
Donc par exemple (choisis vite faits), OK pour mettre de l'assembleur dans un encodeur vidéo, mais certainement pas dans un logiciel de gestion de quelque chose en entreprise où on ne mettra sans doute même pas du C++ mais plutôt un des langages "sécurisés" cités dans l'article, quand c'est pas carrément du Web (bon ça c'est surtout pour la facilité d'accès depuis n'importe où).
#6.7
#6.14
C'est l'humain le soucis et c'est l'idée de se baser sur la capacité d'un dev à ne pas commettre d'erreur qui est une erreur.
#6.16
#6.19
Rust pour le coup serait un très bon langage pour ces personnes-là en leur forçant à réexaminer le code que le compilateur refusera et de voir où les possibilité de condition de course ou d'aliasing interviennent, ce leur serait d'un grand apprentissage. Mais malheureusement leur ego, qui n'a d'égale que leur sentiment d'excellence, ne leur permet pas ce genre de remise en question.
Si tu es dans cette catégorie, je te souhaite de courage pour gérer les bugs sur le field. Mais je sais, ça ne doit jamais t'arriver ;)
Historique des modifications :
Posté le 05/03/2024 à 16h56
Et les bugs sur le terrain, c'est toujours de la faute de leurs clients, rayonnements cosmiques, ou parce que le système n'est pas configuré comme chez eux, n'est-ce pas ?
Rust est pour le coup serait très bon langage pour ces personnes-là en leur forcçant à rééxaminer le code que le compilateur refusera et de voir où les possibilité de condition de course ou d'aliasing interviennent, ce leur serait un grand apprentissage. Mais malheureusement leur ego, qui n'a d'égale que leur sentiment d'excellence, ne leur permet pas se genre de remise en question.
Si tu es dans cette catégorie, je te souhaite de courage pour gérer les bugs sur le field. Mais je sais que ça ne doit jamais t'arriver ;)
Posté le 05/03/2024 à 16h56
Et les bugs sur le terrain, c'est toujours de la faute de leurs clients, rayonnements cosmiques, ou parce que le système n'est pas configuré comme chez eux, n'est-ce pas ?
Rust est pour le coup serait très bon langage pour ces personnes-là en leur forçant à réexaminer le code que le compilateur refusera et de voir où les possibilité de condition de course ou d'aliasing interviennent, ce leur serait un grand apprentissage. Mais malheureusement leur ego, qui n'a d'égale que leur sentiment d'excellence, ne leur permet pas se genre de remise en question.
Si tu es dans cette catégorie, je te souhaite de courage pour gérer les bugs sur le field. Mais je sais que ça ne doit jamais t'arriver ;)
Posté le 05/03/2024 à 16h56
Et les bugs sur le terrain, c'est toujours de la faute de leurs clients, rayonnements cosmiques, ou parce que le système n'est pas configuré comme chez eux, n'est-ce pas ?
Rust est pour le coup serait très bon langage pour ces personnes-là en leur forçant à réexaminer le code que le compilateur refusera et de voir où les possibilité de condition de course ou d'aliasing interviennent, ce leur serait d'un grand apprentissage. Mais malheureusement leur ego, qui n'a d'égale que leur sentiment d'excellence, ne leur permet pas ce genre de remise en question.
Si tu es dans cette catégorie, je te souhaite de courage pour gérer les bugs sur le field. Mais je sais que ça ne doit jamais t'arriver ;)
Posté le 05/03/2024 à 16h57
Et les bugs sur le terrain, c'est toujours de la faute de leurs clients, rayonnements cosmiques, ou parce que le système n'est pas configuré comme chez eux, n'est-ce pas ?
Rust pour le coup serait très bon langage pour ces personnes-là en leur forçant à réexaminer le code que le compilateur refusera et de voir où les possibilité de condition de course ou d'aliasing interviennent, ce leur serait d'un grand apprentissage. Mais malheureusement leur ego, qui n'a d'égale que leur sentiment d'excellence, ne leur permet pas ce genre de remise en question.
Si tu es dans cette catégorie, je te souhaite de courage pour gérer les bugs sur le field. Mais je sais que ça ne doit jamais t'arriver ;)
#6.8
Dans la gestion des risques, les mesures de contrôle "by design" doivent être privilégiées si elles existent.
Avec ce rapport, les autorités US rappellent aux fabricants que ca existe et qu'ils doivent donc les utiliser.
#6.9
Et c'est tellement facile d'utiliser un pointeur après avoir libéré la mémoire dans un programme à états.
#6.11
#6.12
Va falloir inventer le langage de programmation inclusif, piquant les yeux à l'écrit et imprononçable à l'oral, imposant d'oublier "l'accord" qui ferait écrire "developpeur-euse" sonnant trop "develop-peureuse" et bouclerait la boucle de l'inclusif au stigmatisant!
Bon, sur le fond du problème on en revient à des préoccupations très typiques des USA: Liability menant au Foolproof (littéralement: "A l'épreuve des cons"), par conception et/ou parades/avertissements.
Les conséquences chez eux allant du "Objects in the mirror are smaller than they appear" (sans déconner!) gravé sur les rétros de bagnole à des matériels conçus pour presque tout pardonner niveau erreurs de l'utilisateur. Quand c'est trop difficile voir impossible (aviation...), cela peut mener à la faillite des constructeurs sur un seul évènement. Y'a bien que le sacro-saint flingue qui chez eux échappe au concept.
#6.15
Historique des modifications :
Posté le 04/03/2024 à 16h30
Va boire ta camomille
#6.17
Depuis l'EFS écrit de nouveau en français. Un bilan qui vaut sans doute bien des sondages.
#6.18
Je ne supporte pas ta façon de raisonner mais pourtant je considère que tu as le droit de t'exprimer. Tu ne me portes pas irrespect comme le commentaire plus haut ne te porte atteinte en aucune manière.
#6.21
Ce qu'oublient les adorateurs de l'écriture inclusive excluante, c'est qu'en plus d'excluer totalement les non-binaires, elle n'est aucunement prononcable à l'oral. Alors que l'écriture n'est là QUE pour coucher l'oral, et rien d'autre.
#6.25
#6.27
In-fine, comme ils ne viennent pas, l'EFS ne pouvait pas se permettre d'irriter ceux qui viennent pour quelques fio
Et de ré-écrire en français lisible et même prononçable...
Historique des modifications :
Posté le 06/03/2024 à 12h10
Ce qui ressortait de cette affaire au delà du problème d'écrire en français, c'est que les minorités concernées qui ont fait des pieds et des mains des décennies pour pouvoir donner, amenant sans doute à ces point-débiles-pseudo-inclusifs dans les com de l'EFS, sont plus fortiches pour réclamer des droits que pour les devoirs qui en résultent.
qui aiment visiblement plus râler que les piqures!
In-fine, comme ils ne viennent pas, l'EFS ne pouvait pas se permettre d'irriter ceux qui viennent pour quelques fio
Et de ré-écrire en français lisible et même prononçable...
#6.56
Ha mais tu réussis vraiment bien à montrer que le problème que tu as avec cette comm' se situe au niveau de la langue française et pas un problème viscéral contre ces personnes
#6.60
Je dirais que ça a démarré avec la gay-pride: Franchement, qui a envie en croisant cela dans Paris avec ses gosses de leur expliquer pourquoi 2 mecs/nanas se paluchent, ou ce que la grande folle en talons cambrée comme la vache qu'on amène au taureau a logé dans le fion?
Et ça c'était avant qu'ils ne demandent la PMA (le M c'est pour médical, rappelons le) pour toutes (sans logique vs des préférences sexuelles rendant l'affaire normalement impossible) en attendant la mère porteuse pour tous, par souçi d'égalité...
Il y a un moment ou cela pose en effet un problème qui peut devenir viscéral, mais merci de ne pas confondre cause et conséquence.
#6.61
J'ose espérer qu'ils peuvent s'exprimer suffisamment librement que pour pouvoir te poser des questions hautement plus intimes que ça sans avoir à sentir qu'il y a un problème parce que ça dérange papa ou maman.
Historique des modifications :
Posté le 12/03/2024 à 17h47
C'est triste de s'attendre à ce que tes gosses ne te demandent rien de plus compliquer que d'expliquer pourquoi 2 personnes peuvent s'aimer quelque soit leur genre.
J'ose espérer qu'ils peuvent s'exprimer suffisamment librement que pour pouvoir te poser des questions hautement plus intimes que ça sans avoir à sentir qu'il y a un problème parce que ça dérange papa ou maman.
#6.62
#6.20
#6.22
#6.23
Victor Hugo
Mais tu considères aussi qu'un bon dev est un dev qui ne fait jamais d'erreur malgré le fait d'être un humain. Ca ne doit pas te sembler impossible d'arrêter le soleil non plus
Historique des modifications :
Posté le 06/03/2024 à 10h13
«[La] langue française n’est point fixée et ne se fixera point. Une langue ne se fixe pas. L’esprit humain est toujours en marche, ou, si l’on veut, en mouvement, et les langues avec lui. Les choses sont ainsi. […] Toute époque a ses idées propres, il faut qu’elle ait aussi les mots propres à ces idées. Les langues sont comme la mer : elles oscillent sans cesse. À certains temps, elles quittent un rivage du monde de la pensée et en envahissent un autre. Tout ce que leur flot déserte ainsi sèche et s’efface du sol. C’est de cette façon que des idées s’éteignent, que des mots s’en vont. Il en est des idiomes humains comme de tout. Chaque siècle y apporte et en emporte quelque chose. Qu’y faire ? cela est fatal. C’est donc en vain que l’on voudrait pétrifier la mobile physionomie de notre idiome sous une forme donnée. C’est en vain que nos Josué littéraires crient à la langue de s’arrêter; les langues ni le soleil ne s’arrêtent plus. Le jour où elles se fixent, c’est qu’elles meurent.»
Victor Hugo
Mais tu considères aussi qu'un bon dev est un dev qui ne fait jamais d'erreur malgré le fait d'être un humain. Ca ne doit pas te sembler impossible d'arrêter le soleil non plus
#6.28
Maintenant, c'est mon avis. Le sien on ne l'aura jamais et je ne me permettrait certainement pas de me raccrocher à ses écrits pour soutenir mes propres opinions.
#6.26
et puis bon, directement les grands mots, comme "détruire la langue" ... que de balivernes. On est dans un monde qui bouge et change, et s'efforcer de garder la langue au 17è siècle n'est pas lui faire honneur, et ce n'est pas non-plus faire confiance à celleux qui la pratiquent.
#6.13
https://github.com/TNZfr/watchfreq
Edit : Eh bé ... 22 clones du dépôt en 5 heures. :)
Historique des modifications :
Posté le 04/03/2024 à 15h27
Du coup, que penses tu de ce petit programme de monitoring des fréquences CPU en C, écrit le nez au vent sans notes, juste avec le schéma de données en tête ?
https://github.com/TNZfr/watchfreq
#6.24
Il ne démontre aucune compréhension spécifique de l'architecture d'un ordinateur. Faire des malloc, utiliser le keyword "register" ou savoir comment récupérer les fréquence du CPU via sysfs ça n'est pas de la compréhension du fonctionnement d'un ordinateur. Tu sais coder en C et utiliser certaines API du système Linux.
La remarque de Stéphane sur le fait d'être un Dieu s'attache plutôt à critiquer la remarque qui était que si tu sais comment l'ordinateur fonctionne, alors il est à ta charge de gérer l'intégrité de la mémoire et que, au final, c'est facile de ne jamais faire de bourde puisque tu sais comment ça fonctionne.
Tu es inhumain si tu es capable de guarantir que tu ne commetras aucune erreur de distraction qui aboutiront à des problèmes de mémoire si tu n'as pas l'assitance d'outils (et il en existe en C aussi).
Là aussi ton projet ne démontre rien, sa complexité est trop basse pour prouver que tu as cette qualité qu'on trouve inhumaine ;)
Historique des modifications :
Posté le 06/03/2024 à 10h40
Ce projet est vraiment sensé pouvoir démontrer quelque chose ?
Il ne démontre aucune compréhension spécifique de l'architecture d'un ordinateur. Faire des malloc, utiliser le keyword "register" ou savoir comment récupérer les fréquence du CPU via sysfs ça n'est pas de la compréhension du fonctionnement d'un ordinateur. Tu sais coder en C et utiliser certaines API du système Linux.
La remarque de Stéphane sur le fait d'être un Dieu s'attache plutôt à critiquer la remarque qui était que si tu sais comment l'ordinateur fonctionne, alors il est à ta charge de gérer l'intégrité de la mémoire et que, au final, c'est facile de ne jamais faire de bourde puisque tu sais comment ça fonctionne.
Tu es inhumain si tu es capable de guarantir que tu ne commetras aucune erreur de distraction qui aboutiront à des problèmes de mémoire si tu n'as pas l'assitance d'outils (et il en existe en C aussi).
Là aussi ton projet ne démontre rien, sa complexité est trop basse pour prouver que tu as cette qualité qu'on trouve inhumaine ;)
#6.29
Et pour peu que tu aies compris les mécanismes codés ... lire 3 lignes et reconnaître une arborescence linux et un ou 2 mots-clés du langage ne fait pas de toi un critique crédible. Tu as regardé la surface et tu es passé à côté de l'algo.
Historique des modifications :
Posté le 06/03/2024 à 22h09
Fais mieux et après on cause !
#6.30
- fonction GetNbCore() : aucune vérification sur l'accès au pipe, ni aucune gestion des erreurs.
- fonction read_freq() :
- idem, aucune vérification quant aux accès au système de fichiers
- pas de vérification de la valeur de retour des appels à malloc
- je ne vais pas dire que la mémoire n'est pas libérée, puisque ton application à juste besoin d'allouer de la mémoire au début une fois pour toute au début de l'application. Une fois qu'on est dans la boucle principale, aucune allocation n'est faite.
Je m'arrête là pour l'analyse. Un attaquant aurait de quoi largement faire avec ce petit programme ^^ Surtout qu'il y a d'autres problèmes (mais pas lié au langage lui-même).
#6.31
Contrôle du système de fichiers : surtout sur une arborescence mémoire montée par le noyau (et donc mécaniquement présente sinon tu n'aurais pas même pu te connecter à la machine).
Un contrôle de malloc unitaire sur des tailles maîtrisées (dépendant du nombre de cores/threads et non d'un paramètre utilisateur) ... t'es gentil. Tu passerais ton temps à faire des malloc / realloc dans des boucles et/ou des malloc dépendants de paramètres utilisateur (donc potentiellement déconnants), là, oui le contrôle des valeurs retournées est obligatoire.
Et au jeu des vérifications, j'ai aussi oublié de contrôler l'espace disque disponible (ben oui puisqu'il y a des fopen), les T° CPU / carte mère (ben oui, ça boucle) et l'âge du capitaine.
Effectivement, tu fais bien d'arrêter ... parce qu'enfoncer les portes ouvertes des « bonnes » pratiques trouvées sur wikipedia, n'importe quel script-kiddie en est capable. Tu n'as même pas essayé de comprendre l'algo (d'ailleurs personne n'en a parlé) et pourquoi les contrôles que tu dénonces manquants ne sont pas nécessaires.
Maintenant, puisque tu as trouvé des « failles », je te propose de mettre à jour le bout de code et de nous montrer comment il devrait être. Toutefois, il faut que :
* ça compile sans warning,
* ça reste maintenable CàD compréhensible par quelqu'un qui découvre le code pour la 1ere fois (ça c'est pas simple)
* les perfs ne soient pas dégradées : CàD une conso CPU qui ne polluera pas les mesures.
Enjoy !
(d'où le fameux « keep it simple, stupid ! »)
#6.32
Depuis quand "la plupart des programmes" c'est une justification pour faire quelque chose qui s'apparente à une mauvaise pratique ?
Et puis, pas de bol, je ne parlais pas de ça (du aoti). Je parlais d'aller lire un flux sans même savoir s'il est ouvert correctement ou pas.
Il est effectivement impossible d'avoir un programme tournant dans un environnement "sécurisé" comme les conteneurs, un chroot, ou dont l'accès à cette partie du système de fichier est interdite via des règles de gestion fine. De même qu'il est impossible que la limite du nombre de descripteur de fichiers ouverts soit atteinte. Tant de certitude...
Es-tu certains à 100% que les appels à malloc soient maitrisés ? Moi non. Le premier dépend de la valeur de retour du programme "nproc" : le premier programme "nproc" trouvé qui sera dans le PATH (c'est ça la faille qui ne dépend pas du langage : utilisation d'un programme sans préciser son chemin absolu, permettant de le substitué très facilement). Ton nproc renvoi 100000000 et boum.
En gros, ton programme, je peux lui faire consommer 4Go très facilement si j'en ai envie. Toujours maitrisé donc ?
De plus, tu sembles considérer des ordinateurs avec une mémoire de plusieurs Go. Sache que Linux tourne sur de nombreux terminaux. Par exemple, des routeurs. Celui que j'ai et sur lequel tourne OpenWRT ne dispose plus que de quelques ko (oui oui, quelques ko !).
Que d'arrogance.... Que répondre à ça, si ce n'est que tu ne sembles même pas comprendre les bases de la sécurité informatique dans les programmes...
En toute honnêteté, on s'en fiche de ton algo. C'est pas le but de la discussion. Le but c'est l'apport d'un langage comme le Rust par rapport au C.
Et moi je maintiens qu'ils sont nécessaires. Pas pour le cas "normal" (on est d'accord la-dessus). Mais un attaquant qui cherche à exploiter une faille n'en à rien à faire du cas normal. Ce qui l'intéresse, ce sont les effets de bords exploitables.
Et désolé de te le dire, mais ton programme, pourtant court, présente de nombreuses failles que ton orgueil refuse de considérer.
Pas de souci. Je peux. Où puis-je t'adresser mon devis ?
#6.33
Tu nous fais le chapitre du programmeur absolu qui ne sait pas contextualiser. Et justement, la contextualisation permet d'ajuster le code avec ce qui est nécessaire. C'est un ensemble. Pour faire tourner une application dans un datacenter la composante plateforme de production est très importante (puissance de calcul, système d'exploitation ...) dans la conception du code.
Je vais faire le vieux con et j'aime pas ça : un programme ne tourne pas tout seul, il lui faut un OS et une machine pour fonctionner. Si tu ne tiens pas compte de ces paramètres, aucun programme ne pourra être dans les clous des règles de programmation, à part HelloWorld, et encore, y'a des fois où certains arrivent à faire de la m*rde avec ce dernier. Mais bon, pour ça, il faut avoir un peu plus de bagages que des formations médailles en chocolat de paramétrage de frameworks en java. Tout le monde sait qu'avec Java, on a pas besoin de machine et de système d'exploitation !
#6.34
Si, pour toi, une réponse détaillée comme je l'ai fait, ce n'est qu'effleurer la surface... Tu dis ça parce qu'on ne s'intéresse pas à l'algo qu'il y a derrière ? Tu veux des félicitations pour quoi ? Pour le fait d'avoir 2 buffers qui contiennent la valeur courante et la valeur précédente, et que tu switch de l'un à l'autre avec un pointeur sur la base d'un modulo 2 ? Ok, félicitation.
Et il est vrai que tu ne campes pas sur tes positions non plus
C'est là où tu fais une énorme erreur. Ce n'est pas que je ne sais pas contextualiser. C'est que ton outil, il est dispo en ligne et en open-source. Tu ne peux pas savoir COMMENT il sera utilisé, ni par QUI. (En fait, je ne devrais pas dire open source, car il n'y a pas de licence. Il est en source available).
Ne sachant ni comment, ni par qui, tu ne peux pas savoir s'il va être utilisé ou pas pour y exploiter des failles. Et je t'ai donné l'exemple d'une faille qui est présente.
Justement ! (sur la partie en gras). Un programme ne tourne pas tout seul. Ton cas d'usage perso, pour lequel tu l'as développé, c'est peut être OK pour toi. Maintenant, je le répète :ton programme est en ligne. Du coup, tu ne peux pas savoir s'il est utilisé ou non, ni comment, ni par qui, ni dans quel environnement.
Ne sachant pas tout ça, tu dois protéger au maximum pour éviter les problèmes et les failles. Ton programme ne serait utilisé que par toi, sur ton serveur avec 16Go RAM utilisant une Debian12 à jour dont le seul accès est un SSH par clé 4096bits en utilisateur simple. Oui, ton programme suffit tel qu'il est. Sauf que ce cas d'utilisation, tu ne peux pas le garantir. C'est aussi simple que ça, et c'est ça qu'a priori, tu ne comprends pas.
Hmmm, mon trollomètre détecte une attaque ad hominem. Et si tu apportais une réponse précise sur des bases techniques, au lieu de vouloir t'attaquer aux compétences de ton interlocuteur ?
#6.35
Heu, non, au "pire" il y a un dépassement de buffer. Ni l'initialisation de l'array de caractères sur le stack ni le fread ne peuvent garantir qu'il y aura bien un byte nul pour terminer la string. S'il y a un byte nul, c'est par chance parce que le stack n'a pas encore réutilisé de l'espace déjà initilalisé par un appel précédent.
char Buffer[16] = "";
ça garantit juste que Buffer[0] est le caractère nul, mais ne dit rien des 15 autres, qui vont simplement récupérer ce qui traîne sur le stack.
#6.36
Mais, quand tu regardes ce pourquoi la variable va être utilisée, la plage de valeurs recues est très limitée. A vrai dire, j'aurai pu réduire la taille de la variable car la valeur la plus grande est sur 10 caractères, donc un Buffer[11] aurait fait le job.
Et pour finir avec les strings, la commande donnée au popen retourne une string, donc une série de caractères terminée par un 0 binaire. Du coup, je suis sûr d'avoir une string en bon et dûe forme dans le atoi ...
C'est dingue ce que le manque d'XP et une croyance universitaire crasse peuvent faire dire.
Historique des modifications :
Posté le 09/03/2024 à 09h24
En absolu, d'un point de vue purement universitaire et théorique ... tu as raison.
Mais, quand tu regardes ce pourquoi la variable va être utilisée, la plage de valeurs recues est très limitée. A vrai dire, j'aurai pu réduire la taille de la variable car la valeur la plus grande est sur 12 caratères, donc un Buffer[13] aurait fait le job.
Un « char Buffer[16] = ""; » te garanti un Buffer[0]=0; ou *Buffer=0; ... la valeur des 15 autres, quelque part, on s'en tape : soit ils ne sont pas lus soit ils sont écrasés lors des manipulations de string. La gestion de string dans la libc s'arrête sur 0 binaire.
Posté le 09/03/2024 à 09h26
En absolu, d'un point de vue purement universitaire et théorique ... tu as raison.
Mais, quand tu regardes ce pourquoi la variable va être utilisée, la plage de valeurs recues est très limitée. A vrai dire, j'aurai pu réduire la taille de la variable car la valeur la plus grande est sur 10 caractères, donc un Buffer[11] aurait fait le job.
Un « char Buffer[16] = ""; » te garanti un Buffer[0]=0; ou *Buffer=0; ... la valeur des 15 autres, quelque part, on s'en tape : soit ils ne sont pas lus soit ils sont écrasés lors des manipulations de string. La gestion de string dans la libc s'arrête sur 0 binaire.
Posté le 09/03/2024 à 09h31
En absolu, d'un point de vue purement universitaire et théorique ... tu as raison.
Mais, quand tu regardes ce pourquoi la variable va être utilisée, la plage de valeurs recues est très limitée. A vrai dire, j'aurai pu réduire la taille de la variable car la valeur la plus grande est sur 10 caractères, donc un Buffer[11] aurait fait le job.
#6.37
Non, passer Buffer à 11 ou une quelconque autre valeur ne changera rien à l'affaire (et je passe sur le fait que tu hard-codes la taille du buffer au lieu d'utiliser une constante...) . Le simple fait que tu le proposes prouve que tu n'as rien compris. Le problème ce n'est pas le fread qui va écrire trop loin, ce n'est pas un buffer potentiellement trop petit, c'est le atoi qui va lire trop loin car rien ne garantit que le buffer sera terminé par un zéro binaire.
Car non, la commande passée à popen ne renvoie pas une string, elle renvoie un stream de bytes que fread va mettre dans la variable Buffer. Mais cela ne constitue pas une "string" au sens C car le stream ne contient pas de zéro binaire en fin, et fread n'en mettra pas. Pour mettre un tel byte nul en fin, il eut fallu faire un truc du genre (de tête et quick-n-dirty, et pas portable car suppose que sizeof(char) == 1, mais obligé vu que tu n'as pas jugé utile de définir un constante pour la taille du buffer) :
Buffer[fread(Buffer,1,sizeof(Buffer)-1,fd)] = '\0';
Note à quel point c'est différent de ce que tu as écrit, notamment il faut lire au maximum 15 éléments de taille 1, et non 1 élément de taille 15 de façon que fread renvoie le nombre de bytes lus histoire qu'on puisse accoler un NUL en fin.
Ou alors... utiliser fgets() ???
Tout ceci prouve que tu n'as jamais écrit du code qui fonctionne autrement que par hasard et sur ta propre machine. Donc, au niveau expérience, évite de voir la paille dans l'oeil de ton voisin, ça t'évitera de passer pour un noob.
Historique des modifications :
Posté le 10/03/2024 à 14h18
Houlà... que de certitudes qui ne se basent sur rien d'autre qu'une ignorance crasse... Et quelle belle démonstration du postulat de Dunning Kruger.
Non, passer Buffer à 11 ou une quelconque autre valeur ne changera rien à l'affaire (et je passe sur le fait que tu hard-codes la taille du buffer au lieu d'utiliser une constante...) . Le simple fait que tu le proposes prouve que tu n'as rien compris. Le problème ce n'est pas le fread qui va écrire trop loin, ce n'est pas un buffer potentiellement trop petit, c'est le atoi qui va lire trop loin car rien ne garantit que le buffer sera terminé par un zéro binaire.
Car non, la commande passée à popen ne renvoie pas une string, elle renvoie un stream de bytes que fread va mettre dans la variable Buffer. Mais cela ne constitue pas une "string" au sens C car le stream ne contient pas de zéro binaire en fin, et fread n'en mettra pas. Pour mettre un tel byte nul en fin, il eut fallu faire un truc du genre (de tête et quick-n-dirty, et pas portable car suppose que sizeof(char) == 1, mais obligé vu que tu n'as pas jugé utile de définir un constante pour la taille du buffer) :
Buffer[fread(Buffer,1,sizeof(Buffer)-1,fd)] = '\0';
Note à quel point c'est différent de ce que tu as écrit, notamment il faut lire au maximum 15 éléments de taille 1, et non 1 élément de taille 15 de façon que fread renvoie le nombre de bytes lus histoire qu'on puisse accoler un NUL en fin.
Tout ceci prouve que tu n'as jamais écrit du code qui fonctionne autrement que par hasard et sur ta propre machine. Donc, au niveau expérience, évite de voir la paille dans l'oeil de ton voisin, ça t'évitera de passer pour un noob.
#6.38
Effectivement, si la commande lancée par le popen aurait retourné un stream sans fin de ligne ni 0 binaire, cela aurait été pris en compte (avec un p'tit memset). Cette approche plus dépouillée sert la maintenabilité. Et ta proposition est juste, mais n'aide pas la maintenance.
Mon code fonctionne car les procédures appelées forment un ensemble.
PS : surconfiance avec + de 20 ans d'XP sur le sujet ... mais bien sûr.
Historique des modifications :
Posté le 10/03/2024 à 20h13
Que retourne la commande (nproc dans la cas présent) de popen ? ... une string avec un 0 binaire à la fin.
Tout ton commentaire ne sert à rien. Dans un exposé universitaire, tu aurais raison mais pas là.
Et effectivement, si la commande lancée par le popen aurait retourné un stream sans fin de ligne ni 0 binaire, cela aurait été pris en compte (avec un p'tit memset). Cette approche plus dépouillée sert la maintenabilité. Et ta proposition est juste, mais n'aide pas la maintenance.
Mon code fonctionne car les procédures appelées forment un ensemble.
Posté le 10/03/2024 à 20h17
Que retourne la commande (nproc dans la cas présent) de popen ? ... une string avec un 0 binaire à la fin.
Tout ton commentaire ne sert à rien. Dans un exposé universitaire, tu aurais raison mais pas là.
Et effectivement, si la commande lancée par le popen aurait retourné un stream sans fin de ligne ni 0 binaire, cela aurait été pris en compte (avec un p'tit memset). Cette approche plus dépouillée sert la maintenabilité. Et ta proposition est juste, mais n'aide pas la maintenance.
Mon code fonctionne car les procédures appelées forment un ensemble.
PS : surconfiance avec + de 20 ans d'XP sur le sujet ... mais bien sûr. Je dirais plutôt que tu nous fais une crise d'ego dignes des docteur en informatique qui ne sont jamais sortis de leur labo universitaire.
Posté le 10/03/2024 à 20h17
Que retourne la commande (nproc dans la cas présent) de popen ? ... une string avec un 0 binaire à la fin.
Tout ton commentaire ne sert à rien. Dans un exposé universitaire, tu aurais raison mais pas là.
Et effectivement, si la commande lancée par le popen aurait retourné un stream sans fin de ligne ni 0 binaire, cela aurait été pris en compte (avec un p'tit memset). Cette approche plus dépouillée sert la maintenabilité. Et ta proposition est juste, mais n'aide pas la maintenance.
Mon code fonctionne car les procédures appelées forment un ensemble.
PS : surconfiance avec + de 20 ans d'XP sur le sujet ... mais bien sûr. Je dirais plutôt que tu nous fais une crise d'ego digne des docteurs en informatique qui ne sont jamais sortis de leur labo universitaire.
Posté le 10/03/2024 à 20h18
Que retourne la commande (nproc dans la cas présent) de popen ? ... une string avec un 0 binaire à la fin.
Tout ton commentaire ne sert à rien. Dans un exposé universitaire, tu aurais raison mais pas là.
Et effectivement, si la commande lancée par le popen aurait retourné un stream sans fin de ligne ni 0 binaire, cela aurait été pris en compte (avec un p'tit memset). Cette approche plus dépouillée sert la maintenabilité. Et ta proposition est juste, mais n'aide pas la maintenance.
Mon code fonctionne car les procédures appelées forment un ensemble.
PS : surconfiance avec + de 20 ans d'XP sur le sujet ... mais bien sûr. Je dirais plutôt que tu nous fais une crise d'ego universitaire.
Posté le 10/03/2024 à 20h18
Tout ton commentaire ne sert à rien. Dans un exposé universitaire, tu aurais raison mais pas là.
Effectivement, si la commande lancée par le popen aurait retourné un stream sans fin de ligne ni 0 binaire, cela aurait été pris en compte (avec un p'tit memset). Cette approche plus dépouillée sert la maintenabilité. Et ta proposition est juste, mais n'aide pas la maintenance.
Mon code fonctionne car les procédures appelées forment un ensemble.
PS : surconfiance avec + de 20 ans d'XP sur le sujet ... mais bien sûr. Je dirais plutôt que tu nous fais une crise d'ego universitaire.
Posté le 10/03/2024 à 20h44
Tout ton commentaire ne sert à rien. Dans un exposé universitaire, tu aurais raison mais pas là.
Effectivement, si la commande lancée par le popen aurait retourné un stream sans fin de ligne ni 0 binaire, cela aurait été pris en compte (avec un p'tit memset). Cette approche plus dépouillée sert la maintenabilité. Et ta proposition est juste, mais n'aide pas la maintenance.
Mon code fonctionne car les procédures appelées forment un ensemble.
PS : surconfiance avec + de 20 ans d'XP sur le sujet ... mais bien sûr. Je dirais plutôt que tu nous fais une crise d'ego universitaire.
#6.39
12
$ nproc|od -c
0000000 1 2 \n
0000003
$ nproc|wc -c
3
Donc les 3 caractères sortis par nproc sont : 1 2 et \n (=0x0a)
Pas de 0 "binaire" (comme tu l'appelles) de lu en fin de chaîne quand tu lis ces 3 caractères avec ton fread.
Ce qui suit les caractères lus par le fread est indéterminé. Ce n’est pas pour rien que le fread retourne le nombre de caractères lus.
Par contre, c'est le atoi qui te sauve non pas parce que la chaîne est terminée par un 0 mais parce qu'elle est terminée par un 0x0a et que le atoi s'arrête au premier caractère différent d'un chiffre après avoir détecté le début d'un nombre.
Et ici, si la lecture du pipe s'est bien passée (ce que tu ne vérifies pas), tu auras bien ton nombre.
Historique des modifications :
Posté le 10/03/2024 à 20h42
$ nproc
12
$ nproc|od -c
0000000 1 2 \n
0000003
$ nproc|wc -c
3
Donc les 3 caractères sortis par nproc sont : 1 2 et \n (=0x0a)
Pas de 0 "binaire" (comme tu l'appelles) de lu en fin de chaîne quand tu lis ces 3 caractères avec ton fread.
Posté le 10/03/2024 à 20h46
$ nproc
12
$ nproc|od -c
0000000 1 2 \n
0000003
$ nproc|wc -c
3
Donc les 3 caractères sortis par nproc sont : 1 2 et \n (=0x0a)
Pas de 0 "binaire" (comme tu l'appelles) de lu en fin de chaîne quand tu lis ces 3 caractères avec ton fread.
Ce qui suit les caractères lus par le fread est indéterminé. Ce n’est pas pour rien que le fread retourne le nombre de caractères lus.
#6.40
#6.41
#6.43
S'il y avait eu utilisation des strings dans un printf par exemple, oui, il y aurait eu un memset.
#6.53
La spécification de atoi c'est qu'elle reçoit une string. En C une string est terminée par un NUL. Si ce NUL n'est pas là, rien ne prouve que atoi ne va pas continuer à lire les caractères qui suivent. La spec dit que atoi arrête la conversion, pas nécessairement le scan de la string. Le fait qu'atoi est implémenté par une boucle "while le catactère courant est entre '0' et '9'' est un détail d'implémentation qui est généralement valide sur une architecture X86 ou ARM, mais peut-être pas sur une architecture IBM z9, ou une encore différente qui sortira l'année prochaine. Rien n'interdit à atoi() de continuer à scanner plus loin s'il le désire. Il ne peut pas aller plus loin que le NUL mais rien ne dit qu'il ne va pas aussi lire le caractère qui suit le \n.
Maintenabilité
#6.54
La maintenabilité justement, c'est en environnement zOS où j'ai pu voir passer les pires trucs pondus par des « barbus-plein-d'XP ».
Dans ce genre de contexte de travail, les documentations projet tiennent sur une page : Cf Machin-pas-loin-de-la-retraite-ou-déjà-parti. Et les DSI derrière qui attendent en embuscade le départ en retraite pour tout décommissionner en urgence afin que cela ne leur pète pas au nez.
Une fois, des vieux programmes Z ont été rachetés à un client et la prise en main des bouzins a été longue et dure. Plusieurs mois de reverse-engenering pour s’apercevoir qu'on aurait plus vite fait de repartir de la page blanche.
La maintenabilité efficace, par ordre de priorité pour moi :
1. Programmation structurée
2. Capacité à comprendre pour un dev extérieur et accessoirement par l'auteur lui-même
3. Cohérence d'écriture globale : va maintenir un source avec 5 ou 6 styles d'écriture différents et avec du C, ça peut faire très vite mal à la tête.
4. Mail et/ou N° de téléphone de la personne qui a l'histoire du programme en tête : mieux vaut demander à un qui sait plutôt qu'à 2 qui cherchent
#6.55
Tu m'expliques pourquoi tu castes explicitement le résulat de atoi vers un long ? Outre que c'est inutile, ça rend le programme difficile à comprendre car celui qui le lit va devoir se demander pourquoi tu fais ça.
C'est pour la faciliter la compréhension que tu lis une string avec fread au lieu de fgets ?
C'est pour la cohérence que la variable "Buffer" commence par une capitale, contrairement à toutes les autres variables ?
Je confirme, ton code est indigeste
Woaw... Bien sûr.
#6.57
Chapeau pour tes 20 ans d'XP, tu les caches vraiment bien.
#6.42
Désolé de te le dire, mais toi qui défend la maintenabilité à tout va (ça fait plusieurs fois que tu parles de maintenabilité), il y a encore beaucoup de boulot pour que ton programme soit maintenable :
- avoir des conventions cohérentes : un coup de PascalCase, un coup du camelCase, un coup du snake_case
- nommage qui laisse sérieusement à désirer ;
- utilisation de constantes en dure, au lieu de les définir via un #define ou une variable const ;
- utilisation de la virgule au lieu du point virgule pour séparer des instructions (oui, c'est valable en C, je sais, mais cela n'en est pas moins une très mauvaise pratique, surtout pour éviter de définir un bloc d'instructions dans un if ou else par exemple)
Comme je te l'ai déjà dit dans un précédent commentaire : ton code fonctionne pour toi, dans ton cas d'utilisation. Mais il est public (tu l'as publié sur github) et tu ne sais pas dans quelles conditions il sera utilisé.
Ton code est du pain béni pour n'importe quel hacker, mais ça, tu n'en as que faire. Pire, tu refuses ne serait-ce que de le concevoir.
Argument d'autorité + attaque ad hominem (encore). Peux-tu rajouter la victimisation la prochaine fois stp, histoire de varier les procédés rhétoriques ?
Ou plus simplement, avoir de vrais arguments pour défendre ton point de vue. Merci d'avance ;)
#6.44
Je n'ai pas utilisé les conventions normées.
Oui, c'est publié sur github et tous les script-kiddies de passage vont l'utiliser pour coller le boxon sur internet parce que c'est pas dans les normes des gardiens de la méthode.
#6.45
Et le comble, c'est que ton programme se termine par un beau segmentation fault à l'exécution.
Current Minimum Maximum
Core 0 : Khz Khz Khz
Core 1 : Khz Khz Khz
Core 2 : Khz Khz Khz
Core 3 : Khz Khz Khz
Core 4 : Khz Khz Khz
Core 5 : Khz Khz Khz
Core 6 : Khz Khz Khz
Core 7 : Khz Khz Khz
Total : Khz Khz Khz
Average : Khz Khz Khz
Nb Mini :
Nb Maxi :
Extr. Min: Khz Khz Khz
Extr. Max: Khz Khz Khz
Segmentation fault
(tu m'excuseras, je me suis contenté d'un copier/coller de la console, je n'ai pas envie de m'amuser à héberger une image pour ensuite la coller ici).
Alors, tu peux dire tout ce que tu veux de ton programme, tu ne peux pas lutter contre les faits.
Le plus drôle dans tout ça, c'est que j'ai trouvé un buffer overflow exploitable, et que je voulais justement le compiler/tester pour vérifier, mais que je n'ai même pas eu à le faire, car ton programme plante de lui-même.
J'applaudie, à 2 mains, les 20 ans d'expérience mis avec tant de valeur dans ton commentaire précédent
#6.46
#6.47
Ce que j'essaie de te dire (et d'autres aussi), c'est que ton comportement arrogant vis-à-vis de ton programme est une des plaies quant à la sécurité des programmes d'aujourd'hui. Rust (que je n'apprécie pas vraiment, je trouve sa syntaxe illisible) empêche, de par sa conception, les principaux pièges qui constituent la majorité des failles (une étude révélait, par exemple, que la majorité des failles de sécurité dans des programmes C étaient dues à des buffer overflow).
Le pire, c'est que non seulement tu n'arrêtes pas de dire que ton programme est bien pensé, mais qu'en plus, tu te montres plutôt méprisant (pour ne pas dire insultant) envers celles et ceux qui ne seraient pas d'accord avec toi.
Du coup, je ne peux qu'abonder dans le sens du commentaire 14 de Stephane Bortzmeyer (sauf le côté virilisme que je n'ai pas trop compris dans son propos), où, désolé de te le dire, ton comportement est l'archétype même de ceux qu'il dénonce.
#6.48
Au quotidien, je tourne en GCC 13.
« Le pire, c'est que non seulement tu n'arrêtes pas de dire que ton programme est bien pensé, mais qu'en plus, tu te montres plutôt méprisant (pour ne pas dire insultant) envers celles et ceux qui ne seraient pas d'accord avec toi. »
Je reste dans le ton des commentaires qui ont été faits. L'arrogance dont tu me crédites n'est ni plus ni moins que celle avec laquelle tu as entamé les débats.
Pour le virilisme, bien vu, je n'avais pas rebondi sur son commentaire.
Disons que le monsieur ferait bien d'aller faire un stage dans une équipe projet au sein d'une ESN pour voir comment ça se passe dans la vraie vie.
Non, tous les devs ne sont pas nuls (y'en a quand même), les conditions de réalisation des projets, par contre, sont pour beaucoup dans la dette technique des applis (et donc les CVEs créées ou non corrigées ...). Dans ces conditions de réalisation, de manière non exhaustive, on y trouve les comptables gérant à date d'échéance, un turn-over de compétition, des affectations de développeurs sur des périmètres dépassant leur niveau d'expérience, un client girouette, etc ...
#6.49
Au quotidien, je tourne en GCC 13.
Si tu crois que j'ai "recherché" un environnement vétuste... ben non. J'ai juste pris la première VM que j'avais sous la main (car oui, ma machine principale est sous Windows
On pourra se la jouer court de récré, car bizarrement, en relisant nos premiers échanges, je n'ai pas du tout la même interprétation que toi. Je t'avoue qu'après un "script kiddy" et "une médaille en chocolat dans le paramétrage Java", j'ai commencé sans doute à être un peu moins sympa, sans pour autant tomber dans des attaques ad hominem. Je préfère toutefois laisser aux lecteurs se faire leur propre opinion à ce sujet.
Pour ma part, je pense que l'on peut clore la discussion, le tour ayant été fait sur le sujet.
#6.50
Une VM en WSL je suppose ?
Historique des modifications :
Posté le 11/03/2024 à 07h00
« Si tu crois que j'ai "recherché" un environnement vétuste... ben non. J'ai juste pris la première VM que j'avais sous la main (car oui, ma machine principale est sous Windows) »
Une VM en WSL je suppose ?
Posté le 11/03/2024 à 07h00
« Si tu crois que j'ai "recherché" un environnement vétuste... ben non. J'ai juste pris la première VM que j'avais sous la main (car oui, ma machine principale est sous Windows) »
Une VM en WSL je suppose ?
#6.51
#6.58
%ddans unprintfpour formater deslong) j'ai pas été plus loin. De toute évidence, sur son architecture les long et les int ont la même taille... C'est probablement pour cela que sur sa machine à lui il n'y a aucun warning. Et comme "pas de warning = programme OK", tout roule.Et puis comme dit si bien alex.d ailleurs dans le thread, y'a pas de vulnérabilité dans printf
#6.59
Plus sérieusement, tant qu'il y aura des dev avec ce genre de mentalité, les CVE ont de beaux jours devant eux
#6.52
"Cette approche dépouillée" mon dieu... Ce n'est pas une approche dépouillée/
Quant à la ligne suivante où tu castes explicitement le résultat de atoi vers un long, tout ça pour retourner le nombre de processeurs (qui ne devrait en toute logique pas dépasser 65535 dans le meilleur des cas...) oui de fait ça respire 20 ans d'expérience... Vingt ans de cut-n-paste de code que tu ne comprends pas.
#6.3
#6.4
#7
Il parle aussi de "Memory Safe Hardware" (CHERI est cité en exemple: est-ce que Next a déjà fait un article sur le sujet?)
et de "Formal Methods".
#8
#8.1
Historique des modifications :
Posté le 04/03/2024 à 10h12
Le rapport ne dit pas que le C présente des vulnérabilités, il dit par contre qu'il y a beaucoup plus de vulnérabilités dans les logiciels écrits avec un langage qui n'est pas sûr pour la gestion de la mémoire comme le C ou C++.
#8.3
#8.4
1. C/C++ est vulnérable aux risques d'une mauvaise gestion mémoire.
2. C/C++ est invulnérable aux risques d'une mauvaise gestion mémoire.
Votre réponse: ___
#8.5
#8.2
#8.6
#8.7
Après, il faut utiliser le bon outil pour la bonne tâche. Le C n'est pas la bonne solution dans tous les cas, mais il est erroné de vouloir déconseiller l'usage du C dans tous les cas.
#8.8
#8.9
#8.10
gets() est une vulnérabilité exclusivement due à la librairie standard (il manque 'juste" la longueur du buffer dans les arguments - problème que n'a pas fgets)
Par contre le fait d'avoir des arguments quelconques sans aucun contrôle de type (ni même d'implémentation portable avant l'avènement de la notation va_args) pour permettre le fonctionnement de printf (ou scanf si tu y tiens vraiment...) est bien une caractéristique du langage.
#8.11
#8.12
#9
- langage proche du matériel
- délais exécution à timing déterministe (adapté au temps-réel, pas de garbage collector)
- gestion sécurisée de la mémoire
On peut considérer que:
Le premier critère disqualifie les langages interprétés comme Js, Python, Java, ...
Le second exclue C#, go, V, et tous les langages utilisant impérativement un garbage collector
Le troisième exclue l'assembleur, c et c++
Rust est juste cité comme un exemple de langage correspondant à ces trois critères mais n'ayant pas encore fait ses preuves dans l'aérospatial.
D'autres alternatives intéressantes, correspondant à ces critères mais non citées sont par exemple ADA (vénérable langage très implanté dans l'aérospatiale), D (si on désactive le GC) , Zig, Swift, Ordin
Historique des modifications :
Posté le 04/03/2024 à 10h08
Il faut bien regarder le rapport de l'ONCD, et du contexte dans lequel Rust est évoqué qui est assez précis puisqu'ils évoquent le matériel sécurisé de l'aérospatial. Ils énumèrent les critères suivants concernant les besoins des langages de programmation pour ce contexte:
- langage proche du matériel
- délais exécution à timing déterministe (adapté au temps-réel, pas de garbage collector)
- gestion sécurisée de la mémoire
On peut considérer que:
Le premier critère disqualifie les langages interprétés comme Js, Python, Java, ...
Le second exclue C#, go, V, et tous les langages utilisant impérativement un garbage collector
Le troisième exclue l'assembleur, c et c++
Rust est juste cité comme un exemple de langage correspondant à ces trois critères mais n'ayant pas encore fait ses preuves dans l'aérospatial.
D'autres alternatives intéressantes, correspondant à ces critères mais non citées sont par exemple ADA (vénérable langage très implanté dans l'aérospatiale), Zig, Swift, Ordin
#9.1
#9.2
Pour le GC de Java il y a Epsilon, mais je n'ai pas encore pu me faire une opinion...
Faire des mécanismes similaires à Rust en Java? non, impossible, la notion de borrow qui est cruciale dans le modèle Rust et qui oblige les devs à explicitement gérer le cycle de vie des variables quand elles sont passées à des fonctions casserait tout.
Pour le reste l'objectif n'est pas de gérer la mémoire sois-même, c'est même tout le contraire.
#10
#10.1
#11
Historique des modifications :
Posté le 04/03/2024 à 10h37
Non merci, je continue en C.
#11.1
#12
==> Vers l'infini
#13
Si les dispositifs de verrouillage ne sont pas suffisamment implémentés dans un langage, c'est peut-être au développeur de faire un peu plus propre, d'effort. Et d'en finir avec les bêtises du genre "(en Java) ho non faut pas utiliser GC!". Et ce n'est pas la seule qu'on peut entendre.
Ce qui me fait tiquer ce n'est pas la promotion déguisée de ces langages c'est pourquoi la maisons blanche s'immisce dans ces affaires. Y'a pas de fumé sans feu.
#13.1
#13.2
Peut être parce qu’il est infiniment plus facile d'exploiter une faille dans un code PHP (écrit à la va vite souvent open source) qu'une faille d'un Apache à jour.
#13.3
#13.4
J'arrête pas de le dire autour de moi : tu veux de la sécu ? Soit à jour !
#14
#14.1
#14.2
https://fr.wiktionary.org/wiki/virilisme
(Politique) Idéologie prônant la virilité comme valeur supérieure pour le genre masculin
??
#14.3
Rien d'insultant ou de provocateur, c'est juste factuel. Mais bon, d'habitude, le fait de dire ça fait justement réagir cette même communauté de manière très virulente
#14.4
Comme disait Brassens, "le temps ne fait rien à l'affaire".
Je te laisse trouver le reste des paroles.
#14.5
Au bout d'un moment, stoppons tout de suite la mauvaise foi. On retrouve toujours les mêmes personnes en commentaire, et l'estimation qu'on peut se faire se confirme à chaque fois qu'une actualité nostalgique apparaît et où ça balance des âges ou des anecdotes datées (toi y compris).
Encore une fois, rien de méchant ou d'incisif, je souhaite pas vous voir partir hein, merci d'être là et de soutenir Next même. C'est juste dommage de ne pas avoir une communauté plus hétéroclite, avec des expériences et des générations autant représentées à parts égales, surtout sur un thème comme le numérique ou ce serait largement faisable.
Suffit de voir les réaction déjà à mon message pour voir que je ne suis (heureusement) pas le seul à penser ça. Next avait parlé de travailler la vidéo en 2024 pour essayer de rajeunir un peu la communauté. J'attends ça avec impatience.
PS : pour finir sur un aspect taquin, tu cites du Brassens. Si ce n'est pas suffisant comme élément pour définir le côté boomer...
Historique des modifications :
Posté le 06/03/2024 à 13h09
Et voilà, qu'est-ce que je disais. J'aurais même pu parier sur toi pour la réponse...
Au bout d'un moment, stoppons tout de suite la mauvaise foi. On retrouve toujours les mêmes personnes en commentaire, et l'estimation qu'on peut se faire se confirme à chaque fois qu'une actualité nostalgique apparaît et où ça balance des âges ou des anecdotes datées (toi y compris).
Encore une fois, rien de méchant ou d'incisif, je souhaite pas vous voir partir hein, merci d'être là et de soutenir Next même. C'est juste dommage de ne pas avoir une communauté plus hétéroclite, avec des expériences et des générations autant représentées à parts égales, surtout sur un thème comme le numérique ou ce serait largement faisable.
Suffit de voir les réaction déjà à mon message pour voir que je ne suis (heureusement) pas le seul à penser ça. Next avait parlé de travailler la vidéo en 2024 pour essayer de rajeunir un peu la communauté. J'attends ça avec impatience.
#14.6
Perso, je suis dans le camp de ceux qui pensent que le C (et donc le C++) posent des problèmes liés à l'utilisation de la mémoire et que le rapport de la Maison Blanche est pertinent.
Je suis sûr qu'il y a ici plusieurs personnes plus jeunes que moi qui disent le contraire.
Mais j'ai vu trop de logiciels qui ne libéraient pas leur mémoire après usage, entraînant des fuites, trop d'utilisation d'un pointeur après libération de la mémoire, trop d'écritures au delà de la mémoire allouée et j'en passe pour penser que le C est un bon langage sur ces points.
Alors, oui, c'étaient peut-être de mauvais développeurs comme diraient certains ici, ils étaient plutôt moyens mais un langage doit être robuste à la moyenne des développeurs.
#14.7
#15
Quand j'ai commencé dans l'informatique ON parlait (sans exhorter) du COBOL en fin de vie, Aujourd'hui retraité (moi) mais le canard (Cobol) est toujours vivant !
Historique des modifications :
Posté le 04/03/2024 à 12h58
La Maison-Blanche exhorte…
Dans une trentaine d'années ON parlera toujour de l'abandon du C ! 
Quand j'ai commencé dans l'informatique ON parlait (sans exhorter) du COBOL en fin de vie, Aujourd'hui retraité (moi) mais le canard (Cobol) est toujours vivant !
#15.1
#15.2
Mais bon, écrire un driver d'imprimante Windows en COBOL, faut aimer le sport.
#15.3
DATA DIVISION.77 CURRENT-LINE PIC X(132).Le reste c'est juste un détail...
#16
La France a même pris une mesure EXCEPTIONNELLE de passer la retraite à 64 ans pour conserver ses programmeurs
#17
Il n'est pas nécessaire de modifier tous les logiciels, seulement ceux critiques, comme les noyaux de systèmes d'exploitation, les connecteurs réseaux, le décodage logiciel des codecs vidéo/audio, enfin tous ce qui concerne une entré/sortie réseau ou une interprétation d'un code importé (navigateur web, TCP/IP, TLS)
Il n'est pas du tout nécessaire de tous refaire. Par exemple, le noyau Linux à ajouté le support de Rust, pour le moment cela est utile pour quelques pilotes nouvellement développés.
#17.1
Le dépassement de tampon (ou celui de tas) peut se produire dans tout logiciel qui traite des données qui viennent de l'extérieur et ça fait un sacré paquet de logiciels !
Mais comme dit par d'autres, le conseil de changer de langage de programmation est pour les nouveaux logiciels. Il n'est pas de tout réécrire.
#18
Mais bon ok, sauf qu'un programme c'est souvent des librairies externes et je ne pense pas qu'elles puissent toutes être remplacées si simplement.
Puis réécrire un programme... Faut avoir la chance d'avoir ou du code hyper bien commenté ou/et de la doc fonctionnelle vraiment à jour et bien écrite.
M'enfin y'aura bien une IA pour nous convertir du code directement non ?
#19
En C/C++, on risque des effets de bords à cause de pointeurs "unsafe". Il y a des analyseurs statiques qui permettent de suivre un peu ces erreurs, et de bonnes pratiques à acquérir.
En Javascript, on risque ... les erreurs liées à la portée, et beaucoup d'erreur de synchro/parallélisme/exécution dans un ordre pas forcément voulu + des problèmes de mémoire qui enfle, au pire l'injection directe de code.
En C#/Java, voici ce que j'ai pu subir: l'utilisation de la sérialisation/désérialisation à outrance ... y compris en stockant dans les cookies... Magnifique travail, CVE car on peut injecter ce qu'on veut comme code dans le cookie, et il est exécuté par le serveur sous son login de serveur web.
Niveau faille, je dois avouer que tout langage a les siennes. Les programmeurs sont (souvent par fainéantise/pression du temps) très prolifiques.
Mais je trouve tout de même que Rust a de très bon atouts pour forcer de bonnes pratiques. Il est un bon compromis de principe déjà éprouvés dans d'autres langage (d'où le nom il me semble d'ailleurs). Mis à part la syntaxe de %$§!, c'est un bon produit.
#20