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, …)
Il me semble que l'auteur confond « simple » avec « ce que je connais » et préférerait n'être entouré que de gens qui pensent comme lui.
J'ai lu récemment un message de quelqu'un essayant de compiler cmake sur une machine des années 90. La compilation était en cours depuis 4 jours et n'était toujours pas terminée.
J'ai la même expérience avec WebKit (compile en environ une heure sur ma machine actuelle, mais sur un PC de 2014, c'est plutôt 2 jours).
On est pas vraiment dans la frugalité avec ce genre de projet.
(j'ai pas lu le reste de l'article, et les deux citations ne me donnent pas envie d'aller voir, mais il y a quand même peut-être une discussion sur le temps de compilation de cmake. Pour moi une solution est justement peut-être Rust qui compile beaucoup plus vite que C++…)
Sauf que cacher les symboles internes n'a pas je pense un grand intérêt en particulier dans une bibliothèque libre.
ça évite que quelqu'un utilise le même symbole dans une autre partie du code et que ça déclenche un conflit.
Selon le type d'édition de lien (librairie statique ou dynamique, utilisation du "symbolic linking" ou pas, activation de la link-time optimization, dlopen, …), ça peut donner des effets différents: le symbole de la librairie est utilisé à la place de celui du programme, ou l'inverse, ou ils vivent leur vie chacun de leur côté.
Il y a en plus de possibles impacts sur les performances (si un symbole est exporté et peut être remplacé, cela limite les optimisations que le compilateur peut faire).
Il ne s'agit pas de virtualisation pour faire tourner un système classique dedans (comme les qemu, virtualbox, etc).
Pharo est écrit en Smalltalk, un langage qui fonctionne dans une machine virtuelle spécifique, comme la JVM pour Java.
L'idée de départ est la même (faire tourner le code sur une machine qui n'est pas le vrai matériel), mais les raisons ainsi que la réalisation sont très différentes. Dans la virtualisation moderne, on cherche surtout à mutualiser du matériel tout en isolant les applications (pour des questions de sécurité, de séparation de dépendances, ou de facilité en gardant un environnement connu). Pour Smalltalk, il s'agit plutôt de portabilité (le bytecode compilé peut s'exécuter sur n'importe quelle machine physuque, du moment qu'il existe une implémentation de la machine virtuelle) et aussi de s'affranchir (dans une certaine mesure, bien sûr) des limites de la machine physique. Les premières implémentations de Smalltalk (sur le Xerox Alto par exemple) pouvaient ainsi travailler avec des objets en RAM (très limitée, moins de 80Ko disponibles) mais aussi sur le disque dur de façon transparente (ce qu'on appelle aujourd'hui de la mémoire virtuelle).
On peut donc concevoir une application bien plus grosse que la mémoire disponible dans la machine, déplacer/coper cette application sur une autre machine avec une architecture matérielle très différente, et obtenir du code très compact car le jeu d'instruction de la machine virtuelle est très adapté à ce qu'on exécute dessus (on fait donc beaucoup de choses avec peu d'instructions).
L'implémentation peut être très simple (une boucle qui lit les instructions du bytecode une par une et les exécute) ou beaucoup plus complexe avec de la génération de code pour le CPU natif à la volée.
L'augmentation du coût de la RAM est lié à une promesse d'achat de OpenAI pour la future production de puces.
Si la bulle éclate, les fournisseurs de RAM qui ont signé vont être bien embêtés de l'annulation de contrat, mais ne vont probablement pas pouvoir tout de suite rediriger la production vers le marché normal.
Comme c'est une grosse prise de risque, ils ont tout intérêt à continuer de vendre de la RAM très très cher en attendant, et peut-être même après.
[^] # 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é à 6 (+3/-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é à 6 (+3/-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é à 5 (+2/-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é à 6 (+3/-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, …)
[^] # Re: Est-ce un troll ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien "Trente ans d’open source... pour en arriver là". Évalué à 3 (+0/-0).
J'ai lu récemment un message de quelqu'un essayant de compiler cmake sur une machine des années 90. La compilation était en cours depuis 4 jours et n'était toujours pas terminée.
J'ai la même expérience avec WebKit (compile en environ une heure sur ma machine actuelle, mais sur un PC de 2014, c'est plutôt 2 jours).
On est pas vraiment dans la frugalité avec ce genre de projet.
(j'ai pas lu le reste de l'article, et les deux citations ne me donnent pas envie d'aller voir, mais il y a quand même peut-être une discussion sur le temps de compilation de cmake. Pour moi une solution est justement peut-être Rust qui compile beaucoup plus vite que C++…)
[^] # Re: #define public
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal À table !. Évalué à 6 (+3/-0).
ça évite que quelqu'un utilise le même symbole dans une autre partie du code et que ça déclenche un conflit.
Selon le type d'édition de lien (librairie statique ou dynamique, utilisation du "symbolic linking" ou pas, activation de la link-time optimization, dlopen, …), ça peut donner des effets différents: le symbole de la librairie est utilisé à la place de celui du programme, ou l'inverse, ou ils vivent leur vie chacun de leur côté.
Il y a en plus de possibles impacts sur les performances (si un symbole est exporté et peut être remplacé, cela limite les optimisations que le compilateur peut faire).
[^] # Re: Zorin = Ubuntu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Manuel d'installation de Pharo 13 sur Zorin OS 17 Core. Évalué à 10 (+7/-0).
Il ne s'agit pas de virtualisation pour faire tourner un système classique dedans (comme les qemu, virtualbox, etc).
Pharo est écrit en Smalltalk, un langage qui fonctionne dans une machine virtuelle spécifique, comme la JVM pour Java.
L'idée de départ est la même (faire tourner le code sur une machine qui n'est pas le vrai matériel), mais les raisons ainsi que la réalisation sont très différentes. Dans la virtualisation moderne, on cherche surtout à mutualiser du matériel tout en isolant les applications (pour des questions de sécurité, de séparation de dépendances, ou de facilité en gardant un environnement connu). Pour Smalltalk, il s'agit plutôt de portabilité (le bytecode compilé peut s'exécuter sur n'importe quelle machine physuque, du moment qu'il existe une implémentation de la machine virtuelle) et aussi de s'affranchir (dans une certaine mesure, bien sûr) des limites de la machine physique. Les premières implémentations de Smalltalk (sur le Xerox Alto par exemple) pouvaient ainsi travailler avec des objets en RAM (très limitée, moins de 80Ko disponibles) mais aussi sur le disque dur de façon transparente (ce qu'on appelle aujourd'hui de la mémoire virtuelle).
On peut donc concevoir une application bien plus grosse que la mémoire disponible dans la machine, déplacer/coper cette application sur une autre machine avec une architecture matérielle très différente, et obtenir du code très compact car le jeu d'instruction de la machine virtuelle est très adapté à ce qu'on exécute dessus (on fait donc beaucoup de choses avec peu d'instructions).
L'implémentation peut être très simple (une boucle qui lit les instructions du bytecode une par une et les exécute) ou beaucoup plus complexe avec de la génération de code pour le CPU natif à la volée.
[^] # Re: bulle
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le prix de la RAM s'envole : une aubaine pour nos logiciels et applications ?. Évalué à 8 (+5/-0).
L'augmentation du coût de la RAM est lié à une promesse d'achat de OpenAI pour la future production de puces.
Si la bulle éclate, les fournisseurs de RAM qui ont signé vont être bien embêtés de l'annulation de contrat, mais ne vont probablement pas pouvoir tout de suite rediriger la production vers le marché normal.
Comme c'est une grosse prise de risque, ils ont tout intérêt à continuer de vendre de la RAM très très cher en attendant, et peut-être même après.