Sunburst and Luminary: An Apollo Memoir

In 1966, the author graduated from Boston University with a bachelor's degree in mathematics. He had no immediate job prospects or career plans. He thought he might be interested in computer programming due to a love of solving puzzles, but he had never programmed a computer. When asked, in one of numerous job interviews, how he would go about writing a program to alphabetise a list of names, he admitted he had no idea. One day, walking home from yet another interview, he passed an unimpressive brick building with a sign identifying it as the “MIT Instrumentation Laboratory”. He'd heard a little about the place and, on a lark, walked in and asked if they were hiring. The receptionist handed him a long application form, which he filled out, and was then immediately sent to interview with a personnel officer. Eyles was amazed when the personnel man seemed bent on persuading him to come to work at the Lab. After reference checking, he was offered a choice of two jobs: one in the “analysis group” (whatever that was), and another on the team developing computer software for landing the Apollo Lunar Module (LM) on the Moon. That sounded interesting, and the job had another benefit attractive to a 21 year old just graduating from university: it came with deferment from the military draft, which was going into high gear as U.S. involvement in Vietnam deepened.Near the start of the Apollo project, MIT's Instrumentation Laboratory, led by the legendary “Doc” Charles Stark Draper, won a sole source contract to design and program the guidance system for the Apollo spacecraft, which came to be known as the “Apollo Primary Guidance, Navigation, and Control System” (PGNCS, pronounced “pings”). Draper and his laboratory had pioneered inertial guidance systems for aircraft, guided missiles, and submarines, and had in-depth expertise in all aspects of the challenging problem of enabling the Apollo spacecraft to navigate from the Earth to the Moon, land on the Moon, and return to the Earth without any assistance from ground-based assets. In a normal mission, it was expected that ground-based tracking and computers would assist those on board the spacecraft, but in the interest of reliability and redundancy it was required that completely autonomous navigation would permit accomplishing the mission.The Instrumentation Laboratory developed an integrated system composed of an inertial measurement unit consisting of gyroscopes and accelerometers that provided a stable reference from which the spacecraft's orientation and velocity could be determined, an optical telescope which allowed aligning the inertial platform by taking sightings on fixed stars, and an Apollo Guidance Computer (AGC), a general purpose digital computer which interfaced to the guidance system, thrusters and engines on the spacecraft, the astronauts' flight controls, and mission control, and was able to perform the complex calculations for en route maneuvers and the unforgiving lunar landing process in real time.Every Apollo lunar landing mission carried two AGCs: one in the Command Module and another in the Lunar Module. The computer hardware, basic operating system, and navigation support software were identical, but the mission software was customised due to the different hardware and flight profiles of the Command and Lunar Modules. (The commonality of the two computers proved essential in getting the crew of Apollo 13 safely back to Earth after an explosion in the Service Module cut power to the Command Module and disabled its computer. The Lunar Module's AGC was able to perform the critical navigation and guidance operations to put the spacecraft back on course for an Earth landing.)By the time Don Eyles was hired in 1966, the hardware design of the AGC was largely complete (although a revision, called Block II, was underway which would increase memory capacity and add some instructions which had been found desirable during the initial software development process), the low-level operating system and support libraries (implementing such functionality as fixed point arithmetic, vector, and matrix computations), and a substantial part of the software for the Command Module had been written. But the software for actually landing on the Moon, which would run in the Lunar Module's AGC, was largely just a concept in the minds of its designers. Turning this into hard code would be the job of Don Eyles, who had never written a line of code in his life, and his colleagues. They seemed undaunted by the challenge: after all, nobody knew how to land on the Moon, so whoever attempted the task would have to make it up as they went along, and they had access, in the Instrumentation Laboratory, to the world's most experienced team in the area of inertial guidance.Today's programmers may be amazed it was possible to get anything at all done on a machine with the capabilities of the Apollo Guidance Computer, no less fly to the Moon and land there. The AGC had a total of 36,864 15-bit words of read-only core rope memory, in which every bit was hand-woven to the specifications of the programmers. As read-only memory, the contents were completely fixed: if a change was required, the memory module in question (which was “potted” in a plastic compound) had to be discarded and a new one woven from scratch. There was no way to make “software patches”. Read-write storage was limited to 2048 15-bit words of magnetic core memory. The read-write memory was non-volatile: its contents were preserved across power loss and restoration. (Each memory word was actually 16 bits in length, but one bit was used for parity checking to detect errors and not accessible to the programmer.) Memory cycle time was 11.72 microseconds. There was no external bulk storage of any kind (disc, tape, etc.): everything had to be done with the read-only and read-write memory built into the computer.The AGC software was an example of “real-time programming”, a discipline with which few contemporary programmers are acquainted. As opposed to an “app” which interacts with a user and whose only constraint on how long it takes to respond to requests is the user's patience, a real-time program has to meet inflexible constraints in the real world set by the laws of physics, with failure often resulting in disaster just as surely as hardware malfunctions. For example, when the Lunar Module is descending toward the lunar surface, burning its descent engine to brake toward a smooth touchdown, the LM is perched atop the thrust vector of the engine just like a pencil balanced on the tip of your finger: it is inherently unstable, and only constant corrections will keep it from tumbling over and crashing into the surface, which would be bad. To prevent this, the Lunar Module's AGC runs a piece of software called the digital autopilot (DAP) which, every tenth of a second, issues commands to steer the descent engine's nozzle to keep the Lunar Module pointed flamy side down and adjusts the thrust to maintain the desired descent velocity (the thrust must be constantly adjusted because as propellant is burned, the mass of the LM decreases, and less thrust is needed to maintain the same rate of descent). The AGC/DAP absolutely must compute these steering and throttle commands and send them to the engine every tenth of a second. If it doesn't, the Lunar Module will crash. That's what real-time computing is all about: the computer has to deliver those results in real time, as the clock ticks, and if it doesn't (for example, it decides to give up and flash a Blue Screen of Death instead), then the consequences are not an irritated or enraged user, but actual death in the real world. Similarly, every two seconds the computer must read the spacecraft's position from the inertial measurement unit. If it fails to do so, it will hopelessly lose track of which way it's pointed and how fast it is going. Real-time programmers live under these demanding constraints and, especially given the limitations of a computer such as the AGC, must deploy all of their cleverness to meet them without fail, whatever happens, including transient power failures, flaky readings from instruments, user errors, and completely unanticipated “unknown unknowns”.The software which ran in the Lunar Module AGCs for Apollo lunar landing missions was called LUMINARY, and in its final form (version 210) used on Apollo 15, 16, and 17, consisted of around 36,000 lines of code (a mix of assembly language and interpretive code which implemented high-level operations), of which Don Eyles wrote in excess of 2,200 lines, responsible for the lunar landing from the start of braking from lunar orbit through touchdown on the Moon. This was by far the most dynamic phase of an Apollo mission, and the most demanding on the limited resources of the AGC, which was pushed to around 90% of its capacity during the final landing phase where the astronauts were selecting the landing spot and guiding the Lunar Module toward a touchdown. The margin was razor-thin, and that's assuming everything went as planned. But this was not always the case.It was when the unexpected happened that the genius of the AGC software and its ability to make the most of the severely limited resources at its disposal became apparent. As Apollo 11 approached the lunar surface, a series of five program alarms: codes 1201 and 1202, interrupted the display of altitude and vertical velocity being monitored by Buzz Aldrin and read off to guide Neil Armstrong in flying to the landing spot. These codes both indicated out-of-memory conditions in the AGC's scarce read-write memory. The 1201 alarm was issued when all five of the 44-word vector accumulator (VAC) areas were in use when another program requested to use one, and 1202 signalled exhaustion of the eight 12-word core sets required by each running job. The computer had a single processor and could execute only one task at a time, but its operating system allowed lower priority tasks to be interrupted in order to service higher priority ones, such as the time-critical autopilot function and reading the inertial platform every two seconds. Each suspended lower-priority job used up a core set and, if it employed the interpretive mathematics library, a VAC, so exhaustion of these resources usually meant the computer was trying to do too many things at once. Task priorities were assigned so the most critical functions would be completed on time, but computer overload signalled something seriously wrong—a condition in which it was impossible to guarantee all essential work was getting done.In this case, the computer would throw up its hands, issue a program alarm, and restart. But this couldn't be a lengthy reboot like customers of personal computers with millions of times the AGC's capacity tolerate half a century later. The critical tasks in the AGC's software incorporated restart protection, in which they would frequently checkpoint their current state, permitting them to resume almost instantaneously after a restart. Programmers estimated around 4% of the AGC's program memory was devoted to restart protection, and some questioned its worth. On Apollo 11, it would save the landing mission.Shortly after the Lunar Module's landing radar locked onto the lunar surface, Aldrin keyed in the code to monitor its readings and immediately received a 1202 alarm: no core sets to run a task; the AGC restarted. On the communications link Armstrong called out “It's a 1202.” and Aldrin confirmed “1202.”. This was followed by fifteen seconds of silence on the “air to ground” loop, after which Armstrong broke in with “Give us a reading on the 1202 Program alarm.” At this point, neither the astronauts nor the support team in Houston had any idea what a 1202 alarm was or what it might mean for the mission. But the nefarious simulation supervisors had cranked in such “impossible” alarms in earlier training sessions, and controllers had developed a rule that if an alarm was infrequent and the Lunar Module appeared to be flying normally, it was not a reason to abort the descent.At the Instrumentation Laboratory in Cambridge, Massachusetts, Don Eyles and his colleagues knew precisely what a 1202 was and found it was deeply disturbing. The AGC software had been carefully designed to maintain a 10% safety margin under the worst case conditions of a lunar landing, and 1202 alarms had never occurred in any of their thousands of simulator runs using the same AGC hardware, software, and sensors as Apollo 11's Lunar Module. Don Eyles' analysis, in real time, just after a second 1202 alarm occurred thirty seconds later, was:“Again our computations have been flushed and the LM is still flying. In Cambridge someone says, ‘Something is stealing time.’ … Some dreadful thing is active in our computer and we do not know what it is or what it will do next. Unlike Garman [AGC support engineer for Mission Control] in Houston I know too much. If it were in my hands, I would call an abort.”As the Lunar Module passed 3000 feet, another alarm, this time a 1201—VAC areas exhausted—flashed. This is another indication of overload, but of a different kind. Mission control immediately calls up “We're go. Same type. We're go.” Well, it wasn't the same type, but they decided to press on. Descending through 2000 feet, the DSKY (computer display and keyboard) goes blank and stays blank for ten agonising seconds. Seventeen seconds later another 1202 alarm, and a blank display for two seconds—Armstrong's heart rate reaches 150. A total of five program alarms and resets had occurred in the final minutes of landing. But why? And could the computer be trusted to fly the return from the Moon's surface to rendezvous with the Command Module?While the Lunar Module was still on the lunar surface Instrumentation Laboratory engineer George Silver figured out what happened. During the landing, the Lunar Module's rendezvous radar (used only during return to the Command Module) was powered on and set to a position where its reference timing signal came from an internal clock rather than the AGC's master timing reference. If these clocks were in a worst case out of phase condition, the rendezvous radar would flood the AGC with what we used to call “nonsense interrupts” back in the day, at a rate of 800 per second, each consuming one 11.72 microsecond memory cycle. This imposed an additional load of more than 13% on the AGC, which pushed it over the edge and caused tasks deemed non-critical (such as updating the DSKY) not to be completed on time, resulting in the program alarms and restarts. The fix was simple: don't enable the rendezvous radar until you need it, and when you do, put the switch in the position that synchronises it with the AGC's clock. But the AGC had proved its excellence as a real-time system: in the face of unexpected and unknown external perturbations it had completed the mission flawlessly, while alerting its developers to a problem which required their attention.The creativity of the AGC software developers and the merit of computer systems sufficiently simple that the small number of people who designed them completely understood every aspect of their operation was demonstrated on Apollo 14. As the Lunar Module was checked out prior to the landing, the astronauts in the spacecraft and Mission Control saw the abort signal come on, which was supposed to indicate the big Abort button on the control panel had been pushed. This button, if pressed during descent to the lunar surface, immediately aborted the landing attempt and initiated a return to lunar orbit. This was a “one and done” operation: no Microsoft-style “Do you really mean it?” tea ceremony before ending the mission. Tapping the switch made the signal come and go, and it was concluded the most likely cause was a piece of metal contamination floating around inside the switch and occasionally shorting the contacts. The abort signal caused no problems during lunar orbit, but if it should happen during descent, perhaps jostled by vibration from the descent engine, it would be disastrous: wrecking a mission costing hundreds of millions of dollars and, coming on the heels of Apollo 13's mission failure and narrow escape from disaster, possibly bring an end to the Apollo lunar landing programme.The Lunar Module AGC team, with Don Eyles as the lead, was faced with an immediate challenge: was there a way to patch the software to ignore the abort switch, protecting the landing, while still allowing an abort to be commanded, if necessary, from the computer keyboard (DSKY)? The answer to this was obvious and immediately apparent: no. The landing software, like all AGC programs, ran from read-only rope memory which had been woven on the ground months before the mission and could not be changed in flight. But perhaps there was another way. Eyles and his colleagues dug into the program listing, traced the path through the logic, and cobbled together a procedure, then tested it in the simulator at the Instrumentation Laboratory. While the AGC's programming was fixed, the AGC operating system provided low-level commands which allowed the crew to examine and change bits in locations in the read-write memory. Eyles discovered that by setting the bit which indicated that an abort was already in progress, the abort switch would be ignored at the critical moments during the descent. As with all software hacks, this had other consequences requiring their own work-arounds, but by the time Apollo 14's Lunar Module emerged from behind the Moon on course for its landing, a complete procedure had been developed which was radioed up from Houston and worked perfectly, resulting in a flawless landing.These and many other stories of the development and flight experience of the AGC lunar landing software are related here by the person who wrote most of it and supported every lunar landing mission as it happened. Where technical detail is required to understand what is happening, no punches are pulled, even to the level of bit-twiddling and hideously clever programming tricks such as using an overflow condition to skip over an EXTEND instruction, converting the following instruction from double precision to single precision, all in order to save around forty words of precious non-bank-switched memory. In addition, this is a personal story, set in the context of the turbulent 1960s and early ’70s, of the author and other young people accomplishing things no humans had ever before attempted.It was a time when everybody was making it up as they went along, learning from experience, and improvising on the fly; a time when a person who had never written a line of computer code would write, as his first program, the code that would land men on the Moon, and when the creativity and hard work of individuals made all the difference. Already, by the end of the Apollo project, the curtain was ringing down on this era. Even though a number of improvements had been developed for the LM AGC software which improved precision landing capability, reduced the workload on the astronauts, and increased robustness, none of these were incorporated in the software for the final three Apollo missions, LUMINARY 210, which was deemed “good enough” and the benefit of the changes not worth the risk and effort to test and incorporate them. Programmers seeking this kind of adventure today will not find it at NASA or its contractors, but instead in the innovative “New Space” and smallsat industries.

