Plusieurs améliorations ont été apportées au support de Rust dans le noyau Linux,
Personnalisation de core et alloc, abstractions et mises à jour des pilotes
Le 2021-12-09 12:08:44, par Bruno, Chroniqueur Actualités
Linux 5.13 a été publié fin juin sans le support du langage Rust, mais Linus Torvalds avait déclaré en avril que le projet Rust for Linux a maintenant beaucoup avancé et pourrait être fusionné avec la prochaine mouture du noyau, Linux 5.14. Dans une lettre publiée le 6 décembre, Miguel Ojeda, chef du projet Rust pour Linux, présente explique les principaux changements et mises à jour effectués depuis la version 1 du noyau linux. « Il s'agit de la série de patchs (v2) pour ajouter le support de Rust comme second langage au noyau Linux », a déclaré Miguel dans la liste de diffusion publié le 6 décembre.
Les développeurs de Linux discutent depuis un moment de la perspective de permettre l'utilisation du langage développé par Mozilla Research pour écrire de nouveaux pilotes de périphériques pour le noyau. L'année dernière, les développeurs du noyau Linux semblent s'être mis d'accord sur le sujet. Pour mémoire, Rust est plébiscité, car il offre plusieurs avantages, notamment en ce qui concerne la mémoire. Les partisans de Rust ont cité des travaux qui montrent qu'environ deux tiers des vulnérabilités du noyau auxquelles ont été attribués des CVE sur Android et Ubuntu sont tous liés à des problèmes de sécurité de la mémoire.
Dans un post publié sur son blog le 14 avril, l’équipe de développement de Google a annoncé qu’elle participe à l'évaluation du langage Rust pour le développement du noyau Linux. Suite à cette déclaration, Linus Torvalds, ingénieur logiciel, créateur principal et développeur du noyau Linux, a déclaré lors d’une interview que des discussions sur le sujet seraient beaucoup plus importantes qu'un long post de Google sur le langage. Interrogé sur la suggestion d'un internaute qui a indiqué que, « la solution ici est simple : il suffit d'utiliser C++ au lieu de Rust », Linus Torvalds n'a pas pu se retenir et aurait même traité le C++ de « langage de m... ».
Rappelons qu’au mois de mars, le tout premier support permettant l'utilisation du langage de programmation Rust dans le noyau Linux est apparu dans l'arbre Linux-Next pour des tests plus étendus avant son inclusion éventuelle dans le noyau principal. Juste derrière, une "demande de commentaires" a été relancée sur la liste de diffusion du noyau autour des perspectives du code Rust pour le noyau Linux. Miguel Ojeda, développeur du noyau Linux, a lancé une proposition de RFC (Request For Comments) sur la liste de diffusion du noyau Linux.
Miguel Ojeda, a lancé une proposition de RFC sur la liste de diffusion du noyau Linux. Le message de la liste de diffusion décrivait les convictions des développeurs impliqués dans l'ajout du code Rust au noyau, les avantages tels que l'amélioration de la sécurité de la mémoire, et plus encore. « Certains d'entre vous ont remarqué ces dernières semaines et ces derniers mois qu'une tentative sérieuse d'apporter un second langage au noyau était en train de se forger. Nous y sommes enfin, avec une RFC qui ajoute le support pour Rust au noyau Linux », avait déclaré Miguel Ojeja. « Nous savons qu'il y a des coûts et des risques énormes à introduire un nouveau langage dans le noyau », avait-il ajouté. Voici, ci-dessous, les améliorations qui ont été apportées au support général de Rust :
Stabilité du compilateur
L’équipe du projet Rust pour Linux est passée du compilateur Rust beta à l'utilisation des versions stables, en migrant à chaque fois qu'une nouvelle version est publiée. En mettant à jour le compilateur, L’équipe a été en mesure de retirer de la liste quelques fonctionnalités instables : const_fn_transmute, const_panic, const_unreachable_unchecked, core_panic et try_reserve.
Personnalisation de `core` et `alloc`
Quelques options de modularisation supplémentaires ont été ajouté à alloc afin de désactiver certaines fonctionnalités inutiles : no_rc et no_sync. « Nous aimerions remercier Rust pour avoir travaillé avec nous sur ces options afin que le noyau puisse les utiliser », a déclaré Miguel. En amont, afin que le cas d'utilisation du noyau soit bien pris en charge, ou, plus précisément, la "combinaison" d'options dont le noyau a besoin, Upstream core a aussi ajouté no_fp_fmt_parse.
Rust a activé un certain nombre de diagnostics supplémentaires pour le compilateur Rust et de Clippy
lints. Une différence par rapport à C est que les diagnostics Rust sont un peu plus faciles à désactiver dans le code ce qui apporte plus de rigueur dans le cas général.
Abstractions et mises à jour des pilotes L’équipe a ajouté des abstractions pour les verrous de séquence, les callbacks de gestion d'énergie, la mémoire io (readX/writeX), les puces irq et les gestionnaires de flux de haut niveau, les puces gpio (y compris les puces irq), les périphériques, les périphériques amba et les pilotes.
Le support des pilotes est amélioré avec une infrastructure indépendante du bus, des objets révocables, des mutex révocables, des itérateurs de bits efficaces, de meilleurs diagnostics de panique et des wrappers de pointeurs simplifiés. De plus, elle a amélioré et simplifié les objets Ref (soutenus par refcount_t) et remplacé toutes les instances de Rust. Un nouveau pilote pour les périphériques gpio PL061 a été implémenté et est soumis en tant que patch RFC.
Le support de Rust est toujours considéré comme expérimental. Cependant, le support est assez bon pour que les développeurs de noyaux commencent à travailler sur les abstractions Rust pour les sous-systèmes et à écrire des pilotes et autres modules. La série actuelle vient d'arriver dans Linux-next, donc la première exécution aura lieu cette semaine.
Source : Liste de diffusion
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi :
Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google
Les derniers correctifs du projet Rust for Linux montrent que le langage Rust avance à grands pas vers le noyau, Torvalds estime que cela pourrait être prêt pour la version 5.14
La prise en charge de Rust pour le développement du noyau Linux commence à prendre forme, le langage fait un premier pas vers la branche "Linux-Next"
L'année 2020 est-elle celle de Rust au sein du noyau Linux ? C'est ce que suggère une sortie de Linus Torvalds, qui donne des instructions sur l'introduction de son support au système de build
Les développeurs de Linux discutent depuis un moment de la perspective de permettre l'utilisation du langage développé par Mozilla Research pour écrire de nouveaux pilotes de périphériques pour le noyau. L'année dernière, les développeurs du noyau Linux semblent s'être mis d'accord sur le sujet. Pour mémoire, Rust est plébiscité, car il offre plusieurs avantages, notamment en ce qui concerne la mémoire. Les partisans de Rust ont cité des travaux qui montrent qu'environ deux tiers des vulnérabilités du noyau auxquelles ont été attribués des CVE sur Android et Ubuntu sont tous liés à des problèmes de sécurité de la mémoire.
Dans un post publié sur son blog le 14 avril, l’équipe de développement de Google a annoncé qu’elle participe à l'évaluation du langage Rust pour le développement du noyau Linux. Suite à cette déclaration, Linus Torvalds, ingénieur logiciel, créateur principal et développeur du noyau Linux, a déclaré lors d’une interview que des discussions sur le sujet seraient beaucoup plus importantes qu'un long post de Google sur le langage. Interrogé sur la suggestion d'un internaute qui a indiqué que, « la solution ici est simple : il suffit d'utiliser C++ au lieu de Rust », Linus Torvalds n'a pas pu se retenir et aurait même traité le C++ de « langage de m... ».
Rappelons qu’au mois de mars, le tout premier support permettant l'utilisation du langage de programmation Rust dans le noyau Linux est apparu dans l'arbre Linux-Next pour des tests plus étendus avant son inclusion éventuelle dans le noyau principal. Juste derrière, une "demande de commentaires" a été relancée sur la liste de diffusion du noyau autour des perspectives du code Rust pour le noyau Linux. Miguel Ojeda, développeur du noyau Linux, a lancé une proposition de RFC (Request For Comments) sur la liste de diffusion du noyau Linux.
Miguel Ojeda, a lancé une proposition de RFC sur la liste de diffusion du noyau Linux. Le message de la liste de diffusion décrivait les convictions des développeurs impliqués dans l'ajout du code Rust au noyau, les avantages tels que l'amélioration de la sécurité de la mémoire, et plus encore. « Certains d'entre vous ont remarqué ces dernières semaines et ces derniers mois qu'une tentative sérieuse d'apporter un second langage au noyau était en train de se forger. Nous y sommes enfin, avec une RFC qui ajoute le support pour Rust au noyau Linux », avait déclaré Miguel Ojeja. « Nous savons qu'il y a des coûts et des risques énormes à introduire un nouveau langage dans le noyau », avait-il ajouté. Voici, ci-dessous, les améliorations qui ont été apportées au support général de Rust :
Stabilité du compilateur
L’équipe du projet Rust pour Linux est passée du compilateur Rust beta à l'utilisation des versions stables, en migrant à chaque fois qu'une nouvelle version est publiée. En mettant à jour le compilateur, L’équipe a été en mesure de retirer de la liste quelques fonctionnalités instables : const_fn_transmute, const_panic, const_unreachable_unchecked, core_panic et try_reserve.
Personnalisation de `core` et `alloc`
Quelques options de modularisation supplémentaires ont été ajouté à alloc afin de désactiver certaines fonctionnalités inutiles : no_rc et no_sync. « Nous aimerions remercier Rust pour avoir travaillé avec nous sur ces options afin que le noyau puisse les utiliser », a déclaré Miguel. En amont, afin que le cas d'utilisation du noyau soit bien pris en charge, ou, plus précisément, la "combinaison" d'options dont le noyau a besoin, Upstream core a aussi ajouté no_fp_fmt_parse.
Rust a activé un certain nombre de diagnostics supplémentaires pour le compilateur Rust et de Clippy
lints. Une différence par rapport à C est que les diagnostics Rust sont un peu plus faciles à désactiver dans le code ce qui apporte plus de rigueur dans le cas général.
Abstractions et mises à jour des pilotes L’équipe a ajouté des abstractions pour les verrous de séquence, les callbacks de gestion d'énergie, la mémoire io (readX/writeX), les puces irq et les gestionnaires de flux de haut niveau, les puces gpio (y compris les puces irq), les périphériques, les périphériques amba et les pilotes.
Le support des pilotes est amélioré avec une infrastructure indépendante du bus, des objets révocables, des mutex révocables, des itérateurs de bits efficaces, de meilleurs diagnostics de panique et des wrappers de pointeurs simplifiés. De plus, elle a amélioré et simplifié les objets Ref (soutenus par refcount_t) et remplacé toutes les instances de Rust. Un nouveau pilote pour les périphériques gpio PL061 a été implémenté et est soumis en tant que patch RFC.
Le support de Rust est toujours considéré comme expérimental. Cependant, le support est assez bon pour que les développeurs de noyaux commencent à travailler sur les abstractions Rust pour les sous-systèmes et à écrire des pilotes et autres modules. La série actuelle vient d'arriver dans Linux-next, donc la première exécution aura lieu cette semaine.
Source : Liste de diffusion
Et vous ?
Voir aussi :
-
KsassPeukMembre confirméNon, c'est une réponse de menteur.
La vérification de programmes et la quête du programme sans bug, c'est un sujet dans le monde de la recherche et du transfert technologique depuis des décennies. Chaque année des thèses et des papiers sur le sujet, on en publie des camions. C'est des milliers de personnes à travers le monde qui bossent dessus avec des succès et des échecs, et le domaine est assez fier des progrès qui ont été faits ces dernières années sur le sujet. Bizarrement, aucun de ces succès n'avance du "on a de la garantie de correction pour plusieurs millions de lignes de code C++". Alors quand type débarque du fond d'un forum en balançant du "non mais moi je suis trop fort, d'ailleurs j'ai réglé le problème sur lequel des milliers de personnes se sont cassés les dents pendant 40 ans, par contre je ne vous fournirai aucune preuve". Oui, on est en droit de dire que cette personne ment, purement et simplement.
A titre personnel, ça me gonfle d'autant plus que je bosse précisément sur ce type de sujet depuis 10 ans. Ce genre de discours, par son absence totale de sérieux, est prompt à créer une réaction chez les développeurs du genre "Haha ! C'est n'importe quoi, on ne pourra jamais ne serait-ce qu'approcher la possibilité d'un logiciel sans bug". Le genre de trucs qui peuvent flinguer le travail de sensibilisation qu'on fait auprès d'eux. et qui efface toutes les subtilités réelles du problème (notamment les liens entre la spécification du logiciel, du langage utilisé, et de l'implémentation du système, et ce qu'on inclut ou non dans la confiance d'un logiciel). Ces développeurs auront d'autant moins de facilité à prendre au sérieux les gens qui bossent réellement sur le sujet, autant pour produire de nouvelles solutions que pour amener ces connaissances dans le monde académique et industriel, et pousser ces solutions vers des usages de moins en moins critiques. Aujourd'hui l'ANSSI a durcis les critères nécessaires pour obtenir certaines certifications (par exemple CC EAL6/7), c'est en grande partie grâce à l'effort important qui a été fournis pendant la dernière décennie pour faciliter la mise en place d'outil de vérification formelle et qui fait qu'aujourd'hui il devient possible de sortir des garanties formelles de correction à code-level pour des softs de l'ordre de quelques dizaines de milliers de lignes. Sans parler du fait que sans aller jusqu'à de tels niveau de fiabilité, on a aujourd'hui un large panel d'outils capable de détecter des problèmes ou garantir leur absence et ce en fonction du type de problème ou de système visé.le 01/11/2022 à 13:43 -
UtherExpert éminent séniorÉcoutez je me base sur le fait que je n'ai entendu aucun expert en sécurité préconiser ça comme première action fondamentale pour sécuriser un code C++. Alors soit vous êtes quelqu'un de très novateur et dans ce cas je m'excuse et j'aimerais beaucoup que vous détaillez comment vous faites, soit il vous manque effectivement des connaissances sur le sujet. Sachez que ça n'a rien d'une insulte : tout le monde à des sujets qu'il connait mieux que d'autres, moi le premier.
Si c'est vraiment le cas, je serais très curieux de lire votre thèse et d'avoir plus de renseignements sur le sujet. A ma connaissance, les systèmes de vérification s'appuient soit sur des preuves formelles, soit de l'analyse statique du code, soit sur de la détection des comportements dangereux à l’exécution, mais qui ne requièrent pas pour autant le fonctionnement en mode débogage.
Si votre système est si efficace grâce aux informations de débogage, je serais très curieux d'en apprendre plus.
Pour le coup, ça m'inquiète plus que ça me rassure. Un logiciel avec zéro failles de sécurité signalées, c'est plus souvent signe d'une mauvaise surveillance des problèmes de sécurité ou d'une rétention des informations de vulnérabilité que d'une grande fiabilité.
Je ne prétend pas être un expert, juste connaitre assez le problème de la sécurité en C++ pour savoir que les assertions et surtout le débogage ne sont clairement pas les éléments considérés comme prioritaires pour sa sécurisation.
Je préjuge pas des gens, par contre je juge vos préconisations en matière de sécurisation du code qui sont ... peu orthodoxes pour rester poli. Si vous pouvez m'expliquer réellement comment vous pouvez éviter les failles de sécurité grâce mode débogage, je serais on ne peu plus ravi de revoir mon jugement, mais comme je n'ai jamais entendu parler de rien de tel pour le moment dans le domaine de la sécurité du code, vous me permettrez de rester on ne peu plus sceptique en attendant.
Il me semble que sauf cas particulier, un travail de thèse est censé être public non ?
En effet c'est une réponse de normand, mais c'est quand même une réponse qui contredit le propos de base. Vous affirmiez que le C++ est sécurisé, mais comme c'est grâce a une méthode qui ne semble pas vraiment connue des gens du métier, et dont vous ne souhaitez pas nous parler. Même à considérer que vous êtes de bonne foi, il n'en reste pas moins qu'elle n'est à l'heure actuelle pas une solution utilisable par le commun des mortels pour sécuriser ses application C++.
Le peu que vous dites sur votre méthode est basé sur de vielles techniques, très superficielles, qui ont montré leurs limites et dont on est revenu depuis longtemps. C'est très loin de ce qui se fait actuellement dans la sécurité. Si le but était de convaincre de la qualité de vos connaissances en matière de sécurité du code C++, c'est vraiment raté.le 01/11/2022 à 14:21 -
UtherExpert éminent sénior
J'ai bien précisé que mes commentaires ne s'appliquaient qu'au peu que vous avez dit, à savoir : les assertions, le débogage, puis la notation hongroise. Car ces méthodes ne visent pas particulièrement la sécurité de l'application mais plutôt à gérer les bugs en général.
D'ailleurs, je pense que le gros du malentendu vient du fait que l'on parle de faille de sécurité alors que vous parlez de bugs généralistes. Les assertions et le débogage sont en effet de très bons outils pour traiter les bugs classiques, mais les failles de sécurité sont des problèmes qui restent généralement cachés, ce qui fait qu'ils nécessitent plutôt des outils pour être détectés (sanitizers, fuzzer, ...) ou les éviter (preuve formelle, analyse statique, restriction du langage,...).
Je ne demande qu'a avoir tort. Si le débogage permettait d'améliorer la sécurité de mes programme je serais le premier heureux. C'est pour ça que je vous ai invité a partager votre thèse, tout aussi poliment que LittleWhite, car si votre approche est valide elle serait particulièrement novatrice. Mais tant que ça reste une méthode que vous seul savez utiliser, le débogage ne peut clairement pas être considéré comme un moyen d'assurer la sécurité d'un programme.
A aucun moment je n'ai voulu être agressif, si c'est l'impression que j'ai donné, je m'en excuse, mais je pense que cette critique peut aussi vous être retournée. Le seul moment ou j'estime être critiquable c'est sur mon message qui disait que vous ne "maitrisiez" pas C++. Il visait uniquement à faire écho à votre "Il est aussi sécurisé si on le connait bien" or votre explication de la sécurité posait problème. Je pense que j'aurais pu le formuler mieux ou même m'éviter cette figure de style.
Sachez que pour moi "ne pas maitriser" n'est pas une attaque. Je ne prétends pas moi même maitriser le C++. Je ne doute pas que, sur la globalité du langage, vous le connaissiez bien mieux que moi. Par contre, je maintiens que les préconisations que vous donniez en matière de sécurité n'étaient clairement pas adaptées.
Je ne vous ai à aucun moment, contrairement à d'autres, accusé de mentir, mais je ne peux pas non plus prendre ce que vous dites sur la détection de faille par débogage pour argent comptant. Le fait que vous refusiez de partager un travail de thèse dans un domaine ou la communication est la norme, n'aide pas à votre crédibilité.
C'est dommage que vous voyez ça comme une agression alors que je vois ça, au contraire, comme une façon d'avoir un débat sain. Si le but était de gagner un débat d'opinion je ferais au contraire une grande tirade majestueuse, pleine de procès d'intention, dont au final la véracité du contenu importerait peu.
En prenant les points précisément, on peut essayer de voir plus clairement sur lesquels on peut être d'accord et pour ceux sur lesquels on n'est pas d'accord, essayer de comprendre pourquoi.le 09/11/2022 à 11:55 -
KannagiExpert éminent séniorJe serais curieux de lire votre thèse , parce que une thèse est normalement accessible au public non ?
Si votre méthode révolutionnaire c'est de faire du debogage et de la notation hongroise...
ça me semble un peu mytho , sans parler que dire que tu n'as jamais constater de bug , ne veut pas dire qu'il y'en a pas.
C'est là que je me dis que c'est "n'importe quoi" , non faire de prefixage de variable ne réduit pas les bugs , d'ailleurs je doute qu'il y'a beaucoup de bug qui sont vraiment lié au type de variable et à leur conversion (il y'en a , mais la plupart des bugs sont pas lié à celà).
Sans parler que ce n'est pas révolutionnaire, vu que ça existe déjà...le 01/11/2022 à 15:04 -
mintho carmoMembre éclairéUn dev pro (C++ ou non) n'aurait pas pensé a ce type d'exemple (qui est de niveau débutant) quand on parle de qualité logicielle et de sécurité. Le choix de ces exemples montrent que tu n'es pas dev pro et encore moins en C++. Et les chiffres que tu donnes (80 Go de cours, 10M de lignes de code) sont complètement risibles.
Donc je comprend qu'on te qualifie de troll.le 01/11/2022 à 16:44 -
KsassPeukMembre confirmé(note pour le côté public des thèses : non les thèses ne sont pas forcément publiques. Il y a au moins un cas qui peut rendre la thèse privée : si ça a trait à des travaux qui sont sur des éléments confidentiels - notamment pour certaines CIFRE ou travaux liés à la Défense - mais c'est plutôt rare et très fortement déconseillé car ça nuit fortement au démarrage de carrière d'un docteur)le 01/11/2022 à 17:01
-
UtherExpert éminent séniorC'est un langage rapide et puissant mais certainement pas le plus rapide et puissant. Le C et le Rust on des performance similaires.
Visiblement tu ne le maitrises pas toi même, car ce n'est clairement pas le mode de débogage et les assertions qui sont les points important pour assurer la sécurité en C++.
C'est pas le rôle des universitaire d'apprendre tous les détail d'un langage de programmation. Il sont là pourra apprendre les concepts généraux. Et comme C++ est bourré de complexité qui lui sont assez particulière, c'est normal que les universités avec un temps de cours limité ne puissent pas tout couvrir. Si tu veux un bon niveau de formation au C++, et même dans n'importe quel langage, il faut aller bien au delà de ce qu'on apprend à l''université.
Il faut sortir du fantasme du grand remplacement. Personne n'envisage de jeter à la poubelle du code parfaitement fonctionnel pour le remplacer par une récriture de qualité moindre. Pour réécrire un code,il faut que ça apporte un réel gain.le 29/10/2022 à 22:36 -
UtherExpert éminent séniorVous savez peut-être faire du C++ mais si vous pensez que le débogage et les assertions sont les points clés pour assurer la sécurité, clairement vous avez quelques des lacunes dans ce domaine.
Les assertions c'est toujours bien de les utiliser, mais ce n'est clairement pas le premier point pour assurer la sécurité car ça ne couvre que les domaines auxquels on pense, or malheureusement les problèmes de sécurité viennent surtout des cas particuliers que l'on oublie.
Quant au débogage, c'est utile pour résoudre des problèmes dont on a connaissance, alors que les problèmes de sécurités sont au contraire des erreurs dormantes. Si on veut s'attaquer aux failles de sécurités, il y a d'autres outils externes bien plus adaptés comme les memory sanitizer, fuzzers, ...
Je reste poli et me base uniquement sur ce que vous avez déclaré sur la façon de sécuriser du C++, ce qui montre quand même une manque de connaissances dans la partie sécurité du langage.
L'un va généralement avec l'autre. En augmentant les fonctionnalités, on augmente également la complexité, surtout quand les les fonctionnalité on un impact large qui peut entrainer des interactions surprenantes avec d'autres. C'est pas pour rien que la plupart des langages qui se sont posé en successeur du C++ (Java, D, Rust, ...) ont visé à limiter les fonctionnalités pour réduire cette complexité induite qui peut amener a de nombreuses erreursle 30/10/2022 à 12:54 -
MingolitoMembre extrêmement actifDans la vrai vie des développeurs pro qui sont pas mytho, j'en connais qui passent sur C++ 90% de leur temps au débogage. Bon c'est pas les meilleurs mais de la à prétendre faire 0% ...
Dans la vrai vie des développeurs Pro à leur compte, ou d'une ESN, tu peux très bien ne pas arriver à te faire payer même avec une application que as déboguée pendant des mois, parce que le client à trouvé un prétexte quelconque ou a déposé le bilan, alors de la à se faire payer pour une application pleine de bugs. Tu peux me donner les coordonnées du client qui achète à prix d'or des applications C++ boguées ? ça m'intéresse le 02/11/2022 à 19:07 -
KannagiExpert éminent sénior
Envoyé par Mingolito
Et il font aussi la fusion nucléaire avec un trombone et une ficelle.
Il manquerai juste un "Nananère" ,et ça serait parfait !
Je me demande si tu t'es relu ?
Je pense que au début , on aurait pu croire un "minimum" ce que tu dis, mais là je pense que tu t'es décrédibiliser tout seul , oui je sais il y'a une expression qui dit "plus c'est gros , plus ça passe" , mais là c'est un peu trop gros.
Déjà , tu utilise deux argument :
un que c'est très complexe , j'ai l’impression de lire un gosse de 7 ans qui a réussi a faire des additions avec des centaines...
Secundo que tu gagne beaucoup d'argent gage évident de qualité et de sérieux , tu souffre de soucis d'infériorité ?
Soyons sérieux une minute quel "scientifique" (je mets entre guillemet parce que entre nous tu n'es pas chercheur c'est impossible), utiliserait comme argument "très complexe" et "gagner beaucoup d'argent" comme argument fiable ?
La réponse : aucun.
De tout ton discours, je n'ai pas lu une seule fois ,un discours rigoureux , le seul que tu as tenu c'est de raconter des bêtises plus grosse que toi , et d'avoir un complexe de supériorité.
Mais le charlatanisme et se croire plus malin que les autres ne change pas la réalité .
On écrivant ces lignes, je me demande si certaine personne croie que en criant haut et fort des inepties et on se convaincant sois même ce qui est raconté ,cela se réalisera ?
Parce que c'est la seule explication logique que je trouve à ton comportement.le 03/11/2022 à 7:05