Le logiciel de la mission Apollo a été littéralement tissé à la main ! Stocké sur une "mémoire à cordes" (Core rope memory), le code était tressé par des ouvrières du textile. Un fil de cuivre passant à travers un anneau de ferrite codait un "1", et le contournant codait un "0". Inaltérable et ultra-compacte, elle résistait parfaitement aux rayonnements spatiaux, contrairement aux bandes magnétiques de l'époque.
Surnommée "LOL memory" (Little Old Ladies), cette mémoire morte (ROM) demandait des mois de tissage minutieux à l'aide d'une longue aiguille.

Commentaires préférés (1)
Cette mémoire était extrêmement fiable, mais l'inconvénient d'être en lecture seule et de ne pas pouvoir modifier le programme peut être problématique en cas de pépin avec le code.
Comme par exemple lors de la descente du module lunaire d'Apollo 11. Des alarmes 1201 et 1202 se déclenchaient, indiquant que l'ordinateur était surchargé et n'arrivait plus à traiter toutes les données. Cela était causé par un radar qui était resté déployé alors qu'il était censé être éteint durant la descente, et ses informations sautaient l'ordinateur. Heureusement le code était extrêmement robuste et l'ordinateur savait donner priorité aux tâches essentielles comme le guidage et abandonner celles non-essentielles lorsque surchargé. En analysant les entrées et sorties de l'ordinateur, Mission Control a pu décider que cette erreur ne causerait pas de crash du programme et que les astronautes pouvaient malgré tout continuer la descente, ce qu'ils ont fait. Neil Armstrong pilota ensuite manuellement la phase d'atterrissage elle-même, et le module se posa avec succès à 20h17 et 39 secondes UTC dans la Mare Tranquilitatis, où il fut accueilli par Chuck Norris qui attendait là depuis 15 bonnes minutes.
Tous les commentaires (5)
C'est impossible parce qu'il connaissait pas les radiations la ceinture de van elsing et les bovis de ASTRONOGEEK ;-)
Cette mémoire était extrêmement fiable, mais l'inconvénient d'être en lecture seule et de ne pas pouvoir modifier le programme peut être problématique en cas de pépin avec le code.
Comme par exemple lors de la descente du module lunaire d'Apollo 11. Des alarmes 1201 et 1202 se déclenchaient, indiquant que l'ordinateur était surchargé et n'arrivait plus à traiter toutes les données. Cela était causé par un radar qui était resté déployé alors qu'il était censé être éteint durant la descente, et ses informations sautaient l'ordinateur. Heureusement le code était extrêmement robuste et l'ordinateur savait donner priorité aux tâches essentielles comme le guidage et abandonner celles non-essentielles lorsque surchargé. En analysant les entrées et sorties de l'ordinateur, Mission Control a pu décider que cette erreur ne causerait pas de crash du programme et que les astronautes pouvaient malgré tout continuer la descente, ce qu'ils ont fait. Neil Armstrong pilota ensuite manuellement la phase d'atterrissage elle-même, et le module se posa avec succès à 20h17 et 39 secondes UTC dans la Mare Tranquilitatis, où il fut accueilli par Chuck Norris qui attendait là depuis 15 bonnes minutes.
Excellent.
Bien joué le petit hommage...
Joli l'hommage à Chuck
Sinon ce qui me fascine et terrifie c'est les phases de debug d'un truc pareil.
Le machin c'est du binaire, tu run pas en lançant
Python3 monscript.py
Tu dev pendant 3 mois, tu run en test, ah bah faut changer ça.
Chatgpt tu me fais le code ?
"Vtff"
C'est vraiment fascinant, avec un smartphone d'aujourd'hui on a une tellee masse de calcul pour pas grand chose (j'inclus mon com dans ce pas grand-chose)..