Toutefois, dans le cas du choix de la forge, choisir Gitlab, Codeberg ou Gitea, c'est au moins avoir la possibilité de se monter une instance chez soi et de conserver au moins une partie des intégrations.
L'éléphant dans la pièce, comme disent les américains, c'est que Github n'est pas libre, alors que les trois alternatives que tu cites (et plein d'autres), si.
Ça me semble important au moins quand il s'agit d'héberger des projets de logiciels libres. La situation peut être différente quand il s'agit d'un hébergement de projets fermés "en interne" pour une entreprise.
Et surtout ce qui est un peu rageant, c'est que avant Github, il y avait Sourceforge, et plein d'autres outils, basés entièrement sur des technologies libres. Et la partie "sociale"/découverte des projets se faisait ailleurs: via freshmeat.net et d'autres annuaires de projets, indépendants des solutions d'hébergement.
Donc on est même pas dans un cas où il n'y avait pas d'alternative libre et les gens se seraient dirigés vers Github faute d'avoir aucune autre option. Faire de l'hébergement de logiciel avec uniquement du logiciel libre, ce n'est pas le futur, ce n'est pas le présent, c'est possible depuis 30 ans.
J'espère que les efforts de Forgejo/Codeberg pour mettre en place une interface lisible et plus légère, ainsi qu'un système de fédération, pourront aider à faire que certains projets quittent Github.
Pour ma part je retourne petit à petit à de l'auto hébergement avec Trac et Gerrit. Ça marche bien malgré les attaques de robots scrappers qui s'acharnent à cliquer sur tous les liens de mon serveur…
Microsoft a fait un travail incroyable en terme de design d'interface graphique pour Windows 3.1 puis 95, par exemple. Il y a vraiment un avant et un après dans la façon dont on intéragit avec nos ordinateurs. Ils ont apporté de la cohérence entre les applications, un vrai langage de design (cases à cocher carrées, boutons radio ronds, "relief" pour indiquer les zones cliquables, …).
L'interface de ces systèmes est toujours parfaitement utilisable 30 ans après, alors qu'ils fonctionnent avec des machines 100 à 1000 fois moins performantes que ce dont on dispose aujourd'hui (pour rappel: 4Mo de RAM et un processeur 386 à 16MHz sont la configuration minimale, la recommandation pour être à l'aise c'est un 486 à 33MHz avec 8Mo de RAM).
Cela a été également un des premiers systèmes grand public à utiliser la protection mémoire, la mémoire virtuelle, les threads, et sûrement plein d'autres choses auxquelles on ne pense même plus aujourd'hui tellement ça semble évident.
Le Microsoft d'aujourd'hui est-il toujours capable de ce genre de révolution? Ou bien se sont-ils perdus en route? Ils n'ont pas toujours été si mauvais…
Alors oui mais ça n'est pas une distribution de Linux. Je vais d'ailleurs de ce pas ajouter cette précision dans la dépêche en cours de rédaction, parce que c'est vrai qu'on ne pense plus à le dire, alors que c'est un peu important.
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.
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien "Made in EU" - it was harder than I thought.. Évalué à 8 (+5/-0).
L'éléphant dans la pièce, comme disent les américains, c'est que Github n'est pas libre, alors que les trois alternatives que tu cites (et plein d'autres), si.
Ça me semble important au moins quand il s'agit d'héberger des projets de logiciels libres. La situation peut être différente quand il s'agit d'un hébergement de projets fermés "en interne" pour une entreprise.
Et surtout ce qui est un peu rageant, c'est que avant Github, il y avait Sourceforge, et plein d'autres outils, basés entièrement sur des technologies libres. Et la partie "sociale"/découverte des projets se faisait ailleurs: via freshmeat.net et d'autres annuaires de projets, indépendants des solutions d'hébergement.
Donc on est même pas dans un cas où il n'y avait pas d'alternative libre et les gens se seraient dirigés vers Github faute d'avoir aucune autre option. Faire de l'hébergement de logiciel avec uniquement du logiciel libre, ce n'est pas le futur, ce n'est pas le présent, c'est possible depuis 30 ans.
J'espère que les efforts de Forgejo/Codeberg pour mettre en place une interface lisible et plus légère, ainsi qu'un système de fédération, pourront aider à faire que certains projets quittent Github.
Pour ma part je retourne petit à petit à de l'auto hébergement avec Trac et Gerrit. Ça marche bien malgré les attaques de robots scrappers qui s'acharnent à cliquer sur tous les liens de mon serveur…
[^] # Re: Bordeaux Chesnel
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien 15+ years later, Microsoft morged my diagram. Évalué à 8 (+5/-0).
Microsoft a fait un travail incroyable en terme de design d'interface graphique pour Windows 3.1 puis 95, par exemple. Il y a vraiment un avant et un après dans la façon dont on intéragit avec nos ordinateurs. Ils ont apporté de la cohérence entre les applications, un vrai langage de design (cases à cocher carrées, boutons radio ronds, "relief" pour indiquer les zones cliquables, …).
L'interface de ces systèmes est toujours parfaitement utilisable 30 ans après, alors qu'ils fonctionnent avec des machines 100 à 1000 fois moins performantes que ce dont on dispose aujourd'hui (pour rappel: 4Mo de RAM et un processeur 386 à 16MHz sont la configuration minimale, la recommandation pour être à l'aise c'est un 486 à 33MHz avec 8Mo de RAM).
Cela a été également un des premiers systèmes grand public à utiliser la protection mémoire, la mémoire virtuelle, les threads, et sûrement plein d'autres choses auxquelles on ne pense même plus aujourd'hui tellement ça semble évident.
Le Microsoft d'aujourd'hui est-il toujours capable de ce genre de révolution? Ou bien se sont-ils perdus en route? Ils n'ont pas toujours été si mauvais…
[^] # Re: Welcome back !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Retour sur ce site - j'espère retrouver la bonne ambiance d'antant.. Évalué à 7 (+4/-0).
Alors oui mais ça n'est pas une distribution de Linux. Je vais d'ailleurs de ce pas ajouter cette précision dans la dépêche en cours de rédaction, parce que c'est vrai qu'on ne pense plus à le dire, alors que c'est un peu important.
[^] # 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é à 9 (+6/-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 (+9/-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 (+14/-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é à 10 (+7/-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?