votre avatar Abonné

fdorin

est avec nous depuis le 26 mai 2017 ❤️

Bio

Oups.
On dirait que quelqu'un ici aime garder ses petits secrets, comme si de par hasard il y avait quelque chose à cacher...
Désolé, ô lectrice de passage, cher lecteur égaré, pas de révélation sensationnelle pour le moment sur ce profil.
Repassez plus tard ?

2071 commentaires

Aujourd'hui à 00h 49

Vu que le traitement parle des "interactions utilisateurs", il va forcément avoir les noms d'utilisateur puisque le principe est de mentionner le destinataire dans le post. Et ceux-ci sont considérés comme donnée personnelle indirectement identifiante. Voire directe si la personne poste sous sa véritable identité.

Donc cela ne peut être de l'opt-in par défaut.

Mais de toute façon ils s'en foutent. Perso j'ai choisi la solution qui me sied le mieux : refuser d'ouvrir un lien qui va vers ces sites.

Même si cela ne sert pas à grand chose puisque les éviter est quasi impossible. Y compris ici avec des saletés d'intégrations dans les articles.

Je n'ai pas compris "interactions utilisateurs" comme le fait de mentionner un utilisateur, mais comme le fait de lire les tweets d'un utilisateur. Mais peut être que je me trompe.

Après, retirer la mention de l'utilisateur (en gros, "anonymiser") d'un tweet est facile. Il s'agit ici d'entrainer et d'ajuster leur IA. Ce qui importe alors est le contenu, pas les métadonnées.

Encore une fois, cela n'enlève rien au fait que je trouve cette manière de procéder pitoyable. Et je ne cherche pas à les défendre. J'essaie juste de comprendre comment une entité de cette taille et qui est sous surveillance peut se lancer dans ce genre d'initiative alors que le RGPD est entrée en application en Europe depuis 6 ans maintenant et que le moindre écart va être vite sanctionné.

C'est la seule explication "valable" que je vois. On peut voir cela comme une "évolution" des captchas qui ont largement servi à entrainer des modèles d'IA de reconnaissance de texte.

Hier à 18h 49

Juste pour rappel, le RGPD concernent les données à caractère personnel. Toute donnée n'est pas forcément une donnée personnelle.

Je suppose que X et Meta partent du principe qu'un post utilisateur n'est pas a priori une donnée personnelle (même si elle peut éventuellement l'être). Dans le cas contraire, un consentement explicite en opt-in me parait effectivement obligatoire.

Quoi qu'il en soit, cela n'empêche pas cette pratique d'être abjecte.

Hier à 18h 24

Ce soir aura droit dans mon patelin de voir des délégations défiler sur des pénis sur la Seine. Plus rien ne m’étonne.

Sur des penis ? Rahhh les boules :D

Hier à 09h 57

Elle est à combien la barrette chez toi ? :D
(RAM)

Et est-ce que Ness snif quelques paquets parfois ? :D
(TCP)

Hier à 11h 13

J'ai demandé à COPILOT => réponse "il faut une juste mesure entre les bénéfices et effets negatifs"

En bénéfice, la santé était cité. Je lui ai demandé des références d'étude des bénéfices de l'IA sur la santé.
Il ma listé quelque exemple d'utilisation, avec comme source de donnée :
2 entreprises spécialiste dans la vente/promotion d'IA dans le domaine de la santé, et un magazine bidon (l'article sur l'IA perdu au milieu de spoil sur des series TV et autre...)

=> Nous sommes sauvés l'IA à le même niveau de source pour prendre ses décisions que la majorité de la population :D

=> Nous sommes sauvés l'IA à le même niveau de source pour prendre ses décisions que la majorité de la population :D

Pas d'accord. Une part incroyable de la population s'informe uniquement sur les réseaux sociaux maintenant :pleure: :craint:

L'IA reste donc une source plus fiable de ce point de vue :francais:

Hier à 10h 43

Est-ce que la consommation énergétique ne nuit pas a l'homme (Loi n°1) ?

Ca devient vite un bordel cette histoire de loi de la Robotique d'Asimov... Le tout arbitré par l'IA elle même ? :D

J'y ai pensé ^^

Maintenant, la loi 1 fait référence à l'Homme en tant qu'individu, pas en tant qu'espèce.

Mais la loi 0 est inférée à partir de la loi 1, où justement l'Humanité est placée au dessus de l'individu, par Asimov lui-même dans son oeuvre (mais cette loi est beaucoup moins connue que les 3 autres).

Hier à 09h 08

Elle va répondre qu'il faut éteindre les serveurs et s'auto-saborder. :D

Et ne pas respecter la 3e loi de la Robotique d'Asimov :stress:
Un robot doit protéger son existence dans la mesure où cette protection n'entre pas en contradiction avec la première ou la deuxième loi

Hier à 09h 03

Effectivement ma réflexion n'est pas sur le nombre mais le libellé des tickets, qui est assez alarmant : "détecte pas la version installée", "ne gère pas le type d'installeur". ça rejoint entièrement mon ressenti.

Ce sont des problèmes majeurs qui rendent l'outil inutile, et ça fait 1an et demi que ces tickets sont ouverts sans prise en compte. (ça s'est plutôt un bon indicateur je trouve ;-)

Je pense que le qualitatif de daube est assez mérité.

Ce n'est pas un simple problème de métadata mal renseigné par les éditeurs tiers, Notepad (le nouveau), paint 3d produit Microsoft ne sont pas dispo !

En gros, tu vois ce que tu as envie de voir ;)

Juste sur les problèmes de version, pour aptitude (et je n'ai pas fait une recherche exhaustive) :
- Apt downloads arch all packages from wrong repo/checks wrong checksum
- apt-get install segfaults with certain repository configurations
- apt ignores versioned provides if non-matching version is installed via another dep
- [apt-get] build-dep can fail if policy selects candidate version that does not satisfy a versioned dependency
- apt-get autoclean keeps old versions when still provided by some source
- apt-get dumpavail does not print all versions

Donc en appliquant ta logique, je pense que le qualificatif de daube est mérité pour aptitude ;)

Le 24/07/2024 à 10h 20

Acrobat Reader, LibreOffice, Firefox, Gimp: 4 packages significatifs qui ne sont pas ou mal gérés par winget.

Tous étaient en retard de version dans winget, une fois installé au premier lancement chacun de ces softs proposaient leur propre mise à jour à l'exécution. Une fois la mise à jour faite depuis l'appli, winget oublie le soft et ne le propose plus du tout à l'upgrade.

