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?
C'est intéressant de lire cet article juste à còté d'un autre sur la préservation des premières versions de UNIX. Les deux ont à peu près le même âge. Les deux sont toujours très utilisés aujourd'hui, sous des formes qui ont bien sûr beaucoup évolué depuis. Pourtant, il y en a un dont tout le monde semble souhaiter la disparition, et pas l'autre.
COBOL a su traverser des gros chantiers comme le bug de l'an 2000 et le passage à l'euro, des crises comme l'éclatement de la bulle internet, certains de ces systèmes ont commencé leur vie à l'époque du traitement par lots et sont capables aujourd'hui de s'interfacer avec les toutes dernières technologies web et les applications mobiles, ou même l'internet des objets.
Le tout avec des taux de disponibilité élevés (les pannes arrivent parfois dans le secteur bancaire, mais c'est quand même très rare). Et un système distribué qui fait que si une banque rencontre une panne, les autres continuent de fonctionner.
Pourquoi on considère qu'il faudrait tout jeter et recommencer dans un autre langage? Alors qu'il faudrait plutôt célébrer un succès retentissant de l'informatique? Est-ce que les développeurs COBOL s'ennuient avec cette infrastructure qui fonctionnent trop bien, et rêvent d'un langage comme le C où on peut corrompre la mémoire, ou à défaut, de Java et ses NullPointerExceptions, pour pimenter un peu leur quotidien?
Et du coup ça répond à une autre chaîne de commentaires ci-dessus: Airbus utilise Google Workspaces (et probablement aussi du Microsoft) pour des données non critiques et auto-héberge le reste (dont les données sur la conception des avions). Ils cherchent donc une solution pour la partie qui n'est pas encore dans un cloud. Probablement avant que certains de leurs employés en aient assez des méthodes de travail perçues comme archaïques, et décident d'utiliser leur dropbox/github/… personnel pour pouvoir travailler dans des conditions acceptaples.
Bon même si le neuf prends l'ascenseur tu trouves des pc d'occasion avec 16GB de ram et un SSD comfortable pour 50€ en occasion.
Tu les trouves où? J'ai regardé chez backmarket par exemple et le premier modèle avec 16Go de RAM est à plus de 200€ (soit 4 fois plus que le prix annoncé dans ton message).
Moui, les semaines de 10 jours, ça fait moins de week-ends, c'est dommage!
Pourquoi pas le calendrier Eastman, dont je découvre un ancêtre dans cette pag: le calendrier Géorgien, un jeu de mot facétieux datant de 1745, qui n'aurait sûrement pas manqué de causer de nombreuses confusions si ça avait marché!
Pour les applications CP/M, a priori c'est forcément sur disquettes, le lecteur de cassettes n'est pas pris en charge.
Désolé de casser le fun avec cette mauvaise nouvelle.
Pour l'Amstrac CPG 464 il faudra donc ajouter un DDI-1.
Et je ne sais pas pour Cobol, mais pour d'autres langages comme Modula 2, les compilateurs recommndent même dwutiliser une extension mémoire avec un ramdisk ou au roins un deuxième lecteur de disquettes (une disquette avec les outils de compilation, et l'autre avec le source à compiler). Ceci sans compter que le CPM+ disponible uniquement sur les machines avec 128K de mémoire, permettrait d'avoir presque tout l'espace mémoire du z80 (63Ko) disponibles pour le compilateur. Avec CPM 2.2 il faudra que tout rentre dans environ 40Ko de RAM.
D'après l'article, Alstom avait bien identifié le problème puisque ils ont interdit la saisie de dates postérieures à 2037. Ils ont été condamnés parce que la justice a décidé que c'était de la dissimulation de vice.
Il n'y a probablement pas besoin de changer le matériel. On peut très bien manipuler des entiers 64 bit sur un processeur 32 bit (en C il suffit de déclarer l'entier en "nong int" ou "uint64_t" par exemple).
Mais si ça n'a pas été fait depuis le début et que ça utilise un système qui a traîné des pieds pendant 20 ans pour faire la mise à jour (quelque chose comme la glibc, par exemple), ben il faut mettre à jour tout le système. Grosse montée en version si ça n'a pas été fait au fil de l'eau: probablement que mettre à jour la glibc va aller avec une mise à jour du noyau, du compilateur, bref de tout le système.
Ensuite il faut corriger les erreurs de compilation que le nouveau compilateur a généré.
Jusque là, c'est la partie facile: tu peux faire ça tranquille dans ton bureau. Mais une fois que ça compile, tu peux pas dire "allez zou, on installe ça vendredi après-midi au centre de contrôle (ou sur les rames de métro si c'est embarqué dedans) et c'est parti". Il va falloir tester, probablement d'abord en simulation, mais à un moment sur le vrai matériel. Hors de question de le faire avec des gens dans les rames de métro, et il y a assez peu d'endroits où on peut faire des essais sur des voies qui ne sont pas en service.
Donc ça veut probablement dire fermeture de la ligne de métro pendant quelques jours pour vérifier si tout se passe bien, ou éventuellement essais de nuit si les métros sont fermés la nuit (c'est pas le cas dans toutes les villes) et que le temps de fermeture n'est pas déjà mobilisé par d'autres travaux (entretien des voies, …).
Pour le centre de contrôle tu pourrais peut-être t'en sortir en faisant tourner le nouveau logiciel en parallèle de l'ancien, et vérifier qu'ils font toujours "la même chose", si le truc a été architecturé pour avoir deux contrôleurs en parallèle.
Le problème des systèmes embarqués est assez réduit ici: c'est l'accès au calculateur pour le mettre à jour. Dans le cas d'un train ça peut se faire lors d'une visite régulière au centre de maintenance. Par contre il faut s'assurer de ne pas avoir oublié de le faire sur un train.
On a donc des problèmes de gestion de flotte, des problèmes de capacité à tester en situation réelle, et peut-être de la gestion d'obsolescence logicielle.
les gens qui ne livrent pas de package de leurs logiciels
Personellement je développe plusieurs logiciels que je package pour Haiku et éventuellement pour Windows. Pour Linux, il y a beaucoup trop de diversité à moins de se prendre la tête avec des flatpak, à moins que ce soient des snap ou des appimages. Bref, il y a beaucoup trop de diversité.
Donc je distribue les sources et je laisse les distributions Linux gérer le bazar. C'est trop compliqué pour moi.
En dehors des digraphes, il y a une autre solution beaucoup plus simple, voici le code:
Ce programme vide ne fait rien. Il a permit de mettre fin à une situation ennuyeuse pour le jury de l'IOCCC: tous les ans, ils recevaient de nombreux programmes prétendant être le plus court programme C capable d'afficher son propre code source. Ce programme vide a placé le record à 0 octets, ce qui a réglé le débat de façon définitive (au moins jusqu'à que quelqu'un invente les fichiers de taille négative).
Voir la fiche détaillée de cette participation à l'IOCCC pour les détails.
On a donc une association qui s'approche du demi million de dollars en réserves, et qui paie un seul ingénieur à $25000 par an, ce qui est non seulement loin d'être compétitif, mais même loin d'être la moitié d'un salaire compétitif pour un ingénieur aux USA.
Alors, on peut faire du marketing en disant que c'est mieux que Mozilla qui paie un CEO à plusieurs fois le budget annuel de Haiku, mais d'un autre côté, peut-être ce serait bien de dépenser un peu plus de sous pour que le projet avance un peu plus vite?
Cela dit, les dépenses sont raisonnables par rapport aux recettes. Il y aurait une possibilité d'embaucher une deuxième personne en dépensant les sous en réserves pendant quelques temps, et en espérant que cela donne une grosse impulsion au projet pour multiplier les dons (par 2 ou 3) et que l'opération soit équilibrée sur le moyen terme. Donc on peut voir ça comme une gestion saine et prudente?
Il y a aussi le fait que l'association Haiku inc est conçue pour avoir un rôle "passif" dans le financement: elle reçoit les dons, et elle les distribue à la demande des développeurs du projet (avec un peu de contrôle pour ne pas payer n'importe quoi). Ce sont les contributeurs du projet qui doivent prendre l'initiative de demander des sous. Il y a donc peu d'initiatives pour développer des choses qui n'existent pas ou peu (comme le marketing).
Enfin, le projet étant loin d'être abouti, je n'ai pas encore bien réfléchi à l'archivage de ces fichiers pour les siècles des siècles. Faut-il faire un dépôt sur une forge comme Codeberg ? Ou les déposer sur un site comme Wikimedia Commons ? Un par un :-( ? Quelle est votre opinion ? Avez-vous d'autres idées ?
C'est le genre de chose qui a tout à fait sa place chez https://archive.org, je pense?
La situation est toujours la même à ma connaissance: les bitcoins sont toujours chez Coinbase, et comme les dons et réserves en vrai argent sont suffisants, ce n'est pas vraiment la priorité du moment de gérer ça.
On pourra en rediscuter lors de la puplication du prochain rapport financier de Haiku inc en début d'année prochaine. Pour l'instant il est plus intéressant de regarder le compteur de dons de cette année qui n'a pas encore dépassé les 20000$ sur un objectif de 30000$ (on sent l'effet de l'absence de release ainsi que le fait qu'on a pas été retenu pour le Google summer of code). La générosité de fin d'année permettra-t-elle d'atteindre tout de même l'objectif, et ce malgré l'absence complète de communication pour lancer une campagne de dons? (Pour être tout à fait honnête, il y a sunrement d'autres projets qui sauront dépenser votre argent mieux et plus vite que Haiku)
[^] # 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é à 8 (+5/-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?
# Pourquoi casser ce qui fonctionne
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Faut-il se débarrasser des systèmes COBOL ? Entre dédain et transmission des savoirs. Évalué à 10 (+7/-0).
C'est intéressant de lire cet article juste à còté d'un autre sur la préservation des premières versions de UNIX. Les deux ont à peu près le même âge. Les deux sont toujours très utilisés aujourd'hui, sous des formes qui ont bien sûr beaucoup évolué depuis. Pourtant, il y en a un dont tout le monde semble souhaiter la disparition, et pas l'autre.
COBOL a su traverser des gros chantiers comme le bug de l'an 2000 et le passage à l'euro, des crises comme l'éclatement de la bulle internet, certains de ces systèmes ont commencé leur vie à l'époque du traitement par lots et sont capables aujourd'hui de s'interfacer avec les toutes dernières technologies web et les applications mobiles, ou même l'internet des objets.
Le tout avec des taux de disponibilité élevés (les pannes arrivent parfois dans le secteur bancaire, mais c'est quand même très rare). Et un système distribué qui fait que si une banque rencontre une panne, les autres continuent de fonctionner.
Pourquoi on considère qu'il faudrait tout jeter et recommencer dans un autre langage? Alors qu'il faudrait plutôt célébrer un succès retentissant de l'informatique? Est-ce que les développeurs COBOL s'ennuient avec cette infrastructure qui fonctionnent trop bien, et rêvent d'un langage comme le C où on peut corrompre la mémoire, ou à défaut, de Java et ses NullPointerExceptions, pour pimenter un peu leur quotidien?
[^] # Re: La vraie source (en anglais)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Airbus veut du cloud souverain ?. Évalué à 4 (+1/-0).
Et du coup ça répond à une autre chaîne de commentaires ci-dessus: Airbus utilise Google Workspaces (et probablement aussi du Microsoft) pour des données non critiques et auto-héberge le reste (dont les données sur la conception des avions). Ils cherchent donc une solution pour la partie qui n'est pas encore dans un cloud. Probablement avant que certains de leurs employés en aient assez des méthodes de travail perçues comme archaïques, et décident d'utiliser leur dropbox/github/… personnel pour pouvoir travailler dans des conditions acceptaples.
[^] # Re: communication enthousiaste
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche PearOS 25.12 NiceC0re : Le retour d'une distro emblématique. Évalué à 9 (+6/-0).
C'est également étrange d'avoir aucune capture d'écran, étant donné les objectifs de la distribution
[^] # Re: Les sources su Github
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche PearOS 25.12 NiceC0re : Le retour d'une distro emblématique. Évalué à 4 (+1/-0).
Tu les trouves où? J'ai regardé chez backmarket par exemple et le premier modèle avec 16Go de RAM est à plus de 200€ (soit 4 fois plus que le prix annoncé dans ton message).
[^] # Re: 32 bits
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Des lignes de métro, tramway et RER de la RATP concernées par le bogue de 2038. Évalué à 4 (+1/-0).
Moui, les semaines de 10 jours, ça fait moins de week-ends, c'est dommage!
Pourquoi pas le calendrier Eastman, dont je découvre un ancêtre dans cette pag: le calendrier Géorgien, un jeu de mot facétieux datant de 1745, qui n'aurait sûrement pas manqué de causer de nombreuses confusions si ça avait marché!
[^] # Re: Un programme sans accolades ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C sans accolades, IA un problème. Évalué à 4 (+1/-0).
Pour les applications CP/M, a priori c'est forcément sur disquettes, le lecteur de cassettes n'est pas pris en charge.
Désolé de casser le fun avec cette mauvaise nouvelle.
Pour l'Amstrac CPG 464 il faudra donc ajouter un DDI-1.
Et je ne sais pas pour Cobol, mais pour d'autres langages comme Modula 2, les compilateurs recommndent même dwutiliser une extension mémoire avec un ramdisk ou au roins un deuxième lecteur de disquettes (une disquette avec les outils de compilation, et l'autre avec le source à compiler). Ceci sans compter que le CPM+ disponible uniquement sur les machines avec 128K de mémoire, permettrait d'avoir presque tout l'espace mémoire du z80 (63Ko) disponibles pour le compilateur. Avec CPM 2.2 il faudra que tout rentre dans environ 40Ko de RAM.
[^] # Re: Difficulté de la mise à jour
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Des lignes de métro, tramway et RER de la RATP concernées par le bogue de 2038. Évalué à 10 (+7/-0).
D'après l'article, Alstom avait bien identifié le problème puisque ils ont interdit la saisie de dates postérieures à 2037. Ils ont été condamnés parce que la justice a décidé que c'était de la dissimulation de vice.
[^] # Re: Difficulté de la mise à jour
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Des lignes de métro, tramway et RER de la RATP concernées par le bogue de 2038. Évalué à 10 (+14/-0).
Il n'y a probablement pas besoin de changer le matériel. On peut très bien manipuler des entiers 64 bit sur un processeur 32 bit (en C il suffit de déclarer l'entier en "nong int" ou "uint64_t" par exemple).
Mais si ça n'a pas été fait depuis le début et que ça utilise un système qui a traîné des pieds pendant 20 ans pour faire la mise à jour (quelque chose comme la glibc, par exemple), ben il faut mettre à jour tout le système. Grosse montée en version si ça n'a pas été fait au fil de l'eau: probablement que mettre à jour la glibc va aller avec une mise à jour du noyau, du compilateur, bref de tout le système.
Ensuite il faut corriger les erreurs de compilation que le nouveau compilateur a généré.
Jusque là, c'est la partie facile: tu peux faire ça tranquille dans ton bureau. Mais une fois que ça compile, tu peux pas dire "allez zou, on installe ça vendredi après-midi au centre de contrôle (ou sur les rames de métro si c'est embarqué dedans) et c'est parti". Il va falloir tester, probablement d'abord en simulation, mais à un moment sur le vrai matériel. Hors de question de le faire avec des gens dans les rames de métro, et il y a assez peu d'endroits où on peut faire des essais sur des voies qui ne sont pas en service.
Donc ça veut probablement dire fermeture de la ligne de métro pendant quelques jours pour vérifier si tout se passe bien, ou éventuellement essais de nuit si les métros sont fermés la nuit (c'est pas le cas dans toutes les villes) et que le temps de fermeture n'est pas déjà mobilisé par d'autres travaux (entretien des voies, …).
Pour le centre de contrôle tu pourrais peut-être t'en sortir en faisant tourner le nouveau logiciel en parallèle de l'ancien, et vérifier qu'ils font toujours "la même chose", si le truc a été architecturé pour avoir deux contrôleurs en parallèle.
Le problème des systèmes embarqués est assez réduit ici: c'est l'accès au calculateur pour le mettre à jour. Dans le cas d'un train ça peut se faire lors d'une visite régulière au centre de maintenance. Par contre il faut s'assurer de ne pas avoir oublié de le faire sur un train.
On a donc des problèmes de gestion de flotte, des problèmes de capacité à tester en situation réelle, et peut-être de la gestion d'obsolescence logicielle.
# Au stade terminal?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien StackExchange au stade terminal de la merdification : une "question" sur 5 sera une pub. Évalué à 9 (+6/-0).
Il restera donc encore 80% de vraies questions? Ça laisse une belle marge avant d'atteindre le stade terminal, je vous trouve bien optimiste!
[^] # Re: public cible
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Utilisez une tablette ou tout autre ordinateur comme second écran. Évalué à 8 (+5/-0).
Personellement je développe plusieurs logiciels que je package pour Haiku et éventuellement pour Windows. Pour Linux, il y a beaucoup trop de diversité à moins de se prendre la tête avec des flatpak, à moins que ce soient des snap ou des appimages. Bref, il y a beaucoup trop de diversité.
Donc je distribue les sources et je laisse les distributions Linux gérer le bazar. C'est trop compliqué pour moi.
# Trop facile
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C sans accolades, IA un problème. Évalué à 8 (+5/-0).
En dehors des digraphes, il y a une autre solution beaucoup plus simple, voici le code:
Ce programme vide ne fait rien. Il a permit de mettre fin à une situation ennuyeuse pour le jury de l'IOCCC: tous les ans, ils recevaient de nombreux programmes prétendant être le plus court programme C capable d'afficher son propre code source. Ce programme vide a placé le record à 0 octets, ce qui a réglé le débat de façon définitive (au moins jusqu'à que quelqu'un invente les fichiers de taille négative).
Voir la fiche détaillée de cette participation à l'IOCCC pour les détails.
[^] # Re: Arrêter de nous gaver avec de l'IA
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Arrêter de nous gaver avec de l'IA 🤮. Évalué à 5 (+2/-0).
Ah non pas question! Quand je trolle, je le fais à la main, sinon quel est l'intérêt?
[^] # Re: Des nouvelles de vos bitcoins ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 7 (+4/-0).
L'état des finances en 2024:
On a donc une association qui s'approche du demi million de dollars en réserves, et qui paie un seul ingénieur à $25000 par an, ce qui est non seulement loin d'être compétitif, mais même loin d'être la moitié d'un salaire compétitif pour un ingénieur aux USA.
Alors, on peut faire du marketing en disant que c'est mieux que Mozilla qui paie un CEO à plusieurs fois le budget annuel de Haiku, mais d'un autre côté, peut-être ce serait bien de dépenser un peu plus de sous pour que le projet avance un peu plus vite?
Cela dit, les dépenses sont raisonnables par rapport aux recettes. Il y aurait une possibilité d'embaucher une deuxième personne en dépensant les sous en réserves pendant quelques temps, et en espérant que cela donne une grosse impulsion au projet pour multiplier les dons (par 2 ou 3) et que l'opération soit équilibrée sur le moyen terme. Donc on peut voir ça comme une gestion saine et prudente?
Il y a aussi le fait que l'association Haiku inc est conçue pour avoir un rôle "passif" dans le financement: elle reçoit les dons, et elle les distribue à la demande des développeurs du projet (avec un peu de contrôle pour ne pas payer n'importe quoi). Ce sont les contributeurs du projet qui doivent prendre l'initiative de demander des sous. Il y a donc peu d'initiatives pour développer des choses qui n'existent pas ou peu (comme le marketing).
# Internet archive
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Réanimation des tuxeries. Évalué à 6 (+3/-0).
C'est le genre de chose qui a tout à fait sa place chez https://archive.org, je pense?
[^] # Re: Des nouvelles de vos bitcoins ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 4 (+1/-0).
La situation est toujours la même à ma connaissance: les bitcoins sont toujours chez Coinbase, et comme les dons et réserves en vrai argent sont suffisants, ce n'est pas vraiment la priorité du moment de gérer ça.
On pourra en rediscuter lors de la puplication du prochain rapport financier de Haiku inc en début d'année prochaine. Pour l'instant il est plus intéressant de regarder le compteur de dons de cette année qui n'a pas encore dépassé les 20000$ sur un objectif de 30000$ (on sent l'effet de l'absence de release ainsi que le fait qu'on a pas été retenu pour le Google summer of code). La générosité de fin d'année permettra-t-elle d'atteindre tout de même l'objectif, et ce malgré l'absence complète de communication pour lancer une campagne de dons? (Pour être tout à fait honnête, il y a sunrement d'autres projets qui sauront dépenser votre argent mieux et plus vite que Haiku)