Les dévelopeurs qui utilisent l'IA ouvrent 40% de pull requests en plus. Mais leur code est 1.5 fois plus gros, crée 9% de bugs en plus, et le temps de revue des merge requests augmente, ce qui annule les gains lors du développement.
Le reste de l'étude essaie de noyer ces problèmes dans du blabla sur l'amélioration des process pour gagner en productvité (gains qui pourraient hrobablement être mis en place même sans utiliser d'IA pour écrire du gode plus gros et avec plus de bug).
Avec les boîtiers 'télécommande' à l'ancienne, il y a un mode "signature". La page web de confirmation affiche par exemple un RIB pour un ajout de bénéficiaire de virement. Elle surligne 8 chiffres du RIB et de la date-heure de demande choisis au hasard. Il faut alors entrer ces chiffres dans la télécommande et recopier la réponse sur le site.
On a donc le contexte, et en en recopiant un petit morceau dans la télécommande, on confirme que le contexte est bien celui pour lequel on signe l'opération.
Si on a une "télécommande" un peu plus high tech, il suffit d'y ajouter un lecteur de QR code qui permet d'y transférer et afficher le contexte entier afin de le valider, et ce, sans accès internet.
Cependant, ça veut dire fabriquer des gadgets plastique et électronique dont on a peut-être pas vraiment besoin. Une solution purement logicielle est plus écologique.
ça parle toujours d'écrire plus de code, plus vite.
Comme le dit Cory Doctorrow, c'est comme se vanter d'avoir créé "l'avion le plus lourd du monde". C'est prendre le problème à l'envers.
Mon travail ce n'est pas d'écrire du code. Le code est un outil. C'est lui qui me permet de formaliser ce qu'un ordinateur doit faire, de façon précise et non ambiguë. Le travail d'écriture du code me force à réfléchir aux choses dans les moindres détails, et à mettre en évidence les choses qui sont incohérentes ou pas claire dans ce qu'on m'a demandé de faire.
C'est cette étape que l'utilisation des LLM pour générer du code essaie de supprimer. Donnons directement les spécifications en langage naturel, ambiguës, incomplètes, contradictoires, à l'ordinateur. Il saura bien se débrouiller avec. Et en plus, il ne dit jamais "non, c'est n'importe quoi, ça marchera pas" comme un développeur ronchon.
La question qu'il faut se poser, c'est plutôt si votre travail était d'écrire du code pour des problèmes qui étaient déjà résolus. Peut être que votre application est juste un clone de celle de votre concurrent. Peut-être que vous êtes juste développeur et que l'architecte du projet vous a déjà tout parfaitement spécifié et qu'il n'y a plus aucune question lors de l'écriture du code. Auquel cas, effectivement, peut-être que c'est entièrement automatisable. Mais votre métier devait déjà être terriblement ennuyeux avant l'arrivée des LLM, non?
Les versions "mineures" de Python 3 cassent régulièrement des trucs. Ça se fait petit à petit mais en continu, ce qui facilite la migration en lissant la charge de travail.
En C++, selon le compilateur utilisé, l'utilisation de nouvelles versions du compilateur ne se fait pas non plus les yeux fermés, il y a de nouveaux warnings à corriger, des choses qui sont retirées du standard C++, des optimisations qui font que du code qui fonctionnait avant ne fonctionne plus, …
Rust est trop jeune pour avoir ce genre de problème mais je n'ai aucun doute qu'il y aura un jour un Rust 2.0 aussi.
Maintenir la compatibilité pwndant plusieurs dizaines d'années, ce n'est pas facile, et l'environnement évolue aussi (passage au 64 bit par exemple, mais aussi plus simplement des pratiques de développement). Tous les langages doivent s'adapter, chacun a sa façon.
Les deux banques pour lesquelles j'ai l'application installée sur mon Android 8 affichent à chaque démarrage desdites applications un avertissement comme quoi cette version du système n'est plus supportée.
Il y a plusieurs fois eu des mises à jour qui font planter l'application. Pour l'instant il y a encore assez de gens pour se plaindre et les faire réparer le problème, mais ça ne va probablement pas durer très longtemps.
Cela dit, on est bien au-delà des 3 à 5 ans. Mais je n'ai aucune autre raison de changer mon téléphone. Quand ça deviendra vraiment compliqué pour ces applications ou d'autres, je pourrai encore prolonger en passant sous Lineage OS.
Musk m’a expliqué que l’idée est née de sa haine pour le projet de train à grande vitesse californien. À l’époque, il apparaissait que Musk avait présenté la proposition Hyperloop dans le seul but d’inciter le public et les législateurs à remettre en question le train à grande vitesse. Il n’avait pas l’intention de le construire.
Et j'ai trouvé la réponse pour cette histoire de datacwnters dans l'espace: lwintroduction en bourse de SpaceX est hour bientôt. Tout est bon pour gonfler le prix des actions juste avant leur mise en vente.
Et effectivement ce n'est arrivé dans Turbo Pascal que bien plus tard. J'imagine que cela contribue à la réputation de "jouet" du langage Pascal, qui pourtant a beaucoup évolué depuis ses toutes premières versions qui étaient effectivement assez limitées (le Pascal original par des fonctionalités manquantes, puis l'USCD Pascal par son approche avec un interpréteur p-Code, assez lent par rapport à l'exécution directe).
à vrai dire les problèmes de mémoire du C étaient réglés avant même l'invention du C. C'est amusant (mais un peu déprimant) de lire les articles datant des années 60 et 70 où les développeurs LISP se plaignent déjà de l'attitude des programmeurs assembleur, et de voir qu'aujourd'hui, c'est Rust d'un côté et C de l'autre, mais qu'au fond, rien n'a changé.
Il y avait d'autres problèmes à l'époque. Pour Pascal, en particulier, il n'y avait au départ ps de linker, tout le programme devait donc tenir dans un seul fichier. Cela a été corrigé par Modula et Modula 2, mais comme les développeurs n'aiment pas apprendre un nouveau langage, la notion d'unités de compilation (des modules, mais pas vraiment) a été ajoutée par exemple dans Turbo Pascal.
Sinon, si on veut du strict, on peut programmer en Ada. C'est un peu comme Rust: il y a un mode unsafe, et quand on s'en sert, on peut faire exploser une fusée de façon spectaculaire sous les yeux du président de la république.
ça parle pourtant de dissipation thermique, de puissance de calcul embarquée, de résistance aux radiations, d'alimentation en électricité…
Donc la question est bien "est-ce que c'est possible". Question raisonable avec Elon Musk, qui a publiquement admis avoir lancé le délire de l'Hyperloop juste pour occuper la scène et empêcher le développement du train à grande vitesse aux USA, ceci afin de vendre plus de voitures.
La question "est-ce que c'est possible" ayant une réponse qui est plutôt non, on peut maintenant se demander ce que Elon Musk essaie de vendre cette fois-ci?
Même quand les composants sont standardisés, la gestion de l'obsolescence en électronique c'est compliqué.
Par exemple, dans un de mes anciens projets, l'équipe responsable du matériel avait remplacé la puce de mémoire flash utilisée. Il s'agit d'un composant assez bien standardisé, ils ont donc trouvé un autre composant chez un autre fabricant, avec le même brochage et des timings équivalents ou plus rapide. Les tests se sont bien passés et le composant a été utilisé pour produire plusieurs machines.
Cependant, quelques semaines plus tard, en sortant ces machines du stock pour les déployer chez des clients, on s'apperçoit que le logiciel ne fonctionne plus! Après enquête, on finit par comprendre que quelques bits se sont effacés de la mémoire.
Une comparaison plus attentive des datasheets des deux composants a fini par révéler que les garanties sur le nombre de bits défectueux par bloc de mémoire étaient très différents entre les deux puces. Il a donc fallu modifier notre logiciel pour utiliser un algorithme correcteur d'erreur plus performant, capable de corriger ces erreurs plus nombreuses pour utiliser cette nouvelle mémoire de façon fiable.
Avec la difficulté de devoir migrer les machines existantes et déjà déployées avant la détection du problème (lecture et reprogrammation de la flash avec le nouveau code correcteur d'erreur par le bootloader), de devoir mettre à jour les outils de production pour écrire la flash sur les nouvelles machines produites directement avec le code d'erreur robuste, la gestion dans le code des deux versions du matériel avec les deux types de correction d'erreur (le nouveau utilisait du support matériel de la nouvelle puce de flash et ne pouvait donc pas être déployé sur l'ancienne carte), …
Dans d'autres cas (par exemple des microcontrôleurs, où le remplacement nécessiterait une réécriture complète du firmware), le plus simple était de réagir à l'annonce d'obsolescence et d'acheter un gros stock de composants pour les années à venir. Si le volume de production est relativement faible et le composant pas très cher, les quelques milliers d'euros nécessaires pour ça vont être bien inférieurs au coût de conception d'un nouveau firmware et d'une nouvelle électronique.
Plus récemment dans un autre projet, c'est un changement de référence sur une simple diode qui a causé un changement de comportement du matériel. Je n'ai pas tous les détails car je ne suis pas responsable du matériel sur ce projet. Mais il y a une série de matériel avec la "mauvaise" diode sur laquelle une partie du circuit électronique ne fonctionne pas. Le moindre changement doit donc être validé avec tout le périmètre matériel et logiciel, et aussi dans toutes les conditions de température, humidité, …
On comprend peut-être un peu mieux pourquoi les fabricants de téléphones préfèrent sortir régulièrement de nouveaux modèles plutôt que de faire ce type de micro mise à jour qui peut coûter presque aussi cher que de repartir de zéro.
On dit plutôt ordonnanceur en français il me semble.
Pour les périodes rétrogrades, la traduction me semble bien (ce sont les périodes ou visuellement les planètes se déplacent dans le ciel dans le sens "inverse", ce qui semblait très complexe avant qu'on ne comprenne le modèle héliocentrique du système solaire, mais la question est résolue depuis Copernic et Kepler il y a presque un demi millénaire de ça); pour la Lune je pense qu'on parle plutôt de phases de la Lune (pleine Lune, croissante, décroissante, etc).
Si on croit ou qu'on a envie de croire à l'astrologie et à l'importance des alignements de planètes (hors missions de type Voyager), on peut installer un ordonnanceur qui tient compte de ces paramètres dans son noyau Linux.
C'est surtout un problème de topologie: les prises de téléphones sont en "daisy chain": un seul câble fait tout le tour de la maison et va d'une prise à la suivante.
Pour de l'ethernet gigabit, et surtout pour de la fibre, il faut un réseau en étoile avec tous les câbles qui convergent vers un concentrateur (switch ethernet).
Ce qui de,ande un peu plus de travaux que simplement recâbler la maison, il faut probablement passer de nouvelles gaines qui vont directement de chaque prise à l'endroit où on veut installer le commutateur.
En France on est passé sur un câblage centralisé (dans l'armoire électrique en général) pour les logements neufs depuis déjà quelques temps. Il y a même des prises électriques disponibles pour y installer des équipements actifs (ONT, modem/box internet, switch, …)
[^] # Re: POGAM, c'est très bien
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Se défendre contre l'IA générative. Évalué à 5 (+2/-0).
Je propose ChatGPT, Copilot, Claude et Perplexity, ou CCCP
[^] # Re: POGAM, c'est très bien
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Se défendre contre l'IA générative. Évalué à 6 (+3/-0).
Il y a déjà BATX pour désigner les entreprises chinoises de la tech, mais c'est vrai qu'on en entend moins souvent parler par ici.
Et pour les GAFAM, comme Google s'appelle Alphabet et Facebook s'appelle Meta, l'acronyme n'est de toutes façons plus "bon".
[^] # Re: Chiffre éloquent
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Des appels malveillants venant de "masculinistes" saturent la ligne d’écoute du 3919 (N° pour les femmes victimes de violences). Évalué à 6 (+3/-0).
J'avais la ref, mais j'ai moinssé quand même parce que j'ai trouvé ça pas drôle.
# Résumé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien AI Coding Assistants ROI Study: Measuring Developer Productivity Gains. Évalué à 10 (+8/-0).
Les dévelopeurs qui utilisent l'IA ouvrent 40% de pull requests en plus. Mais leur code est 1.5 fois plus gros, crée 9% de bugs en plus, et le temps de revue des merge requests augmente, ce qui annule les gains lors du développement.
Le reste de l'étude essaie de noyer ces problèmes dans du blabla sur l'amélioration des process pour gagner en productvité (gains qui pourraient hrobablement être mis en place même sans utiliser d'IA pour écrire du gode plus gros et avec plus de bug).
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 6 (+3/-0).
Même pas besoin en fait.
Avec les boîtiers 'télécommande' à l'ancienne, il y a un mode "signature". La page web de confirmation affiche par exemple un RIB pour un ajout de bénéficiaire de virement. Elle surligne 8 chiffres du RIB et de la date-heure de demande choisis au hasard. Il faut alors entrer ces chiffres dans la télécommande et recopier la réponse sur le site.
On a donc le contexte, et en en recopiant un petit morceau dans la télécommande, on confirme que le contexte est bien celui pour lequel on signe l'opération.
Si on a une "télécommande" un peu plus high tech, il suffit d'y ajouter un lecteur de QR code qui permet d'y transférer et afficher le contexte entier afin de le valider, et ce, sans accès internet.
Cependant, ça veut dire fabriquer des gadgets plastique et électronique dont on a peut-être pas vraiment besoin. Une solution purement logicielle est plus écologique.
[^] # Re: CIC
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 3 (+0/-0).
Oui je sais, c'est pour ça que je retarde ça autant que possible…
Avec un peu de chance mon téléphone sera cassé pour une raison matérielle avant d'en arriver là, en j'en rachèterai un moins dépassé.
[^] # Re: Encore du FOMO
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Nous pleurons notre métier : Le pire avec ces outils d'IA, c'est qu'ils fonctionnent, ils peuvent écrire du code mieux que vous ou moi. Évalué à 10 (+13/-0).
ça parle toujours d'écrire plus de code, plus vite.
Comme le dit Cory Doctorrow, c'est comme se vanter d'avoir créé "l'avion le plus lourd du monde". C'est prendre le problème à l'envers.
Mon travail ce n'est pas d'écrire du code. Le code est un outil. C'est lui qui me permet de formaliser ce qu'un ordinateur doit faire, de façon précise et non ambiguë. Le travail d'écriture du code me force à réfléchir aux choses dans les moindres détails, et à mettre en évidence les choses qui sont incohérentes ou pas claire dans ce qu'on m'a demandé de faire.
C'est cette étape que l'utilisation des LLM pour générer du code essaie de supprimer. Donnons directement les spécifications en langage naturel, ambiguës, incomplètes, contradictoires, à l'ordinateur. Il saura bien se débrouiller avec. Et en plus, il ne dit jamais "non, c'est n'importe quoi, ça marchera pas" comme un développeur ronchon.
La question qu'il faut se poser, c'est plutôt si votre travail était d'écrire du code pour des problèmes qui étaient déjà résolus. Peut être que votre application est juste un clone de celle de votre concurrent. Peut-être que vous êtes juste développeur et que l'architecte du projet vous a déjà tout parfaitement spécifié et qu'il n'y a plus aucune question lors de l'écriture du code. Auquel cas, effectivement, peut-être que c'est entièrement automatisable. Mais votre métier devait déjà être terriblement ennuyeux avant l'arrivée des LLM, non?
[^] # Re: Langage pro
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la rigueur dans la programmation. Évalué à 8 (+5/-0).
Les versions "mineures" de Python 3 cassent régulièrement des trucs. Ça se fait petit à petit mais en continu, ce qui facilite la migration en lissant la charge de travail.
En C++, selon le compilateur utilisé, l'utilisation de nouvelles versions du compilateur ne se fait pas non plus les yeux fermés, il y a de nouveaux warnings à corriger, des choses qui sont retirées du standard C++, des optimisations qui font que du code qui fonctionnait avant ne fonctionne plus, …
Rust est trop jeune pour avoir ce genre de problème mais je n'ai aucun doute qu'il y aura un jour un Rust 2.0 aussi.
Maintenir la compatibilité pwndant plusieurs dizaines d'années, ce n'est pas facile, et l'environnement évolue aussi (passage au 64 bit par exemple, mais aussi plus simplement des pratiques de développement). Tous les langages doivent s'adapter, chacun a sa façon.
[^] # Re: CIC
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 7 (+4/-0).
Les deux banques pour lesquelles j'ai l'application installée sur mon Android 8 affichent à chaque démarrage desdites applications un avertissement comme quoi cette version du système n'est plus supportée.
Il y a plusieurs fois eu des mises à jour qui font planter l'application. Pour l'instant il y a encore assez de gens pour se plaindre et les faire réparer le problème, mais ça ne va probablement pas durer très longtemps.
Cela dit, on est bien au-delà des 3 à 5 ans. Mais je n'ai aucune autre raison de changer mon téléphone. Quand ça deviendra vraiment compliqué pour ces applications ou d'autres, je pourrai encore prolonger en passant sous Lineage OS.
[^] # Re: markdown pas assez strict
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la rigueur dans la programmation. Évalué à 6 (+3/-0).
C'est ce qui arrive quand on ne met pas son interpréteur Markdown en mode strict!
[^] # Re: C'est mieux en lisant l'article
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Pourrait-on faire fonctionner des data centers dans l’espace ?. Évalué à 5 (+2/-0).
https://reporterre.net/Hyperloop-la-grande-entourloupe-d-Elon-Musk cite le biographe d'Elon Musk par exmple:
Et j'ai trouvé la réponse pour cette histoire de datacwnters dans l'espace: lwintroduction en bourse de SpaceX est hour bientôt. Tout est bon pour gonfler le prix des actions juste avant leur mise en vente.
[^] # Re: La suite , la suite ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la rigueur dans la programmation. Évalué à 6 (+3/-0).
La chronologie semble être:
Pascal (1970) -> Modula (1975) -> USCD Pascal (1977) -> Modula 2 (1978).
Et effectivement ce n'est arrivé dans Turbo Pascal que bien plus tard. J'imagine que cela contribue à la réputation de "jouet" du langage Pascal, qui pourtant a beaucoup évolué depuis ses toutes premières versions qui étaient effectivement assez limitées (le Pascal original par des fonctionalités manquantes, puis l'USCD Pascal par son approche avec un interpréteur p-Code, assez lent par rapport à l'exécution directe).
[^] # Re: La suite , la suite ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la rigueur dans la programmation. Évalué à 7 (+4/-0).
à vrai dire les problèmes de mémoire du C étaient réglés avant même l'invention du C. C'est amusant (mais un peu déprimant) de lire les articles datant des années 60 et 70 où les développeurs LISP se plaignent déjà de l'attitude des programmeurs assembleur, et de voir qu'aujourd'hui, c'est Rust d'un côté et C de l'autre, mais qu'au fond, rien n'a changé.
# C++
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la rigueur dans la programmation. Évalué à 8 (+5/-0).
Je m'attendais à lire ça dans l'article et je ne l'ai pas vu:
[^] # Re: La suite , la suite ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la rigueur dans la programmation. Évalué à 9 (+6/-0).
Il y avait d'autres problèmes à l'époque. Pour Pascal, en particulier, il n'y avait au départ ps de linker, tout le programme devait donc tenir dans un seul fichier. Cela a été corrigé par Modula et Modula 2, mais comme les développeurs n'aiment pas apprendre un nouveau langage, la notion d'unités de compilation (des modules, mais pas vraiment) a été ajoutée par exemple dans Turbo Pascal.
Sinon, si on veut du strict, on peut programmer en Ada. C'est un peu comme Rust: il y a un mode unsafe, et quand on s'en sert, on peut faire exploser une fusée de façon spectaculaire sous les yeux du président de la république.
[^] # C'est mieux en lisant l'article
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Pourrait-on faire fonctionner des data centers dans l’espace ?. Évalué à 8 (+5/-0).
ça parle pourtant de dissipation thermique, de puissance de calcul embarquée, de résistance aux radiations, d'alimentation en électricité…
Donc la question est bien "est-ce que c'est possible". Question raisonable avec Elon Musk, qui a publiquement admis avoir lancé le délire de l'Hyperloop juste pour occuper la scène et empêcher le développement du train à grande vitesse aux USA, ceci afin de vendre plus de voitures.
La question "est-ce que c'est possible" ayant une réponse qui est plutôt non, on peut maintenant se demander ce que Elon Musk essaie de vendre cette fois-ci?
[^] # Re: Flash
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal find / -type f -name '*.fla' -delete. Évalué à 4 (+5/-4).
Et c'est pas avec une attitude condescendante comme ça qu'on va les convaincre de passer à du logiciel libre.
Parfois ça ne suffit pas d'avoir raison…
[^] # Re: Toujours pas convaincu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Retour d'expérience sur le développement d'une application par l'utilisation d'IA. Évalué à 3 (+0/-0).
Il y a un site web pour ça avec une équipe de canards en plastique prêts à répondre à toutes les questions pour beaucoup moins cher qu'un LLM.
[^] # Re: Projet FAMES sur le site du CEA
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La France va produire des processeurs. Évalué à 7 (+4/-0).
Même quand les composants sont standardisés, la gestion de l'obsolescence en électronique c'est compliqué.
Par exemple, dans un de mes anciens projets, l'équipe responsable du matériel avait remplacé la puce de mémoire flash utilisée. Il s'agit d'un composant assez bien standardisé, ils ont donc trouvé un autre composant chez un autre fabricant, avec le même brochage et des timings équivalents ou plus rapide. Les tests se sont bien passés et le composant a été utilisé pour produire plusieurs machines.
Cependant, quelques semaines plus tard, en sortant ces machines du stock pour les déployer chez des clients, on s'apperçoit que le logiciel ne fonctionne plus! Après enquête, on finit par comprendre que quelques bits se sont effacés de la mémoire.
Une comparaison plus attentive des datasheets des deux composants a fini par révéler que les garanties sur le nombre de bits défectueux par bloc de mémoire étaient très différents entre les deux puces. Il a donc fallu modifier notre logiciel pour utiliser un algorithme correcteur d'erreur plus performant, capable de corriger ces erreurs plus nombreuses pour utiliser cette nouvelle mémoire de façon fiable.
Avec la difficulté de devoir migrer les machines existantes et déjà déployées avant la détection du problème (lecture et reprogrammation de la flash avec le nouveau code correcteur d'erreur par le bootloader), de devoir mettre à jour les outils de production pour écrire la flash sur les nouvelles machines produites directement avec le code d'erreur robuste, la gestion dans le code des deux versions du matériel avec les deux types de correction d'erreur (le nouveau utilisait du support matériel de la nouvelle puce de flash et ne pouvait donc pas être déployé sur l'ancienne carte), …
Dans d'autres cas (par exemple des microcontrôleurs, où le remplacement nécessiterait une réécriture complète du firmware), le plus simple était de réagir à l'annonce d'obsolescence et d'acheter un gros stock de composants pour les années à venir. Si le volume de production est relativement faible et le composant pas très cher, les quelques milliers d'euros nécessaires pour ça vont être bien inférieurs au coût de conception d'un nouveau firmware et d'une nouvelle électronique.
Plus récemment dans un autre projet, c'est un changement de référence sur une simple diode qui a causé un changement de comportement du matériel. Je n'ai pas tous les détails car je ne suis pas responsable du matériel sur ce projet. Mais il y a une série de matériel avec la "mauvaise" diode sur laquelle une partie du circuit électronique ne fonctionne pas. Le moindre changement doit donc être validé avec tout le périmètre matériel et logiciel, et aussi dans toutes les conditions de température, humidité, …
On comprend peut-être un peu mieux pourquoi les fabricants de téléphones préfèrent sortir régulièrement de nouveaux modèles plutôt que de faire ce type de micro mise à jour qui peut coûter presque aussi cher que de repartir de zéro.
[^] # Re: Grenoble ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La France va produire des processeurs. Évalué à 4 (+1/-0).
Chez ST, ça bouge aussi pour moderniser la production, mais plutôt à Tours et l'annonce date du trimestre dernier:
https://www.reuters.com/business/stmicro-invest-60-million-french-plant-facing-restructuring-2025-09-17/
[^] # Re: Chaise
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Disquette des Univac, 2,2 MB. Évalué à 4 (+1/-0).
Est-ce qu'on peut vraiment appeler ça une disquette? Pour mois ça semble être plutôt un assez grand disque.
# Micral
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien C’est la « renaissance » de la marque Bull, sous le giron de l’État. Évalué à 7 (+4/-0).
Est-ce qu'ils vont relancer la production du Micral N?
[^] # Re: J'ai pas trop compris
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien scx_horoscope - Astrological CPU Scheduler. Évalué à 5 (+2/-0).
On dit plutôt ordonnanceur en français il me semble.
Pour les périodes rétrogrades, la traduction me semble bien (ce sont les périodes ou visuellement les planètes se déplacent dans le ciel dans le sens "inverse", ce qui semblait très complexe avant qu'on ne comprenne le modèle héliocentrique du système solaire, mais la question est résolue depuis Copernic et Kepler il y a presque un demi millénaire de ça); pour la Lune je pense qu'on parle plutôt de phases de la Lune (pleine Lune, croissante, décroissante, etc).
# Les planètes sont alignées
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Linux : les planètes s'alignent en 2026. Évalué à 10 (+9/-0).
Si on croit ou qu'on a envie de croire à l'astrologie et à l'importance des alignements de planètes (hors missions de type Voyager), on peut installer un ordonnanceur qui tient compte de ces paramètres dans son noyau Linux.
[^] # Re: Passez à la fibre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Utiliser les vieilles prises téléphoniques d'une maison pour avoir une connection gigabit. Évalué à 4 (+1/-0).
C'est surtout un problème de topologie: les prises de téléphones sont en "daisy chain": un seul câble fait tout le tour de la maison et va d'une prise à la suivante.
Pour de l'ethernet gigabit, et surtout pour de la fibre, il faut un réseau en étoile avec tous les câbles qui convergent vers un concentrateur (switch ethernet).
Ce qui de,ande un peu plus de travaux que simplement recâbler la maison, il faut probablement passer de nouvelles gaines qui vont directement de chaque prise à l'endroit où on veut installer le commutateur.
En France on est passé sur un câblage centralisé (dans l'armoire électrique en général) pour les logements neufs depuis déjà quelques temps. Il y a même des prises électriques disponibles pour y installer des équipements actifs (ONT, modem/box internet, switch, …)