winget ne gère même pas le propre store de Microsoft

winget upgrade --all

tu ouvres le store Microsoft, il trouve pleins de màj que winget n'avait pas vu.

J'ai suivi tes conseils et me suis documenté :
- 991 bugs ouverts
- les 80 bugs uniquement sur la commande upgrade semblent confirmés mon ressenti

Je réagis juste sur la métrique utilisée (le nombre de bogues).

Le nombre de bogue a un instant T ne donne absolument aucune information sur la (non) qualité d'un logiciel. Plus le nombre de bogues est grand, plus le logiciel est utilisé. C'est éventuellement la seule chose que l'on pourrait en déduire.

De plus, bogue dans ce contexte est inapproprié, c'est plutôt ticket qu'il faudrait employer. En effet, des demandes d'évolutions apparaissent aussi en tant que bogue. Et s'il y a des demandes d'évolutions, c'est que le logiciel est aussi utilisé.

Enfin, si le nombre de bogues ouvert reflétait la (non)qualité d'un logiciel, alors aptitude ne fait guère mieux que winget. Faut-il en conclure pour autant que c'est une daube ?

Le 23/07/2024 à 09h 32

On peut certes télécharger en amont les paquets à installer, mais un paquet peut ensuite avoir besoin de ressources complémentaires nécessitant une connexion internet que le gestionnaire de paquets ne pourra pas télécharger lui-même (c'est rare, mais ça arrive).


C'est totalement faux, tous les gestionnaires de paquets connaissent et chargent à l'avance le contenu (éventuellement en // d'un autre install pour gagner du temps). C'est comme ça que les distrib linux ont toujours fonctionné, et c'était absolument impératif à l'époque où les distrib arrivaient en DVD / CD. Sous windows c'est pas du tout le cas, pour beaucoup de soft tu charges en fait un installeur coquille vide qui à son tour va télécharger réellement le logiciel.

Crois ce que tu veux.

Quand le téléchargement est dans un script en hook post-install, ton gestionnaire de paquet ne peut rien faire. Je suis d'accord pour dire que le paquet était mal foutu, mais c'est le paquet fourni par l'éditeur. Donc au bout d'un moment...

Par contre, je n'ai pas souvenir d'avoir eu le problème avec des dépôts officiels. C'était toujours des dépôts tiers.

Hier à 08h 22

1) A minima, pour l'mage de l'entreprise
2) absolument, de nombreuses entreprises et organismes gouvernementaux organisent des audits de ce genre.
3) le nombre de technologies opensource utilisées pour les infrastructures du web et du cloud est un bon indicateur des gains de l'ouverture. En plus, ces dernières années nous avons vu de nombreux leaks de code source applicatif, et quand un code un peut trop obscure est soudainement révélé sans travail préparatoire, ça peut faire très mal.

1) donc non
2) source ? Car beaucoup de solutions non open-source sont également audités
3) le nombre de technologies opensource utilisées pour les infrastructures du web et du cloud est un bon indicateur des gains de l'ouverture en terme de part de marché. Est-ce parce que les solutions sont de qualité ? Peut-être. C'est sans doute un des facteurs. Est-ce parce que les solutions sont généralement gratuites ? Très certainement (ne pas oublier que la sécurité est un parent pauvre dans les entreprises !). Est-ce parce que cela offre une indépendance vis-à-vis du bon vouloir tarifaire des éditeurs ? Aussi (cf. récemment Broadcom et vmware par exemple)

Le 25/07/2024 à 20h 49

Honnêtement, je trouve que c'est plutôt à l'obscurité de prouver sa valeur ajoutée par rapport au préjudice de perdre la possibilité d'avoir de nombreux contrôles indépendants de haut niveau.

Pour le reste, du code consultable mais de mauvaise qualité entrainera plus vite des réactions, quand on joue l'a transparence, on a généralement pas envie de se faire allumer parce-qu’on a laissé du code mal ficelé ici et là parce qu’on était à la bourre. Du code consultable, ça engage systématiquement l'image de l'entreprise.

Je pourrais te dire la même chose concernant la disponibilité des sources :
1) est-ce prouvé que cela augmente la qualité du logiciel ?
2) est-ce prouvé qu'il y aura réellement plus d'audit indépendant ?
3) si avantages il y a, est-ce qu'ils compensent le préjudice que les hackers peuvent trouver en l'examinant directement ?

Le 25/07/2024 à 14h 53

"Sauf que là, on ne parle pas de trouver une faille en tant que telle, mais de comprendre un mécanisme de détection pour éviter de le déclencher. C'est une complexité tout autre."

Eeeeeuuuuuh ... non, pas vraiment. Pas besoin du code source pour ça, il suffit de tester l'application "live" et de soumettre les systèmes à différents types d'attaque pour savoir où attaquer. On a déjà vu des attaques contre des antivirus où le virus en fait était conçu pour provoquer un dépassement de pile dans le moteur de scan de l'antivirus lui-même.

Les bons hackers appliquent la méthode scientifique pour attaquer et s'adaptent à leurs cibles, et les attaques sont d'autant plus facile si la cible développe un sentiment non-justifiée de sécurité en pensant que l'obscurité va constituer un frein majeur pour l'attaquant, quitte à se bander les yeux pour renforcer ce sentiment.

Pour le virus biologique j'ai parlé d'heuristique car le mécanisme de mutation aléatoire est bien conditionné par un système de succès /échec et que ces succès et échecs conditionnent des tendances d'accentuation de traits dans les générations successives. L'évolution peut être rationalisée en un système d'attaques par force brute aléatoires, arbitraires et parallélisées.

"Eeeeeuuuuuh ... non, pas vraiment. Pas besoin du code source pour ça"

Je n'ai jamais dit que le code source était nécessaire. Je dis que l'accès au code source facilite la tâche par rapport à une décompilation ou une analyse de comportement.

"Les bons hackers appliquent la méthode scientifique pour attaquer et s'adaptent à leurs cibles, et les attaques sont d'autant plus facile si la cible développe un sentiment non-justifiée de sécurité en pensant que l'obscurité va constituer un frein majeur pour l'attaquant, quitte à se bander les yeux pour renforcer ce sentiment."

La sécurité ne reposant QUE sur l'obscurité est une hérésie. Là dessus, tout le monde est d'accord. Maintenant, rajouter de l'obscurité complique les choses pour les hackers, aussi bon soient-ils.

