Personnellement, je comprends que l'engouement de la part des dev soit pas fou pour changer progressivement de langage, surtout un langage qui ne s'aborde pas de la même façon. Un noyau, c'est plusieurs millions de lignes de code, c'est critique, le chantier parait insurmontable quand on le dit comme ça. Maintenant, le rejet de ceux qui veulent tenter quelque chose de nouveau avec le langage Rust ne m'étonne pas vraiment. Pour en avoir fait l'expérience ici, critiquer le C, c'est s'exposer à des attaques ad hominem, et à des arguments d'autorité. Mais l'argument de dire, si ton programme n'est pas stable en C, c'est que tu es mauvais en C date depuis plusieurs dizaines d'années j'ai l'impression.
Ça a l'air plus large si on en croit cette citation de Jeremy Soller, créateur de Redox OS (OS codé en Rust) : « Les développeurs Linux sont des mégalomanes pédants et condescendants »
Mais sur cette citation, je dirais qu'il vaut mieux éviter les généralités, d'autant qu'il y a un conflit d'intérêt car en disant ça, ça lui permet de mettre en avant son OS.
Je retiens par contre que faire co-évoluer deux technologies dans le même projet Linux, c'est peut être plus un inconvénient, même ça parait être un avantage pour la "transition". La transition peut en effet ne jamais se terminer.
Le côté redévelopper tout le noyau, ça parait tout aussi insurmontable, mais en fait je pense que ça l'est moins, car il n'y aurait pas forcément besoin de porter tout le code concernant de vieilles architectures, juste le code concernant les architectures récentes. Je trouve que c'est un projet intéressant de tout repenser à zéro. Le fait de tout repenser sur Rust plutôt que d'adapter un noyau initialement pensé pour le C vers le Rust peut éventuellement être moins complexe. Faudrait voir ce que donne des projets comme Redox ou autre.
Cette mise à jour a aussi permis de rendre les ISO d'installation Debian à nouveau bootable sur les machines en dual boot avec Windows, depuis que Microsoft avait fait les mêmes mis à jour avec les mêmes restrictions sur l'UEFI mi-août. Debian était devenu non bootable sur les machines en dual boot avec Windows. Peut-être que Debian a tardé a appliqué cette mis à jour (6 mois), car les restrictions peuvent être effectivement problématiques.
Je rappel que le test de Turing était une façon à Turing de ne pas définir l'intelligence, ni la conscience. Comme il ne savait pas le faire, il a fait un test qui n'exige pas de connaître la définition.
Le
28/08/2024 à
10h
15
Même s'il faut bien que le titre évoque quelque chose qui parle, je ne suis pas sur que de parler "d'IA" est une bonne idée. Il faudrait plutôt parler d'algorithmes d'apprentissage supervisés dans ce cas ou non supervisés pour les autoencodeurs. Parler d'IA évoque l'intelligence, et c'est plutôt trompeur. C'est donc plutôt un terme commercial à mon sens.
De quelle vulnérabilité il s'agit ? S'il s'agit de celle-ci, elle semble ne dater que de février. D'autre part, Ubuntu 24.04 a bien la dernière version de shim corrigée sauf erreur de ma part.
Edit: Ubuntu a bien la dernière version corrigée, et pourtant il ne démarre plus après ce qu'à fait Microsoft. Quand à Debian, la version corrigée n'est toujours que dans le canal sid (à tester), et non encore officielle.
Et s'il s'agit de celle ci, Debian semble l'avoir déjà corrigée (donc j'imagine Ubuntu aussi).
Le
23/08/2024 à
09h
32
- Solution Linux - Vulnérabilité d'il y a 2 ans - Certaines distros sont touchées, pas toutes - Procédure de correctif à faire sous Linux = "Ouin ouin méchant M$ :'("
De quelle vulnérabilité il s'agit ? S'il s'agit de celle-ci, elle semble ne dater que de février. D'autre part, Ubuntu 24.04 a bien la dernière version de shim corrigée sauf erreur de ma part.
Edit: Ubuntu a bien la dernière version corrigée, et pourtant il ne démarre plus après ce qu'à fait Microsoft. Quand à Debian, la version corrigée n'est toujours que dans le canal sid (à tester), et non encore officielle.
Pour le coup, le secure boot est parfois désactivé sur des machines ayant un OS un peu hors normes (certains Linux qui vont servir d'hyperviseur), donc ça peut quand-même faire des dégâts...
En complément de ma réponse précédente, il m'est aussi arrivé de signer moi même mes noyaux pour garder le SecureBoot. Il faut par contre installer sa clé publique dans le BIOS/UEFI. C'est plus pénible, mais c'est faisable.
Le
14/08/2024 à
16h
00
Pour le coup, le secure boot est parfois désactivé sur des machines ayant un OS un peu hors normes (certains Linux qui vont servir d'hyperviseur), donc ça peut quand-même faire des dégâts...
Oui je suis d'accord. Après, sans vouloir entrer dans le troll, est-ce absolument nécessaire de sortir d'une distribution un peu commune si on veut un hyperviseur (je suis pas vraiment connaisseur du domaine) ?
Le
13/08/2024 à
15h
37
Mais s'il faut avoir un accès avec les privilèges de type "ring 0", il faut convaincre le noyau. En supposant que ce n'est pas possible et que ce noyau n'a pas de failles connues, il ne me vient à l'esprit pour aboutir à l'attaque que une clé usb insérée au démarrage de la machine, avec un programme de démarrage ayant par défaut le privilège "ring 0" (comme tous les programme de démarrage si j'ai bien compris). Sauf que si le "SecureBoot" est activée, et à supposer que la signature du programme de démarrage ne correspond à rien d'officiel, et à supposer que les "officiels" ne réalisent pas l'attaque, est-ce que cela est réellement exploitable en ayant accès à la machine comme c'est indiqué dans l'article (vrai question) ?
Avant de ratifier, il faut signer... Il faudrait d'abord que nos représentants marquent l'adhésion à cette convention.
Il faut aussi noter que les pays occidentaux ont déjà la Convention de Budapest contre la cybercriminalité. Un texte beaucoup plus équilibré mais qui ne correspondait pas aux ambitions des autocrates et dictateurs à l'origine de l'autre texte.
Enfin, même signé et ratifié, il est probable que ce texte reste lettre morte pour les situations où nos pays décident que ce n'est pas opportun. On a déjà en ce moment un cas très visible de convention signée, ratifiée et pourtant en ce moment même ignorée voir combattue par les pays occidentaux: la Convention pour la prévention et la répression du crime de génocide.
Sans contredire ce que vous avez dit, le sens de ma remarque avait pour but d'interroger au moins par une expérience de pensée que chacune et chacun envisegera comme il ou elle veut, à savoir : "que dit la représentation nationale sur ce sujet ?". Et si la question se pose à mon avis, c'est que en effet certains pourraient considérer pratique de passer par un autre pays pour user de méthodes autoritaires tout en coucircuitant les principes élementaires de la vie privée et de l'esprit de la DDDH.
Le
10/08/2024 à
15h
33
L'ONU n'est pas une démocratie, c'est une organisation qui a pour but d'organiser le dialogue et la coopération entre les nations. Le fait que des pays se regroupent pour travailler sur un texte et votent ce texte au niveau du groupe de travail pour ensuite le présentent à l'assemblée ne semble pas en sois un problème démocratique.
Même après une adoption en session plénière de cette convention, les pays membres ne sont pas obligés de la signer et peuvent bloquer au moment de la ratification.
Ce qui est plutôt interpellant, c'est que l'influence des pays occidentaux soit occupée à fondre comme neige au soleil et que ce genre de texte ne soit pas corrigé pour être compatible avec leurs prétendues valeurs démocratiques.
Nous sommes peut-être occupés à voir la disparition de l'influence occidentale à l'ONU, avec des pays comme la Chine, l'Inde et la Russie gagnant de plus en plus en influence.
Très bonne remarque. Donc maintenant, il reste à voir si le parlement la ratifie...
Donc si je comprend bien, comme il n'est pas possible de prévenir de tous les bugs, évitons d'essayer de prévenir de quelque bug que ce soit...
On parle bien du bug qui concerne cette news-ci. Le process parcourt une séquence de fichiers de définitions pour définir divers types d'attaques ou signatures de virus. Si un fichier est invalide, il est tout à fait possible de soit l'ignorer, soit d'afficher un warning à l'attention de l'utilisateur et de faire un reporting pour détecter activement de cette anomalie.
Le processus tournait bien avant l'ajout du fichier de définition invalide, le fait de l'ignorer est envisageable.
Je ne dis pas que c'est LA solution à privilégier, je réagis simplement à votre remarque qui dit que finalement, à quoi bon tenter de catcher la moindre exception, étant donné qu'il y en aura toujours bien une qui sera lancée un jour où l'autre et qu'on aura pas prévu...
Dans ce cas-ci, on aurait évité des BSOD qui ont causé des pertes économiques certaines, sans parler des risques pour les personnes dans le cas où ça concerne des postes utilisés en milieu sensible.
Si l'exception pouvait être catché, très bien, il aurait fallu le faire. Je n'ai pas de problème avec l'idée et ne dit pas le contraire. Sauf que là, c'est une exception non prévue, puisque de fait, elle n'était pas attendue ni anticipée, sans doute à tord. Je dis juste que vous ne pouvez pas catcher toutes les exceptions sans réfléchir à chaque fois pourquoi vous le faites.
Je vais partir du cas général, pour arriver au contexte du bug cité plus haut.
Admettons que vous faites "a=1/2". Vous ne pouvez pas faire un catch d'une exception générique de cette opération, en disant j'attrape tout. Si vous avez une division par zéro, c'est incohérent car elle ne devrait pas arriver, donc autant tout faire tout planter (la mémoire peut être instable ou que sais-je). Si vous continuez l'exécution, vous arrivez de toute façon dans un état incohérent.
Autre exemple, si vous n'avez plus assez d'espace mémoire et avez une exception de ce type, vous pouvez essayer de catcher l'exception, mais si vous le faites, vous devez savoir comment vous en sortir sachant que vous n'avez pas assez de mémoire. Et peut être qu'il n'y a pas de bonne façon de s'en sortir ici. Donc en faisant un catch de cela sans y réfléchir, vous risquez de générer une boucle infinie d'exceptions indiquant qu'il n'y a pas assez de mémoire et comme vous catchez l'exception sans prendre des mesures adéquates, ça ne s'arrête jamais, ce qui sans doute n'a pas fait planter le noyau, mais je ne sais pas trop quel serait son état si un de ses drivers tourne à l'infini.
Mais c'est valable en général pour un algorithme. Si votre algorithme arrive dans état complètement illogique (enfin à priori), je dis qu'il faut tout faire planter, ne serait-ce que pour s'en rendre compte pendant les tests. C'est le principe des assertions.
Donc ici, pour revenir au contexte du "sensor"/driver qui ne s'en sortait pas à cause d'un accès mémoire invalide, vous pouvez faire un catch du tout et n'importe quoi, mais si vous faites ça, vous devez vous assurer que ce n'est pas une fausse bonne idée. Alors bien sûr, dans le contexte du noyau, sans doute aurait-il fallu simplement ignorer le chargement du drivers, émettre un rapport comme vous le dite, et passer à autre chose. Mais du coup, vous faites un catch en conscience de ce que vous faites, et vous acceptez de faire sauter un "sensor"/drivers lors du chargement de tous les drivers. Je n'ai pas du tout de problème avec l'idée. Mais au moment où prenez cette décision, vous acceptez que des drivers peuvent être manquants, et devez en tenir dans toute votre architecture, sinon, cela pourrait planter ailleurs, et ainsi de suite. Donc oui, avoir une tolérance à la panne, et faire simplement remonter un rapport aurait sans aucun doute été la bonne solution ici, mais ça ne s'improvise pas, il faut peut être en tenir compte ailleurs dans le reste de l'architecture.
Si vous faites des catchs partout sans prendre la mesure de ce vous êtes en train de faire, cela risque in fine de quand même planter mais beaucoup plus loin dans le programme, et là bon courage pour remonter le bug, surtout si vous avez pleins de rapports qui été pondus pendant 2 jours avant que ça ne plante quand même (je ne dis pas que c'est ce qui se serait passé ici, je n'en sais rien). D'autre part, comme c'est dans l'espace noyau, cela pourrait avoir des conséquences délétères non prévues si vous ne l'avez pas bien encadré. Vous évoquez les problèmes économiques, mais là, on parle d'une machine immobilisée par un BSOD. Étant donné qu'on est dans l'espace noyau, imaginez qu'en catchant tout et n'importe quoi, le noyau se mette à faire tout et n'importe quoi en dézinguant le système de fichier. Là, c'est carrément la cohérence des données du système de fichier que vous pouvez flinguer. Je ne sais pas si on peu en arriver là, et si les gardes fou du noyau sont suffisants, mais je veux dire que dans un contexte économique, il y a pire qu'un BSOD.
Mais encore une fois, dans le contexte de ce bug, il était sans doute possible d'accepter une tolérance à la panne, mais cette tolérance doit tout de même être anticipée et encadrée, ce qui n'a pas été le cas ici et c'est bien dommage. Mais ce n'est pas une décision qu'il faut prendre de manière légère et aveugle comme une règle générale (en tout cas pas pour moi).
Donc je ne dis pas "Donc si je comprend bien, comme il n'est pas possible de prévenir de tous les bugs, évitons d'essayer de prévenir de quelque bug que ce soit...", je dis "essayez de prévenir tous les bugs, y compris ceux que vous comprenez pas à l'avance, acceptez la tolérance à la panne, mais si un bug ou une panne non anticipée arrive quand même alors que vous ne l'avez pas prévu ni encadré, je ne crois pas qu'il faille faire un catch aveugle sans en mesurer les conséquences, d'autant qu'à force de faire ça, vous prenez le risque de rendre un bug silencieux lors des tests, et rendre vos remontées de bug plus pénibles et fastidieuses.
Le
30/07/2024 à
04h
18
Le sens de mon premier commentaire était de dire que les langages C et C++ ne génèrent pas les mêmes exceptions en fonction de la configuration mémoire dans laquelle on se trouve à cause du laxisme des deux langages dans la gestion de la mémoire
Il sera bon de ne pas tenter de réécrire l'histoire. C et C++ ne sont pas laxistes. Ils permettent des choses que d'autres ne permettent pas. Un grand pouvoir implique de grandes responsabilités.
Certains langages proposent effectivement des mécanismes pour éviter les problèmes de gestion de mémoire, et utilisent plusieurs mécanismes, parfois complémentaire, à cette fin.
Maintenant, nous parlons ici d'un cas particulier, qui est de la programmation système, nécessitant un très bas niveau d'abstraction, ce qu'offre le C et dans une moindre mesure, le C++. Pour de la programmation système, on oublie tous les langages qui dépendent d'un runtime et/ou d'une machine virtuelle.
Ne pas oublier non plus que le C a été initialement inventé pour réécrire de manière "portable" Unix. La gestion de la mémoire se devait donc d'offrir un contrôle important au développeur. Ce n'est pas du laxisme, mais une volonté forte.
Avant son invention, le seul moyen utilisable pour écrire un OS était l'assembleur. Ce qui n'était absolument pas portable, puisqu'on devait alors réécrire entièrement les OS pour chaque architecture et chaque processeur.
A ma connaissance, il n'y a que très peu de langages qui permettent aujourd'hui de faire de la programmation système : - le C - le C++ (privé de certaines fonctionnalités comme la gestion des exceptions) - l'Ada - le Rust - l'assembleur
Il en existe surement d'autres, mais dans les plus connus/répandus, je ne pense pas en oublier.
Pour terminer, le coup de la remonté des erreurs par le programme jusqu'à le faire crasher, c'est effectivement plutôt une bonne pratique (pour les exceptions, ça va dépendre du type d'exception et de la robustesse que l'on souhaite donner à son applicatif). Mais ça, c'est possible pour les programmes justement, pas lorsqu'on fait de la programmation système.
Si on faisait ça en programmation système, les BSOD ou les kernel panic seraient légions. Un OS ne doit pas planter. Et on le voit bien aujourd'hui, Windows, Linux, MacOS, FreeBSD, etc. sont très stable et fiable. Un programme qui plante ne fera pas planter le système.
Par contre, lorsque le problème est dans un driver / module noyau... les choses se corsent.
Bon, je vous ai lu à tête reposé. La dernière fois, j'avais une journée très chargées et j'ai lu beaucoup de choses en diagonale. Désolé, mais si vous commencez votre message par "il ne faut pas réécrire l'histoire", ça fait procès d'intention, et de mon point de vue, vous m'avez déjà jugé, je n'ai aucune chance que je me preniez pour votre égal. Donc, j'ai déjà plus trop envie de vous lire.
Puis vous avez commencé un historique des langages, et j'ai arrêté à ce moment de vous lire. Partir du principe que je ne comprend rien à ce que je raconte m'indiquait que vous jugiez sur les apparences. Alors certes, j'aurais du attendre un moment où j'avais plus de disponibilité pour vous lire, mais étant donné que vous ne donniez aucun crédit à ma façon d'aborder les choses, je ne voyais pas pourquoi je devais en faire plus que vous.
Pourtant après avoir relu tout vos commentaires, j'ai compris tout ce que vous aviez dit, même si j'estime que ça n'avait pas trop rapport avec mon commentaire initial, et comme je n'avais pas le temps de digresser, je n'ai pas vraiment compris pourquoi toutes ces digressions, et ces tons péremptoires que vous aviez avec moi. Le mal entendu naissait et grandissait de plus en plus.
Donc oui, un pointeur P de valeur nulle, qui pointe vers une structure à la position relative 4, aura l'adresse absolue 4, donc non égale à zéro. Je vous rassure, ce n'est pas une découverte pour moi. Le problème, c'est que comme c'est évident, il est impossible pour ma part de comprendre le malentendu avec des commentaires qui répondent à côté de mon commentaire initial avec des présomptions fortes sur ce que je sais ou pense dès le départ, et avec moi vous lit en diagonale n'ayant pas eu la patience d'attendre 1 jour pour répondre.
Très bien. Au moment de mon commentaire initial, je ne suis pas dans l'esprit de faire la différence entre le contexte du noyau et celui du programme, ou entre les adresses valides ou non. Je ne pense pas non plus "translation d'adresse". Mon commentaire initial n'en avait pas besoin, puisque je commentais le problème inhérent que pose le C, car la question n'est pas de savoir si on doit tester un pointeur NULL, mais pourquoi on arrive dans un état qui ne s'est pas produit pendant les tests. Le pointeur NULL n'a peut être rien à voir, et s'est peut être la résultante d'un bug plus en amont.
Dire qu'un noyau doit être stable, mais comment dire, vous pensez vraiment que quelqu'un pense que le noyau peut être bâclé dès lors que l'on comprend ne serait-ce qu'à minima ses fonctions ? Quiconque a déjà utilisé Windows Millenium sais ce que cela implique un noyau instable, qu'il soit informaticien, ou utilisateur de Word. J'ai l'impression que tous les utilisateurs de Windows Millenium étaient devenus superstitieux, tellement il était imprévisible. Pas besoin d'utiliser un argument d'autorité pour le savoir.
Cela étant dit, lorsque je dis qu'un programme qui arrive dans un état incohérent doit tout arrêter, vous dites en retour que l'on ne peut se permettre d'en faire autant avec le noyau en tant que dev, avec en creux l'idée qu'il faille continuer coûte que coûte, ce qui n'est pas ce qu'a choisi de faire le noyau de Windows. C'est votre appréciation, mais si ne vous faites pas planter un noyau sans savoir si c'est bien raisonnable, comment être sûr que ce ne sera pas pire ? Ce qui s'applique pour un programme, s'applique aussi pour le noyau.
Si l'on se place du point de vu d'un programme, l'objectif principal est que ce dernier ne plante pas et remplisse ses rôles. Si à un moment un problème se pose et que cette éventualité avait été anticipée, on peut alors prévoir plusieurs stratégies pour fonctionner en mode dégradé. On peut déléguer la tâche à un système de secondaire, on peut considérer une autre option, on peut simplement désactiver une fonctionnalité, on peut considérer que le problème n'est pas si important et qu'il suffit juste de faire remonter l'information dans un rapport, on peut appliquer un autre algorithme contournant le problème en le résolvant d'une autre façon, on peut développer un système avec une tolérance à la panne, etc.
Mais si le problème n'avait pas été anticipé, et s'il arrive quand même alors qu'il ne devrait pas arriver, c'est à dire au moment d'une assertion qui vérifie un pointeur non NULL par exemple, alors il faut faire planter le programme.
Imaginez un outil de contrôle aérien qui arrive dans un état mémoire théoriquement impossible alors qu'il a été testé mille fois, de manière empirique et par un système de preuve. Vaut-il mieux tout faire planter, ou continuer ? - Si vous continuez, vos tests unitaires ne détecterons rien. Peut être aurez vous un rapport de généré, mais si vous oubliez le lire à temps, votre programme aura quand même poursuivi son excécution. - Vous pouvez aussi ne pas avoir la même stratégie pendant les tests ou en production, mais dans ce cas, vos tests ne sont pas tout à fait valides car il ne testent pas la même chose. - Si vous faites tout planter, et que cela arrive pendant les tests, vous corrigez vos tests. Mais si vous poursuivez l'exécution du programme en production sans savoir si cela est bien raisonnable, et alors que vous êtes sûr que cela ne devrait pas arriver (assertion), vous prenez le risque pour le dire vite d'afficher à l'écran des avions à une mauvaise position. - Si vous faites tout planter et que cela arrive en production, vous avertissez les contrôleurs aérien que le système n'est plus fiable, et qu'il faut qu'ils se débrouillent autrement. Faut-il tout faire pour en arriver là ? Non, car un oui serait trop évident -> que voulez-vous que je vous dise d'autre ? Tout ceci est banal, et je suis sûr que je ne vous apprend rien.
Maintenant, la question soulevée au départ est, pourquoi un programme qui ne plante pas pendant les tests peut finir par planter en production avec le C ? Etant donné que le C permet de faire n'importe quoi avec la mémoire (oui oui), il suffit que la configuration mémoire soit différente au moment de l'exécution pour que le comportement du programme soit différent.
Car justement, le langage C ne vérifie pas si un accès mémoire est autorisé ou non. Tant que la zone pointée ne déborde pas de l'espace d'adressage du processus, le noyau ne dit rien (enfin le processeur, ça serait trop lent si le noyau testait chaque accès mémoire sans accélération processeur). Si vous faites un dépassement mémoire, ou si vous lisez un pointeur non égal à 0, parfois le programme plante, parfois c'est le noyau qui le fait planter, parfois il ne plante pas.
Rien que de changer les options de compilation fera donner un comportement différent au programme avec le même bug, voir cela fera virtuellement disparaître le bug, le programme n'ayant pas planté.
On peut même avoir un pointeur non initialisé qui vaut une valeur aléatoire au moment des tests, car une variable non initialisée prend par défaut la valeur de son état mémoire au moment de son allocation, probablement non NULL. Donc si cette valeur par défaut correspond à une valeur acceptable de l'espace d'adressage du programme, le processus ne plante pas. Si vous relancez plusieurs fois le test sur la même machine, en relançant plusieurs fois le même programme, la configuration mémoire de l'ordinateur de test n'ayant pas changé, le bug n’apparaît jamais, le pointeur n'est jamais à NULL.
Pendant la prod, disons pour des raisons d'options de compilation différentes, le pointeur non initialisé aura la valeur par défaut à zéro, et le programme plante à se moment, là où il n'avait pas planté pendant les tests. Voilà un scénario possible. Mais il peut y en avoir d'autres.
Est-ce que c'est cela qui s'est passé ici ? Je ne sais pas, je ne faisais qu'émettre une hypothèse.
Ce qui nous amène au fond du sujet, puisque vous avez quand même répondu à mon commentaire initial à un moment, c'est à dire dans le commentaire auquel je répond présentement. Vous dites que C est un langage à remettre dans son contexte. Très bien, mais là encore, vous enfoncez une porte ouverte. Le problème n'est pas celui là, ni l'histoire du C, mais plutôt que faisons nous en 2024 avec un tel langage ?
Vous dites en creux qu'un OS ne peut se passer d'un tel langage qui permet tant de liberté. Peut être avez-vous raison, personnellement, n'étant pas dev sys, je me contente d'observer que personne n'a envie de redévelopper plusieurs millions de ligne de code d'un noyau dans un autre langage, d'autant que beaucoup de dev sys développent en C. Est-ce que les deux raisons qui font que le C soit toujours aussi populaire ne sont pas les suivantes : 1. il n'y a pas assez de monde dans les dev sys qui maîtrisent un autre langage que le C 2. il est très démotivant de redévelopper tout un noyau dans un autre langage dont on ne sais même pas s'il est plus mature que le C .
Mais comme ici, il s'agissait que d'un (parait-il faux) pilote, peut être qu'en fait si, on peut progressivement développer dans un autre langage, qui plante dès qu'un accès mémoire n'est pas licite à l'intérieur même du processus, et non plusieurs centaines de lignes plus loin, et non "jamais jusqu'au jour où on le met en prod". Peut être qu'à la périphérie du noyau et dans les couches du dessus, il n'est plus nécessaire de développer dans un langage devenu pour moi bien trop vieux. C'est bien là mon droit d'émettre une opinion. Personne ne vous oblige d'être d'accord. Mais ne croyez pas qu'une seule opinion doit survivre. Ce n'est pas Highlander !
Je pense franchement qu'on aurait pu éviter ces digressions et cette perte de temps, car je soupçonne que dès le départ, que vous comprenez ce type de position.
Vous êtes libre de penser ce que vous voulez, pas de me dire ce que je dois penser.
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.
Merci d'avoir enfin entendu le message. Cette conversation est stérile, nous sommes d'accord au moins sur ce point. Bonne continuation à vous aussi !
Le
08/08/2024 à
13h
24
J'avais dit que je ne répondrais plus, mais vous me prêtez un avis qui n'est pas le mien.
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").
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.
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.
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.
Le
08/08/2024 à
13h
03
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 à compétence égale, 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.
Commentaire déplacé plus bas
Le
08/08/2024 à
12h
48
J'avais dit que je ne répondrais plus, mais vous me prêtez un avis qui n'est pas le mien.
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").
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.
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.
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 à compétence égale, 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.
Le
08/08/2024 à
11h
47
Et puis, j'ai aussi précisé qu'il n'était probablement pas possible de le remplacer dans beaucoup de cas, ne serait-ce que parce qu’il faut tout réécrire. Enfin, je n'ai jamais proposé cela pour le code noyau. Donc au final, il reste uniquement le Rust pour les nouveaux projets (ce que vous avez dit), et à condition d'avoir suffisamment de développeuses et développeurs formés pour le faire (ce que j'ai aussi précisé dans d'autres fils). Au final, ma position est relativement équilibrée, et n'est pas la caricature que vous décrivez.
Enfin, tous les commentaires de moi que vous avez cités sont factuels. Au fond, vous ne les réfutez pas. Nous sommes donc d'accord depuis le début, et si vous tirez des conlusions différentes face à ces faits, vous avez le droit, c'est ce je vous dis depuis le début. Si vous voulez coder en C, pas de problèmes. Là encore, ce n'est pas "y'a ka fo kon", c'est même tout le contraire. Mes réactions aussi sont constantes.
Le
08/08/2024 à
11h
09
"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."
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.
Et puis, j'ai aussi précisé qu'il n'était probablement pas possible de le remplacer dans beaucoup de cas, ne serait-ce que parce qu’il faut tout réécrire. Enfin, je n'ai jamais proposé cela pour le code noyau. Donc au final, il reste uniquement le Rust pour les nouveaux projets (ce que vous avez dit), et à condition d'avoir suffisamment de développeuses et développeurs formés pour le faire (ce que j'ai aussi précisé dans d'autres fils). Au final, ma position est relativement équilibrée, et n'est pas la caricature que vous décrivez.
Le
08/08/2024 à
11h
03
Est-ce un traitement particulier que vous me réservez ?
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.
Je n'ai pas dit "y'a qua fo kon". Pouvez-vous me citer ? N'est-ce pas vous qui exagérez ?
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.
"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."
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.
Le
08/08/2024 à
10h
16
Mais Rust est un langage moderne, et Rust a un facteur de 1.05 si ma mémoire est bonne. Même Microsoft essaye de basculer vers Rust. Mon petit doigt me dit que c'est pour les même raisons que celles que j'ai évoquées "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."
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.
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
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.
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.
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).
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. 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.
Le
08/08/2024 à
00h
10
Mais Rust est un langage moderne, et Rust a un facteur de 1.05 si ma mémoire est bonne. Même Microsoft essaye de basculer vers Rust. Mon petit doigt me dit que c'est pour les même raisons que celles que j'ai évoquées "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.
Après en disant cela, je sais que probablement aucun langage ne remplacera C dans le noyau, mais en périphérie, comme au niveau des pilotes, pourquoi pas !
Le
08/08/2024 à
00h
03
x77, c'est le pire cas observé pour une implémentation particulière (celle du papier). Que la batterie de tests soit longue, on s'en fiche royalement. Ce n'est d'ailleurs pas un problème en soit, les systèmes d'intégration continue sont justement là pour marquer les builds qui passent et sont donc "déployables".
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.
Mais Rust est un langage moderne, et Rust a un facteur de 1.05 si ma mémoire est bonne. Même Microsoft essaye de basculer vers Rust. Mon petit doigt me dit que c'est pour les même raisons que celles que j'ai évoquées "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.
Le
07/08/2024 à
23h
41
Inutile d'aller aussi loin. Ici, c'est presque une implémentation d'un boundary checker à la Rust. Travaille de recherche intéressant, mais je n'ai pas la compétence pour juger (et visiblement le papier n'a pas eu de peer-review).
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; }
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 et donc qu'il fasse ce test à votre place. 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.
Le
07/08/2024 à
23h
35
Le boundary checker (en C++, donc langage moderne ou en Rust donc soit encore plus moderne et stricte) fonctionne en levant des exceptions (je me souviens plus de la manière exact de Rust ceci dit). Mais bref, c'est au dev de gérer ce cas là y compris en prod. Peut-être d'informé d'une erreur sans mettre l'OS en carafe. Ou bien de recharger l'ancien fichier et de fonctionner en mode dégradé et d'informer l'admin. Les solutions existent, et dans des domaines critiques où les langages modernes ne peuvent pas encore percée c'est ce qui est fait, en autres.
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).
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. Et encore une fois, dans un autre langage, à N+1 ou à N+10, ça plante forcément, sans aucun effort dev ou monitoring à faire. Ce n'est pas négligeable ! 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 !
Le
07/08/2024 à
23h
12
"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, "
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.
D'après cet article, le temps d'exécution des tests peut être augmenté de 1,8 à 77 fois. Après je l'ai lu en diagonal, et n'irai pas plus loin. Mais dans le pire cas, si votre test de base dure 3 heures, et que vous dites, pour être sûr, à chaque nouvelle version du logiciel, on va augmenter le temps du test par "fois 77", vous pouvez mais bon, c'est comme tout, ça se discute et c'est une question de choix. Dans un autre langage, encore une fois, ce serait beaucoup plus simple.
Le
07/08/2024 à
22h
57
Fastidieux ? On parle quand même d'une grosse boîte (au sens bénéfice) et qui travaille sur un élement sensible. 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.
Mais même si vous utilisez un boundary checker pendant les tests, vous ne pouvez pas l'utiliser en production. Et si le problème arrive quand même en production, il pourrait y avoir pire que le "système plante", le système pourrait continuer son exécution dans un état incohérent (d'autant que c'était dans l'espace noyau si j'ai bien compris), avec des conséquences incalculables.
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 !
Le
07/08/2024 à
22h
38
Oui enfin, c'est plus complexe à mettre en place, d'autant plus si le projet est fastidieux. 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.
Et puis vu la lourdeur de ces outils en C qui dégradent significativement les performances, et sachant qu'il peut y avoir des tests qui prennent des heures, c'est vraiment pas l'idéal.
Le
07/08/2024 à
22h
35
"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, "
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.
Oui enfin, c'est plus complexe à mettre en place, d'autant plus si le projet est fastidieux. 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.
Le
07/08/2024 à
19h
59
J'ai à peu près compris le rapport et ce qui s'est passé. Pour résumer ce que j'ai compris, ils ont testé les parties/modules incriminées indépendamment sans avoir semble t'il un scénario global qui test l'ensemble. le module X a été testé avec des données entrées manuellement, mais qui auraient du être fournies par le module X-1 en amont. Du coup, les données apportées au module X ne correspondaient pas celles qu'il allait trouver en production.
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.
Le
07/08/2024 à
17h
48
Avec autant de clients et de machines, ils auraient pu au moins avoir un serveur en pré-prod pour avoir les conditions du réel au plus proche !
C'est vrai que je ne me suis pas posé la question pour les téléphones et me suis plus concentré sur les voitures électriques vu que l'ordre de grandeur sur l'impact environnemental des batteries n'est pas du tout du tout le même (question de priorité).
Donc je ne sais pas répondre à votre question, si ce n'est que je ne milite pas pour une écologie de spécialistes et/ou une écologie qui coûte trop chère si cela ne passe pas l'échelle. Sachant que dans le prix de la non écologie, il faut comptabiliser les dégâts, économiques et autres bien réels que cela produit.
Même si j'avais la réponse à votre question (que je n'ai pas), je n'estimerai pas avoir fait un pas important vers plus d'écologie si la majorité de la population ne peut y accéder (enfin qu'en sais-je ?), soit pour une question de manque de temps pour acquérir les compétences, soit pour une question de manque d'argent (ce qui inclut le point précédent). Mais si vous obtenez la réponse, et si les constructeurs finissent pas suivre des utilisateurs spécialistes et en faire profiter tout le monde, vous aurez gagné quelque chose, mais dans ce cas, autant avoir des batteries LFP dès le départ, quitte à avoir des téléphones légèrement plus lourds, comme pas ça, pas de prise de tête avec les problèmes de charges partielles.
Mais il faudrait ajouter à ce que j'ai dit, que pour qu'une stratégie de durabilité d'une batterie de téléphone fonctionne, quelque soit la stratégie, il faut aussi que les OS de ces téléphones puissent être mis à jour pendant longtemps. Un téléphone non mis à jour pendant des années peut être une passoire sur le plan de la sécurité informatique, ce qui peut le rendre tout simplement inutilisable, sans parler des problèmes potentiellement systémiques que cela cause.
Ce que je propose, c'est qu'au mieux, les pilotes des téléphones soit obligatoirement sous licence libre. Ainsi, on pourrait simplement avoir des communauté rémunérés par des fond publics pour adapter les pilotes vers les nouvelles version de chaque OS. Je sais pas dans quel mesure c'est possible concrètement et économiquement, mais ce qui est sûr, c'est que les actes individuels ne peuvent s'abstraire d'actes collectifs, donc d'actes politiques.
Le
06/08/2024 à
21h
52
En effet, sur mon smartphone rootė, j'utilise AccA et je stoppe la recharge à 80% ,(et sans jamais dépasser les 4V).
Par contre, j'ai une vingtaine de batteries 18650 ainsi que 2 chargeurs Li-ion... Je fais comment pour l'arrêter de charger ma 18650 à 80% seulement ?
Ça doit exister mais encore pas vu dans les pages de vente de catalogue genre Amazon ou Aliexpress. Peut-être que ce genre de matériel existe mais dans le monde pro ou scientifique en labo mais alors à des prix où aucun consommateur ne va acheter...
C'est vrai que je ne me suis pas posé la question pour les téléphones et me suis plus concentré sur les voitures électriques vu que l'ordre de grandeur sur l'impact environnemental des batteries n'est pas du tout du tout le même (question de priorité).
Donc je ne sais pas répondre à votre question, si ce n'est que je ne milite pas pour une écologie de spécialistes et/ou une écologie qui coûte trop chère si cela ne passe pas l'échelle. Sachant que dans le prix de la non écologie, il faut comptabiliser les dégâts, économiques et autres bien réels que cela produit.
Même si j'avais la réponse à votre question (que je n'ai pas), je n'estimerai pas avoir fait un pas important vers plus d'écologie si la majorité de la population ne peut y accéder (enfin qu'en sais-je ?), soit pour une question de manque de temps pour acquérir les compétences, soit pour une question de manque d'argent (ce qui inclut le point précédent). Mais si vous obtenez la réponse, et si les constructeurs finissent pas suivre des utilisateurs spécialistes et en faire profiter tout le monde, vous aurez gagné quelque chose, mais dans ce cas, autant avoir des batteries LFP dès le départ, quitte à avoir des téléphones légèrement plus lourds, comme pas ça, pas de prise de tête avec les problèmes de charges partielles.
Le
06/08/2024 à
20h
51
Pas beaucoup de sources a part quelques articles en anglais : Auto Evolution
Tesla recommande 100% pour pouvoir calibrer, MG recommande 80%.
Il semble quand même que charger a 100% affecte la durée de vie des LFP, mais moins que les NMC.
Ok, malgré tout d'après l'étude empirique que je vous ai cité plus haut, on peut voir qu'une batterie LFP dont la charge/décharge varie entre 20 et 80% à 25° obtient un nombre de cycles recensés (faudrait voir les conditions de mesure) d'environ 7200 cycles pour une batterie LFP, et d'environ 1800 cycles pour les batteries NMC. Pour une charge décharge qui varie entre 0 et 100% toujours à 25°, le nombre de cycle mesurés est de environ 6200 cycles pour une batterie LFP, tandis qu'il est de environ 400 cycles pour une batterie NMC. Donc on peut non seulement dire que les batteries NMC sont dans les choux en condition "normales" préconisées par les constructeurs par rapport aux batterie LFP (ça on le savait déjà), mais on peut aussi dire qu'elles le sont d'autant plus lorsque l'on fait des cycles de charge/décharge complets. Ce qui veut dire que mon raisonnement de départ qui expliquait que la densité énergétique des batteries était plutôt trompeur au regard de ces chiffres, sauf si l'on considère des cycles de charge/décharges profond assez rares (i.e. seulement pendant les vacances) pour que cela impact la durée de vie globale de la batterie. Et si on considère ne jamais faire de charge/décharge de 0 à 100%, alors la densité énergétique est complètement trompeuse, car il suffirait d'avoir une batterie LFP plus petite qui supporterait plus de cycles complets pour un prix inférieur.
Par ailleurs, on peut voir que la charge à de 0 à 100% n'impacte pas beaucoup les batteries LFP (7200 vers 6200 cyles), et sachant que c'est surtout les décharges profondes qui dégradent les batteries LFP, on peut considérer (mais sans trop savoir), que les charges/décharges de 20 à 100% n'ont pas beaucoup d'impact sur les cycles des batteries LFP, et beaucoup moins en proportion par rapport au batterie NMC (peut être moins en valeur absolue).
Je peux ajouter que même si ce n'est pas dans le sujet de ce fil, et sachant que les batteries LFP sont moins chères, plus stables (moins de risque à l'emballement), plus écologiques à la fabrication et au recyclage, et durent beaucoup plus longtemps (donc elle sont encore plus écologiques), le fait qu'elles pèsent un peu plus lourd vaut quand même qu'on se pose des questions à l'achat, et si l'on part du principe qu'acheter une voiture électrique s'inscrit dans une démarche écologique (avec un batterie pas trop grosse quand même pour rester cohérent), il me semble que les batterie LFP ont plus d'intérêt sauf informations contraires non encore dévoilées. Il parait que la France à misé sur la fabrication de batterie NMC, ce serait vraiment dommage d'avoir fait un pari unique de ce type.
Le
06/08/2024 à
09h
46
Tous les BMS que je connais (ou que j'ai développé ) ont cette fonction de recharge ponctuelle à 100% même quand ce n'était pas recommandé pour la durée de vie de la batterie (l'important étant de ne pas rester longtemps au-dessus de 80-90%). Cela vient du fait que les cellules de la batterie ne se déchargent pas uniformément. Le pourcentage de charge est alors estimé et avec le temps, il devient peu fiable. Seul moyen de recalibrer la jauge et rééquilibrer le niveau de charge des cellules ? Charger au max du max.
Ok. Merci pour l'info :)
Le
05/08/2024 à
14h
40
Il me semble que les 100% de charge pour le LFP font toujours débat. Aurais tu des sources ?
En complément de ma réponse, est-ce que tu as toi même des sources concernant ce débat qu'il y aurait sur la charge 100% des batteries LFP ? Cela m'intéresse.
Le
05/08/2024 à
14h
38
Il me semble que les 100% de charge pour le LFP font toujours débat. Aurais tu des sources ?
Je ne savais pas qu'il y avait débat là dessus, mais mes sources, c'est les informations que j'ai pu glaner chez quelques constructeurs, la presse de vulgarisation en général (personne ne semble dire le contraire de mémoire), et cet article qui compare empiriquement les performances des différentes types de batteries selon la température et le taux de charge/décharge : https://iopscience.iop.org/article/10.1149/1945-7111/abae37 . Toutefois, dans ce dernier article, le cas 20%-100% (celui que j'évoquais) n'est pas vraiment traité sauf erreur de ma part, mais le cas 0%-100% oui.
Par ailleurs, et pour corroborer ce que je dit, j'ai moi même des batteries LFP raccordées à mon onduleur solaire, et ce dernier décide de temps en temps (surtout quand il y a pas assez de lumière pendant plusieurs jours) de charger les batteries à 100% (en réalité c'est le BMS des batteries qui demande une charge complète), sachant que l'onduleur connaît le modèle exacte des batteries. Je pars du principe donc que tout va dans ce sens et que les concepteurs de l'onduleur devaient bien savoir ce qu'ils faisaient.
Le
05/08/2024 à
13h
46
Oui, d'accord avec toi. Densité énergétique plus faible.
Je suis d'accord avec un petit bémol. Les batterie LFP acceptent nativement d'être chargée à 100% sans être détériorée prématurément (c'est même recommandé pour prolonger leur durée de vie), la où il est recommandé de ne pas charger les batteries de type NMC au delà de 80% pourtant plus denses énergétiquement et sachant que les batteries NMC ont beaucoup moins de cycles de charge/décharge garantis. Au final, et selon les besoins, dire que les batteries NMC sont plus denses énergétiquement peut être dans la réalité de l'usage plutôt trompeur.
Relire… mais surtout comprendre, être sûr que ce que fait le code Rust correspond à ce que doit faire le code C+/C++ (donc avoir les deux en parallèle).
Bon courage, ça va être un boulot passionnant.
Oui, je suis pas sûr que cela fasse gagner beaucoup de temps si l'idée est d'avoir en résultat un code de qualité, d'autant qu'il faut valider l'architecture logiciel qui à mon avis ne doit pas être automatiquement considérée comme automatiquement la même en passant d'un langage à l'autre. Si le squelette du code n'est in fine pas celui qu'il faudrait choisir, c'est au choix : 1. Tout le code qu'il faut revoir 2. le risque (avec une proportion inconnue) que le code V2 accumule une dette technique difficile à résorber et qui empêche des évolutions lisibles et faciles, quand bien même le code serait fonctionnel au départ.
Le
05/08/2024 à
14h
19
Quel narratif autour de Rust tend à faire croire que tout va bien ?
En tant que programmeur C++ pendant 13 ans et pratiquant le Rust régulièrement depuis 2/3 ans. "Mon narratif" c'est que Rust aide beaucoup à faire mieux, plus facilement. Bien sur Rust à lui seul n’empêche pas la présence d'erreurs, mais il permet d'en éviter beaucoup, permettant ainsi de se concentrer sur une quantité moins importante de questions. Le langage en lui-même et tous les outils disponibles sont autant de support pour se concentrer sur ce qu'il reste. Une des difficultés étant de savoir ce à quoi il faut toujours faire attention (en plus de l’algorithme en lui même). Sur de la collaboration ça a son importance par exemple, et je trouve beaucoup plus reposant en Rust de relire le code d'une autre personne pour vérifier s'il semble ok qu'en C++.
Je suis d'accord, peesonnellement, je n'ai jamais compris "rust évitenent toute faille" ou "ouf, plus besoin de gérer la securité", ni entendu/lu personne le dire.
En revanche, ce que j'ai lu, c'est que la mémoire était nativement bien mieux gérée, et que cela suprimait d'office tout en un pan de failles/bug en comparaison (d'autres languages savent le faire). Cela est compréhensible d'amblé mais cela semble aussi être vérifié empiriquement par des audits sur des libs.
Les injections (SQL ou autres) sont aussi populaires que faciles à éviter (troisième place dans le classement OWASP). La faille a perdu trois places depuis le même classmement de 2017.
D'après ce que j'ai compris, l'article fait plus référence à des bibiolthèques non mises à jour sur des systèmes considérés comme "non critiques", même s'ils peuvent être la porte d'entrée vers d'autres systèmes. J'imagine le foisonnement d'API accumulées codées plus ou moins rapidement, puis oubliées. Je pense qu'il s'agit surtout d'une culture de la sécurité que l'entreprise a ou n'a pas. Un dev seul ne pourra pas changer tout seul une culture et sans qu'il ne soit missionné pour le faire.
Oui, clairement, l'informatique ne fait pas partie des indispensables pour vivre. Preuve, l'humanité a vécu et fait des choses extraordinaires sans (il n'y a qu'à regarder les bâtiments, les vestiges des autres époques). Il n'y a qu'à regarder les J.O de Paris : qu'est-ce qui est le plus impressionnant les gradins ? les bâtiments qui ont plusieurs siècles ?
L'IT et les technologies sont utiles (et je n'ai jamais dit le contraire), je constate et déplore que nous en sommes devenus dépendants et esclaves. Pour celles & ceux qui pensent que je n'ai qu'à aller aux champs pour me nourrir, c'est bien là le problème : La liberté des uns (à faire ce qu'ils veulent) impactent celles d'autres (ex : agriculteurs) puisque le climat qui est leur outil a déjà changé et va l'être de plus en plus. Ils ont droits au double effet KissKool : 1 - subir le dérèglement climatique 2 - être payé une misère et avoir beaucoup de mal pour en vivre
Eux (et donc nous aussi, ne l'oublions pas) ne pourrons pas revenir au backup d'hier : c'est une triste réalité physique !
Dans l'esprit, je suis d'accord avec ce que vous dites, mais vous avez cité Jancovici, et lui explique que la dernière fois que développement durable a existé, c'était au moyen age. C'était "bien", "moyen" ou "pas bien", mais ça fonctionnait (d'après lui). Il rajoute que le moyen age, c'était 500 millions de personnes, et qu’aujourd’hui, nous ne savons plus le faire avec notre densité de population. Ce que j'en ai compris, c'est que si on voulais retourner à un développement durable, c'était avec une forte diminution de la consommation, mais accompagnée d'une technologie qui parfois est low tech car elle extrait moins de minerais, alors que d'autre fois il faut de la high tech car il faut plus d'optimisations. Et pour avoir de la high tech pas cher, il ne faut pas en produire en petite quantité j'imagine. Je ne suis pas sûr du bouton sur lequel il faut appuyer sans tout casser. Exemple, si vous appuyez sur le bouton "moins de production", est-ce que ça se traduit par moins "de richesse" ?
Si c'est le cas, cela veut dire moins de financement pour la défense, et est-ce que cela veut dire que c'est le régime d'un état pas trop soucieux de l'étique qui finira par imposer son ordre en appuyant sur un autre bouton que je développerais pas ici ?
J'ai pris un exemple extrême et caricatural, mais je peux en prendre un plus léger. Si ma plaque à induction ne fonctionne plus, je peux prendre du bois, mais si ça arrive à beaucoup de monde en même temps, je ne pense qu'il y aura assez de bois en France d'après ce que j'ai compris de l'état des forêts. C'est encore pire pour le chauffage. Alors est-ce qu'il ne vaut pas mieux dans ce cas avoir une stratégie diversifiée qui tente plusieurs choses ? Par exemple, n'ai-ce pas aussi pertinent d'avoir des panneaux photovoltaïques pour faire tourner un petit robot qui consomme que 500W (c'est mort pour la plaque à induction). Pourtant, les panneaux photovoltaïques c'est de la haute technologie, au moins car il faut des transistors de puissance pour transformer le courant continu en courant alternatif, transistors que l'on ne fabrique pas dans son garage (enfin je crois). Mais pour vous rejoindre, cela serait mieux si on avait des appareils qui fonctionnaient avec du courant continue pour se passer de cette partie "onduleur", et ça serait plus lowtech. Sauf que c'est pas si simple, car les éoliennes fonctionnent nativement en alternatif, les centrales thermique (nucléaire ou non) aussi, et les centrales hydrauliques aussi. Donc, il faux cohabiter avec différents types de courant.
Je n'ai pris que deux exemples, qui sont déjà bien casse-tête. On pourrait alors se demander comment faire face à une telle complexité à l'échelle de tous les "boutons" de la société ? et on pourrait alors imaginer des ordinateurs qui nous aiderais à optimiser des objectifs antagonistes, qui pourtant doivent cohabiter. Se pose alors la question des algorithmes à appliquer pour que ces optimisations sous incertitudes puissent aller dans le bon sens. C'est donc là par exemple, un axe de recherche en informatique (j'en fait mention car vous vous demandiez de l'utilité fondamentale d'un sujet recherche sur ces questions).
Tout ce ceci pour dire que comme pour la nature, la société est complexe car elle est même naturelle. Elle n'atteint jamais l'optimum, car elles est composées de contraires. Mais c'est ces contraires qui font que la nature tient. Pour citer Edgar Morin, l'ordre crée le chaos, et le chaos crée l'ordre. Pour en donner un exemple, certains écosystèmes ont été privés des loups, et il semble que cela ait causé beaucoup de tord dans toute la chaîne alimentaire. Toucher un élément de la chaîne a tout perturbé d'après les scientifiques. Je pense que cette leçon de l'équilibre est à lire aussi dans la société, car je ne pense pas que nos sociétés fonctionnent tellement différemment de la nature. Une seule idée ne peut suffire je pense pour équilibrer le tout. C'est à mon avis plus complexe que cela. Il n'y a peut être d'ailleurs pas de solution si on écoute certains collapsologues, même si je n'irai pas sur ce terrain.
On sait déjà que les algorithmes des GAFAM amplifient les choix des utilisateurs. Ce que tente de savoir, maladroitement peut être, le journal, est l'influence de l'algorithme sur les choix via des propositions non neutres.
Peut-être qu'il faudrait une vitesse de défilement contrôlée et un enregistrement vidéo pour pouvoir analyser le contenu hors du site pour éviter toute interaction non désirée.
Oui, dans ce cas, je ne sais pas, mais il m'a semblé via différentes études que les RS n'ont jamais été neutres. Et puis la neutralité est une question philosophique assez simple de mon point de vue. Si vous laissez passer quelque chose de moralement discutable, vous n'êtes pas neutre, si vous le censurez, vous n'êtes pas neutre, etc. Je ne vois pas trop à quel moment la neutralité peut exister. La question serait plus de savoir à mon sens, et c'est je pense ce que vous avez voulu dire, si les RS amplifient artificiellement un thème sans que cela ne vienne du comportement des utilisateurs. Ici, le mobile serait sans doute lié au fait que les thèmes à caractère sexuels génèrent plus de dépendances psychique et physiologique (libération par le cerveau d'endorphines ou je ne sais quelles autres drogues naturelles) dans un but de rendre les utilisateurs plus dépendants de la plateforme, afin que ces derniers restent plus longtemps et consomment plus de pub (quelconques). A noter que la loi française interdit le neuromarketing, mais je ne connais pas son périmètre exact, et il faudrait démontrer qu'il a été utilisé.
Le
26/07/2024 à
10h
31
La question est donc de savoir si les réseaux sociaux se contentent d'accompagner une trajectoire de l'utilisateur, ou s'il l'amplifie. Ce n'est pas exactement la même chose, mais c'est sûr que le réseau est responsable dans les deux cas, car on sais déjà qu'il peuvent inhiber les algos et qu'ils le font pour d'autres sujets. L'utilisateur est sans doute responsable au départ de rentrer dans ces trajectoires algorithmiques, mais il peut aussi être influencé par l'algorithme qui lui dit "si si c'est tout à fait normal". Si les pub n'avaient pas d'influence, ça se saurait.
Merci pour les précisions @tazvld, je suis 100% d'accord avec ce que vous dites et ne le conteste pas. Merci aussi pour m'avoir parlé sans sarcasme d'égal à égal (en tous les cas, c'est comme cela que je l'ai reçu).
Ce que vous dites est tout à fait vrai si on l'aborde sur le plan juridique, ou sur le plan des groupes politiques formés dans l'assemblée. Mais ce que je dis vise, sur la base d'une définition conceptuelle trouvée dans les dictionnaires (et non dans la loi), à refléter la même réalité mais du point de vue de l'électeur. Étant donné qu'il est impossible de dire de manière objective si l'électeur a préféré voter pour un parti du NFP plutôt qu'un autre vu qu'il n'avait qu'un seul bulletin NFP (et son programme) a sa disposition, diviser le NFP en plusieurs morceaux est plutôt vain et chimérique politiquement, et dessert le résultat du vote car chaque groupe interne au NFP pourrait un jour dire "oui mais moi, je suis plus légitime". Si ça se trouve, l'électeur se trouve très bien dans un parti du NFP autant que dans un autre, ou si ça se trouve, il a des préférences, mais comment en connaître les proportions ?
D'autre part, on pourrait trouver plusieurs courant au sein d'un même parti avec des élections internes et pour avoir exactement les mêmes problèmes (enfin pas tout à fait, vu que l'on pourrait avoir des tendances avec les pourcentages, mais même des tendances ne permettraient pas de dire si elles s'excluent ou s'assemblent). En définitive, plutôt de s'opposer des subjectivités tout à fait stériles, il convient de dire que le résultat des élections met le NFP en tête. Que j'ai choisi le mot "parti" pour décrire le NFP n'a pas été tout à fait conscient au départ, mais reflétait tout de même une réalité telle que je l'ai décrite et dans les conditions que les ai décrite plus haut.
Enfin, si certains pensent que je suis aveugle à ce qu'ils disent, où que je les ai attendu pour envisager le point de vue qu'il défendent (et qu'ils défendent de manière condescendante), dites vous bien que si vous refusez d'envisager mon angle de vue, j'en ferais autant. Ce n'est que de la réciprocité. Il suffit simplement de changer de ton, et tout ira mieux. Et dans les tons employés, ceux qui veulent jouer sur les mots pour ne pas voir l'essentiel de mon propos initial ne verront en retour qu'un reflet de leur comportement (jouer sur les mots).
Enfin, la réciprocité n'ira pas de mon côté jusqu'au mépris et aux insultes qu'on peut me porter, ça je leur laisse volontiers ce comportement.
Le
24/07/2024 à
13h
26
Larousse en ligne :
Organisation structurée dont les membres mènent une action collective dans la société aux fins de réaliser un programme politique : Les partis représentés au Parlement. Un régime de parti unique.
On est bien d'accord qu'il y a plusieurs partis représentés au Parlement dans la coalition du NFP ? LFI, PC, PS, Les Écologistes (EELV), ça fait 4 partis et je ne compte pas les partis d'outremer qui sont souvent différents mais qui se rattachent à un autre parti pour former un groupe.
Je ne propage pas de fausse nouvelle, c'est un fait : le Président a dit exactement la même chose que moi hier. C'est vous qui utilisez de mauvais mots et qui ne le reconnaissez pas. En utilisant le mot entité, vous êtes plus dans le vrai, mais ce n'est pas un terme utilisé à l'Assemblée Nationale.
Les 2 entités reconnues par celle-ci sont les groupes et les intergroupes. Le NFP n'est ni l'un ni l'autre.
Je ne nie pas le résultat des élections, je dis juste que vous utilisez de mauvais termes. Et, c'est très important d'utiliser les bons termes pour ne pas propager de fausses nouvelles, justement.
Sur le fond, aucune coalition prévisible actuellement (NFP, Ensemble pour la république + LR(+ RIOT ?), RN+LR de Ciotti) n'a la majorité et tombera probablement à la première motion de censure. C'est tout le problème pour le Président pour nommer un premier ministre, mais tant pis pour lui, c'est lui qui a créé cette situation.
On peut aussi séparer chaque électeur en disant qu'il représente sa propre nuance, et dire qu'à lui tout seul, il n'est pas majoritaire. En partant de votre façon de penser, à la fin, le bulletin qu'il a mis dans l'urne ne vaut rien, car il ne le représente pas exactement. Vous niez le résultats des élections officielles, vous propagez des fausses nouvelles. Quant aux termes, j'ai très bien choisi le miens, car la première définition que j'ai trouvé dans plusieurs dictionnaires correspond exactement à la réalité.
Le
24/07/2024 à
12h
56
NFP n'est pas un parti mais un ensemble de partis, une coalition pour reprendre le terme utilisé par Le Monde. Ce n'est même pas un groupe politique au sens de l'Assemblée Nationale mais un intergroupe.
Le président a d'ailleurs rappelé le point que je soulevais hier lors de son interview.
Édit : NFP n'est pas un intergroupe (voir mon autre commentaire plus haut pour la source).
Sur mon Larousse 2011 : parti = "association de personnes constituées en vu d'une association politique." Le NFP correspond exactement à cette définition, d'autant qu'il y a eu qu'un bulletin de vote NFP possible pour les électeurs, sans nuances possibles. Le résultat officiel des élections est très clair d'un point de vue administratif et regroupe le NFP comme une seule entité. Vous niez le résultat officiel des élections et propagez des fausses nouvelles.
Le
24/07/2024 à
12h
44
Il a raison. Tu parles de parti politique, le NFP n'en est pas un, c'est une coalition de partis. Le parti vainqueur en nombre, c'est le RN. Si on parle de coalition, c'est effectivement le NFP le vainqueur.
Je sais bien où vous voulez m'emener, mais je ne marche pas : Définition de parti : "Un parti politique est un groupe de personne, réunie en association, autour d'idées politiques communes. Cette organisation politique a pour objectif d'influence l'opinion publique ainsi que les actions du gouvernement en place. Elle propose également des candidats pour les élections. " source : https://www.linternaute.fr/dictionnaire/fr/definition/parti-politique/ Le NFP correspond exactement à cette définition, d'autant que les électeurs ont voté pour un seul bulletin, sans nuance. Je ne m'attendais pas à ce qu'il y ait des personnes qui propagent des fausses nouvelles ici, et qui nient les résultats officiels d'une élection.
Le
24/07/2024 à
12h
21
Le parti majoritaire (majorité relative) de l'Assemblée Nationale est le Rassemblement National. C'est lui qui a le plus de députés.
Dire que du point de vue de la connaissance du pays, il ne faut pas parler d'une candidate désignée par le parti majoritaire des dernières élections (historiques ?) sur une encyclopédie qui peut parfois citer et résumer chaque épisode d'une série TV, c'est tout sauf neutre. Penser qu'il y a débat et que ce débat est légitime est assez stupéfiant ! Les partisans de la neutralité de Wikipédia me font bien rire.
119 commentaires
Frustrations et départ dans l'équipe Rust du noyau Linux
Le 08/09/2024 à 12h 07
Personnellement, je comprends que l'engouement de la part des dev soit pas fou pour changer progressivement de langage, surtout un langage qui ne s'aborde pas de la même façon. Un noyau, c'est plusieurs millions de lignes de code, c'est critique, le chantier parait insurmontable quand on le dit comme ça. Maintenant, le rejet de ceux qui veulent tenter quelque chose de nouveau avec le langage Rust ne m'étonne pas vraiment. Pour en avoir fait l'expérience ici, critiquer le C, c'est s'exposer à des attaques ad hominem, et à des arguments d'autorité. Mais l'argument de dire, si ton programme n'est pas stable en C, c'est que tu es mauvais en C date depuis plusieurs dizaines d'années j'ai l'impression.Ça a l'air plus large si on en croit cette citation de Jeremy Soller, créateur de Redox OS (OS codé en Rust) : « Les développeurs Linux sont des mégalomanes pédants et condescendants »
Mais sur cette citation, je dirais qu'il vaut mieux éviter les généralités, d'autant qu'il y a un conflit d'intérêt car en disant ça, ça lui permet de mettre en avant son OS.
Je retiens par contre que faire co-évoluer deux technologies dans le même projet Linux, c'est peut être plus un inconvénient, même ça parait être un avantage pour la "transition". La transition peut en effet ne jamais se terminer.
Le côté redévelopper tout le noyau, ça parait tout aussi insurmontable, mais en fait je pense que ça l'est moins, car il n'y aurait pas forcément besoin de porter tout le code concernant de vieilles architectures, juste le code concernant les architectures récentes. Je trouve que c'est un projet intéressant de tout repenser à zéro. Le fait de tout repenser sur Rust plutôt que d'adapter un noyau initialement pensé pour le C vers le Rust peut éventuellement être moins complexe. Faudrait voir ce que donne des projets comme Redox ou autre.
Debian 12.7 et 11.11 disponibles, attention à Secure Boot
Le 08/09/2024 à 11h 11
Cette mise à jour a aussi permis de rendre les ISO d'installation Debian à nouveau bootable sur les machines en dual boot avec Windows, depuis que Microsoft avait fait les mêmes mis à jour avec les mêmes restrictions sur l'UEFI mi-août. Debian était devenu non bootable sur les machines en dual boot avec Windows. Peut-être que Debian a tardé a appliqué cette mis à jour (6 mois), car les restrictions peuvent être effectivement problématiques.[Tuto] L’influence des couches de neurones sur l’intelligence artificielle
Le 28/08/2024 à 10h 18
Je rappel que le test de Turing était une façon à Turing de ne pas définir l'intelligence, ni la conscience. Comme il ne savait pas le faire, il a fait un test qui n'exige pas de connaître la définition.Le 28/08/2024 à 10h 15
Même s'il faut bien que le titre évoque quelque chose qui parle, je ne suis pas sur que de parler "d'IA" est une bonne idée. Il faudrait plutôt parler d'algorithmes d'apprentissage supervisés dans ce cas ou non supervisés pour les autoencodeurs. Parler d'IA évoque l'intelligence, et c'est plutôt trompeur. C'est donc plutôt un terme commercial à mon sens.Une mise à jour Windows bloque le démarrage de Linux sur certaines installations en dual-boot
Le 23/08/2024 à 09h 38
Le 23/08/2024 à 09h 32
Edit: Ubuntu a bien la dernière version corrigée, et pourtant il ne démarre plus après ce qu'à fait Microsoft. Quand à Debian, la version corrigée n'est toujours que dans le canal sid (à tester), et non encore officielle.
Sinkclose : tous les processeurs AMD sont vulnérables à l'insertion de code malveillant
Le 14/08/2024 à 16h 06
Le 14/08/2024 à 16h 00
Le 13/08/2024 à 15h 37
Mais s'il faut avoir un accès avec les privilèges de type "ring 0", il faut convaincre le noyau. En supposant que ce n'est pas possible et que ce noyau n'a pas de failles connues, il ne me vient à l'esprit pour aboutir à l'attaque que une clé usb insérée au démarrage de la machine, avec un programme de démarrage ayant par défaut le privilège "ring 0" (comme tous les programme de démarrage si j'ai bien compris). Sauf que si le "SecureBoot" est activée, et à supposer que la signature du programme de démarrage ne correspond à rien d'officiel, et à supposer que les "officiels" ne réalisent pas l'attaque, est-ce que cela est réellement exploitable en ayant accès à la machine comme c'est indiqué dans l'article (vrai question) ?L’ONU adopte la proposition controversée de traité sur la cybercriminalité portée par la Russie
Poutine et les pédo-nazis
Le 10/08/2024 à 17h 54
Le 10/08/2024 à 15h 33
[MàJ] Fiasco CrowdStrike : détails techniques, 8,5 millions de machines touchées selon Microsoft
78 minutes ont suffi
Le 08/08/2024 à 21h 16
Je vais partir du cas général, pour arriver au contexte du bug cité plus haut.
Admettons que vous faites "a=1/2". Vous ne pouvez pas faire un catch d'une exception générique de cette opération, en disant j'attrape tout. Si vous avez une division par zéro, c'est incohérent car elle ne devrait pas arriver, donc autant tout faire tout planter (la mémoire peut être instable ou que sais-je). Si vous continuez l'exécution, vous arrivez de toute façon dans un état incohérent.
Autre exemple, si vous n'avez plus assez d'espace mémoire et avez une exception de ce type, vous pouvez essayer de catcher l'exception, mais si vous le faites, vous devez savoir comment vous en sortir sachant que vous n'avez pas assez de mémoire. Et peut être qu'il n'y a pas de bonne façon de s'en sortir ici. Donc en faisant un catch de cela sans y réfléchir, vous risquez de générer une boucle infinie d'exceptions indiquant qu'il n'y a pas assez de mémoire et comme vous catchez l'exception sans prendre des mesures adéquates, ça ne s'arrête jamais, ce qui sans doute n'a pas fait planter le noyau, mais je ne sais pas trop quel serait son état si un de ses drivers tourne à l'infini.
Mais c'est valable en général pour un algorithme. Si votre algorithme arrive dans état complètement illogique (enfin à priori), je dis qu'il faut tout faire planter, ne serait-ce que pour s'en rendre compte pendant les tests. C'est le principe des assertions.
Donc ici, pour revenir au contexte du "sensor"/driver qui ne s'en sortait pas à cause d'un accès mémoire invalide, vous pouvez faire un catch du tout et n'importe quoi, mais si vous faites ça, vous devez vous assurer que ce n'est pas une fausse bonne idée. Alors bien sûr, dans le contexte du noyau, sans doute aurait-il fallu simplement ignorer le chargement du drivers, émettre un rapport comme vous le dite, et passer à autre chose. Mais du coup, vous faites un catch en conscience de ce que vous faites, et vous acceptez de faire sauter un "sensor"/drivers lors du chargement de tous les drivers. Je n'ai pas du tout de problème avec l'idée. Mais au moment où prenez cette décision, vous acceptez que des drivers peuvent être manquants, et devez en tenir dans toute votre architecture, sinon, cela pourrait planter ailleurs, et ainsi de suite. Donc oui, avoir une tolérance à la panne, et faire simplement remonter un rapport aurait sans aucun doute été la bonne solution ici, mais ça ne s'improvise pas, il faut peut être en tenir compte ailleurs dans le reste de l'architecture.
Si vous faites des catchs partout sans prendre la mesure de ce vous êtes en train de faire, cela risque in fine de quand même planter mais beaucoup plus loin dans le programme, et là bon courage pour remonter le bug, surtout si vous avez pleins de rapports qui été pondus pendant 2 jours avant que ça ne plante quand même (je ne dis pas que c'est ce qui se serait passé ici, je n'en sais rien). D'autre part, comme c'est dans l'espace noyau, cela pourrait avoir des conséquences délétères non prévues si vous ne l'avez pas bien encadré. Vous évoquez les problèmes économiques, mais là, on parle d'une machine immobilisée par un BSOD. Étant donné qu'on est dans l'espace noyau, imaginez qu'en catchant tout et n'importe quoi, le noyau se mette à faire tout et n'importe quoi en dézinguant le système de fichier. Là, c'est carrément la cohérence des données du système de fichier que vous pouvez flinguer. Je ne sais pas si on peu en arriver là, et si les gardes fou du noyau sont suffisants, mais je veux dire que dans un contexte économique, il y a pire qu'un BSOD.
Mais encore une fois, dans le contexte de ce bug, il était sans doute possible d'accepter une tolérance à la panne, mais cette tolérance doit tout de même être anticipée et encadrée, ce qui n'a pas été le cas ici et c'est bien dommage. Mais ce n'est pas une décision qu'il faut prendre de manière légère et aveugle comme une règle générale (en tout cas pas pour moi).
Donc je ne dis pas "Donc si je comprend bien, comme il n'est pas possible de prévenir de tous les bugs, évitons d'essayer de prévenir de quelque bug que ce soit...", je dis "essayez de prévenir tous les bugs, y compris ceux que vous comprenez pas à l'avance, acceptez la tolérance à la panne, mais si un bug ou une panne non anticipée arrive quand même alors que vous ne l'avez pas prévu ni encadré, je ne crois pas qu'il faille faire un catch aveugle sans en mesurer les conséquences, d'autant qu'à force de faire ça, vous prenez le risque de rendre un bug silencieux lors des tests, et rendre vos remontées de bug plus pénibles et fastidieuses.
Le 30/07/2024 à 04h 18
Puis vous avez commencé un historique des langages, et j'ai arrêté à ce moment de vous lire. Partir du principe que je ne comprend rien à ce que je raconte m'indiquait que vous jugiez sur les apparences. Alors certes, j'aurais du attendre un moment où j'avais plus de disponibilité pour vous lire, mais étant donné que vous ne donniez aucun crédit à ma façon d'aborder les choses, je ne voyais pas pourquoi je devais en faire plus que vous.
Pourtant après avoir relu tout vos commentaires, j'ai compris tout ce que vous aviez dit, même si j'estime que ça n'avait pas trop rapport avec mon commentaire initial, et comme je n'avais pas le temps de digresser, je n'ai pas vraiment compris pourquoi toutes ces digressions, et ces tons péremptoires que vous aviez avec moi. Le mal entendu naissait et grandissait de plus en plus.
Donc oui, un pointeur P de valeur nulle, qui pointe vers une structure à la position relative 4, aura l'adresse absolue 4, donc non égale à zéro. Je vous rassure, ce n'est pas une découverte pour moi. Le problème, c'est que comme c'est évident, il est impossible pour ma part de comprendre le malentendu avec des commentaires qui répondent à côté de mon commentaire initial avec des présomptions fortes sur ce que je sais ou pense dès le départ, et avec moi vous lit en diagonale n'ayant pas eu la patience d'attendre 1 jour pour répondre.
Très bien. Au moment de mon commentaire initial, je ne suis pas dans l'esprit de faire la différence entre le contexte du noyau et celui du programme, ou entre les adresses valides ou non. Je ne pense pas non plus "translation d'adresse". Mon commentaire initial n'en avait pas besoin, puisque je commentais le problème inhérent que pose le C, car la question n'est pas de savoir si on doit tester un pointeur NULL, mais pourquoi on arrive dans un état qui ne s'est pas produit pendant les tests. Le pointeur NULL n'a peut être rien à voir, et s'est peut être la résultante d'un bug plus en amont.
Dire qu'un noyau doit être stable, mais comment dire, vous pensez vraiment que quelqu'un pense que le noyau peut être bâclé dès lors que l'on comprend ne serait-ce qu'à minima ses fonctions ? Quiconque a déjà utilisé Windows Millenium sais ce que cela implique un noyau instable, qu'il soit informaticien, ou utilisateur de Word. J'ai l'impression que tous les utilisateurs de Windows Millenium étaient devenus superstitieux, tellement il était imprévisible. Pas besoin d'utiliser un argument d'autorité pour le savoir.
Cela étant dit, lorsque je dis qu'un programme qui arrive dans un état incohérent doit tout arrêter, vous dites en retour que l'on ne peut se permettre d'en faire autant avec le noyau en tant que dev, avec en creux l'idée qu'il faille continuer coûte que coûte, ce qui n'est pas ce qu'a choisi de faire le noyau de Windows. C'est votre appréciation, mais si ne vous faites pas planter un noyau sans savoir si c'est bien raisonnable, comment être sûr que ce ne sera pas pire ? Ce qui s'applique pour un programme, s'applique aussi pour le noyau.
Si l'on se place du point de vu d'un programme, l'objectif principal est que ce dernier ne plante pas et remplisse ses rôles. Si à un moment un problème se pose et que cette éventualité avait été anticipée, on peut alors prévoir plusieurs stratégies pour fonctionner en mode dégradé. On peut déléguer la tâche à un système de secondaire, on peut considérer une autre option, on peut simplement désactiver une fonctionnalité, on peut considérer que le problème n'est pas si important et qu'il suffit juste de faire remonter l'information dans un rapport, on peut appliquer un autre algorithme contournant le problème en le résolvant d'une autre façon, on peut développer un système avec une tolérance à la panne, etc.
Mais si le problème n'avait pas été anticipé, et s'il arrive quand même alors qu'il ne devrait pas arriver, c'est à dire au moment d'une assertion qui vérifie un pointeur non NULL par exemple, alors il faut faire planter le programme.
Imaginez un outil de contrôle aérien qui arrive dans un état mémoire théoriquement impossible alors qu'il a été testé mille fois, de manière empirique et par un système de preuve. Vaut-il mieux tout faire planter, ou continuer ?
- Si vous continuez, vos tests unitaires ne détecterons rien. Peut être aurez vous un rapport de généré, mais si vous oubliez le lire à temps, votre programme aura quand même poursuivi son excécution.
- Vous pouvez aussi ne pas avoir la même stratégie pendant les tests ou en production, mais dans ce cas, vos tests ne sont pas tout à fait valides car il ne testent pas la même chose.
- Si vous faites tout planter, et que cela arrive pendant les tests, vous corrigez vos tests. Mais si vous poursuivez l'exécution du programme en production sans savoir si cela est bien raisonnable, et alors que vous êtes sûr que cela ne devrait pas arriver (assertion), vous prenez le risque pour le dire vite d'afficher à l'écran des avions à une mauvaise position.
- Si vous faites tout planter et que cela arrive en production, vous avertissez les contrôleurs aérien que le système n'est plus fiable, et qu'il faut qu'ils se débrouillent autrement. Faut-il tout faire pour en arriver là ? Non, car un oui serait trop évident -> que voulez-vous que je vous dise d'autre ? Tout ceci est banal, et je suis sûr que je ne vous apprend rien.
Maintenant, la question soulevée au départ est, pourquoi un programme qui ne plante pas pendant les tests peut finir par planter en production avec le C ? Etant donné que le C permet de faire n'importe quoi avec la mémoire (oui oui), il suffit que la configuration mémoire soit différente au moment de l'exécution pour que le comportement du programme soit différent.
Car justement, le langage C ne vérifie pas si un accès mémoire est autorisé ou non. Tant que la zone pointée ne déborde pas de l'espace d'adressage du processus, le noyau ne dit rien (enfin le processeur, ça serait trop lent si le noyau testait chaque accès mémoire sans accélération processeur). Si vous faites un dépassement mémoire, ou si vous lisez un pointeur non égal à 0, parfois le programme plante, parfois c'est le noyau qui le fait planter, parfois il ne plante pas.
Rien que de changer les options de compilation fera donner un comportement différent au programme avec le même bug, voir cela fera virtuellement disparaître le bug, le programme n'ayant pas planté.
On peut même avoir un pointeur non initialisé qui vaut une valeur aléatoire au moment des tests, car une variable non initialisée prend par défaut la valeur de son état mémoire au moment de son allocation, probablement non NULL. Donc si cette valeur par défaut correspond à une valeur acceptable de l'espace d'adressage du programme, le processus ne plante pas. Si vous relancez plusieurs fois le test sur la même machine, en relançant plusieurs fois le même programme, la configuration mémoire de l'ordinateur de test n'ayant pas changé, le bug n’apparaît jamais, le pointeur n'est jamais à NULL.
Pendant la prod, disons pour des raisons d'options de compilation différentes, le pointeur non initialisé aura la valeur par défaut à zéro, et le programme plante à se moment, là où il n'avait pas planté pendant les tests. Voilà un scénario possible. Mais il peut y en avoir d'autres.
Est-ce que c'est cela qui s'est passé ici ? Je ne sais pas, je ne faisais qu'émettre une hypothèse.
Ce qui nous amène au fond du sujet, puisque vous avez quand même répondu à mon commentaire initial à un moment, c'est à dire dans le commentaire auquel je répond présentement. Vous dites que C est un langage à remettre dans son contexte. Très bien, mais là encore, vous enfoncez une porte ouverte. Le problème n'est pas celui là, ni l'histoire du C, mais plutôt que faisons nous en 2024 avec un tel langage ?
Vous dites en creux qu'un OS ne peut se passer d'un tel langage qui permet tant de liberté. Peut être avez-vous raison, personnellement, n'étant pas dev sys, je me contente d'observer que personne n'a envie de redévelopper plusieurs millions de ligne de code d'un noyau dans un autre langage, d'autant que beaucoup de dev sys développent en C. Est-ce que les deux raisons qui font que le C soit toujours aussi populaire ne sont pas les suivantes :
1. il n'y a pas assez de monde dans les dev sys qui maîtrisent un autre langage que le C
2. il est très démotivant de redévelopper tout un noyau dans un autre langage dont on ne sais même pas s'il est plus mature que le C .
Mais comme ici, il s'agissait que d'un (parait-il faux) pilote, peut être qu'en fait si, on peut progressivement développer dans un autre langage, qui plante dès qu'un accès mémoire n'est pas licite à l'intérieur même du processus, et non plusieurs centaines de lignes plus loin, et non "jamais jusqu'au jour où on le met en prod". Peut être qu'à la périphérie du noyau et dans les couches du dessus, il n'est plus nécessaire de développer dans un langage devenu pour moi bien trop vieux. C'est bien là mon droit d'émettre une opinion. Personne ne vous oblige d'être d'accord. Mais ne croyez pas qu'une seule opinion doit survivre. Ce n'est pas Highlander !
Je pense franchement qu'on aurait pu éviter ces digressions et cette perte de temps, car je soupçonne que dès le départ, que vous comprenez ce type de position.
Fiasco CrowdStrike : un paramètre en trop (ou en moins) est à l’origine du bug
Ça se joue parfois à pas grand chose…
Le 08/08/2024 à 16h 29
Le 08/08/2024 à 13h 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.
Le 08/08/2024 à 13h 03
Le 08/08/2024 à 12h 48
Le 08/08/2024 à 11h 47
Le 08/08/2024 à 11h 09
Le 08/08/2024 à 11h 03
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.
Le 08/08/2024 à 10h 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.
Le 08/08/2024 à 00h 10
Le 08/08/2024 à 00h 03
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.
Le 07/08/2024 à 23h 41
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.
Le 07/08/2024 à 23h 35
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 !
Le 07/08/2024 à 23h 12
Le 07/08/2024 à 22h 57
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 !
Le 07/08/2024 à 22h 38
Le 07/08/2024 à 22h 35
Le 07/08/2024 à 19h 59
J'ai à peu près compris le rapport et ce qui s'est passé. Pour résumer ce que j'ai compris, ils ont testé les parties/modules incriminées indépendamment sans avoir semble t'il un scénario global qui test l'ensemble. le module X a été testé avec des données entrées manuellement, mais qui auraient du être fournies par le module X-1 en amont. Du coup, les données apportées au module X ne correspondaient pas celles qu'il allait trouver en production.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.
Le 07/08/2024 à 17h 48
Avec autant de clients et de machines, ils auraient pu au moins avoir un serveur en pré-prod pour avoir les conditions du réel au plus proche !Recyclage des batteries des voitures électriques : une « lithiation révolutionnaire » au CNRS
Le 06/08/2024 à 22h 03
Ce que je propose, c'est qu'au mieux, les pilotes des téléphones soit obligatoirement sous licence libre. Ainsi, on pourrait simplement avoir des communauté rémunérés par des fond publics pour adapter les pilotes vers les nouvelles version de chaque OS. Je sais pas dans quel mesure c'est possible concrètement et économiquement, mais ce qui est sûr, c'est que les actes individuels ne peuvent s'abstraire d'actes collectifs, donc d'actes politiques.
Le 06/08/2024 à 21h 52
Donc je ne sais pas répondre à votre question, si ce n'est que je ne milite pas pour une écologie de spécialistes et/ou une écologie qui coûte trop chère si cela ne passe pas l'échelle. Sachant que dans le prix de la non écologie, il faut comptabiliser les dégâts, économiques et autres bien réels que cela produit.
Même si j'avais la réponse à votre question (que je n'ai pas), je n'estimerai pas avoir fait un pas important vers plus d'écologie si la majorité de la population ne peut y accéder (enfin qu'en sais-je ?), soit pour une question de manque de temps pour acquérir les compétences, soit pour une question de manque d'argent (ce qui inclut le point précédent). Mais si vous obtenez la réponse, et si les constructeurs finissent pas suivre des utilisateurs spécialistes et en faire profiter tout le monde, vous aurez gagné quelque chose, mais dans ce cas, autant avoir des batteries LFP dès le départ, quitte à avoir des téléphones légèrement plus lourds, comme pas ça, pas de prise de tête avec les problèmes de charges partielles.
Le 06/08/2024 à 20h 51
Par ailleurs, on peut voir que la charge à de 0 à 100% n'impacte pas beaucoup les batteries LFP (7200 vers 6200 cyles), et sachant que c'est surtout les décharges profondes qui dégradent les batteries LFP, on peut considérer (mais sans trop savoir), que les charges/décharges de 20 à 100% n'ont pas beaucoup d'impact sur les cycles des batteries LFP, et beaucoup moins en proportion par rapport au batterie NMC (peut être moins en valeur absolue).
Je peux ajouter que même si ce n'est pas dans le sujet de ce fil, et sachant que les batteries LFP sont moins chères, plus stables (moins de risque à l'emballement), plus écologiques à la fabrication et au recyclage, et durent beaucoup plus longtemps (donc elle sont encore plus écologiques), le fait qu'elles pèsent un peu plus lourd vaut quand même qu'on se pose des questions à l'achat, et si l'on part du principe qu'acheter une voiture électrique s'inscrit dans une démarche écologique (avec un batterie pas trop grosse quand même pour rester cohérent), il me semble que les batterie LFP ont plus d'intérêt sauf informations contraires non encore dévoilées. Il parait que la France à misé sur la fabrication de batterie NMC, ce serait vraiment dommage d'avoir fait un pari unique de ce type.
Le 06/08/2024 à 09h 46
Le 05/08/2024 à 14h 40
Le 05/08/2024 à 14h 38
Par ailleurs, et pour corroborer ce que je dit, j'ai moi même des batteries LFP raccordées à mon onduleur solaire, et ce dernier décide de temps en temps (surtout quand il y a pas assez de lumière pendant plusieurs jours) de charger les batteries à 100% (en réalité c'est le BMS des batteries qui demande une charge complète), sachant que l'onduleur connaît le modèle exacte des batteries. Je pars du principe donc que tout va dans ce sens et que les concepteurs de l'onduleur devaient bien savoir ce qu'ils faisaient.
Le 05/08/2024 à 13h 46
La DARPA veut traduire automatiquement le code C en Rust
Vers un monde rouillé
Le 06/08/2024 à 14h 41
1. Tout le code qu'il faut revoir
2. le risque (avec une proportion inconnue) que le code V2 accumule une dette technique difficile à résorber et qui empêche des évolutions lisibles et faciles, quand bien même le code serait fonctionnel au départ.
Le 05/08/2024 à 14h 19
En revanche, ce que j'ai lu, c'est que la mémoire était nativement bien mieux gérée, et que cela suprimait d'office tout en un pan de failles/bug en comparaison (d'autres languages savent le faire). Cela est compréhensible d'amblé mais cela semble aussi être vérifié empiriquement par des audits sur des libs.
Akamai alerte d’une explosion des attaques contre les API et applications web
Corvée d'inventaire
Le 04/08/2024 à 18h 01
Les injections (SQL ou autres) sont aussi populaires que faciles à éviter (troisième place dans le classement OWASP). La faille a perdu trois places depuis le même classmement de 2017.D'après ce que j'ai compris, l'article fait plus référence à des bibiolthèques non mises à jour sur des systèmes considérés comme "non critiques", même s'ils peuvent être la porte d'entrée vers d'autres systèmes. J'imagine le foisonnement d'API accumulées codées plus ou moins rapidement, puis oubliées. Je pense qu'il s'agit surtout d'une culture de la sécurité que l'entreprise a ou n'a pas. Un dev seul ne pourra pas changer tout seul une culture et sans qu'il ne soit missionné pour le faire.
Nouvelles vagues de vandalisme sur les fibres optiques : Internet perturbé en France
Fiber cut, le retour
Le 30/07/2024 à 00h 53
Si c'est le cas, cela veut dire moins de financement pour la défense, et est-ce que cela veut dire que c'est le régime d'un état pas trop soucieux de l'étique qui finira par imposer son ordre en appuyant sur un autre bouton que je développerais pas ici ?
J'ai pris un exemple extrême et caricatural, mais je peux en prendre un plus léger. Si ma plaque à induction ne fonctionne plus, je peux prendre du bois, mais si ça arrive à beaucoup de monde en même temps, je ne pense qu'il y aura assez de bois en France d'après ce que j'ai compris de l'état des forêts. C'est encore pire pour le chauffage. Alors est-ce qu'il ne vaut pas mieux dans ce cas avoir une stratégie diversifiée qui tente plusieurs choses ? Par exemple, n'ai-ce pas aussi pertinent d'avoir des panneaux photovoltaïques pour faire tourner un petit robot qui consomme que 500W (c'est mort pour la plaque à induction). Pourtant, les panneaux photovoltaïques c'est de la haute technologie, au moins car il faut des transistors de puissance pour transformer le courant continu en courant alternatif, transistors que l'on ne fabrique pas dans son garage (enfin je crois). Mais pour vous rejoindre, cela serait mieux si on avait des appareils qui fonctionnaient avec du courant continue pour se passer de cette partie "onduleur", et ça serait plus lowtech. Sauf que c'est pas si simple, car les éoliennes fonctionnent nativement en alternatif, les centrales thermique (nucléaire ou non) aussi, et les centrales hydrauliques aussi. Donc, il faux cohabiter avec différents types de courant.
Je n'ai pris que deux exemples, qui sont déjà bien casse-tête. On pourrait alors se demander comment faire face à une telle complexité à l'échelle de tous les "boutons" de la société ? et on pourrait alors imaginer des ordinateurs qui nous aiderais à optimiser des objectifs antagonistes, qui pourtant doivent cohabiter. Se pose alors la question des algorithmes à appliquer pour que ces optimisations sous incertitudes puissent aller dans le bon sens. C'est donc là par exemple, un axe de recherche en informatique (j'en fait mention car vous vous demandiez de l'utilité fondamentale d'un sujet recherche sur ces questions).
Tout ce ceci pour dire que comme pour la nature, la société est complexe car elle est même naturelle. Elle n'atteint jamais l'optimum, car elles est composées de contraires. Mais c'est ces contraires qui font que la nature tient. Pour citer Edgar Morin, l'ordre crée le chaos, et le chaos crée l'ordre. Pour en donner un exemple, certains écosystèmes ont été privés des loups, et il semble que cela ait causé beaucoup de tord dans toute la chaîne alimentaire. Toucher un élément de la chaîne a tout perturbé d'après les scientifiques. Je pense que cette leçon de l'équilibre est à lire aussi dans la société, car je ne pense pas que nos sociétés fonctionnent tellement différemment de la nature. Une seule idée ne peut suffire je pense pour équilibrer le tout. C'est à mon avis plus complexe que cela. Il n'y a peut être d'ailleurs pas de solution si on écoute certains collapsologues, même si je n'irai pas sur ce terrain.
Facebook et Instagram renvoient leurs jeunes utilisateurs vers des contenus sexistes
"Neutralité algorithmique ?"
Le 29/07/2024 à 16h 10
Le 26/07/2024 à 10h 31
La question est donc de savoir si les réseaux sociaux se contentent d'accompagner une trajectoire de l'utilisateur, ou s'il l'amplifie. Ce n'est pas exactement la même chose, mais c'est sûr que le réseau est responsable dans les deux cas, car on sais déjà qu'il peuvent inhiber les algos et qu'ils le font pour d'autres sujets. L'utilisateur est sans doute responsable au départ de rentrer dans ces trajectoires algorithmiques, mais il peut aussi être influencé par l'algorithme qui lui dit "si si c'est tout à fait normal". Si les pub n'avaient pas d'influence, ça se saurait.[MàJ] La page Wikipédia francophone de la première ministrable du NFP Lucie Castets débattue
Le 24/07/2024 à 16h 49
Merci pour les précisions @tazvld, je suis 100% d'accord avec ce que vous dites et ne le conteste pas. Merci aussi pour m'avoir parlé sans sarcasme d'égal à égal (en tous les cas, c'est comme cela que je l'ai reçu).Ce que vous dites est tout à fait vrai si on l'aborde sur le plan juridique, ou sur le plan des groupes politiques formés dans l'assemblée. Mais ce que je dis vise, sur la base d'une définition conceptuelle trouvée dans les dictionnaires (et non dans la loi), à refléter la même réalité mais du point de vue de l'électeur. Étant donné qu'il est impossible de dire de manière objective si l'électeur a préféré voter pour un parti du NFP plutôt qu'un autre vu qu'il n'avait qu'un seul bulletin NFP (et son programme) a sa disposition, diviser le NFP en plusieurs morceaux est plutôt vain et chimérique politiquement, et dessert le résultat du vote car chaque groupe interne au NFP pourrait un jour dire "oui mais moi, je suis plus légitime". Si ça se trouve, l'électeur se trouve très bien dans un parti du NFP autant que dans un autre, ou si ça se trouve, il a des préférences, mais comment en connaître les proportions ?
D'autre part, on pourrait trouver plusieurs courant au sein d'un même parti avec des élections internes et pour avoir exactement les mêmes problèmes (enfin pas tout à fait, vu que l'on pourrait avoir des tendances avec les pourcentages, mais même des tendances ne permettraient pas de dire si elles s'excluent ou s'assemblent). En définitive, plutôt de s'opposer des subjectivités tout à fait stériles, il convient de dire que le résultat des élections met le NFP en tête. Que j'ai choisi le mot "parti" pour décrire le NFP n'a pas été tout à fait conscient au départ, mais reflétait tout de même une réalité telle que je l'ai décrite et dans les conditions que les ai décrite plus haut.
Enfin, si certains pensent que je suis aveugle à ce qu'ils disent, où que je les ai attendu pour envisager le point de vue qu'il défendent (et qu'ils défendent de manière condescendante), dites vous bien que si vous refusez d'envisager mon angle de vue, j'en ferais autant. Ce n'est que de la réciprocité. Il suffit simplement de changer de ton, et tout ira mieux. Et dans les tons employés, ceux qui veulent jouer sur les mots pour ne pas voir l'essentiel de mon propos initial ne verront en retour qu'un reflet de leur comportement (jouer sur les mots).
Enfin, la réciprocité n'ira pas de mon côté jusqu'au mépris et aux insultes qu'on peut me porter, ça je leur laisse volontiers ce comportement.
Le 24/07/2024 à 13h 26
Le 24/07/2024 à 12h 56
Le 24/07/2024 à 12h 44
Définition de parti :
"Un parti politique est un groupe de personne, réunie en association, autour d'idées politiques communes. Cette organisation politique a pour objectif d'influence l'opinion publique ainsi que les actions du gouvernement en place. Elle propose également des candidats pour les élections. " source : https://www.linternaute.fr/dictionnaire/fr/definition/parti-politique/
Le NFP correspond exactement à cette définition, d'autant que les électeurs ont voté pour un seul bulletin, sans nuance. Je ne m'attendais pas à ce qu'il y ait des personnes qui propagent des fausses nouvelles ici, et qui nient les résultats officiels d'une élection.
Le 24/07/2024 à 12h 21
Le 24/07/2024 à 11h 45
Dire que du point de vue de la connaissance du pays, il ne faut pas parler d'une candidate désignée par le parti majoritaire des dernières élections (historiques ?) sur une encyclopédie qui peut parfois citer et résumer chaque épisode d'une série TV, c'est tout sauf neutre. Penser qu'il y a débat et que ce débat est légitime est assez stupéfiant ! Les partisans de la neutralité de Wikipédia me font bien rire.