On connait désormais la cause profonde du fiasco CrowdStrike. Il s’agit bien d’un écran bleu provoqué par une tentative de lecture de la mémoire hors des limites, causée par… une erreur de compréhension entre deux composants du logiciel de CrowdStrike. L’un attend 21 paramètres, quand l’autre n’en propose que 20. Pour une entrée manquante, c’est la grosse tuile.
Le 19 juillet au matin, la société spécialisée dans la cybersécurité CrowdStrike publiait une mise à jour de son logiciel. Rien d’anormal jusque-là, mais le nouveau fichier avait un gros problème : il provoquait des plantages et des écrans bleus en boucle sur les PC Windows, y compris les serveurs.
Un bug, des conséquences importantes
Le grand public a alors découvert l’existence de CrowdStrike pour une bonne partie, et sa présence dans de nombreux systèmes critiques. En effet, difficile de passer à côté des pannes en série qui ont découlées de ce bug : des annulations dans les aéroports, une bourse au ralenti, des employés au chômage technique faute d’ordinateurs utilisables, etc.
Les ordinateurs de la très grande majorité des utilisateurs de Windows n’étaient pas directement affectés. Il faut en effet avoir CrowdStrike, une solution pour les entreprises, pour être directement touché. Indirectement par contre, c’était une autre histoire.
Le week-end suivant la panne, CrowdStrike publiait de premiers détails techniques sur la panne. De son côté, Microsoft annonçait que 8,5 millions de machines étaient affectées, soit moins de 1 % de l’ensemble du parc Windows. Suffisant pour provoquer une belle pagaille un peu partout dans le monde.
Cinq jours après le fiasco, l’entreprise détaillait la chronologie des événements et annonçait des mesures correctives pour éviter que cela puisse se reproduire. On y apprenait notamment que les mises à jour subissaient des tests avant d’être déployées, mais que celle du 19 juillet était passée entre les mailles du filet à cause d’un bug dans le validateur de contenu.
- [MàJ] Fiasco CrowdStrike : détails techniques, 8,5 millions de machines touchées selon Microsoft
- Fiasco CrowdStrike : la chronologie des évènements, les mesures prises par l’éditeur
Le Root Cause Analysis est là
Hier, CrowdStrike a mis en ligne un nouveau document attendu : le Root Cause Analysis (RCA), un PDF de 12 pages qui détaille les causes profondes et les actions mises en place. Une nouvelle fois, l’éditeur « s’excuse sans réserve » auprès de ses clients. Le fondateur et CEO de l’entreprise, George Kurtz, fait de même. Il précise au passage que 99 % des sondes sous Windows étaient de nouveau fonctionnelles au 29 juillet, avec une variation de ±1 % au fil des semaines, contre 97 % le 24 juillet, cinq jours après l’incident.
This morning, we published the Root Cause Analysis (RCA) detailing the findings, mitigations and technical details of the July 19, 2024, Channel File 291 incident. We apologize unreservedly and will use the lessons learned from this incident to become more resilient and better…
— CrowdStrike (@CrowdStrike) August 6, 2024
Dans son introduction, le rapport détaillé sur les causes profondes de la panne remonte en février 2024, quand CrowdStrike ajoute à son capteur Falcon une nouvelle fonctionnalité pour détecter de nouveaux types d’attaques (Template Type) sous Windows. C'est pour cela que seul le système de Microsoft était impacté. CrowdStrike est aussi disponible sur MacOS et Linux, mais ils ne pouvaient donc pas être affectés.
Quelques jours plus tard, le 5 mars, un premier Rapid Response Content est déployé (pour le Channel File 291) après une série de tests, affirme l’entreprise. Les Rapid Response Content sont au capteur Falcon ce que les fichiers de définition sont aux antivirus : ils permettent de se tenir à jour sur les attaques, sans actualiser le capteur en lui-même.
Février, mars, avril… tout va bien avec la nouvelle config
D’autres mises à jour sont ensuite déployées entre les 8 et 24 avril, toujours via les Rapid Response Content. CrowdStrike ajoute que toutes ces versions ont fonctionné comme prévu en production.
Les Rapid Response Content sont traités par le Content Interpreter du capteur, « à l'aide d'un moteur basé sur des expressions régulières ». Chaque Rapid Response Content est donc « associé à un Template Type spécifique », pour chaque version du capteur.
Avec la nouvelle version 7.11 de son capteur, CrowdStrike a ajouté un Template Type pour prendre en charge de nouvelles techniques d’attaques, notamment les canaux nommés et d’autres communications interprocessus dans Windows (IPC). C’est le rôle du Channel File 291.
Du Rapid Response Content au Rapid BSOD
La suite, on la connait : deux nouvelles instances sont déployées via une mise à jour Rapid Response Content à 6h09, heure française, le 19 juillet. Et là, c’est le drame. Une des deux « faisait évoluer la nouvelle fonctionnalité publiée pour la première fois en février 2024 », avec les conséquences que l’on connait.
L’explication est finalement assez simple : « Le capteur attendait 20 champs en entrée, alors que la mise à jour en fournissait 21. Dans cette situation, la non-concordance a entraîné une lecture mémoire hors limites, provoquant un crash du système ».
Cette différence entre le nombre de paramètres proposés et ceux attendus « a échappé à plusieurs couches de validation et de tests ». CrowdStrike n’a rien vu non plus lors des « stress test » sur son Template Type ni lors des premiers déploiements sans encombre quelques mois auparavant.
Un paramètre en plus ou en moins, et c’est le drame
Pourquoi en juillet et pas avant, ni pendant les tests ? « Cela était dû en partie à l'utilisation de critères de correspondance génériques pour la 21e entrée lors des tests et dans les premières Template Instances IPC ». Le bug était donc déjà présent lors des précédentes mises à jour, sans pour autant se déclencher.
Lors de la mise à jour du 19 juillet, une des deux mises à jour « a introduit un critère de correspondance non générique pour le 21e paramètre d'entrée ». Et patatras : « Ces nouvelles Template Instances ont conduit à une nouvelle version du fichier Channel File 291 qui nécessitait alors que le capteur examine le 21e paramètre d'entrée ».
Jusqu’à présent, le 21e paramètre n’avait pas d’importance et n’était pas utilisé par les Template Instances IPC. Mais les capteurs qui ont reçu la nouvelle version du Channel File 291 et dès « la prochaine notification IPC du système d'exploitation, les nouvelles Template Instances IPC ont été vérifiées ».
La 21e entrée a alors fait son entrée fracassante. « Le Content Interpreter n'attendait que 20 valeurs. Par conséquent, la tentative d'accès à la 21e valeur a généré une lecture de mémoire hors limites […] et a entraîné un crash du système ».
Simple, mais diablement efficace. Cela explique aussi pourquoi CrowdStrike faisait planter en boucle les ordinateurs : la même erreur se répétait sans cesse à chaque démarrage. On comprend aussi pourquoi une mise à jour de l’application permettait de résoudre le souci… encore fallait-il que la mise à jour se fasse avant le plantage. Certains y arrivaient, d’autres non. Les recommandations étaient d’essayer de redémarrer sa machine une quinzaine de fois.
Une série de problèmes et au moins autant de correctifs
Pour résumer, le bug est la conséquence de plusieurs éléments : « l'inadéquation entre les 21 entrées du Content Validator et des 20 du Content Interpreter, le problème de lecture hors limites qui était latent dans le Content Interpreter et l'absence d'un test pour vérifier spécifiquement les critères de correspondance non génériques dans le 21e champ ».
Plusieurs correctifs ont été mis en place. Désormais, le Content Compiler du capteur vérifie le nombre de paramètres. Il a déjà été mis en production le 27 juillet dans les outils internes de la société. Le programme vérifie au passage qu’il n’existe pas de problème sur le nombre de paramètres des Template Types, quelle que soit la plateforme.
Le Content Interpreter vérifie également qu’il ne va pas lire des données mémoire hors limite, une sage précaution… Une mise à jour sera déployée sur toutes les versions à partir de la 7.11 du capteur, avec une disponibilité générale prévue au 9 août. Bien évidemment, le nombre d’entrées attendues et proposées ont été alignées, à 21.
Ce bug « ne peut plus se reproduire »
Enfin, toujours selon l’analyse de CrowdStrike et celle d’un tiers (dont le nom n’est pas précisé), « ce bug n'est pas exploitable par un acteur malveillant ». L’entreprise ajoute avoir évidemment procédé à des corrections. Dorénavant, un tel scénario avec le Channel File 291 « ne peut plus se reproduire ».
Commentaires (52)
#1
Ne jamais dire jamais. Surtout en informatique, et encore moins quand on a le cul sale et qu'on est à l'origine d'un des plus grands fiascos de l'informatique.
Pour preuve :
- le processus de vérification n'aurait jamais du laisser passer cette erreur (zut, il était bogué lui aussi)
- un fichier de définition ne devrait jamais faire planter un driver (zut, c'est pourtant ce qu'il s'est passé)
- "ce bug n'est pas exploitable par un acteur malveillant" : si, pour faire un DOS
#1.1
J'ose espérer qu'ils contrôlent qui leur envoie les mise à jour de leurs fichiers de configuration (connexion sécurisée et authentifiée ou autre moyen) et que ça ne peut qu'être eux.
Dans ce cas, on ne peut pas exploiter ce bug même avant que la MAJ soit poussée.
#1.2
Le bogue ne sera plus exploitable quand :
1) il sera corrigé (c'est fait)
2) le correctif sera déployé partout (ce qui n'est pas encore tout à fait le cas, même si une grande part est à jour maintenant).
Mais dire que le bogue n'est pas exploitable par un acteur malveillant, c'est factuellement faux.
#1.3
#1.4
Historique des modifications :
Posté le 07/08/2024 à 14h40
Pas forcément besoin des droits admin sur la machine, surtout en entreprise. Une corruption du proxy est bien suffisante, qui permettrait une attaque de type de l'homme du milieu, souvent facilité par le fait que de tels entités installent généralement un certificat racine sur l'ensemble de leur parc pour pouvoir analyser le trafic entrant...
#1.5
#2
#2.1
#2.2
Un peu comme quand on retrouve les boites noires d'un avion après un crash. Il faut plusieurs mois pour avoir le rapport de l'autorité compétente. Même si la cause apparaît rapidement, il faut être sûr qu'on a bien tout analysé et compris.
#2.3
20 jours c'est le délai entre le bug et la publication du post mortem.
#3
#3.1
eBPF est considéré comme une solution plus sûre que de la programmation système pour faire tourner du code ajouté dans le noyau Linux.
Je pense que le problème ne vient pas des regex, mais des extensions noyaux façon Crowdstrike, ou éventuellement de l'absence d'un mécanisme similaire à eBPF recommandé par Microsoft.
#4
Vivement un 22e paramètre pour qu'on ressorte les pop-corn
#4.1
Mais je n'étais dit la même chose.
#4.2
cela dépendra de si le tableau commence a zéro ou à un.
/mode troll off
#5
#5.1
#6
Les clients ont-ils une interface d'Administration ?
De notre côté, on pousse la nouvelle version sur quelques postes "tests" et puis si pas d'écran bleu, là on pousse à tout le monde.
J'ai peut-être loupé une étape cette affaire.
#6.1
Le jour même ils ont publié un nouveau fichier et plus tard, ils ont visiblement mis à disposition une nouvelle version de l'agent.
Jusqu'à présent, l'agent pouvait être déployé selon le bon vouloir des adminsys, par contre les définitions étaient poussées automatiquement par Crowstrike sans moyen de différer la mise à jour, d'où le fait que toutes les machines ont toutes plantées en même temps (pour celles allumées et sur internet au moment de la panne).
Crowdstrike a promit que les clients pourraient désormais temporiser également les mises à jour des définitions.
Historique des modifications :
Posté le 07/08/2024 à 19h11
Ce n'est pas l'agent qui s'est déployé automatiquement mais les fichiers de signatures ("Template Type Definitions").
Le jour même ils ont publié un nouveau fichier et plus tard, ils ont visiblement mis à disposition une nouvelle version de l'agent.
Jusqu'à présent, l'agent pouvait être déployé selon le bon vouloir des adminsys, par contre les définitions étaient poussées automatiquement par Crowstrike sans moyen de différer la mise à jour, d'où le fait que toutes les machines ont toutes plantées en même temps (pour celles allumées et sur internet au moment de la panne).
Crowdstrike a promit que les clients pourraient désormais temporiser également les mises à jour des définitions.
Posté le 07/08/2024 à 19h11
Ce n'est pas l'agent qui s'est déployé automatiquement mais les fichiers de signatures ("Template Type Definitions").
Le jour même ils ont publié un nouveau fichier et plus tard, ils ont visiblement mis à disposition une nouvelle version de l'agent.
Jusqu'à présent, l'agent pouvait être déployé selon le bon vouloir des adminsys, par contre les définitions étaient poussées automatiquement par Crowstrike sans moyen de différer la mise à jour, d'où le fait que toutes les machines ont toutes plantées en même temps (pour celles allumées et sur internet au moment de la panne).
Crowdstrike a promit que les clients pourraient désormais temporiser également les mises à jour des définitions.
#6.2
- Dans un cas, je ne patch pas tout de suite mes assets les plus importants, mais ils risquent les attaques pendant plus longtemps
- Dans l'autre, je patch vite pour me protéger (on rappelle que c'est pour ça que les DSI achètent ces produits...)
Crowstrike existe depuis bien longtemps et on entend parler d'eux en mal pour la 1ere fois. Quand on achète un produit, on doit faire en partie confiance à l'éditeur : à chacun de mettre le curseur là où il le souhaite. Si on veut faire des vérifications en plus, il faut avoir les moyens (financier et humains) !
#6.3
L'origine des problèmes ne semble pas être la même (et l'étendue non plus), mais cela n'empêche qu'il y a déjà eu des soucis plus tôt en 2024 :
https://www.neowin.net/news/crowdstrike-broke-debian-and-rocky-linux-months-ago-but-no-one-noticed/
#7
#8
#8.1
#9
"Si une grosse couill... peut potentiellement arriver dans un système, elle finira SYSTEMATIQUEMENT par arriver un jour ou l'autre, tout n'étant qu'une question de temps"
"des fois, la vie est mal faite" ... ou bien aussi "certains n'ont vraiment pas de bol dans la vie"
.
Historique des modifications :
Posté le 07/08/2024 à 18h39
Est-ce un exemple éclatant (et mémorable) qui valide la loi de Murphy ?
"Si une grosse couill... peut potentiellement arriver dans un système, elle finira SYSTEMATIQUEMENT par arriver un jour ou l'autre, tout n'étant qu'une question de temps"
(des fois, la vie est mal faite...)
Posté le 07/08/2024 à 18h40
Est-ce un exemple éclatant (et mémorable) qui valide la loi de Murphy ?
"Si une grosse couill... peut potentiellement arriver dans un système, elle finira SYSTEMATIQUEMENT par arriver un jour ou l'autre, tout n'étant qu'une question de temps"
(des fois, la vie est mal faite...)
Posté le 07/08/2024 à 18h41
Est-ce un exemple éclatant (et mémorable) qui valide la loi de Murphy ?
"Si une grosse couill... peut potentiellement arriver dans un système, elle finira SYSTEMATIQUEMENT par arriver un jour ou l'autre, tout n'étant qu'une question de temps"
"des fois, la vie est mal faite" ... ou bien aussi "certains n'ont vraiment pas de bol dans la vie"
.
Posté le 07/08/2024 à 18h42
Est-ce un exemple éclatant (et mémorable) qui valide la loi de Murphy ?
"Si une grosse couill... peut potentiellement arriver dans un système, elle finira SYSTEMATIQUEMENT par arriver un jour ou l'autre, tout n'étant qu'une question de temps"
"des fois, la vie est mal faite" ... ou bien aussi "certains n'ont vraiment pas de bol dans la vie"
.
Posté le 07/08/2024 à 18h42
Est-ce un exemple éclatant (et mémorable) qui validerait la loi de Murphy ?
"Si une grosse couill... peut potentiellement arriver dans un système, elle finira SYSTEMATIQUEMENT par arriver un jour ou l'autre, tout n'étant qu'une question de temps"
"des fois, la vie est mal faite" ... ou bien aussi "certains n'ont vraiment pas de bol dans la vie"
.
Posté le 07/08/2024 à 18h43
Est-ce un exemple éclatant (et mémorable) qui validerait la loi de Murphy ?
"Si une grosse couill... peut potentiellement arriver dans un système, elle finira SYSTEMATIQUEMENT par arriver un jour ou l'autre, tout n'étant qu'une question de temps"
"des fois, la vie est mal faite" ... ou bien aussi "certains n'ont vraiment pas de bol dans la vie"
.
Posté le 07/08/2024 à 18h43
Est-ce un exemple éclatant (et mémorable) qui validerait la loi de Murphy ?
"Si une grosse couill... peut potentiellement arriver dans un système, elle finira SYSTEMATIQUEMENT par arriver un jour ou l'autre, tout n'étant qu'une question de temps"
"des fois, la vie est mal faite" ... ou bien aussi "certains n'ont vraiment pas de bol dans la vie"
.
Posté le 07/08/2024 à 18h44
Est-ce un exemple éclatant (et mémorable) qui validerait la loi de Murphy ?
"Si une grosse couill... peut potentiellement arriver dans un système, elle finira SYSTEMATIQUEMENT par arriver un jour ou l'autre, tout n'étant qu'une question de temps"
"des fois, la vie est mal faite" ... ou bien aussi "certains n'ont vraiment pas de bol dans la vie"
.
Posté le 07/08/2024 à 18h47
Est-ce un exemple éclatant (et mémorable) qui validerait la loi de Murphy (@Wiki) ?
"Si une grosse couill... peut potentiellement arriver dans un système, elle finira SYSTEMATIQUEMENT par arriver un jour ou l'autre, tout n'étant qu'une question de temps"
"des fois, la vie est mal faite" ... ou bien aussi "certains n'ont vraiment pas de bol dans la vie"
.
#10
Mais j'ai relevé ceci comme proposition d'atténuation du bug : "Bounds checking was added to the Content Interpreter function that retrieves input strings on July 25, 2024." Ici, ils proposent que le module module X (Content Interpreter), qui reçoit les paramètres sous la forme d'un tableau teste s'il y a bien le nombre de case attendues dans le tableau. Plus loin dans le rapport, on lit : "Examining the input array, we indeed find an array of 20 pointers to input string structures, followed by a 21st value which does not point to valid memory". On comprend plus loin dans la trace exposée que le programme n'a pas planté parce qu'il avait lu la 21ème case, mais il a planté parce qu'à la 21 case (enfin celle qui suit la vingtième), il y a un pointeur invalide (puisqu'il n'y a que 20 cases de reçues), et c'est en lisant ce pointeur censé pointer vers une chaîne de caractères que le tout a planté. Dans une autre configuration mémoire, ce pointeur dans la case 21 d'un tableau de 20 cases, bien que invalide, aurait pu pointer vers une zone mémoire valide par pur hasard. En d'autre termes, le processus n'aurait pas planté dans ce cas, ce qui rend hypothétiquement le bug intempestif. A certains moment le processus plante parce que le pointeur de la case 21 est invalide, à d'autres moment, le pointeur de la case 21 pointe malencontreusement vers une zone mémoire valide du processus ce qui peut permettre de valider les tests d'un côté, mais quand même faire planter le processus en production de l'autre côté. Je ne sais pas si c'est ce qui produit ici, mais ça aurait pu être le cas.
Dans un autre langage plus moderne que le C, le programme aurait planté dans 100% des cas dès la lecture de la case N+1 du tableau de N cases, avant la lecture du pointeur invalide dans certains cas, et malencontreusement valide dans d'autres cas. Je n'ai pas réussi à déterminer si ce "hasard" s'est produit ou non en lisant le rapport.
#10.1
Avec une équipe de dev compétente en C et un management adapté, le code aurait 100% planté lors des tests avec, par exemple un canari ou un run-time boundary checker, et ceux sans compter sur la chance ou non d'invalité un pointeur ou une page mémoire.
#10.2
#10.3
#10.5
Oui des tests de plusieurs heures. On parle d'un driver tournant dans le kernel. Je vois pas le soucis vu la sensibilité du bestiau.
#10.4
C'est pas une start-up qui produit des filtres pour Insta ou autres en user-space sandboxé, docker et co.
Donc elle a largement les moyens d'avoir des gens compétents et au fait de ce genre de choses. Mettre un canarie en place, c'est le compilo qui le fait (sauf peut-être pour MVSC...). Un boundary checker proprement implanté, oui c'est un poil plus hard mais c'est faisable surtout qu'ici la valeur semblait connu à l'avance. Encore une fois, elle en a les moyens financiers de se donner les moyens techniques.
Quant au choix du C, c'est peut-être à la toolchain de MS pour compiler ou bien à des questions de stabilité d'API.
#10.6
Quant au canari, ça peut fonctionner pour la case N+1, mais est-ce que ça fonctionnera pour la case N+10 ?
Après, ce n'est pas une question de compétence pour moi, mais c'est juste une question de choisir un langage un poil moins casse gueule. Sur des projets de cette importance, comme sur des projets modestes, ça s'envisage ! De cette manière vous pourrez mettre vos compétences, votre concentration, et donc votre argent ailleurs. Mais si vous préférez le C, vous faites comme vous le sentez ! Tout comme moi !
#10.8
Un canari sur un N+10, bonne question car la représentation mémoire va jouer. Mais si à N+10, ça ne se fait pas choper lors des tests, c'est qu'il y a un gros soucis.
Sauf que Rust ou autres langages safe n'étaient peut-être pas présent à l'époque. Pourquoi ne pas avoir passé dans un langage plus safe (C++ ou Rust) ? Je vois au moins trois raisons : Premièrement le coût (et là c'est un soucis de compétences dans la capacité à évaluer le risques. Boeing-like).
Secondo, les outils pour la toolchain n'existe peut-être pas pour du C++ ou Rust. Pour rappel, c'est du kernel ! ça ne ce code pas "comme ça".
Troisio, une question de stabilité d'API/ABI.
Mon point est de dire que le C n'est pas un choix idiot et que ce n'est pas la faute du langage. Oui le C est casse-gueule (c'est comme donné un glock à gamin de 4 ans chargées et sécurité désengagé), mais si il y a des parfois du bon sens quand on code avec ce genre de langages (i.e., déchargé le pistolet et mettre la sécurité) et des choses aussi critique d'un module noyau (i.e., le gamin).
#10.10
Le C++ plantait pas forcément à N+1 si vous faisiez pas le test. Comme le C, c'était le hasard. Je sais pas si ça a changé. Vous aviez plus de chance en mode debug d'avoir l'erreur, mais le mode debug, c'était 7 fois plus lent !
Historique des modifications :
Posté le 07/08/2024 à 23h35
Ah, quand vous parliez de "boundary checker" je pensais que vous parliez d'un outil de monitoring qui fait le boulot pour vous. Si c'est vous qui faites le boulot, ben autant que ce soit le compilateur qui le fasse en ajoutant une taille au tableau, et un test à chaque accès, surtout sur ces notions où l'erreur coûte chère. C'est juste le point que j'ai voulu souligner au départ dans mon premier commentaire.
Le C++ plantait pas forcément à N+1 si vous faisiez pas le test. Comme le C, c'était le hasard. Je sais pas si ça a changé. Vous aviez plus de chance en mode debug d'avoir l'erreur, mais le mode debug, c'était 7 fois plus lent !
#10.7
#10.9
Je pensais en pratique à un truc plus simple dans le genre :
int readMemory(const char* arr, const int idx, const int len)
{
if(idx<len)
return arr[idx];
else
return -1;
}
#10.11
Miser sur la compétence dans ce cas est inutile car l'erreur est humaine !
Quant à l'article, qu'il ne soit pas peer reviewé n'est pas si important, je cherchais juste un ordre de grandeur pour appuyer mon propos, ce n'est pas ici qu'on va faire un article sur le sujet.
Historique des modifications :
Posté le 07/08/2024 à 23h41
Non, mais là, si vous vous qui le faites le test, c'est hors sujet. Mon commentaire initial visait à ce que le langage ne vous permette pas de faire tout et n'importe quoi. Là vous prenez un test valide qui fonctionne, mais ce n'est pas le problème. Le problème est d'éviter les comportement random quand justement, vous avez oublié de faire ce test !
Miser sur la compétence dans ce cas est inutile car l'erreur est humaine !
Quant à l'article, qu'il ne soit pas peer reviewé n'est pas si important, je cherchais juste un ordre de grandeur pour appuyer mon propos, ce n'est pas ici qu'on va faire un article sur le sujet.
Posté le 07/08/2024 à 23h44
Non, mais là, si c'est vous qui faites le test, c'est hors sujet. Mon commentaire initial visait à ce que le langage ne vous permette pas de faire tout et n'importe quoi. Là vous prenez un test valide qui fonctionne, mais ce n'est pas le problème. Le problème est d'éviter les comportement random quand justement, vous avez oublié de faire ce test !
Miser sur la compétence dans ce cas est inutile car l'erreur est humaine !
Quant à l'article, qu'il ne soit pas peer reviewé n'est pas si important, je cherchais juste un ordre de grandeur pour appuyer mon propos, ce n'est pas ici qu'on va faire un article sur le sujet.
#10.12
Et si vraiment la durée des tests était un problème, on augmenterait tout simplement le nombre de machines de test pour faire tourner les tests en parallèles.
Changer de langage ne va pas permettre de résoudre le problème magiquement sans pénalité. Les langages contrôlant les accès à la mémoire sont, de manière générale, plus lent que le C, d'un facteur... qui correspond peu ou prou au 1,8 (Java, C#) à 77 (Python, Ruby) fois celui indiqué dans le papier. Sans compter que le langage aura souvent besoin d'un runtime et/ou d'une VM.
A ma connaissance, il n'y a que Rust qui permettrait de se prémunir de se genre d'erreurs (et à la condition de ne pas abuser du code unsafe), ne nécessitant pas de VM, et ayant un runtime très léger.
Et encore une fois, nous parlons ici d'un driver. Un driver nécessite un langage de bas niveau comme le C, le Rust ou encore l'Ada. La plupart des langages "modernes" sont totalement inutilisables pour écrire un driver.
#10.13
Pour les tests, encore une fois c'est une question de choix. Donc si vous faites le choix que c'est pas grave d'avoir 77 fois plus de serveurs pour lancer une batterie de test, c'est votre droit, mais ce n'est pas forcément "tout simple" comme décision à prendre. Maintenant oui, 77 est la pire situation.
Très sincèrement, au bout d'un moment, je ne comprend pas cette discussion. Vous avez le droit de continuer de développer en C, mais mon propos est appuyé et j'ai le droit de constater et de considérer que ce langage a fait son temps, comme un certain nombre de personne l'on déjà fait.
Historique des modifications :
Posté le 08/08/2024 à 00h03
Mais Rust est un langage moderne, et Rust a un facteur de 1.05 si ma mémoire est bonne. Même Microsoft essayer de basculer vers Rust. Mon petit doigt me dit que c'est pour les même raisons que celles que j'ai évoqué "La firme s’est lancée dans une série d’articles portant sur la sécurité du code informatique. L’éditeur en dresse un tableau peu reluisant, avec un objectif en tête : réduire, et si possible se débarrasser des erreurs liées à la gestion de la mémoire."
Pour les tests, encore une fois c'est une question de choix. Donc si vous faites le choix que c'est pas grave d'avoir 77 fois plus de serveurs pour lancer une batterie de test, c'est votre droit, mais ce n'est pas forcément "tout simple" comme décision à prendre. Maintenant oui, 77 est la pire situation.
Très sincèrement, au bout d'un moment, je ne comprend pas cette discussion. Vous avez le droit de continuer de développer en C, mais mon propos est appuyé et j'ai le droit de constater et de considérer que ce langage a fait son temps, comme un certain nombre de personne l'on déjà fait.
#10.14
#10.15
Ai-je dis le contraire ? Relisez mon commentaire, et vous verrez. J'y précise que Rust est un des rares candidats viables pour la programmation système.
Heureusement que vous rappelez à la fin que 77 est la pire des situations, sinon, on pourrait penser que vous êtes dans l'exagération permanente. Ce n'est pas comme si le papier sur lequel vous vous basez datait de 2015 (9 ans, c'est une éternité en informatique, des progrès ont été fait depuis), n'était que rarement cité par d'autres articles, était un proof of concept en mal d'optimisation, et qu'il n'existait pas d'alternative bien plus performante comme Address Sanitizer (pourtant cité dans l'article) "se contentant" d'un facteur 2.
Utiliser un langage pour démarrer un nouveau projet n'est pas la même chose que d'inclure un nouveau langage dans un projet existant. Ce ne sont pas du tout les mêmes contraintes et à de nombreux niveaux. Maintenant oui, vous avez le droit d'avoir votre opinion, comme j'ai le droit d'avoir la mienne.
J'en ai simplement marre de lire des "y'a qu'à faut qu'on". Ne pas oublier qu'un langage comme Rust par exemple, la première version stable est sortie en 2015. C'est récent pour un langage. Les effets de mode en informatique aussi et il est important de ne pas se jeter sur une nouvelle techno lorsqu'elle sort. Rust a connu de grosses incertitudes quant à a sa survie durant la crise de la COVID en 2020, quand Mozilla a dégagé l'équipe de Servo, dont les membres étaient les principaux contributeurs à Rust.
Aujourd'hui, les choses sont plus stables. Rust a maintenant sa fondation, qui se repose sur plusieurs entreprises dont certains GAFAM, et c'est effectivement un langage qui se réfléchit. Mais il faut :
1) se former (au langage, aux outils, ...)
2) avoir un nouveau projet (ou un projet très modularisé)
2bis) ou avoir une refonte d'un projet qui nécessite une réécriture complète (ce qui est, en fait, l'équivalent d'un nouveau projet).
#10.16
Je n'ai pas dit "y'a qua fo kon". Pouvez-vous me citer ? N'est-ce pas vous qui exagérez ?
Mon commentaire initial ne discute pas de Rust. Vous m'y avez amené entre citant plusieurs langages et en expliquant qu'ils étaient trop lents, puis ensuite, vous me reprochez de citer un langage trop récent. Je vous ai cité Rust pour vous dire qu'il y a au moins un exemple. Que ce soit Rust ou un autre langage ne m'intéresse pas beaucoup au fond, c'est pourquoi, dans mon commentaire initial, je n'ai cité aucun langage de particulier. Que la transition se fasse demain ou après demain ne m'intéresse pas beaucoup. Ca se fera quand ça se fera ou ça se fera pas.
Si vous êtes d'accord sur le fond, pourquoi me contredire ? C'est inutile je trouve. Si Rust n'est pas un langage mature, ben il l'est pas, je vais pas vous contredire. Si il l'est, il l'est. Je n'ai pas dit qu'il l'était, j'ai même sous entendu une possibilité du contraire dans des commentaires de fils précédents avant que vous ne le disiez.
Quand à l'historique que vous citez de Rust, je vois pas pourquoi vous partez du principe que je ne le connais pas et que j'aurais besoin d'un cours, et que je ne sais pas tout ce que vous dites. Et pour dire quoi au final qui contredise ce que j'ai dit ?
Non franchement, je comprend pas cette discussion, ni sur quoi ne sommes pas vraiment d'accord. J'ai l'impression que si je dis quelque chose, vous allez détourner la conversion sur autre chose que je n'ai pas dite, puis je vous répond, vous ça recommence et ainsi de suite. Relisez mon commentaire initial, et je vois pas ce qu'il y a à redire.
Historique des modifications :
Posté le 08/08/2024 à 10h16
Je ne suis pas dans l'exagération permanente, j'ai écrit dès le début que c'était la pire situation. Relisez aussi mon commentaire qui en parle au départ. Et si j'envisage la pire situation situation, c'est parce que si elle se produit, il faut être capable de l'assumer, simple précaution de base. Vous me donnez des intentions que je n'ai pas, comme c'est à votre habitude maintenant. Est-ce un traitement particulier que vous me réservez ?
Je n'ai pas dit "y'a qua fo kon". Pouvez-vous me citer ?
Mon commentaire initial ne discute pas de Rust. Vous m'y avez amené entre citant plusieurs langages et en expliquant qu'ils étaient trop lents, puis ensuite, vous me reprochez de citer un lange trop récent. Je vous ai cité Rust pour vous dire qu'il y a au moins un exemple. Que ce soit Rust ou un autre langage ne m'intéresse pas beaucoup au fond, c'est pourquoi, dans mon commentaire initial, je n'ai cité aucun langage de particulier. Que la transition se fasse demain ou après demain ne m'intéresse pas beaucoup. Ca se fera quand ça se fera ou ça se fera pas.
Si vous êtes d'accord sur le fond, pourquoi me contredire ? C'est inutile je trouve. Si Rust n'est pas un langage mature, ben il l'est pas, je vais pas vous contredire. Je n'ai pas dit qu'il l'était, j'ai même sous entendu le contraire dans des commentaires de fils précédents avant que vous ne le disiez.
Quand à l'historique que vous citez de Rust, je vois pas pourquoi vous partez du principe que je ne le connais pas et que j'aurais besoin d'un cours. Et pour dire quoi au final qui contredirez ce que j'ai dit ?
Non franchement, je comprend pas cette discussion, ni sur quoi ne sommes pas vraiment d'accord. J'ai l'impression que si je dis quelque chose, vous allez détourner la conversion sur autre chose que je n'ai pas dite, puis je vous répond, vous ça recommence et ainsi de suite. Relisez mon commentaire initial, et je vois pas ce qu'il y a à redire.
Posté le 08/08/2024 à 10h16
Je ne suis pas dans l'exagération permanente, j'ai écrit dès le début que c'était la pire situation. Relisez aussi mon commentaire qui en parle au départ. Et si j'envisage la pire situation situation, c'est parce que si elle se produit, il faut être capable de l'assumer, simple précaution de base. Vous me donnez des intentions que je n'ai pas, comme c'est à votre habitude maintenant. Est-ce un traitement particulier que vous me réservez ?
Je n'ai pas dit "y'a qua fo kon". Pouvez-vous me citer ?
Mon commentaire initial ne discute pas de Rust. Vous m'y avez amené entre citant plusieurs langages et en expliquant qu'ils étaient trop lents, puis ensuite, vous me reprochez de citer un langage trop récent. Je vous ai cité Rust pour vous dire qu'il y a au moins un exemple. Que ce soit Rust ou un autre langage ne m'intéresse pas beaucoup au fond, c'est pourquoi, dans mon commentaire initial, je n'ai cité aucun langage de particulier. Que la transition se fasse demain ou après demain ne m'intéresse pas beaucoup. Ca se fera quand ça se fera ou ça se fera pas.
Si vous êtes d'accord sur le fond, pourquoi me contredire ? C'est inutile je trouve. Si Rust n'est pas un langage mature, ben il l'est pas, je vais pas vous contredire. Je n'ai pas dit qu'il l'était, j'ai même sous entendu le contraire dans des commentaires de fils précédents avant que vous ne le disiez.
Quand à l'historique que vous citez de Rust, je vois pas pourquoi vous partez du principe que je ne le connais pas et que j'aurais besoin d'un cours. Et pour dire quoi au final qui contredirez ce que j'ai dit ?
Non franchement, je comprend pas cette discussion, ni sur quoi ne sommes pas vraiment d'accord. J'ai l'impression que si je dis quelque chose, vous allez détourner la conversion sur autre chose que je n'ai pas dite, puis je vous répond, vous ça recommence et ainsi de suite. Relisez mon commentaire initial, et je vois pas ce qu'il y a à redire.
Posté le 08/08/2024 à 10h17
Je ne suis pas dans l'exagération permanente, j'ai écrit dès le début que c'était la pire situation. Relisez aussi mon commentaire qui en parle au départ. Et si j'envisage la pire situation situation, c'est parce que si elle se produit, il faut être capable de l'assumer, simple précaution de base. Vous me donnez des intentions que je n'ai pas, comme c'est à votre habitude maintenant. Est-ce un traitement particulier que vous me réservez ?
Je n'ai pas dit "y'a qua fo kon". Pouvez-vous me citer ? N'est-ce pas vous qui exagérez ?
Mon commentaire initial ne discute pas de Rust. Vous m'y avez amené entre citant plusieurs langages et en expliquant qu'ils étaient trop lents, puis ensuite, vous me reprochez de citer un langage trop récent. Je vous ai cité Rust pour vous dire qu'il y a au moins un exemple. Que ce soit Rust ou un autre langage ne m'intéresse pas beaucoup au fond, c'est pourquoi, dans mon commentaire initial, je n'ai cité aucun langage de particulier. Que la transition se fasse demain ou après demain ne m'intéresse pas beaucoup. Ca se fera quand ça se fera ou ça se fera pas.
Si vous êtes d'accord sur le fond, pourquoi me contredire ? C'est inutile je trouve. Si Rust n'est pas un langage mature, ben il l'est pas, je vais pas vous contredire. Je n'ai pas dit qu'il l'était, j'ai même sous entendu le contraire dans des commentaires de fils précédents avant que vous ne le disiez.
Quand à l'historique que vous citez de Rust, je vois pas pourquoi vous partez du principe que je ne le connais pas et que j'aurais besoin d'un cours. Et pour dire quoi au final qui contredise ce que j'ai dit ?
Non franchement, je comprend pas cette discussion, ni sur quoi ne sommes pas vraiment d'accord. J'ai l'impression que si je dis quelque chose, vous allez détourner la conversion sur autre chose que je n'ai pas dite, puis je vous répond, vous ça recommence et ainsi de suite. Relisez mon commentaire initial, et je vois pas ce qu'il y a à redire.
Posté le 08/08/2024 à 10h19
Je ne suis pas dans l'exagération permanente, j'ai écrit dès le début que c'était la pire situation. Relisez aussi mon commentaire qui en parle au départ. Et si j'envisage la pire situation situation, c'est parce que si elle se produit, il faut être capable de l'assumer, simple précaution de base. Vous me donnez des intentions que je n'ai pas, comme c'est à votre habitude maintenant. Est-ce un traitement particulier que vous me réservez ?
Je n'ai pas dit "y'a qua fo kon". Pouvez-vous me citer ? N'est-ce pas vous qui exagérez ?
Mon commentaire initial ne discute pas de Rust. Vous m'y avez amené entre citant plusieurs langages et en expliquant qu'ils étaient trop lents, puis ensuite, vous me reprochez de citer un langage trop récent. Je vous ai cité Rust pour vous dire qu'il y a au moins un exemple. Que ce soit Rust ou un autre langage ne m'intéresse pas beaucoup au fond, c'est pourquoi, dans mon commentaire initial, je n'ai cité aucun langage de particulier. Que la transition se fasse demain ou après demain ne m'intéresse pas beaucoup. Ca se fera quand ça se fera ou ça se fera pas.
Si vous êtes d'accord sur le fond, pourquoi me contredire ? C'est inutile je trouve. Si Rust n'est pas un langage mature, ben il l'est pas, je vais pas vous contredire. Je n'ai pas dit qu'il l'était, j'ai même sous entendu le contraire dans des commentaires de fils précédents avant que vous ne le disiez.
Quand à l'historique que vous citez de Rust, je vois pas pourquoi vous partez du principe que je ne le connais pas et que j'aurais besoin d'un cours. Et pour dire quoi au final qui contredise ce que j'ai dit ?
Non franchement, je comprend pas cette discussion, ni sur quoi ne sommes pas vraiment d'accord. J'ai l'impression que si je dis quelque chose, vous allez détourner la conversion sur autre chose que je n'ai pas dite, puis je vous répond, vous ça recommence et ainsi de suite. Relisez mon commentaire initial, et je vois pas ce qu'il y a à redire.
#10.17
J'avais répondu sans faire attention à l'auteur du commentaire (maintenant, chose faite), juste par rapport à son contenu. Donc non, n'y voyez absolument rien de personnel. Je constate en tout cas que je réagis avec une certaine constance à vos propos.
D'accord :
- commentaire #10.7 : Dans un autre langage, encore une fois, ce serait beaucoup plus simple.
- commentaire #10.6 : Après, ce n'est pas une question de compétence pour moi, mais c'est juste une question de choisir un langage un poil moins casse gueule.
- commentaire #10.2 : C'est quand même plus simple si le langage gère nativement ces problèmes en 2024, surtout sur des machines modernes qui n'ont pas peur de stocker un int+un test à chaque accès.
- commentaire #10 : Dans un autre langage plus moderne que le C, le programme aurait planté dans 100% des cas dès la lecture de la case N+1 du tableau de N cases
Dénigrer un langage ("plus moderne", "langage un poil moins casse gueule", etc.) sans tenir compte du contexte de son utilisation, ni même du pourquoi il a été créé, en insistant bien sur les aspects obsolètes véhicule un message qui me semble très clair : le langage de base a été mal choisi, il fallait en prendre un autre. Le fameux y'a qua faut qu'on.
Après, ce n'est effectivement pas la première fois que nous ne nous comprenons pas du tout. Fin de discussion pour moi.
#10.18
Ok, sauf que ce n'est pas la conclusion "le langage de base a été mal choisi" que je tire, mais "le langage a fait font temps" pour me citer. Ce n'est pas exactement la même chose.
#10.19
#10.20
#10.21
Sans être en désaccord total sur tout, je suis pourtant loin d'être d'accord avec un grand nombres de vos remarques, qui sont loin d'être purement factuelles. Je me contenterai juste d'un exemple pour étayer mon propos (n'ayant pas envie de faire des commentaires bien plus long qu'ils ne le sont déjà, je n'ai pas relevé chaque point pour les "réfuter").
Rien de factuel, juste un avis. Le votre. Et là dessus, je suis en total désaccord avec vous sur la question de la compétence du développeur.
#10.22
Historique des modifications :
Posté le 08/08/2024 à 12h48
Mais la question de la compétence vaut pour tous les langages, et le C n'arrange pas les choses. Voilà mon avis. Et puis, ce que vous appelez de la compétence, j'appelle cela de la concentration, et je trouve plus utile de porter son attention sur autre chose que des bugs fantômes et latents. Mon point de vue est pourtant facile à comprendre.
#10.23
Historique des modifications :
Posté le 08/08/2024 à 13h03
Je ne dit pas que vous dites êtes d'accord avec moi, mais je pense au fond que vous l'êtes, et ça c'est mon opinion :)
Vous ne pouvez pas contredire mon point de vue, pourtant attayé, pour m'imposer tranquillement le votre. Depuis le début, c'est ce que je vous faites.
A la limite, si vous aviez dit "je comprend votre point de vue mais personnellement j'estime que le C restera un langage de choix bon gré mal gré", ben simplement, on aura échangé nos points de vue, et c'est OK.
Mais vous êtes dans l'attaque, ça me met sur une position défensive, c'est assez usant, d'autant que j'argumente mon point de vue et ai étayé mon propos, tout en l'équilibrant et en le relativisant face un à un sujet à contextualiser selon les cas.
Et puis je vous trouve assez gonflé de venir dire sous mon commentaire qu'il est de type "yakafokon" quand vous écrivez comme premier commentaire de l'article à propos de Crowdstrike :
"Ne jamais dire jamais. Surtout en informatique, et encore moins quand on a le cul sale et qu'on est à l'origine d'un des plus grands fiascos de l'informatique.
Pour preuve :
- le processus de vérification n'aurait jamais du laisser passer cette erreur (zut, il était bogué lui aussi)
- un fichier de définition ne devrait jamais faire planter un driver (zut, c'est pourtant ce qu'il s'est passé)"
Si ça c'est pas du "yakafokon" pure ! Pourtant, je ne suis pas venu vous expliquer sous votre commentaire que vous devez avoir forcément mon opinion !
Je ne suis pas votre miroir, ni votre agent conversationnel, ni votre chose à placer dans un bloc if/else (ce que vous avez fait dans un autre fil). Merci de ma pas me considérer comme tel. Mon opinion n'empêche pas la votre, et cela doit être réciproque. Entre deux opinions subjectives, vous choisirez la votre, et je choisi la mienne, et alors ? On est dans un espace de commentaire d'un site de vulgarisation sur l'IT, c'est tout.
Posté le 08/08/2024 à 13h05
Je ne dit pas que vous dites êtes d'accord avec moi, mais je pense au fond que vous l'êtes, et ça c'est mon opinion :)
Vous ne pouvez pas contredire mon point de vue, pourtant attayé, pour m'imposer tranquillement le votre. Depuis le début, c'est ce que je vous faites. Vous pouvez éventuellement m'aider à mieux construire mon opinion, mais pas m'imposer la votre. Je rappel que vous écrivez sous mon commentaire.
A la limite, si vous aviez dit "je comprend votre point de vue mais personnellement j'estime que le C restera un langage de choix bon gré mal gré", ben simplement, on aura échangé nos points de vue, et c'est OK.
Mais vous êtes dans l'attaque, ça me met sur une position défensive, c'est assez usant, d'autant que j'argumente mon point de vue et ai étayé mon propos, tout en l'équilibrant et en le relativisant face un à un sujet à contextualiser selon les cas.
Et puis je vous trouve assez gonflé de venir dire sous mon commentaire qu'il est de type "yakafokon" quand vous écrivez comme premier commentaire de l'article à propos de Crowdstrike :
"Ne jamais dire jamais. Surtout en informatique, et encore moins quand on a le cul sale et qu'on est à l'origine d'un des plus grands fiascos de l'informatique.
Pour preuve :
- le processus de vérification n'aurait jamais du laisser passer cette erreur (zut, il était bogué lui aussi)
- un fichier de définition ne devrait jamais faire planter un driver (zut, c'est pourtant ce qu'il s'est passé)"
Si ça c'est pas du "yakafokon" pure ! Pourtant, je ne suis pas venu vous expliquer sous votre commentaire que vous devez avoir forcément mon opinion !
Je ne suis pas votre miroir, ni votre agent conversationnel, ni votre chose à placer dans un bloc if/else (ce que vous avez fait dans un autre fil), ni une chose mentale sur laquelle vous pouvez projeter ce que vous voulez. Merci de ma pas me considérer comme tel. Mon opinion n'empêche pas la votre, et cela doit être réciproque. Entre deux opinions subjectives, vous choisirez la votre, et je choisi la mienne, et alors ? On est dans un espace de commentaire d'un site de vulgarisation sur l'IT, c'est tout.
Posté le 08/08/2024 à 13h07
Je ne dit pas que vous dites êtes d'accord avec moi, mais je pense au fond que vous l'êtes, et ça c'est mon opinion :) C'est juste que vous prenez pas le temps d'envisager mon angle de vue.
Vous ne pouvez pas contredire mon point de vue, pourtant attayé, pour m'imposer tranquillement le votre. Depuis le début, c'est ce que je vous faites. Vous pouvez éventuellement m'aider à mieux construire mon opinion, mais pas m'imposer la votre. Je rappel que vous écrivez sous mon commentaire.
A la limite, si vous aviez dit "je comprend votre point de vue mais personnellement j'estime que le C restera un langage de choix bon gré mal gré", ben simplement, on aura échangé nos points de vue, et c'est OK.
Mais vous êtes dans l'attaque, ça me met sur une position défensive, c'est assez usant, d'autant que j'argumente mon point de vue et ai étayé mon propos, tout en l'équilibrant et en le relativisant face un à un sujet à contextualiser selon les cas.
Et puis je vous trouve assez gonflé de venir dire sous mon commentaire qu'il est de type "yakafokon" quand vous écrivez comme premier commentaire de l'article à propos de Crowdstrike :
"Ne jamais dire jamais. Surtout en informatique, et encore moins quand on a le cul sale et qu'on est à l'origine d'un des plus grands fiascos de l'informatique.
Pour preuve :
- le processus de vérification n'aurait jamais du laisser passer cette erreur (zut, il était bogué lui aussi)
- un fichier de définition ne devrait jamais faire planter un driver (zut, c'est pourtant ce qu'il s'est passé)"
Si ça c'est pas du "yakafokon" pure ! Pourtant, je ne suis pas venu vous expliquer sous votre commentaire que vous devez avoir forcément mon opinion !
Je ne suis pas votre miroir, ni votre agent conversationnel, ni votre chose à placer dans un bloc if/else (ce que vous avez fait dans un autre fil), ni une chose mentale sur laquelle vous pouvez projeter ce que vous voulez. Merci de ma pas me considérer comme tel. Mon opinion n'empêche pas la votre, et cela doit être réciproque. Entre deux opinions subjectives, vous choisirez la votre, et je choisi la mienne, et alors ? On est dans un espace de commentaire d'un site de vulgarisation sur l'IT, c'est tout.
Posté le 08/08/2024 à 13h09
Je ne dit pas que vous dites êtes d'accord avec moi, mais je pense au fond que vous l'êtes, et ça c'est mon opinion :) Après je suis d'accord pour que dire que c'est peut être déplacé de le penser. C'est juste que vous prenez pas le temps d'envisager mon angle de vue, ce qui rend la discussion stérile.
Vous ne pouvez pas contredire mon point de vue, pourtant attayé, pour m'imposer tranquillement le votre. Depuis le début, c'est ce que je vous faites. Vous pouvez éventuellement m'aider à mieux construire mon opinion, mais pas m'imposer la votre. Je rappel que vous écrivez sous mon commentaire.
A la limite, si vous aviez dit "je comprend votre point de vue mais personnellement j'estime que le C restera un langage de choix bon gré mal gré", ben simplement, on aura échangé nos points de vue, et c'est OK.
Mais vous êtes dans l'attaque, ça me met sur une position défensive, c'est assez usant, d'autant que j'argumente mon point de vue et ai étayé mon propos, tout en l'équilibrant et en le relativisant face un à un sujet à contextualiser selon les cas.
Et puis je vous trouve assez gonflé de venir dire sous mon commentaire qu'il est de type "yakafokon" quand vous écrivez comme premier commentaire de l'article à propos de Crowdstrike :
"Ne jamais dire jamais. Surtout en informatique, et encore moins quand on a le cul sale et qu'on est à l'origine d'un des plus grands fiascos de l'informatique.
Pour preuve :
- le processus de vérification n'aurait jamais du laisser passer cette erreur (zut, il était bogué lui aussi)
- un fichier de définition ne devrait jamais faire planter un driver (zut, c'est pourtant ce qu'il s'est passé)"
Si ça c'est pas du "yakafokon" pure ! Pourtant, je ne suis pas venu vous expliquer sous votre commentaire que vous devez avoir forcément mon opinion !
Je ne suis pas votre miroir, ni votre agent conversationnel, ni votre chose à placer dans un bloc if/else (ce que vous avez fait dans un autre fil), ni une chose mentale sur laquelle vous pouvez projeter ce que vous voulez. Merci de ma pas me considérer comme tel. Mon opinion n'empêche pas la votre, et cela doit être réciproque. Entre deux opinions subjectives, vous choisirez la votre, et je choisi la mienne, et alors ? On est dans un espace de commentaire d'un site de vulgarisation sur l'IT, c'est tout.
#10.24
Vous ne pouvez pas contredire mon point de vue, pourtant attayé, pour m'imposer tranquillement le votre. Depuis le début, c'est ce que je vous faites. Vous pouvez éventuellement m'aider à mieux construire mon opinion, mais pas m'imposer la votre. Je rappel que vous écrivez sous mon commentaire.
A la limite, si vous aviez dit "je comprend votre point de vue mais personnellement j'estime que le C restera un langage de choix bon gré mal gré", ben simplement, on aura échangé nos points de vue, et c'est OK.
Mais vous êtes dans l'attaque, ça me met sur une position défensive, c'est assez usant, d'autant que j'argumente mon point de vue et ai étayé mon propos, tout en l'équilibrant et en le relativisant face un à un sujet à contextualiser selon les cas.
Et puis je vous trouve assez gonflé de venir dire sous mon commentaire qu'il est de type "yakafokon" quand vous écrivez comme premier commentaire de l'article à propos de Crowdstrike :
"Ne jamais dire jamais. Surtout en informatique, et encore moins quand on a le cul sale et qu'on est à l'origine d'un des plus grands fiascos de l'informatique.
Pour preuve :
- le processus de vérification n'aurait jamais du laisser passer cette erreur (zut, il était bogué lui aussi)
- un fichier de définition ne devrait jamais faire planter un driver (zut, c'est pourtant ce qu'il s'est passé)"
Si ça c'est pas du "yakafokon" pure ! Pourtant, je ne suis pas venu vous expliquer sous votre commentaire que vous devez avoir forcément mon opinion !
Je ne suis pas votre miroir, ni votre agent conversationnel, ni votre chose à placer dans un bloc if/else (ce que vous avez fait dans un autre fil), ni une chose mentale sur laquelle vous pouvez projeter ce que vous voulez. Merci de ma pas me considérer comme tel. Mon opinion n'empêche pas la votre, et cela doit être réciproque. Entre deux opinions subjectives, vous choisirez la votre, et je choisi la mienne, et alors ? On est dans un espace de commentaire d'un site de vulgarisation sur l'IT, c'est tout.
Historique des modifications :
Posté le 08/08/2024 à 13h24
commentaire déplacé plus haut
Posté le 08/08/2024 à 13h24
Je ne dit pas que vous dites êtes d'accord avec moi, mais je pense au fond que vous l'êtes, et ça c'est mon opinion :) Après je suis d'accord pour que dire que c'est peut être déplacé de le penser. C'est juste que vous prenez pas le temps d'envisager mon angle de vue, ce qui rend la discussion stérile.
Vous ne pouvez pas contredire mon point de vue, pourtant attayé, pour m'imposer tranquillement le votre. Depuis le début, c'est ce que je vous faites. Vous pouvez éventuellement m'aider à mieux construire mon opinion, mais pas m'imposer la votre. Je rappel que vous écrivez sous mon commentaire.
A la limite, si vous aviez dit "je comprend votre point de vue mais personnellement j'estime que le C restera un langage de choix bon gré mal gré", ben simplement, on aura échangé nos points de vue, et c'est OK.
Mais vous êtes dans l'attaque, ça me met sur une position défensive, c'est assez usant, d'autant que j'argumente mon point de vue et ai étayé mon propos, tout en l'équilibrant et en le relativisant face un à un sujet à contextualiser selon les cas.
Et puis je vous trouve assez gonflé de venir dire sous mon commentaire qu'il est de type "yakafokon" quand vous écrivez comme premier commentaire de l'article à propos de Crowdstrike :
"Ne jamais dire jamais. Surtout en informatique, et encore moins quand on a le cul sale et qu'on est à l'origine d'un des plus grands fiascos de l'informatique.
Pour preuve :
- le processus de vérification n'aurait jamais du laisser passer cette erreur (zut, il était bogué lui aussi)
- un fichier de définition ne devrait jamais faire planter un driver (zut, c'est pourtant ce qu'il s'est passé)"
Si ça c'est pas du "yakafokon" pure ! Pourtant, je ne suis pas venu vous expliquer sous votre commentaire que vous devez avoir forcément mon opinion !
Je ne suis pas votre miroir, ni votre agent conversationnel, ni votre chose à placer dans un bloc if/else (ce que vous avez fait dans un autre fil), ni une chose mentale sur laquelle vous pouvez projeter ce que vous voulez. Merci de ma pas me considérer comme tel. Mon opinion n'empêche pas la votre, et cela doit être réciproque. Entre deux opinions subjectives, vous choisirez la votre, et je choisi la mienne, et alors ? On est dans un espace de commentaire d'un site de vulgarisation sur l'IT, c'est tout.
#10.25
Vous vous sentez attaqué ? J'en suis bien désolé, ça n'a jamais été le but. Ce que je perçois, de vos différents propos, ce n'est pas une opinion, mais une présentation de faits totalement péremptoires. Et vous appelez ça argumenter ? Je ne fais que réagir à vos commentaires (et si j'avais regardé qui les avait écrit avant, j'aurais peut être évité d'écrire pour éviter un dialogue de sourd).
Vous analysez les silences, les faits sur lesquels je ne reviens pour venir me dire que je suis d'accord avec vous, etc. avec cette manie de faire de multiples commentaires pour ne pas dire grand chose au final et des arguments (quand il y en a) vides de sens ou totalement sorti de leur contexte. J'ai plus l'impression d'avoir un Dunning-Kruger en face de mois qu'autre chose.
Si vous dites une chose qui me parait absurde, et bien je le dirai. Pas parce que j'ai envie de vous enquiquiner. Car, comme vous dites (attention, oui, là je suis d'accord avec vous) : On est dans un espace de commentaire d'un site de vulgarisation sur l'IT. Je prends plaisir à lire les commentaires des uns et des autres, notamment lorsqu'il apporte des éléments riches, éclairés et sourcés qui apportent une véritable plus value. Et je fais de même lorsque cela me semble pertinent. Et lorsque j'écris un commentaire, je n'ai jamais comme objectif de me "farcir quelqu'un". Mais si quelqu'un écrit une énorme bêtise, je ne vais pas m'empêcher de le lui dire.
J'accepte volontiers les désaccords. Je n'ai pas la science infuse. Il m'arrive aussi de me tromper. Ca m'est déjà arrivé, et je suis certain que cela m'arrivera encore. Mais balancer des faits comme étant des soi-disant vérités comme vous le faite, en prenant d'énormes raccourcis, etc. désolé, mais non, ce n'est pas "donner une opinion".
Je viens de voir que je viens encore de perdre 20min à vous répondre. Personnellement, j'ai autre chose à faire que cette conversion absolument pas constructive. Bonne continuation.
#10.26