Tu pars du principe pour justifier l'ouverture que si le code est ouvert, alors il sera de meilleur qualité. C'est une assertion qui reste à prouver.

"L'évolution peut être rationalisée en un système d'attaques par force brute aléatoires, arbitraires et parallélisées."

On est d'accord. Mais si on peut orienter les recherches pour que ce ne soit plus de l'arbitraire, on gagne en efficacité. Ce qu'un accès au code source permet plus facilement.

Le 25/07/2024 à 12h 01

"La différence majeure que je vois dans ton analogie, c'est qu'en informatique, les pirates et auteurs d'outils malveillants sont intéressés pour connaitre les mécanismes de détection mis en place, afin de pouvoir les contourner / éviter."

ce point a déjà fait l'objet de tant de littérature pour faire simple:

- le code source n'est pas nécessaire pour un attaquant motivé. La grande majorité des vulnérabilités exploitées concernent du logiciel dont le code source n'est pas public.
- le code visible publiquement n'est pas une garantie que l'on identifiera les vulnérabilités mais ça aide
- le code visible publiquement motive par contre les auteurs à en soigner la qualité, question d'image de l'entreprise.

Concernant le virus biologique, il mute continuellement et participe à un jeu de chat et de souris heuristique qui se déroule sur des dizaines de milliers d'années. Le terme technique pour ça est "évolution". Les bactéries suivent le même principe mais s'adaptent encore plus vite, c'est pour cela que l'introduction de contremesures radicales comme les antibiotiques se conclue presque irrémédiablement par l'émergence de bactéries résistantes.

Ce que tu dis est vrai concernant la recherche de failles de sécurité.

Sauf que là, on ne parle pas de trouver une faille en tant que telle, mais de comprendre un mécanisme de détection pour éviter de le déclencher. C'est une complexité tout autre.

Pour le virus biologique, il n'y a aucune "reflexion" de sa part. Il mute (comme tout virus) plus ou moins régulièrement. Si une mutation lui donne un avantage (résistance à un médicament par exemple) et qu'il se trouve en présence d'un contexte dont il peut tirer avantage par rapport aux autres (présence dudit médicament) alors effectivement, il va proliférer, car la concurrence sera éliminée alors que lui non. C'est le principe d'évolution et notamment de la sélection naturelle évoquée par Darwin.

Du coup, le virus ne s'adapte pas en tant que tel (il n'y a aucune volonté). C'est le principe de sélection naturelle. Le hasard.

Si on en revient à son équivalent numérique, un virus détecté par une solution de sécurité, on va avoir plusieurs cas :
- le virus "mute" (nouvelle version) : peut être qu'il passera sous les radars, peut être pas. C'est au petit bonheur la chance
- le virus "mute", mais son créateur connait les mécanismes de défense mis en place par les solutions antivirus et assimilées : il peut "orienter" les mutations pour l'aider à passer outre. C'est beaucoup plus efficace que juste le petit bonheur la chance.

Le 25/07/2024 à 11h 15

C'était des critères généraux, j'ai déjà pu confronter Crowdstrike à ces critères...

Je me permet d'être en désaccord avec ta remarque sur le code source, non ce n'est pas mieux d'avoir le code non audité et sans audit public.

De même, la documentation (je ne parlais pas du code) du produit n'est pas publique et la communauté utilisateur est sous cloche.

Dans l'ensemble c'est juste un nième produit de sécurité développé à la sauvage et qui garde tous ses cadavres sous le tapis. Il faut bien constater que les pratiques des années 90-2000 sont encore très vivaces, par contre les échelles des dégâts sont bien de 2024.

En fait, c'est formidable de voir que dans un domaine où l'adversaire démontre chaque jour des méthodes plus intelligentes et sophistiquées, les entreprises se cramponnent à des approches conservatrice reposant sur une confiance aveugle et ininformée à des entreprises pratiquant le charlatanisme.

On est pas supposés se soigner avec des molécules mystérieuses qui n'auraient pas été documentées et approuvées par des chercheurs et des autorités médicales, mais en informatique tout le monde fait ça tout le temps.

On est pas supposés se soigner avec des molécules mystérieuses qui n'auraient pas été documentées et approuvées par des chercheurs et des autorités médicales, mais en informatique tout le monde fait ça tout le temps.


Je réagis juste sur la fin de ton commentaire (étant plutôt d'accord avec le reste). La différence majeure que je vois dans ton analogie, c'est qu'en informatique, les pirates et auteurs d'outils malveillants sont intéressés pour connaitre les mécanismes de détection mis en place, afin de pouvoir les contourner / éviter.

Un virus (biologique) n'a, à ma connaissance, pas de conscience lui permettant d'agir et d'anticiper en fonction de la molécule qui lui est foutu devant lui.

Ainsi, et malheureusement, c'est un peu le jeu du chat de la souris. Et qu'on le veuille ou non, la fermeture maximale des solutions n'a pas qu'une explication mercantile (ce qui n'enlève pas pour autant cet argument, juste que ce n'est pas le seul) mais aussi une explication d'efficience. C'est triste, mais c'est ainsi.

Le 25/07/2024 à 09h 35

La question c'est "pourquoi linux n'est pas présent dans ces domaines?" alors qu'on sait bien que ca reste redoutablement stable, surtout pour du serveur applicatif... MS trop présent ? Trop de lobbyisme ? Pas assez d'équivalents sur linux pour les logiciels ? Dans les années 80/90 j'aurais pu admettre mais à l'heure des applis web, même les applis .net peuvent se passer de Windows, du coup ca reste inquiétant cette prédominance de Windows un peu partout (et je suis un dev Windows donc c'est pas un parti pris)

De ce que j'ai vu via la panne Crowdstrike (ou en tout cas, ce qui a été montré partout dans les média) se sont de beaux écrans bleus. Donc plutôt du frontend.

Niveau serveur, Linux a une très belle part de marché, supérieure à celle de Windows (il suffit de voir Azure :)).

Effectivement, le côté applis web change un peu la donne, dans le sens où il n'y a plus de dépendance forte à Windows comme auparavant. Mais quand il faut gérer l'inertie (que ce soit des utilisateurs ou des techniciens), l'homogénéité d'un parc (plus facile de ne gérer que du Windows ou qu'une seule version d'une distribution linux que 36000 versions différentes).