Historical software development of life-critical systems on very constrained software. Certainly interesting if you’ve worked on an embedded software, or done any assembly programming. Possibly also beyond that niche

A really entertaining story by one of the engineers who helped write the software for the Apollo moon flights. Weaving in the background of the ‘60’s with the challenges of writing the two programs that would navigate Apollo to the moon, and land the LM on the moon. The programs that were encoded and embedded in tiny iron cores had to do an amazing number of tasks during the landing. Integrating inertial measurements, landing radar, descent engine settings, a shifting center of mass as fuel was burned and astronaut inputs, the computer effectively was an amazing man-machine interface. As the descent was in progress, the computer used numeric codes to update the astronauts on the landing sequences. Likewise, the astronauts employed numerical verbs and nouns to give commands to the computer and through the computer, to the landing sequence. Fitting all of the programs necessary into the limited memory available is the behind the scenes story by one of the participants. The hardware and software could quickly reboot in a second when errors occurred or the workload got too high (try that in Windows. You would end up in your own crater on the moon before the reboot was complete). The incredibly small (for the time) yet powerful Apollo computers were at the bleeding edge of technology. And the authors and his colleagues, many in their twenties, did this work at Draper Labs in Cambridge, Ma. Boston back then was a major nidus of computer technology, and even the Apollo computers were built in a Boston suburb. Later, computer technology firms largely decamped to California. This book, along with Mindell's Digital Apollo are the best sources for understanding these critical digital computers and how sophisticated programs squeezed into a limited memory came about and contributed to success.You will also find here the definitive explanation for the program alarms that became a nail-biter during the Apollo 11 landing. I have read a couple of past explanations, but this offers the clearest description of how these came about on the first moon landing flight.One of my favorite stories in the book is when they are working with the Apollo 12 astronauts, Pete Conrad and Alan Bean, to refine the landing programs so that they could make a pinpoint landing on target (Apollo 11 missed by miles). One morning, Bean is late for the simulator run with the new program, so the author gets to be the lunar module pilot for Conrad’s command pilot role. They run exercises of the landing with the newly revised software in the LM simulator. We are also treated to some of the author’s adventures of being young at the end of 1960’s, and the revolutions in music and lifestyles that were occurring at that time. If you have any interest in the space program, don’t miss this book!

