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.
Une raison possible est que la correction que ferait le matériel n'est pas forcément la bonne.
En gros, le principe des codes détecteurs et correcteurs d'erreur, c'est de trouver le code (la valeur du message et de ses octets de contrôle) "le plus proche" de ce qui est trouvé dans la mémoire.
Si il y a effectivement un seul bit qui avait changé de valeur, la correction est forcément la bonne. Mais s'il y avait 2, ou 4, ou 31 bits sur 32 de changés? Dans certains cas on peut toujours détecter qu'il y a une erreur, mais la correction proposée par le matériel n'est pas la bonne: elle donne une valeur dont la somme de contrôle est valide, mais pas celle d'origine.
Pour prendre un exemple très simple, imaginons un système de parité en lignes et colonnes.
Le message qu'on veut envoyer est:
00
01
On ajoute sur chaque ligne et chaque colonne un bit de telle façon que il y ait toujours un nombre pair de 1 dans chaque ligne et colonne:
00 0
01 1
01 1
Maintenant, si il y a un seul bit corrompu, on détecte tout de suite quelle ligne et quelle colonne ne sont pas bonnes, et on peut corriger. Par exemple:
00 0
00 1 <- Erreur sur cette ligne
01 1
^- Erreur sur cette colonne
Mais si on a 2 bits qui sont changés, on ne sait plus. Par exemple si on reçoit:
00 0
00 0 <- Deux bits 1 sont devenus des 0 ici
01 1
On détecte une erreur sur 2 colonnes et sur aucune ligne.
Il y a plusieurs corrections possibles en changeant 2 bits:
00 0
00 0
00 0 <- On peut corriger ici
00 0
01 1 <- On peut corriger ici
01 1
01 1 <- Ou alors on peut corriger ici
00 0
01 1
Et s'il y a encore plus d'erreurs, on peut se trouver dans un cas où la correction la plus évidente (changer 1 seul bit) ne correspond pas au message initial (il fallait en fait changer 3 bits ailleurs).
Ce code de parité matriciel permet de corriger toutes les erreurs de 1 bit. Il permet de détecter toutes les erreurs de 1, 2 ou 3 bits. Au delà, dans certains cas il ne détecte même pas forcément qu'il y a une erreur.
Bien sûr, ce n'est pas un code très performant, on sait faire beaucoup mieux, mais le principe reste le même.
Pour plus d'info là dessus, voir le principe du calcul de distance de Hamming (combien de bits il faut changer pour passer d'un code à un autre) et les garanties apportées par le code correcteur (une distance de Hamming minimale entre 2 codes valides). Si il y a plus d'erreurs que cette distance minimale, on va se retrouver plus "proche" d'un autre code que celui initial.
Le même code détecteur/correcteur est donc plus performant pour détecter les erreurs (il suffit de voir qu'on a pas un mot de code valide), que pour les corriger (il faut en plus retrouver quel était le mot de code de départ).
On utilise le mode de correction dans le cas où la donnée n'est pas récupérable autrement (lecture depuis un support de stockage, transmission radio (ou filaire) temps réel, …). Mais ici on a un meilleur moyen: redémarrer le satellite et réinitialiser toute la mémoire. Donc, pas la peine de prendre le risque de tenter une correction qui ne serait peut-être pas la bonne.
Quelle meilleure formulation tu proposerais pour dire que les vols spatiaux ont fait augmenter le coût des télescopes spatiaux, sans impact sur le coût des télescopes au sol?
Sans cette précision, la phrase n'aurait aucun sens non plus.
Je dirais que ta traduction n'est pas tout à fait correcte, quelque chose comme ça serait peut être mieux:
Tout d'abord, alors que les miroirs devenaient de plus en plus grands pour observer plus loin dans l'univers, leur coût augmentait exponentiellement. Puis, avec l'avènement des vols spatiaux, le coût des télescopes spatiaux est devenu encore plus important. [sous-entendu: que le coût des télescopes au sol]
En fait, ma question portait plus largement sur Smalltalk sur le long terme. Est-ce que par exemple Microsoft n'aurait pas pu s'en servir aux débuts de Windows pour faire des applications graphiques ? Est-ce qu'on aurait pu alors avoir un environnement Smalltalk au lieu de Visual Basic dans les années 90 ?
Les débuts de Smalltalk en dehors de Xerox ont été très compliqué à cause de problèmes de performances (il fallait du matériel hors de prix spécifique au moins dans la première moitié des années 80).
Puis ensuite, d'autres technos avaient pris la place. Smalltalk (les versions de l'époque, en tout cas) fonctionne bien si il est utilisé comme un système d'exploitation complet (il vient avec sa propre façon de gérer les fenêtres et l'environnement graphique, le stockage sur disque, …). Mais il est difficile à intégrer dans un système existant.
Enfin, le fait de développer son application en modifiant directement son environnement de travail (il n'y a pas de phase de compilation, ou de distinction entre l'environnement de développement et d'exécution), c'est super pour expérimenter et développer le système lui-même, mais ce n'est pas forcément quelque chose qu'on veut mettre entre toutes les mains. C'est trop facile de faire une fausse manipulation et de "casser" un objet essentiel au fonctionnement du système. Tout cela n'a été résolu que plus tard.
Cependant, beaucoup d'idées développées dans Smalltalk ont trouvé une utilisation ailleurs. Les machines virtuelles orientées objet avec un bytecode ont donné Java, la gestion de la mémoire avec les applications résidentes en RAM a donné Palm OS, l'interface graphique à base de fenêtres a fortement inspiré Apple pour le Lisa et le Macintosh, puis ensuite un peu tous les autres systèmes, et tout ça sans parler des aspects matériels qui ont été développés en parallèle: Ethernet, imprimantes laser, CPU avec un microcode reprogrammable…
J'ai 16Go sur ma machine Haiku. Je me contenterais de beaucoup moins si je n'avais pas besoin de compiler et de mettre à jour régulièremet WebKit.
La compilation C++ sur 8 coeurs, ça mange beaucoup de RAM (en fait la plupart du temps je dois compiler avec moins de 8 jobs en parallèle, sinon je tombe à court de RAM).
Je pourrais aussi me contenter de moins si la gestion de la mémoire était mieux pensée: pas de plantage, gestion "intelligente" par les outisl de build (ninja prend en compte le "load" de la machine pour décider de combien de jobs lancer, mais ça ne tient pas compte de l'utilisation mémoire). Je commence même à me dire qu'un fonctionnement comme en Smalltalk (ou on travaille sur une méthode à la fois sans jamais avoir besoin de recompiler tout le reste du système) me ferait gagner pas mal de temps, même si l'exécution du code peut être rendue plus lente. Je suppose que l'optimisation pourrait tourner en tâche de fond quand je ne fais rien d'autre avec mon ordinateur.
Est-ce que d'autres langages (Rust? Swift?) font mieux en la matière?
[^] # 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é à 3 (+0/-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é à 5 (+2/-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é à 6 (+3/-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.
[^] # Re: Pourquoi le matériel ne corrige pas directement la mémoire ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche « It works on my satellite » ou l'histoire d'un bug dans l'espace. Évalué à 9 (+6/-0).
Une raison possible est que la correction que ferait le matériel n'est pas forcément la bonne.
En gros, le principe des codes détecteurs et correcteurs d'erreur, c'est de trouver le code (la valeur du message et de ses octets de contrôle) "le plus proche" de ce qui est trouvé dans la mémoire.
Si il y a effectivement un seul bit qui avait changé de valeur, la correction est forcément la bonne. Mais s'il y avait 2, ou 4, ou 31 bits sur 32 de changés? Dans certains cas on peut toujours détecter qu'il y a une erreur, mais la correction proposée par le matériel n'est pas la bonne: elle donne une valeur dont la somme de contrôle est valide, mais pas celle d'origine.
Pour prendre un exemple très simple, imaginons un système de parité en lignes et colonnes.
Le message qu'on veut envoyer est:
On ajoute sur chaque ligne et chaque colonne un bit de telle façon que il y ait toujours un nombre pair de 1 dans chaque ligne et colonne:
Maintenant, si il y a un seul bit corrompu, on détecte tout de suite quelle ligne et quelle colonne ne sont pas bonnes, et on peut corriger. Par exemple:
Mais si on a 2 bits qui sont changés, on ne sait plus. Par exemple si on reçoit:
On détecte une erreur sur 2 colonnes et sur aucune ligne.
Il y a plusieurs corrections possibles en changeant 2 bits:
Et s'il y a encore plus d'erreurs, on peut se trouver dans un cas où la correction la plus évidente (changer 1 seul bit) ne correspond pas au message initial (il fallait en fait changer 3 bits ailleurs).
Ce code de parité matriciel permet de corriger toutes les erreurs de 1 bit. Il permet de détecter toutes les erreurs de 1, 2 ou 3 bits. Au delà, dans certains cas il ne détecte même pas forcément qu'il y a une erreur.
Bien sûr, ce n'est pas un code très performant, on sait faire beaucoup mieux, mais le principe reste le même.
Pour plus d'info là dessus, voir le principe du calcul de distance de Hamming (combien de bits il faut changer pour passer d'un code à un autre) et les garanties apportées par le code correcteur (une distance de Hamming minimale entre 2 codes valides). Si il y a plus d'erreurs que cette distance minimale, on va se retrouver plus "proche" d'un autre code que celui initial.
Le même code détecteur/correcteur est donc plus performant pour détecter les erreurs (il suffit de voir qu'on a pas un mot de code valide), que pour les corriger (il faut en plus retrouver quel était le mot de code de départ).
On utilise le mode de correction dans le cas où la donnée n'est pas récupérable autrement (lecture depuis un support de stockage, transmission radio (ou filaire) temps réel, …). Mais ici on a un meilleur moyen: redémarrer le satellite et réinitialiser toute la mémoire. Donc, pas la peine de prendre le risque de tenter une correction qui ne serait peut-être pas la bonne.
[^] # Re: Pas relu par un humain ? Ça ne doit pas être lu par un humain.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Eric Schmidt va financer seul le successeur du télescope spatial Hubble. Évalué à 3 (+0/-0).
Quelle meilleure formulation tu proposerais pour dire que les vols spatiaux ont fait augmenter le coût des télescopes spatiaux, sans impact sur le coût des télescopes au sol?
Sans cette précision, la phrase n'aurait aucun sens non plus.
Je dirais que ta traduction n'est pas tout à fait correcte, quelque chose comme ça serait peut être mieux:
[^] # Re: smalltalk
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).
Les débuts de Smalltalk en dehors de Xerox ont été très compliqué à cause de problèmes de performances (il fallait du matériel hors de prix spécifique au moins dans la première moitié des années 80).
Puis ensuite, d'autres technos avaient pris la place. Smalltalk (les versions de l'époque, en tout cas) fonctionne bien si il est utilisé comme un système d'exploitation complet (il vient avec sa propre façon de gérer les fenêtres et l'environnement graphique, le stockage sur disque, …). Mais il est difficile à intégrer dans un système existant.
Enfin, le fait de développer son application en modifiant directement son environnement de travail (il n'y a pas de phase de compilation, ou de distinction entre l'environnement de développement et d'exécution), c'est super pour expérimenter et développer le système lui-même, mais ce n'est pas forcément quelque chose qu'on veut mettre entre toutes les mains. C'est trop facile de faire une fausse manipulation et de "casser" un objet essentiel au fonctionnement du système. Tout cela n'a été résolu que plus tard.
Cependant, beaucoup d'idées développées dans Smalltalk ont trouvé une utilisation ailleurs. Les machines virtuelles orientées objet avec un bytecode ont donné Java, la gestion de la mémoire avec les applications résidentes en RAM a donné Palm OS, l'interface graphique à base de fenêtres a fortement inspiré Apple pour le Lisa et le Macintosh, puis ensuite un peu tous les autres systèmes, et tout ça sans parler des aspects matériels qui ont été développés en parallèle: Ethernet, imprimantes laser, CPU avec un microcode reprogrammable…
# C'est la faute de WebKit
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Quelle quantité de RAM ai-je sur ma machine principale ?. Évalué à 3 (+0/-0).
J'ai 16Go sur ma machine Haiku. Je me contenterais de beaucoup moins si je n'avais pas besoin de compiler et de mettre à jour régulièremet WebKit.
La compilation C++ sur 8 coeurs, ça mange beaucoup de RAM (en fait la plupart du temps je dois compiler avec moins de 8 jobs en parallèle, sinon je tombe à court de RAM).
Je pourrais aussi me contenter de moins si la gestion de la mémoire était mieux pensée: pas de plantage, gestion "intelligente" par les outisl de build (ninja prend en compte le "load" de la machine pour décider de combien de jobs lancer, mais ça ne tient pas compte de l'utilisation mémoire). Je commence même à me dire qu'un fonctionnement comme en Smalltalk (ou on travaille sur une méthode à la fois sans jamais avoir besoin de recompiler tout le reste du système) me ferait gagner pas mal de temps, même si l'exécution du code peut être rendue plus lente. Je suppose que l'optimisation pourrait tourner en tâche de fond quand je ne fais rien d'autre avec mon ordinateur.
Est-ce que d'autres langages (Rust? Swift?) font mieux en la matière?
# Néologisme
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal À la recherche du Linuxfrien type. Évalué à 6 (+3/-0).
Ah tiens, j'aurais plutôt écrit epublié?
[^] # Re: Analyse un peu trop rapide
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Stackoverflow est en train de mourir. Évalué à 4 (+1/-0).
Il va probablement être revendu, la question est surtout de savoir qui va mettre la main sur toutes ces données?