Sans compter que quand ça marche, pourquoi changer (coucou les aéroports non affectés qui tournaient sur du Windows 3.1 !)

Et pour les appli .Net, tant qu'elles ne sont pas graphiques oui, elles peuvent se passer de Windows. Avec .NET Maui, on a de bons portages sur Linux possible, mais c'est une techno assez récente (d'un point de vue industriel j'entends) et le support Linux est communautaire et non pas officiel (et ça en freine certains).

PS : je suis aussi dev Windows

Le 24/07/2024 à 17h 11

D'ailleurs on voit vite la différence de traitement dans les médias entre linux (totalement passé à côté des médias mainstream) et win. Ca semblerait prouver aussi que les parts de marché linux restent faibles comparées aux parts de MS.

En même temps, la mise à jour sous Linux n'ayant pas cloué au sol des avions ou reporté des opérations chirurgicales, elle a été beaucoup moins visible par le commun des mortels. C'est peut être ça aussi là cause du traitement radicalement différent entre les deux problèmes...

Après, si cela avait été traité par les médias "classiques", on aurait eu droit à "une mise à jour Linux fait planter tous les systèmes" au lieu d'une mise à jour Windows (et encore, le terme Linux étant inconnu de bon nombre de nos concitoyens, je ne suis même pas sûr que Linux aurait été cité)..

Le 23/07/2024 à 17h 05

"Et si cela implique une réécriture partielle du noyau ? Et de leur solution de sécurité ?

Vu la criticité de la chose, il n'y a rien d'étonnant à ce que cela n'ait pas été fait, sans compter les coûts induits par ce type de réécriture. "

C'est vrai que ce serait vraiment chaud pour une petite boîte comme Microsoft d'assurer une réécriture propre et robuste avec toute la conduite de changement que cela impliquerait auprès des constructeurs de matériel et les éditeurs logiciels concernés de près ou de loin.
Au bas mot, 5 milliards de dollars sur 3 ans...

C'est vrai que MS ne fait que 20 milliards de bénéfices nets par trimestre...

J'avoue que ça me fatigue cet argument. C'est un GAFAM, donc ils peuvent se le permettre car ils ont l'argent. Ce n'est pas comme ça que les choses fonctionnent.

Et franchement, si ça devait couter 5 milliards de dollars sur 3 ans, je prendrais le risque d'amende. Ça couterait moins cher, surtout en faisant trainer les choses !

Le 23/07/2024 à 15h 25

Sans vouloir spécialement taper sur crosoft, mais si pour répondre à la demande de l'Europe, ils avaient fournis des APIs pour accéder au kernel et que les EDR/AV (y compris celui de crosoft) étaient en user space et tapaient sur ces apis, le pb auraient surement été moins violent.
Plutôt que de donner à des tiers des clés trop puissantes, et pas obligatoirement avec toutes les infos nécessaires pour agir à ce niveau.

Et si cela implique une réécriture partielle du noyau ? Et de leur solution de sécurité ?

Vu la criticité de la chose, il n'y a rien d'étonnant à ce que cela n'ait pas été fait, sans compter les coûts induits par ce type de réécriture.

Microsoft n'a pas rien fait non plus, puisqu'il a mis en place un système de qualité pour les drivers en espace noyau.

Je pense qu'à l'époque, personne n'avait songé qu'un pilote puisse se retrouver à faire planter la moitié de la planète en 78 minutes dès lors qu'il était installé. On critique beaucoup Microsoft, mais le problème numéro 1 n'en reste pas moins qu'un fichier de définition en espace utilisateur n'aurait jamais du être capable de faire planter un driver en espace noyau.

Le 23/07/2024 à 13h 54

Les kernels panic du mois dernier ne vont pas trop dans ce sens, sauf à ce que l'utilisation de ces hooks soit récente.

Et dans les commentaires, j'ai trouvé celui-ci très instructif :
ils l'utilisent (NdM: cette nouvelle implémentation), mais l'ancienne implémentation est toujours disponible (et documentée comme l'option à privilégier).


Bref, cela aurait très bien pu arriver sous Linux.

Le 25/07/2024 à 10h 41

Merci. J'ai explosé de rire à la lecture de ton commentaire :)

Le 24/07/2024 à 16h 41

Et bien vraiment pas le genre de matos qu'on verrait dans un film d'action:

Le héro: " - Attends, attends, il ne nous reste plus que 3min avant que tout explose !"

Le Geek: " - Pas de problème, je reboote le serveur et alors on pourra se connecter sur le réseau pour stopper le compte-à-rebours de la bombe"

50min plus tard...

Ha ben soit ils sont tous morts maintenant, soit tous les spectateurs ont déjà quitté la salle depuis longtemps... :mdr2:

Je ne répondrais que par ça : https://www.youtube.com/watch?v=SD-hCyyTv6U xD

Le 24/07/2024 à 14h 54

# C’est des vieux Diesel ou voire même des chaudières à la vapeur les Call Servers (Passerelles VoIP / RTC) de chez Orange (en fait conçus & fabriqués par le sous-traitant Itatel) ?

Pas forcément. Ce genre de truc, c'est sensé rester online 24h/24, 7j/7. Donc il suffit que quand ça démarre, ça lance toute une série de diagnostics pour s'assurer qu'il n'y a pas eu un soucis / panne matériel pour que cela prenne autant de temps.

Le 24/07/2024 à 15h 38

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é.

Retourne jouer avec tes pointeurs (non) NULL et arrête d'écrire des bêtises. Nul n'est plus aveugle que celui qui refuse de voir...

Si le NFP était un parti, alors tu pourrais y adhérer et y prendre une carte. Ce qui n'est pas le cas.

Le 24/07/2024 à 12h 03

Mon incompréhension était sur ce que tu nommes espace utilisateur.

Quand on oppose espace noyau (kernel tout court en anglais) et espace utilisateur (user space), il ne s'agit que du mode dans lequel tournent les programmes, pas du système de fichiers.

Même si les articles Wikipédia sont assez sommaires, surtout en français, mais ils sont assez clairs sur ce point.

J'avoue avoir utilisé ces termes dans un sens peu conventionnel, notamment du point de vue d'un dev.

Je pensais que le contexte général suffirait à comprendre. Il semblerait que non. Mea culpa.

Le 24/07/2024 à 10h 33

- un driver en espace noyau lit un fichier de configuration en espace utilisateur


2 points :
- je ne suis pas sûr de comprendre ce que tu veux dire : tu parles en même temps d'espace noyau et espace utilisateur.
- je ne suis pas sûr que la lecture du fichier de configuration se fasse en espace noyau. On n'a pas l'info, mais je pense que ce n'est pas une pratique habituelle qu'un driver (Windows ou autre) qui tourne en espace noyau lise un fichier (de configuration ici). L'architecture habituelle est qu'un logiciel dans l'espace utilisateur (un service de pilote , si j'ai bien compris le vocabulaire Microsoft) lise le fichier de conf, le décode et fasse un appel au driver pour passer la (nouvelle) configuration. J'ai tendance à penser que c'est plutôt cela qui s'est passé, mais que la nouvelle configuration était mauvaise et que le module l'a utilisée sans de contrôle.