Questo libro eccelle per diversi aspetti. Cominciamo dallo stile, dimostrando che anche gli ingegneri sanno scrivere bene ed in modo interessante. Il contesto storico e sociale è anche rappresentato, un aspetto fondamentale perchè ogni grande opera umana nasce anche come riflesso del contesto in cui si è sviluppata.L'accuratezza tecnica poi è senza precedenti perchè l'autore è stato uno dei tanti protagonisti del programma Apollo, quelli che le cose le hanno fatte davvero e soprattutto hanno avuto modo di interagire con una delle parti più critiche dell'intera missione: l'atterraggio sulla Luna.Il libro evidenzia ovviamente il ruolo del computer di bordo (uno dei massimi successi del programma Apollo, ancor oggi oggetto di studio e approfondimento) e dunque del suo software. Quando si parla di software per un veicolo spaziale, o in generale di un software che controlla qualcosa, è evidente che nel progetto rientrano tantissimi degli aspetti del veicolo: dagli altri componenti dell'avionica di bordo, ai propulsori, agli indicatori per l'equipaggio, ai modi operativi, alle funzioni autonome, e così via. Chi lavora in questo tipo di applicazioni ha dunque una cultura superiore: è uno specialista del suo campo ma deve avere competenze che in tanti altri aspetti. Per questo motivo Don Eyles è in grado di spiegare tutte le finezze dell'atterraggio sulla Luna, dalla traiettoria alla gestione del motore, e così via, e lo fa non solo per Apollo 11 ma anche per le missioni successive perchè il software del computer di bordo si è evoluto di missione in missione.Per Apollo 11 in particolare, la prova del fuoco per le funzioni del software che gestivano al discesa e l'atterraggio, viene spiegato in dettaglio preciso il perchè degli allarmi che hanno complicato il già difficile lavoro di Armstrong (che considerava l'atterraggio sulla Luna come il vero successo della missione), e perchè la missione ha rischiato di essere annullata per un altro fattore scoperto solo dopo il rientro dell'equipaggio.La complessità inerente in questo tipo di sistemi è enorme, le soluzioni adottate nel programma Apollo erano adattate alla tecnologia dell'epoca, ma i fondamenti teorici sono gli stessi che si usano oggi. Eyles spiega tutto nei particolari, ma senza appesantire troppo la discussione e allo stesso tempo illustra il "modus operandi" del suo mondo, decisamente diverso da quello industriale, ma non per questo meno rigoroso. Il modo di lavorare era alla fine diverso, ma in alcuni aspetti riconducibile per la parte formale, ai metodi che usiamo oggi: erano gli anni in cui le tecniche di "software engineering" si sono sviluppate e dunque si era in un contesto molto più avanzato di quello che si pensa comunemente.Il fatto che Eyles abbia anche assistito tutti i comandanti di missione lunare nell'addestramento all'uso del computer per la fase di atterraggio, gli permette anche di svelare altri aspetti di questi personaggi, spesso considerati gli attori principali, ma che invece erano solo utenti del lavoro di centinaia di migliaia di persone che hanno consegnato un prodotto eccellente in tempi miracolosi. Diceva bene Micheal Collins quando dichiarava che l'equipaggio era solo come il periscopio di un sottomarino: è la parte più visibile di un insieme incredibilmente più grande e più complesso.Per tutti questi motivi non ci sono dubbi che questo libro possa considerarsi uno dei "top five" in una classifica ideale dei migliori libri scritti sul programma Apollo.

In "Sunburst and Luminary" (die Namen zweier Computerprogramme für Mondflüge) beschreibt Don Eyles seine Arbeit als Computeringenieur für mehrere NASA-Raumfahrtmissionen. Er begann seine Aufgabe im Alter von 23 Jahren, frisch von der Uni, ohne jegliche Computer-Kenntnisse.Der Autor verhilft dem Leser zu einem neuen Blick auf das US-Raumfahrtprogramm in den 1960er Jahren. Genauer gesagt auf den nach heutigen Maßstäben winzigen und schwachen Rechner dessen Programm den Abstieg zur Mondoberfläche steuerte. Dieses Programm hat der Autor geschrieben.Eyles erzählt im Laufe des Buches von seinen Begegnungen mit namhaften Astronauten und NASA-Managern und seine Eindrücke von ihren Charakteren und Fähigkeiten. Seine Geschichten sind prägnant, kohärent und vollständig, das Buch ist sowohl unterhaltsam als auch lehrreich. Der Leser erfährt etwas über die Technologie der sechziger Jahre, über Computer, Simulatoren, Verfahren und Techniken. Er schildert (quasi in einem eingebauten zweiten Buch) die Stimmung im Boston dieser Zeit, wenn er Sex, Drogen und die anderen Aufregungen dieser Ära, die dem Silicon-Valley vorausging, erkundet.Diese Memoiren sind eine neue Art von Buch über das Apollo-Projekt. Das Buch entwirft eine neue Innenansicht auf das Mondlandungsprogramm, von einem der selbst „Bits geschubst“ hat. Von einem Programmierer, der selbst in der „Ölwanne“ gearbeitet hat.Aber auch die jungen Programmierer der heutigen digitalen Kultur, die die Beobachtungen des Autors über die Kunst des Programmierens, ihrer möglichen Irrtümer, Probleme und Anstrengungen mitbekommen, können sich vielleicht mit Don Eyles identifizieren.Ja, junge Programmierer können durchaus noch lernen, wenn sie sich anregen lassen tiefer zu graben und z. B. den Hintergrund des 1204-Alarms während der Endphase der Apollo-11-Landung genauer zu analysieren.

In his notes at the start of this fine book, author Don Eyles comments that the conventional gatekeepers of the publishing world, literary agents and editors, refused to represent his book due to its technical nature. More fool them. Eyles was in at the heart of the Apollo moonlanding adventure and he has fabulous stories to tell that any reasonably intelligent person can grasp and be enthralled by. It is a slur on the publishing industry that he had to struggle to get this book out. But thank goodness he did.Eyles's strength is that he confounds the stereotype of the square engineer with the pocket-protector; a caricature that is often used to characterise the folk who organised and carried out the immense engineering triumph that was the Apollo program. He is the guy who wrote the software that ran in the spacecraft's computer to fly Armstrong and Aldrin safely to the lunar surface, then repeat the feat five more times. The first landing was not without hair-raising moments with computer alarms and restarts and Eyles expertly dissects exactly what was going on and how it was addressed. He also relates his starring role in a virtuoso piece of computer hacking that saved the Apollo 14 mission moments before it would have been aborted.But Eyles is culturally sensitive. He strides the artificial barrier that western culture has built between the arts/humanities and science/engineering. He breaks away from the stuffy norms of the sixties and seventies establishment. He enjoys a joint, sees the Stones and Joplin in concert and takes in the power of opera. He protests against the Vietnam War and gets tear-gassed; all the while writing and refining software for NASA's most precious spacecraft, the lunar module, and revelling in the great adventure of Apollo. He even labels one of the lunar module's computer subroutines as BURNBABY, a shout-out to a legendary DJ and his love of hot music. We get a picture of his life within the space program and his intimacy with the electronic brains of the machines that carried it out; and also outside the program where the love of a woman mattered more.Eyles views the Apollo program as something greater than just one-upmanship against the Soviets. Rather he sees space exploration as having the potential to transform human society and believes it is important for those at the centre of great events to leave behind their account of it. Eyles does so in spades and takes the reader into a world of creativity, risk and ingenuity that led to an ultimately satisfying adventure of human exploration.

Suivre la conception du logiciel de vol du LEM à travers le récit d'un ingénieur de l'équipe de développement est vraiment une porte ouverte sur le temps et l'espace. C'est documenté, précis, rien n'est laissé dans l'ombre, on a toutes les explications. L'auteur a de plus un véritable talent pour rendre son récit captivant.J'ai lu pas mal d'ouvrages documentant la conception de systèmes, dont le célèbre "The soul of a new machine" de Tracy Kinder, qui a obtenu le prix Pulitzer pour cet ouvrage, et je peux affirmer que Sunburst and Luminary: An Apollo Memoir est du même niveau d'excellence.

Absolute masterpiece! I could not put it away. It is written very well technically but also gives a wide panoramic view of the era - 50s and 60s were full of interesting political and cultural events. We meet Mr Webb and Mr Gates and many, many other famous figures throughout the story. Highly recommended.