Ça ne changer rien au résultat final quel que soit l'endroit où s'est fait le décodage du fichier.

Alors je vais essayer d'éclaircir.

L'espace noyau, c'est, comme son nom l'indique, l'espace noyau (je sais, Lapalisse n'aurait pas fait mieux). C'est le coeur du kernel de l'OS. C'est le truc qui doit impérativement être hyper stable, sous peine de créer des BSOD ou kernel panic (pour prendre l'équivalent Linux)

L'espace utilisateur, c'est ce qui est externe à l'espace noyau, et que potentiellement, un utilisateur peut modifier. Un fichier sur disque par exemple, c'est de l'espace utilisateur. Le fichier de configuration fait partie de l'espace utilisateur, car réside sur un espace de stockage externe au noyau.

Un driver, avant d'être chargé, est en espace utilisateur. Maintenant, il existe des mécanismes pour assurer l'intégrité du driver entre son chargement et son activation effective au sein de l'espace noyau, pour éviter qu'un driver modifié (=fichier modifié sur le système de fichier) par un utilisateur quelconque ne soit chargé.

L'UEFI, décrié par certains, est un mécanisme qui permet justement d'assurer l'intégrité de l'espace noyau dès le démarrage du système.


Maintenant, que la lecture du fichier de configuration se fasse directement par le noyau ou par un programme utilisateur qui transmet ensuite l'information au driver, qu'importe, le résultat est le même : la configuration est transmise depuis l'espace utilisateur vers l'espace noyau, et doit donc, à ce titre, est (re)validé côté noyau. C'est une règle de base de la sécurité : ne jamais accepter sans vérification une entrée utilisateur (le bogue classique en contexte applicatif "classique" de cette règle étant l'injection SQL).


J'espère avoir été plus clair ;)

Le 24/07/2024 à 10h 06

Par contre, un truc qu'aurait pu faire Microsoft, et cela, sans nécessiter a priori de modification profonde, c'est de détecter ce genre de redémarrages intempestifs pour proposer un démarrage en mode sans échec. Ce qui ne semble pas être le cas ici.
Je suppose que c'est parce que le système avait le temps de booter entièrement.


Mauvaise idée dans ce contexte très précis; des machines business-critical qui tout d'un coup n'ont plus aucune protection et se retrouvent en réseau ? ça aurait été encore plus catastrophique, et Microsoft aurait quand même été vu comme coupable par les semi-habiles qui ne lisent que les titres de journaux.

Quan je dis mode sans échec, c'est un abus de langage. Pour moi, il commence avec le menu présenté au démarrage, où on indique ce que l'on veut faire :
- démarrer normalement
- démarrer en mode sans échec
- démarrer en mode sans échec avec prise en charge réseau
- ouvrir une console
etc.

Mais sinon oui, tu as tout à fait raison : un démarrage en mode sans échec sans intervention de l'utilisateur, c'est une mauvaise idée.

Le 24/07/2024 à 08h 44

Et qui a forcé Linux et BSD à abaisser leur sécu pour que les solutions de sécurité soient au même niveau ?
Une autre solution pour Ms, plutôt que de permettre (forcer) n'importe quelle solution de sécurité (hum - y compris les gestionnaires de DRM) à devenir des rootkits, ça aurait été de mettre SA solution de sécu au niveau des autres au lieu de la mettre dans le noyau... Ou de la partager, si c'est le noyau...
Ou de rendre les solutions plugables dans Hyper-V si on veut un genre de rootkit...

N'importe quel spécialiste pourrait démonter cet argument je pense.

A mon avis, c'est loin d'être aussi simple. Pour créer une API spécifique :
- il faut que tout les besoins soient clairement identifiés (ce qui est difficile dans ce genre de situation)
- très certainement remodelé une partie du coeur même du noyau (opération hautement critique).

Sans compter qu'un des points forts de Microsoft reste la rétrocompatibilité. Faire un tel changement aurait sans doute cassé quelques trucs. Je ne connais pas beaucoup d'OS qui permettent de prendre un programme vieux de 25 ans (par ex. sous Windows 98) et de le faire tourner sur un Windows 10 ou 11 juste en cliquant dessus (et non, Linux ne rentre pas dans cette catégorie, il faudra au mieux recompiler le programme si tant est que l'opération reste possible).

Faire en sorte que sa solution soit au même niveau que les autres, c'est potentiellement abaisser la sécurité globale du système. Pas vraiment souhaitable donc.

Rendre les solutions plugables dans Hyper-V n'aurait pas résolu les problèmes. Pour ce qui est virtualisé, sans doute. Pour le reste non.

Là, on est dans une situation qui est un bel exemple de la Loi de Murphy. La situation a été catastrophique, car :
- le driver est un driver noyau
- la solution est très répandue
- la solution est utilisée dans des infrastructures visibles (aéroports, hopitaux, etc.)
- la gestion de la mise à jour est faite par l'éditeur
- un driver en espace noyau lit un fichier de configuration en espace utilisateur
- l'éditeur pousse une mise à jour d'un fichier de configuration chez tous ses clients en même temps
- les clients n'ont pas vraiment de moyen de contrôler la mise à jour de ce fichier de configuration
- la mise à jour faisait planter quasi-systématiquement le système (au point qu'on se demande si elle a été testé !)

Enlève ne serait-ce qu'un de ces points, et la situation critique que nous avons connu il y a quelques jours n'aurait pas eu lieu.

L'argument avancé par Microsoft peut tout à fait tenir la route (je n'ai pas suffisamment d'éléments pour dire si c'est effectivement le cas ou non). Je dis juste qu'il est tout à fait plausible, et le démonter ne sera pas si facile que ça.

[edit]
Par contre, un truc qu'aurait pu faire Microsoft, et cela, sans nécessiter a priori de modification profonde, c'est de détecter ce genre de redémarrages intempestifs pour proposer un démarrage en mode sans échec. Ce qui ne semble pas être le cas ici.

Je suppose que c'est parce que le système avait le temps de booter entièrement.

Le 23/07/2024 à 10h 26

Une actu arrive sur Next :) (avec une confirmation de Microsoft)

màj : J’en profite puisque @fdorin et @fred42 sont là tous les deux pour un message perso. Si vous voulez toujours qu’on se fasse une petite rencontre sur LR (ou les environs) on peut se programmer ça en aout (je vous laisse me contacter par email ? Sebastien at nom du site, ou nom de l’ancien site comme vous voulez :D)

Ah ben désolé, j'ai spoilé ^^

Au sujet du message perso : toujours partant. C'est juste compliqué depuis quelques mois niveau timing et j'avoue que je n'ai pas mis les pieds à La Rochelle depuis des lustres donc yes, ça me tente bien à la rentrée, quand les touristes seront partis. Et autre détail : je suis "sans voiture" actuellement. J'ai une C3 victime des airbags Takata... :craint:

Le 23/07/2024 à 10h 23

Genre, au hasard, dans OpenSSL ? On pourrait même l’appeler HeartBleed ^^ ?

Par exemple. Même si les conséquences n'étaient pas du tout les mêmes. D'un côté, c'était plutôt l'exfiltration de données. De l'autre, l'arrêt complet, que l'on pourrait presque assimilé à un DOS avec l'arrêt complet de certaines activités !

[edit] Rajout de la partie en italique.

Le 23/07/2024 à 09h 26

Mouais j'avais vu ça. C'est surtout Microsoft qui cherche à se dédouaner en rejetant la faute sur les autres. En tout cas il ne manque pas de culot.

Je ne dis pas que tout est blanc ou tout est noir. Maintenant, qu'une décision vienne amoindrir la sécurité mise en place, c'est tout à fait possible (pour l'avoir vécu, cf. anecdote).

Après, est-ce qu'il ne manque pas de culot ? Je ne dirai pas ça. Vu la couverture médiatique et le manque de professionnel d'un grand nombre de journaliste sur le sujet, qui ont titré, à tord, que la faute incombait à une mise à jour de Windows, j'ai presque envie de dire que c'est normal que Microsoft se défende.

Ils se prennent des critiques de toute part, notamment sur le soi-disant manque de sécurité de Windows (il n'y a qu'à regarder les commentaires sur les articles parlant de Crowdstrike sur Next ces derniers jours pour s'en convaincre).

Si fermer le coeur du noyau implique de se prendre un procès pour abus de position dominante, la société est sensée faire quoi ? On peut ne pas être d'accord, mais je trouve que rappeler que la solution n'est pas qu'un problème technique fait tout à fait sens, surtout dans le contexte actuel.



Anecdote : un client me demandait une fois de mettre en place une fonctionnalité. En tant que consultant externe, je suis "aux ordres" de mon client. Mais je l'ai prévenu : s'il voulait cette fonctionnalité à tout prix, je lui ferai signer une décharge comme quoi je l'avais prévenu que la sécurité de la solution serait amoindri, que je l'avais prévenu, qu'il avait décidé de passer outre mon avertissement et d'en assumer ainsi l'entière responsabilité. Bizarrement, j'ai jamais eu ce papier signé et jamais eu à mettre en place cette fonctionnalité ^^

Le 23/07/2024 à 08h 53

Concernant ce fiasco, je tombe sur cet article assez intéressant : https://www.euronews.com/next/2024/07/22/microsoft-says-eu-to-blame-for-the-worlds-worst-it-outage (désolé, en anglais).

En gros, ce serait en partie de la faute de l'Europe que ce fisco ait pu prendre une telle ampleur, du point de vue de Microsoft. Un accord européen de 2009 obligerait Microsoft à accorder les mêmes droits aux solutions tierces de sécurité pour des raisons de concurrence. Microsoft n'aurait donc pas pu verrouiller autant qu'il le souhaitait le noyau de Windows, en tout cas, pas sans violer cette accord visant à favoriser la libre concurrence...

Point de vue intéressant qui ouvre d'autres perspectives.

Le 23/07/2024 à 08h 40

L'heure de rendre des comptes arrive. J'espère que partout dans le monde cela fait être un peu la même histoire, car le problème n'est pas resté cloisonné aux Etats-Unis.

Sinon, je pense qu'un petit article sur les différentes responsabilités (civil, commercial, pénal, etc.) des éditeurs en cas de problèmes avec leur logiciel, cela sera pas mal. Par exemple, est-il possible de se dédouaner de toutes responsabilités via la licence d'utilisation ? Ou de limiter les dommages et intérêts à un plafond, à la localisation de l'entreprise ou d'un pays ? etc.

En tout cas, je serais très preneur ! Sans oublier l'open source, avec des logiciels qui ont souvent une clause d'absence de garantie. Un logiciel open-source pourrait-il être tenu responsable si un tel fiasco se produisait ? La personne ayant choisi d'utiliser un tel logiciel pourrait-elle alors être tenue responsable ? etc.

Bref, une idée d'article ^^

[edit]
Pour aller plus loin dans l'idée d'article, aborder aussi la notion de compétence. Un client français peut-il attaquer un éditeur américain par exemple ? Si oui, dans quelle condition ? Car par exemple, si l'éditeur américain ne cible que les Etats-Unis, mais que le petit client français achète quand même la solution, c'est radicalement différent de l'éditeur qui va se prendre un .fr, monter un site en français, avoir une filiale en France et faire payer en euro. Et si on inverse les rôles ? Si c'est un éditeur français qui veut être poursuivi par un client américain ? Quel est la juridiction compétente ?

Le 23/07/2024 à 18h 40

Ca mériterait un Strike ce commentaire :mega:

Vincent a abandonné sa sword ? :stress:

Le 23/07/2024 à 18h 24

# pas super convaincu par l'explication de microsoft Intel

Je crois qu'on a tellement vu "plantage de Windows suite à une mise à jour" c'est dernier jours que tous les problèmes ont pour source Microsoft, même quand ça ne concerne que le processeur.

Les plus mauvaises langues diront que c'est la responsabilité de Windows de modifier le voltage pour faire en sorte que le CPU ne plante pas :D

Le 23/07/2024 à 08h 21

Question naïve: quand une grande partie des emplois peu qualifiés seront entièrement automatisés (robots ou IA), tu feras comment pour rémunérer les personnes qui ne pourront plus trouver de jobs ?

On utilisera des IA génératives pour générer des billets pardi !

:pastaper:

Le 22/07/2024 à 16h 05

Vous dites que mon exemple parle de l'entier 0x9C, car l'éditeur de Next.ink a modifié mon texte. Si vous cliquez sur mon lien, vous pourrez constater que mon code de départ parle bien du pointeur qui a l'adresse 0x9c. Mais ce pointeur est bien un entier au final. Cela revient au même.

Et en plus vous avez la malhonnêteté de modifier le code sur onlinedb pour utiliser des pointeurs...

Pas de bol, vous avez oublier de modifier votre commentaire #12.15 qui en reprenait le copier/coller...

Cela en dit long sur votre état d'esprit. Fin de la discussion.

Le 22/07/2024 à 15h 56

Vous dites ici "if (test!=null), mais dans le commentaire d'avant, vous faisiez référence au lien qui donnait ce code
: typedef struct {
int field1;
int field2;
} test_s;

int main()
{
test_s* test = NULL;

printf("Adresse de l'attribut field2 : %lx", (unsigned long int)&(test->field2));

return 0;
}
Or il n'y a pas de "if(test!=null)" dans ce code. Donc on ne parle de pas de la même chose.
Encore une fois, si vous testez :
int main()
{
printf("Hello World");
int v=(int)0x9c;
if (v==NULL)
printf("0x9c est un pointeur NULL");
else
printf("0x9c n'est pas un pointeur NULL");


return 0;
}

Ca m'affiche "0x9c n'est pas un pointeur NULL". Vous pouvez tester le code ici : https://onlinegdb.com/oi9IbrDM5
C'est de ça dont au parlait au début et uniquement de ça. NULL correspond à l'adresse 0, et if "(test!=null)" sera validé si test n'est pas égal à 0, et non pas si test n'est pas égal à 0x9a ce dont on parle dans l'article.

Oui, et ce code était là pour montrer qu'avec un pointeur NULL, on pouvait facilement accéder à un espace mémoire non nul, en montrant l'adresse en mémoire d'un des attributs de la structure.

Un code qui génère un accès non autorisé à une adresse très très basse (du style de 0x9C) a de très forte chance d'être provoqué par le déréférencement d'un pointeur NULL, dont un simple test if (v != NULL) protège. Ce n'est pas l'unique possibilité d'avoir ce genre d'erreurs, mais dans la grande majorité des cas, c'est ça.

Donc l'article parle bien de l'adresse 0x9C. Un accès à ce type d'adresse est très majoritairement dû à l'usage non testé d'un pointeur NULL (le fameux déréférencement). Donc, le test proposé par Wosgien (qui protège contre le déréférencement d'un pointeur NULL) sera efficace dans la grande majorité des cas.

Maintenant, et sans vouloir être désagréable, notre échange m'indique clairement que vous n'êtes pas développeur (ou si c'est le cas, j'en suis désolé, mais vous avez de grave lacune sur la notion de pointeur). Dans les deux cas, il me parait inutile de continuer ce dialogue de sourd.

Le 22/07/2024 à 15h 36

Concernant l'argument d'autorité, je ne vois pas le rapport ! J'ai donné un exemple qui explicitait ce que je disais. Si vous êtes compétent, vous devriez comprendre mon propos. Si vous parlez d'autre chose, je ne peux rien pour vous, car nous allons avoir un dialogue de sourd, et cette conversation ne sert à rien. Partez de "if (v!=null)" qui est l'exemple donné plus haut par Wogien que j'ai contredis.

Votre exemple ne dit rien du tout. Votre exemple dit que l'entier 0x9C est différent de 0 (et je dis bien entier, pas pointeur). Ce qui est d'une évidence qu'il n'est même pas besoin de souligner.
Partez de "if (v!=null)" qui est l'exemple donné plus haut par Wogien que j'ai contredis.


Cf. mon commentaire #12.5

Le 22/07/2024 à 15h 25

Mais dans l'exemple que vous donnez, il n'y a pas "if (v!=null)", pourtant c'est de ça dont parlait "Wogien" plus haut. Si vous parlez d'autre chose, je ne peux pas vous répondre puisqu'on parlait pas de ça au départ.

if (test != null) {
test->machin++;
}

Alors c'est pas "v", mais "test", mais je parlais bien de ça depuis le début... Cf. mon commentaire #12.5

Le 22/07/2024 à 15h 09

Je viens de vérifier avec ce code :
`
int main()
{
printf("Hello World");
int v=(int)0x9c;
if (v==NULL)
printf("0x9c est un pointeur NULL");
else
printf("0x9c n'est pas un pointeur NULL");


return 0;
}
`
Ca m'affiche "0x9c n'est pas un pointeur NULL". Vous pouvez tester le code ici : https://onlinegdb.com/oi9IbrDM5
Donc je dirais que vous avez tous les deux tord.

Relis l'exemple de code que je t'ai donné. Je te parle de déréférencement de pointeur. Le problème n'est pas d'accéder au pointeur, mais à un des attributs de la structure pointée par le pointeur (sans compter que ton code ne manipule pas de pointeurs, juste des entiers).

https://onlinegdb.com/03Sut0yrO
Donc je dirais que vous avez tous les deux tord.


Je vais utiliser un argument d'autorité, même si je n'aime pas ça : ça fait plus de 30 ans que je développe et au moins 25 que je fais du C plus ou moins régulièrement, dont de la programmation système et sur système embarqué.

Donc oui, je suis sûr de mon coup et tu te trompes. Ce que je t'énonce là, cela fait partie de la base du C.

Le 22/07/2024 à 14h 06

D'autre part, vous proposez des tests pour éviter le problème dans le code en production, mais vous ne pouvez pas faire un try/catch à chaque fois que vous lisez une variable. Et même si vous le faites, il faut vous attendre à deux catégories de problèmes ; les exceptions (ouvrir un fichier qui n'existe pas), ou les erreurs (arriver à un état du programme qui n'aurait pas du arriver). A moins de considérer qu'une mauvaise adresse mémoire pointé par une variable soit un comportement normal, il s'agit au tout état de cause d'une erreur et non d'une exception. Dans ce cas, quand un programme génère une erreur, il faut laisser le programme planter et ne surtout pas continuer l'exécution pour éviter qu'un comportement improbable (et pire) ne se produise. Donc même si vous faites un try/catch, si ça ne doit pas arriver, il faut quand même terminer le programme. Le try/cath ne servirait dans cet exemple qu'à journaliser la trace de l'erreur et/ou à fermer correctement les verrous obtenus sur le système.

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, ce qui pose problème quand on test le programme, que le test est validé dans un environnement et que l'erreur se produit quand même quand l'environnement et la configuration mémoire du programme changent, i.e. lorsque le programme passe en production. Ce type de problèmes intempestifs ne se produit pas dans d'autres langages de programmation, où la gestion de la mémoire est plus cadrée. Maintenant, je n'ai pas dit que c'est ceci qui s'est passé dans le cas de cet article d'où le "peut-être" dans mon premier commentaire.

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.

Le 22/07/2024 à 13h 41

Mais dans l'article, on parle bien de l'adresse 0x9c et non de NULL (qui est représenté par 0 si ma mémoire est bonne). Ici 0x9c pointe vers la page 0 si j'ai bien compris et qui n'est pas à l'adresse 0 dans la mémoire. Du coup votre test if (v!=null) ne devrait pas passer.

Il a pourtant raison. Bien que l'adresse 0x9C ne soit pas une adresse nulle, cela ressemble fortement au déréférencement d'un pointeur NULL.

Exemple :
`
if (test != null) {
test->machin++;
}
`

test est une structure plus ou moins complexe, dont l'adresse de base est représentée par la valeur contenue dans test, et dont chaque champs ce déduit ensuite à partir de cette valeur de base.

Maintenant, ce n'est pas parce que cela ressemble a un pointeur NULL que c'est effectivement le cas. Ce n'est pas la seule chose qui puisse provoquer ce genre de comportement.

Le 20/07/2024 à 17h 58

Rust est dans le noyau et il peut-être utilisé. Certains drivers pour des FS ou bien pour le scheduler l'utilse. Mais très généralement ce n'est qu'un wrapper sur les fonctions importantes du kernel.

Pour moi, Rust n'a pas le choix de devoir résoudre ce problème. S'il ne peut pas s'intégrer au noyau Linux (autrement qu'en étant un wrapper), alors perdra un certains coté promotionnel. Mais oui ce n'est pas gagné pour eux.

Exact ZigBee n'est pas le langage. C'est Zig que je voulais mentionner. My bad, il fait trop chaud dans ce pays, con !

Rust est dans le noyau et il peut-être utilisé. Certains drivers pour des FS ou bien pour le scheduler l'utilse. Mais très généralement ce n'est qu'un wrapper sur les fonctions importantes du kernel.


Tout à fait, ce qui en limite grandement les avantages.
Pour moi, Rust n'a pas le choix de devoir résoudre ce problème. S'il ne peut pas s'intégrer au noyau Linux (autrement qu'en étant un wrapper), alors perdra un certains coté promotionnel. Mais oui ce n'est pas gagné pour eux.


C'est même pas le côté promotionnel. C'est juste que Rust n'aura alors AUCUN intérêt a être utilisé au sein du noyau. Pire, on se retrouvera avec des portions écrites en Rust, d'autre en C. 2 langages au lieu d'un, sans avantage. Chouette :/
Exact ZigBee n'est pas le langage. C'est Zig que je voulais mentionner. My bad, il fait trop chaud dans ce pays, con !


Ah oui, Zig. J'étais tombé dessus il y a quelques mois. Mais je ne me suis pas penché dessus de manière approfondi (faut dire que si on devait se pencher sur tous les langages et toutes les technos qui sortent, on ne serait pas sorti de l'auberge :mdr:). J'avais regardé rapidement, j'ai vu un Rust like, la notoriété en moins (sans vouloir dénigrer le langage)

Le 20/07/2024 à 17h 37

Même si je n'aime pas ce langage, je pense que Rust est une réponse possible. Et peut-être prochainement ZigBee.

Il y a eu des tentatives au niveau du noyau Linux pour utiliser Rust. Mais se pose des problèmes avec le modèle de gestion de la mémoire qui est radicalement différent et incompatible en l'état. Je ne sais pas si cela sera possible de résoudre ce problème ou pas.

Zigbee, je ne connais pas ce langage. Pour moi, c'est un protocole de communication. Et je ne trouve pas de référence en tant que langage. Tu es sûr ?

Le 22/07/2024 à 09h 47

L'amstrad CPC avait un bug dans sa rom, pour une des fonctions du basic il ne fallait pas fermer la parenthèse.
Amstrad a tout géré à la Amstrad: correction (manuelle au début) du mode d'emploi pour l'indiquer.

Ah ? C'était quoi ? Quelle version ? J'ai eu un CPC 6128 et pas de souvenir de ce bogue, que ce soit sur la machine ou dans le manuel.

Le 20/07/2024 à 17h 48

j'ai trouvé ce pseudo en utilisant ChatGPT4



"est avec nous depuis le 6 décembre 2004"

Salut à toi, voyageur temporel

ou il a juste changé son pseudo (et oui, on peut :p)

Le 20/07/2024 à 16h 24

Cela aurait pu arriver à un Avast


La nana d'Avast a trop fait faire d'arrêts cardiaques aux gentils geeks qui avaient laissé leurs HP à donf :D

Je me souviendrais toujours d'une fois où j'ai littéralement failli me pisser dessus à cause de ça.

C'était début des années 2000, je jouais à Silent Hill premier du nom genre à 2h du mat. Suspens à son paroxisme (c'était la première fois que j'y jouais ^^). J'étais dans l'école, le son à fond pour épier le moindre bruit.

Quand soudain...

VOTRE BASE DE DONNEES VIRALE A BIEN ETE MISE A JOUR



Le 20/07/2024 à 15h 03

Courage, de tout coeur avec toi

Merci. Le seul truc qui est pénible, c'est que les logs ne montrent rien donc je cherche un peu dans le vide :duel1:

Le 20/07/2024 à 13h 38

Allez je termine la pelouse et je vais me replonger dans mon installation iredmail
Parce qu’effectivement c’est bien cela

Et un problème de résolu un \o/

Bon, maintenant, je vais m'occuper de mon problème avec Nginx :stress:
1 2 … 41 42