Как, находясь на Земле, пропатчить программу на компьютере, летающем вокруг Луны? Очень осторожно.
Миссия "Аполлона-14", которой командовал Алан Шепард (единственный астронавт из программы "Меркурий", летавший на Луну в составе миссии «Аполлон») была повторением плана посадки на Луну "Аполлона-13", от которой в своё время отказались. Шепард в компании пилота лунного модуля Эда Митчелла и пилота командного модуля Стю Русы нацеливались на кратер Фра Мауро – холмистую местность неподалёку от Лунного экватора и недалеко к югу от гигантского кратера Коперника. Считалось, что Фра Мауро, появившийся, скорее всего, благодаря выбросу вулканом пород во время создания Моря Дождей, содержит материалы из глубин Луны, которые могут пролить свет на происхождение нашего спутника.
За восемь месяцев с момента неудачного полёта «Аполлона-13» инженеры внесли несколько изменений в космический корабль с целью уменьшения вероятности повторного взрыва. Чтобы гарантировать возвращение команды домой в случае очередной внештатной ситуации, добавили дополнительный бак с кислородом и аккумулятор. Незапланированная пауза дала время на обновление программ в компьютере лунного модуля; особенно долгожданной стала возможность компьютера распознавать изменения высоты поверхности при приближении к месту посадки. Благодаря этому компьютер уже не запутывала волнистая поверхность спутника на подлёте спускаемого аппарата к поверхности.
Команда Аполлона-14, 11 января 1971 года. Слева направо: Эд Митчелл, Эл Шепард и Стю Руса.
Официальный портрет команды, декабрь 1970
Митчелл, Шепард и Руса готовятся к прогону на симуляторе в космическом центре Кеннеди, 26 января 1971. До запуска всего пять дней.
Шепард на фоне симулятора лунного модуля, 26 января 2971
Завтрак перед запуском, утром 31 января 1971. Слева, по часовой стрелке: пилот лунного модуля Эл Митчелл, главный астронавт Том Стэффорд, пилот лунного модуля Стю Руса, командир Эл Шепард, глава полётных операций Дик Слейтон, запасной пилот лунного модуля Джо Ингл и запасной пилот командного модуля Рон Эванс
Командир Шепард во время процедуры одевания перед стартом
Задумчивый Руса во время одевания
Команда «Аполлона-14» идёт по коридору в фургон для перевозки
Команда садится в фургон, который доставит их к ожидающей ракете «Сатурн-5»
Команда в Белой комнате рядом с капсулой, с лидером пусковой команды Гюнтером Вендтом. В рамках традиционного обмена подарками перед запуском команда подготовила для Вендта шлем полковника Клинка [отсылка к американскому ситкому Hogan's Heroes 1970-х годов про немецкий лагерь военнопленных Второй мировой / прим. перев.], а тот подготовил для Шепарда тросточку – намёк на то, что в случае успеха миссии 47-летний Шепард станет самым старым человеком, ступавшим на луну [надпись на записке для трости: поддерживающее оборудование для лунного исследователя]
Все, что случилось с нами, лишь пролог*
[У. Шекспир, «Буря» / прим. перев.]
Днём 31 января 1971 года космическая ракета Сатурн-5 с грохотом взлетела с космического центра им. Кеннеди, задержавшись всего на 40 мин из-за погоды. Перезапустив третью ступень S-IVB для выхода на траекторию к Луне, командный модуль «Китти Хок» с командой отправились в сторону нашего спутника.
Почти сразу после постановки на траекторию выхода на орбиту вокруг Луны появилась серьёзная проблема, когда «Китти Хок» попытался пристыковаться к лунному модулю миссии, «Антаресу». Защёлки размером с ноготь на стыковочном модуле не смогли захватить его, и два космических корабля не сумели состыковаться. Только после нескольких попыток «Китти Хок» смог удачно поймать и надёжно присоединить к себе «Антарес». После этого S-IVB отправили на одинокую, но яркую смерть, и комбинированный корабль «Аполлон-14» продолжил свой путь к Фра Мауро.
Четыре дня путешествия оказались небогатыми на события – по крайней мере, для путешествия на Луну. Выход на лунную орбиту случился на 82-й час полёта. Для экономии ценного топлива в лунном модуле комбинированный корабль снизился, через несколько часов заняв орбиту с перигеем в 14,5 км. На следующий день с активации и проверки лунного модуля началась подготовка к спуску.
Однако всего за четыре часа до запланированной посадки диспетчеры заметили, что, судя по индикации на консолях в центре управления полётом, нажата кнопка отмены на лунном модуле. По радио Шепард подтвердил, что на борту «Антареса» никто не нажимал кнопку отмены – а это означало, что где-то в запутанных кишочках лунного модуля произошло короткое замыкание или иная электрическая проблема.
Такая проблема в потенциале могла и закончить миссию: если кнопка нажата, а двигатель работает, то лунный модуль должен немедленно начать процедуру отмены сразу после спуска, что сделает посадку невозможной.
SA-509, ракета Сатурн-5, которая должна доставить Аполлон-14 на Луну, выкатывается из здания вертикальной сборки на гусеничном транспортёре. Утро 9 ноября 1970 года.
SA-509 на взлётной площадке 39А во время теста обратного отсчёта, 19 января 1971
SA-509 медленно карабкается в небо, 31 января 1971
Снимок запуска Аполлона-14 с камеры, расположенной на башне запуска. Сверху видно командный модуль «Китти Хок» в защитной облочке.
Третья ступень SA-509 отбрасывается перед извлечением лунного модуля. На её передней части всё ещё находится лунный модуль «Антарес»
Широкоугольный снимок 2-й комнаты центра управления в Хьюстоне во время исправления ошибки с извлечением лунного модуля. На самом правом экране видно, что «Антарес» всё ещё ожидает отсоединения от S-IVB
В условиях ограниченного времени в центре управления нужно было быстро понять, что не так, и придумать способ обойти эту проблему. В итоге они придумали самый гениальный из всех компьютерных хаков в истории миссии «Аполлон», и, возможно, за всю историю электронных компьютеров.
Чтобы точнее пояснить, что это был за хак, как он работал, и с какими проблемами столкнулись разработчики во время его создания, нам нужно сильнее углубиться в работу бортового управляющего компьютера «Аполлона». Держитесь – мы погружаемся.
Разбираем бортовой управляющий компьютер «Аполлона»
Бортовой управляющий компьютер «Аполлона» часто описывают как обычный калькулятор, или сравнивают с чипом контроллера часов или микроволновки. Однако ваши часы кроме времени мало что показывают. Управляющий микроволновкой чип тупо запускает и останавливает магнетрон для разогрева курочки с истёкшим сроком годности. У этих устройств происходит мало взаимодействия с окружающим оборудованием, они не проводят сложных вычислений и не принимают решений.
Описывая «компьютер», ожидаешь, что у этой системы найдутся возможности, которые мы приписываем современным компьютерам – к примеру, способность запускать несколько программ одновременно, или выдавать простой и интуитивно понятный интерфейс, управлять широким спектром устройств и аккуратно восстанавливаться после ошибок в приложениях. «Ха!» – можете воскликнуть вы, «да я в кармане ношу такой компьютер!»
В идею о том, что подобные возможности существовали почти 60 лет назад, верится с трудом, однако у бортового управляющего компьютера «Аполлона» было и это, и многое другое. Интерпретатор для обработки «виртуальных» машин, похожий на байт-код Java? Есть. Возможность удалённого обновления данных? Ага. Учитывая все эти возможности, разумно сравнивать бортовой управляющий компьютер «Аполлона» с современным смартфоном. Да, бортовой управляющий компьютер «Аполлона» был медленнее, у него было куда как меньше памяти, но лишь из-за неудачной даты рождения, из-за чего он оказался не на том конце кривой закона Мура.
И хотя процессор, выполнявший по 80 000 инструкций в секунду, был не особенно быстрым, сложно преувеличить ограничения, накладываемые скудным объёмом его памяти на разработчиков ПО. Представьте себе эти ограничения: все программы для полёта на Луну и обратно должны были умещаться в 36 К слов (слова по 15 бит, плюс бит чётности), на памяти только для чтения на прошитых магнитных сердечниках. И поскольку бортовой управляющий компьютер «Аполлона» не работал с «байтами», все 15 бит слова считывались за один раз, и простого способа разбить слово на более мелкие составляющие не было.
Несколько дисковых накопителей IBM 2314 (белые) и устройство для чтения и перфорирования перфокарт IBM 2540, 1968 год.
Дополнительный накопитель использовать было нельзя – дисковые модули, которые тогда были размером со стиральную машину, не поместились бы в космический корабль. Магнитную ленту, надёжный и реальный вариант, рассматривали уже слишком поздно для того, чтобы включать её в проект компьютера. Все программы бортового управляющего компьютера «Аполлона» содержались внутри модулей на прошитых сердечниках внутри самого компьютера – это была коробка весом 32 кг и размерами 61х32х17 см.
В дополнение к 36К слов памяти только для чтения, у бортового управляющего компьютера «Аполлона» была RAM всего на 2К слов – это было необходимо для работы операционной системы, управления процессами, восстановления и глобальных переменных всех фаз миссий. И всё. В эту жалкого размера память были втиснуты выделенные области памяти, используемые приложениями: программами, выполнявшими задачи навигации и управления, приземлением на Луну и встречами. Каждой базовой программе выделялось целых семь слов на хранение временных переменных. Нет, это не опечатка.
Легко быть циничным, вспоминая все эти ограничения при установке на ноутбук какой-нибудь новой программы, занимающей несколько гигабайт.
Бортовой управляющий компьютер «Аполлона» (слева), с модулем интерфейса дисплея и клавиатуры (справа). Размер компьютера 61×32×17 см
Как работал бортовой управляющий компьютер «Аполлона»: задачи и задания
В начале 1960-х, в ранние дни микрокомпьютеров, было совершенно нормально использовать компьютер с редкими обращениями к монитору. Вы загружали одну программу, давали ей отработать, а потом просматривали её вывод. Довольно быстро стало понятно, что такой способ очень сильно тратит ресурсы, и в мейнфреймах появилось понятие «мультипрограммирования», кардинально улучающее утилизацию системы. А небольшим компьютерам, которым недоставало памяти, поддержки оборудования и инструментов для системного программирования, оставалось запускать свои отдельные приложения по очереди.
И хотя бортовой управляющий компьютер «Аполлона» был реально небольшим компьютером для своего времени, выполнение программ по одной не устраивало его проектировщиков. Компьютеру космического корабля с широким диапазоном запросов к быстродействию требовался какой-то пользовательский интерфейс, и ввиду непредсказуемых колебаний трафика ввода и вывода выполнение программ по отдельности отмели сразу же. Было необходимо реализовать ОС с мультипрограммированием – способную разбивать работу на удобоваримые кусочки и планировать их исполнение по необходимости.
На бортовом управляющем компьютере «Аполлона» выполнялись программы двух типов – «задачи» [jobs] и «задания из списка ожидания» [waitlist tasks]. Задачи запускались независимо, у них была крохотная выделенная область в памяти для переменных, и они пользовались приоритетом в очереди на запуск.
Модуль интерфейса дисплея и клавиатуры бортового управляющего компьютера «Аполлона» на своём месте в командном модуле «Аполлона» (у командного модуля обычно был запасной модуль интерфейса дисплея и клавиатуры, расположенный в нижнем отсеке)
Модуль интерфейса дисплея и клавиатуры бортового управляющего компьютера «Аполлона» в лунном модуле. На переднем плане – справочная таблица.
Внутри модуля на прошитых сердечниках. После изготовления такие модули обычно заливали эпоксидкой для защиты от вибраций. В данном модуле эпоксидки нет, и видно сердечники.
Внутри модуля бортового управляющего компьютера «Аполлона» с плоским корпусом и дискретной электроникой
Модули внутри бортового управляющего компьютера «Аполлона»
Почти все задачи были не большими программами, которые бы преимущественно ничего не делали и отъедали ресурсы – это были небольшие программки, работавшие недолго, и с узко определёнными функциями. По завершению работы задача планировала свой запуск на некий момент в будущем, или заканчивала выполнение, ожидая, что её перезапуск запланирует какая-нибудь другая задача. Таким образом задачи постоянно создавались и прекращались, и количество работы, требовавшееся от компьютера, очень сильно менялось в зависимости от фазы миссии.
В отличие от других систем того времени, где запуск и прекращение процесса было делом трудоёмким, планирование выполнения задач на бортовом управляющем компьютере «Аполлона» было тривиальным. На современных системах создаются виртуальные адресные пространства и области страничного обмена, процедуры выделения памяти резервируют рабочие области хранения, создаётся сложное безопасное окружение. Ничего такого не требовалось для бортового управляющего компьютера «Аполлона» (и даже концепций таких во время его разработки не существовало). Всё, что требовалось, это запросить свободное место («набор сердечников») в таблице процессов, и передать управление программе. Закончить процесс было так же просто – задача запрашивала очистку выделенного для процесса места, и в этот момент переставала существовать.
Процесс выполнения программ бортового управляющего компьютера «Аполлона» тщательно контролировался, чтобы гарантировать наличие свободных наборов сердечников для выполнения нужного количества задач на каждой стадии полёта. Если бортовой управляющий компьютер «Аполлона» не смог бы найти свободный набор сердечников – чего не должно было быть – он выдавал программный сигнал тревоги «1202». И так сложилось, что это невозможное событие действительно произошло во время посадки «Аполлона-11», и только быстрая реакция центра управления исправила ситуацию, которая иначе могла бы обернуться опасной отменой посадки.
Что важно для компьютера, работающего в реальном времени, у задач была примечательная способность определять точку, с которой их можно было бы перезапустить при появлении в системе проблемы. Логика обработки была разработана так, что когда программа доходила до важной фазы вычислений, можно было определить точку перезапуска. В случае перезапуска системы (но не полной перезагрузки, которая стёрла бы все данные в RAM), данные в памяти сохранялись, и задача могла возобновлять работу с предварительно заданной точки перезапуска так, будто ничего не произошло. Такая способность оказалась полезной во время проблем с посадкой «Аполлона-11», когда компьютеру пришлось перезапускаться много раз, но он продолжал вести лунный модуль к цели посадки без проблем.
Часть комплекса вычислений в реальном времени, расположенного на первом этаже центра управления полётами в Хьюстоне. НАСА использовало несколько мейнфреймов IBM System/360 для обслуживания каждой миссии «Аполлон», но на космических кораблях и близко не было места для размещения мейнфрейма целиком
На дисплее и клавиатуре (которые называли DSKY, и произносили как слово, рифмующееся с «виски») расположено немного сбивающее с толку поле под названием PROG, сокращение от program. Обычный наблюдатель может ошибочно решить, что в этом поле видна программа, работающая в данный момент на бортовом управляющем компьютере «Аполлона» (проигнорировав тот факт, что в фоне работают множество других процедур). Точнее сказать, там демонстрируется номер программы под названием «основной режим», отражающий фазу полёта или навигации, которую астронавту нужно завершить. При этом дисплей основного режима в основном нужен был только для членов команды, чтобы они понимали цель исполняющейся в данный момент программы. Лишь в нескольких местах к числу, демонстрировавшемуся на этом дисплее, обращались другие программы – и как раз один из этих случаев оказался критически важным для нашей истории.
Задания из списка ожидания представляли собой нечто совсем иное, нежели задачи. По определению это ещё более простые программы, чем задачи – это были чрезвычайно короткие и критически важные задачи, которым не нужны были выделенная память или сложное управление процессами. На считывание угла поворота инструмента или данных акселерометра из модуля измерения инерции уходило всего несколько машинных инструкций, однако эта работа была необходима для вычислений, проводившихся программами навигации, ориентирования и управления. Поэтому было жизненно важно выдавать данные, полученные с модуля измерения инерции, через точно заданные временные промежутки, из-за чего задания выполнялись по жёсткому графику.
Другие задания из списка ожидания отвечали за отключение маневровых двигателей, запускаемых цифровым автопилотом, или проверку факта нажатия упомянутой ранее кнопки отмены. Эти задания запускались по заранее установленным таймерам, и работали, подавляя все другие события, поскольку ожидалось, что каждое из них будет длиться лишь крохотную долю секунды.
Как создавали виртуальные машины в 1960-х
На бортовом управляющем компьютере лунного модуля могло выполняться до восьми задач одновременно (и до семи в компьютере модуля командования и обслуживания), и из этих восьми в пяти мы могли бы сегодня признать, с некоторыми допущениями, «виртуальные машины». Каждая из них могла выполняться независимо, со своим собственным приоритетом, хотя и без изолированного адресного пространства.
Это может показаться странным, но некоторым из наиболее загруженных задач был назначен более низкий приоритет. Основная процедура посадки на луну, Program 63 (или просто P63), имела более низкий приоритет, чем большая часть остальных задач. И это имело смысл, поскольку объём и сложность Р63 легко могли монополизировать все вычислительные ресурсы компьютера. Назначив этой интенсивной задаче низкий приоритет, ей позволяли выполнять небольшие, короткие, но критически важные отрезки работы. Во многих случаях эти мелкие программы выполняли жизненно важные операции – управление ориентацией корабля, чтение данных с радара, обновление дисплеев астронавтов.
Чарльз Старк Дрейпер, основатель и директор Лаборатории измерительных приборов Массачусетского технологического института (позже была отделена от института и переименована в Лабораторию Чарльза Старка Дрейпера), изучает макет системы контроля «Аполлона», 1963
Железо в основе бортового управляющего компьютера «Аполлона» страдало от извилистой эволюции компьютера, следы которого начинаются с 1960-го года, с компьютера, разработанного для предполагавшейся миссии на Марс. К тому времени, как с MIT заключили контракт на создание бортового компьютера для управления и навигации «Аполлона» в 1961, «марсианский компьютер» развился уже до того, что умел выполнять восемь разных машинных инструкций и работал с памятью из 4К слов. Этого было смехотворно мало даже для полёта на Луну, однако разработка железа и софта с нуля просто не укладывалась в назначенные президентом США Кеннеди сроки «до конца десятилетия». Это железо взяли за точку отсчёта и изо всех сил развивали, выжимая из архитектуры всё, что только можно.
Однако и такой вынужденной эволюции оказалось недостаточно – железу недоставало жизненно важных способностей. Программам для космического корабля требуются сложные операции – работа с матрицами, тригонометрические функции, множество переменных большой точности. Эти требования могла бы удовлетворить объёмная библиотека ПО, однако постоянные вызовы и возвраты из бесконечных библиотечных функций съели бы всю ограниченную память и вычислительные возможности. Требовалось более удачное решение. И для создания совершенного новой среды для выполнения программ была придумана совершенно новая (для того времени) техника программирования, повлекшая за собой создание новой программной «архитектуры».
Чтобы справиться с ограничениями бортового управляющего компьютера «Аполлона», разработчики создали программу-«интерпретатор» – и это подводит нас к «виртуальной машине».
Для начала представил новый язык с новой стэковой префиксной нотацией. Выделялись области памяти впечатляющего объёма в 43 слова («область накопления векторов, или VAC), по одной для каждой из одновременно запущенных интерпретируемых программ, общим числом до пяти. Как и набор сердечников, эти VAC были ограничены, и ими приходилось тщательно управлять, поэтому казалось невозможным, что они могут исчерпаться. Иначе же вызывалась программная тревога „1201“.
В „интерпретаторе“ операции были совершенно непохожи на машинные инструкции, использовавшиеся в других частях кода бортового управляющего компьютера „Аполлона“. Одна-две инструкции упаковывались в одно слово, за которым следовал список адресов, с которыми нужно было работать инструкции. Работавшие в „интерпретаторе“ программы жировали на списке инструкций из 128 новых операций, в которых новое окружение реализовывало необходимые для полёта математические операции.
Кроме того, окружение „интерпретатора“ обеспечивало функции, которых не было у железа. Сюда входили возможности, знакомые программистам ПО, работающим с языками высокого уровня – индексные регистры, сложное ветвление программ, маски. Вся эта новая сложная функциональность „интерпретатора“, реализованная с использованием менее 2,5К слов, создавала совершенное новое программное окружение. Кроме высокоуровневых функций, „интерпретатор“ скрывал изощрённую систему работы с банками памяти – к облегчению разработчиков бортового управляющего компьютера „Аполлона“. Не будет преувеличением сказать, что созданное „интерпретатором“ окружение по многим параметрам похоже на современные виртуальные машины.
Язык модуля интерфейса дисплея и клавиатуры
Читая эту статью, редактируя фотографии из своей коллекции, просматривая очередную фотку с котиком, вы взаимодействуете с богатым графическим интерфейсом, делающим навигацию по экрану относительно безболезненной. Но элементы взаимодействия с компьютером, очевидные сегодня, являются результатом проб и ошибок, многолетних экспериментов и изучения фокус-групп.
Но как спроектировать интуитивно понятный и интерактивный интерфейс для компьютера, работающего в реальном времени, если раньше никто этого не делал? Также важно понять, как должен выглядеть дисплей, какие данные потребуются астронавту для выполнения миссии, и в каком формате.
Инструменты блока II командного модуля „Аполлона“. Сможете найти модуль интерфейса дисплея и клавиатуры?
Рубки самолёта и космического корабля кажутся перегруженными, каждый кусочек доступного пространства покрыт измерительными приборами, специальными инструментами и переключателями. Куда втиснуть подобный интерфейс? Традиционную QWERTY-клавиатуру никогда не рассматривали в качестве варианта для бортового управляющего компьютера „Аполлона“. Можно представить себе трагикомическую картину – астронавт в неуклюжих перчатках в условиях сильного ускорения и вибраций пытается вбить критически важную команду.
Модуль интерфейса дисплея и клавиатуры разрабатывали так, чтобы он играл роль интерфейса, и предлагал цифровую клавиатуру совместно с клавишами для специальных операций; дисплей из трёх-пяти цифровых регистров, куда можно было вводить данные и откуда их можно было считывать; десятки лампочек, сигнализирующих о проблемах. Три дисплея поменьше показывали работающую в данный момент программу (т.н. „основной режим“, упомянутый ранее), и тип данных, с которыми она работает. Да, и там было поле, мигавшее, когда компьютер был занят – вероятно, чтобы демонстрировать команде активность процесса, который иначе никак не увидеть.
Хорошо проработанный интерфейс должен определять язык общения пользователя и машины – превращающий нужды и желания пользователя в запросы, которые легко будет понять программе. В результате гениального прозрения такой „язык“ бортового управляющего компьютера „Аполлона“ основывался на общении людей.
Представьте, что к вам на улице подходит человек с минимальным знанием языка, и говорит просто „есть, пицца“. С грамматической точки зрения эта фраза нелепа, но через какое-то время вы догадываетесь, что человек хочет есть, и есть пиццу. Несколько жестов, и вы направляете его в сторону ближайшего ресторана. Ключевым моментом данного общения является наличие действия, обозначаемого глаголом [verb], и объекта, обозначаемого существительным [noun].
Подобное общение настолько интуитивно, что компьютеры использовали комбинации глагол-существительное. Мы видим, что от машинных инструкций (ADD [Memory Location]), команд (EDIT LETTER.TXT) и до графических интерфейсов (File > Print > taxes.xls) такие конструкции используются повсеместно.
Неудивительно, что на модуле интерфейса дисплея и клавиатуры выделяются две кнопки – VERB и NOUN.
Расшифровка модуля интерфейса дисплея и клавиатуры от бортового управляющего компьютера „Аполлона“
Другие клавиши модуля интерфейса дисплея и клавиатуры тоже довольно ожидаемые. Клавиша ENTER командует компьютеру принять только что введённые данные, клавиши ± обеспечивают знак десятичных чисел, клавиша PRO (сокращение от „PROCEED“) позволяет астронавту принять новое событие – запуск двигателя или новую фазу программы.
Поскольку бортовой управляющий компьютер „Аполлона“ – система мультипрограммная, может случиться так, что процедуре необходимо выдать данные команде в то время, как другая программа уже взаимодействует с астронавтом. Лампочка KEY REL (от „KEYBOARD RELEASE“) сигнализирует, что другая программа требует внимания, и запрашивает освобождение клавиатуры с тем, чтобы она смогла использовать дисплей. Нажатие KEY REL очищает текущий дисплей и выдаёт астронавту новые данные из процедуры, работавшей в фоне.
Диалог с бортовым управляющим компьютером „Аполлона“ ведётся посредством комбинации числовых глаголов и существительных. Глаголы можно использовать для ввода или запроса данных. Но каких? На этот вопрос отвечает существительное. К примеру, последовательность запроса компьютера о выводе на дисплей времени грядущего запуска двигателя на модуле интерфейса дисплея и клавиатуры выглядит так:
VERB 06 ENTER, NOUN 33 ENTER
VERB 06 – запрос на вывод десятичного числа, NOUN 33 уточняет, что запрос касается параметра „время зажигания“. Компьютер реагирует при помощи трёх дисплеев (»регистров"), выводя на них час, минуту и секунду, в которую должен заработать двигатель. Некоторые глаголы работают сами по себе, к примеру, VERB 57, сообщающий компьютеру, что данные с посадочного радара лунного модуля достоверные, и их можно включить в уравнения управления приземлением.
Понимаю разочарование людей, ожидавших детального учебника по работе с компьютером. На самом деле, это, в общем-то, и всё. Прелесть бортового управляющего компьютера «Аполлона» и модуля интерфейса дисплея и клавиатуры в том, что практически всё взаимодействие с ними шло через простые глаголы и существительные. Однако помнить около 100 глаголов и примерно столько же существительных довольно сложно, поэтому «подсказки» для кодов были закреплены на панелях модуля интерфейса дисплея и клавиатуры в модуле командования и обслуживания и лунного модуля.
Подсказка с глаголами и существительными
Ещё одна подсказка, из нижнего отсека командного модуля «Аполлона» (эта ограничена командами, связанными с навигацией)
Подготовка к Фра Мауро: проблема с отменой
Лунный модуль «Аполлона» был чудом инженерной мысли. Обе нереально лёгкие части космического аппарата, для фаз подъёма и спуска, были оптимизированы для своих этапов миссии. Для посадки на Луну требуются большие топливные баки, опорные стойки, и, самое важное, большой маневровый двигатель. И хотя для посадки всё это было необходимо, оно стало бы мёртвым грузом при возвращении – поэтому от него избавились на поверхности, и на орбиту вышла только подъёмная ступень. По сути, ничего кроме кабины, небольшого двигателя и системы жизнеобеспечения, рассчитанной на сутки, там не было, и эта ступень привезла команду и их научные изыскания обратно к ожидавшему на орбите командному модулю.
Общая схема посадки на Луну. Аэродинамические профили или парашюты отпадают из-за отсутствия атмосферы, и остаётся только один способ – посадка на ракете.
Как конкретно происходит посадка на Луну на «Аполло-14». Скан с полётного плана показывает все шаги, которые необходимо выполнить.
Продолжение плана посадки, сразу после старта двигателя и до момента, когда проходит три минуты (TD+3). В таблице, кроме прочего, перечислены ожидаемая скорость посадки и высота.
Процедуры отмены работы лунного модуля пользовались наличием двух отдельных ступеней. Если проблема появлялась на ранних стадиях спуска, то весь корабль возвращался на орбиту при помощи работающего двигателя для спуска. На поздних стадиях спуска, когда в ступени спуска практически заканчивалось топливо, её отсоединяли и запускался подъёмный двигатель, возвращавший команду в безопасность.
Примерно через 45 минут после расстыковки для спуска на Луну, команда «Антареса» была всецело занята проходом по списку необходимых действий, выстраивая систему наведения и обеспечивая готовность лунного модуля к спуску. На Земле командам в Хьюстоне было известно о работе лунного модуля и его систем гораздо больше. Телеметрия, преодолевавшая расстояние от Луны до Земли со скоростью в 50 Кб/с, содержала огромное количество информации по кораблю, большая часть которой команде была не видна.
Именно в этот момент на контрольной консоли GUIDO в Хьюстоне, которая наблюдала за компьютерными системами, заметили, что установлен бит статуса, отвечающий за нажатие кнопки Abort (отмены). Такого очевидно не должно было происходить – если только команда не нажала эту кнопку, а Шепард с Митчеллом категорически подтвердили, что они этого не делали.
Затем команде отправили запрос на демонстрацию канала I/O, где содержался бит отмены. Команда ввела команду:
VERB 11 ENTER, NOUN 10 ENTER, 30 ENTER
VERB 11 – запрос на отслеживание восьмеричных данных в первых регистрах трёх дисплеев модуля интерфейса дисплея и клавиатуры. NOUN 10 обозначал источник данных, которые надо было вывести – в данном случае, канал I/O. Последнее число, 30, обозначало номер одного из 17 каналов I/O, который команда желала посмотреть.
В 30-м канале содержалось несколько битов статуса, включая состояние инерционной платформы, дросселирование двигателя, и несколько индикаторов отказа. Однако самым главным битом была самая правая цифра дисплея: бит «отмена этапа спуска». И он был установлен.
Последствия этого были угрожающими. В данный момент ложный сигнал не представлял опасности, поскольку его не будут проверять вплоть до запуска двигателя лунного модуля, с которого начинается посадка. Однако как только программа спуска дойдёт до зажигания (Program 63, or just P63), она взведёт битовый флаг LETABBIT («Let Abort bit»), позволяющий другим программам считывать состояние бита отмены. Если на тот момент бит отмены ещё будет установлен, то автоматически запустится Program 70 (P70, «Abort using the descent engine»), из-за чего миссия может потенциально закончиться.
Команда могла просто попробовать отключить этот бит в нужный момент, однако с учётом того, сколько всего одновременно происходит за долю секунды, непрактично было надеяться продолжить работу посадочного двигателя переустановкой LETABBIT, пытаясь быстро забивать команды в неуклюжих перчатках скафандра.
При должной подготовке команда могла быстро отменить Abort и предпринять ещё одну попытку посадки позже, однако возникающие при этом сложности поставили бы под угрозу успех посадки.
До попытки посадки оставалось почти три часа, что давало инженерам на Земле время на выработку более надёжного решения.
Внутри макета лунного модуля «Аполлона». Кнопки Abort и Abort Stage слева обведены яркой рамкой
Немного времени выиграно при помощи ударной починки
Знакомые с аналоговыми системами знают одно быстрое решение, которое всегда приходит в голову при возникновении проблем. Застрявший счётчик или отошедший провод часто можно починить, ударив по устройству или пошерудив контакт, пока он не оживёт. Хьюстон отправил запрос именно на такой вариант: постучать по панели вокруг переключателя, и посмотреть, к чему это приведёт. Команда, великолепно подготовленная ко всем аспектам миссии, продемонстрировала свои превосходные навыки стука, и бит Abort очистился.
Учитывая длинный список этапов подготовки к спуску, Шепард и Митчелл вернулись к настройке систем лунного модуля. О бите не вспоминали, пока они проходили за Луной и вышли из зоны связи с диспетчерами из центра управления.
Однако меньше чем через час лунный модуль вышел из-за дальней стороны Луны и диспетчерам донесли плохую новость: бит отмены вновь был установлен. Стук по панели очистил его, однако повторяемость проблемы не способствовала успеху миссии.
Отказ был непредсказуем, и по закону Мёрфи, скорее всего, случился бы в наихудший возможный момент. Учитывая симптомы проблемы, стало ясно, что внутри кнопки отмены находился какой-то загрязняющий материал – вероятно, капля припоя, летающая внутри корпуса, и иногда замыкающая контакты. Физического отключения кнопки не было предусмотрено, и быстро стало ясно, что надёжным решением будет изменение обработки компьютером сигнала с кнопки.
В MIT команда под управлением автора посадочного софта Дона Айлса придумала процедуру переустановки LETABBIT, который, по крайней мере, скомандует компьютеру и дальше игнорировать застрявший бит отмены. Следующие инструкции по нажатию кнопок были переданы команде:
VERB 25 ENTER, NOUN 7 ENTER, 105 ENTER, 400 ENTER, 0 ENTER
VERB 25 загружает данные во все три регистра дисплея, NOUN 7 сообщает компьютеру, что команде нужно изменить отдельные биты в памяти. Три операнда NOUN 7, это: 105 – адрес слова с флагами 9, содержащего LETABBIT; 400 (в двоичной системе — 100 000 000), устанавливает 9-й бит в слове; 0, отключающий бит.
Хотя было ясно, что эти процедуры бесполезны, если бит отмены будет установлен во время зажигания, была надежда, что проблема не проявится до ввода обновления. Но это была выдача желаемого за действительное. Если постукивание по панели переключало бит, то ускорение и вибрация двигателя тоже легко могут сделать это.
Также очевидным было ещё одно осложнение: если космический аппарат столкнётся с неприятностями, которые потребуют реальной отмены программы, то бортовой управляющий компьютер «Аполлона» и основную систему навигации использовать будет нельзя. Отмена потребует включения системы управления отменой – компьютера, справляющегося со своей работой, но куда как более простого (у него даже не было системы с глаголами и существительными, как у бортового управляющего компьютера «Аполлона» – единственным способом взаимодействовать с системой управления отменой было считывать и записывать значения напрямую в память).
«Аполлон CSM-110», «Китти Хок», на орбите вокруг Луны. Фото сделано с лунного модуля.
Ещё один ракурс
Лунный модуль LM-8 «Антарес», расстыковавшийся от «Китти Хок». Пока что команда ещё не знает, что спуск окажется чуть более интересным, чем планировалось.
Ещё один ракурс
«Китти Хок», вид с «Антареса», после расстыковки, но до включения двигателя спуска
Стю Руса в тускло освещённом модуле «Китти Хок»
Звёздный час хакеров
И снова орбита лунного модуля унесла его за Луну, лишив возможности обмениваться сообщениями, и оставив команду с поверхностным представлением о процедурах и малым количеством вариантов. Продолжилась нормальная работа по завершению настройки системы, команда вышла на посадочную высоту, прибралась в кабине, надела шлемы и перчатки. Тем временем команда Дона Айлса лихорадочно искала лучшее решение проблемы с битом отмены.
Для работы над проблемой приходилось разворачивать сложные цепочки событий, цеплявшихся одно за другое. Основная посадочная программа P63 не выполняет все расчёты самостоятельно. Она управляет большим количеством задач и заданий из списка ожидания, каждая из которых отвечает за свою часть работы. Параллельно работала ещё одна задача, SERVICER, считывавшая показания по высоте и ускорению, которые затем входили в уравнения по навигации. SERVICER в свою очередь запускал по расписанию каждые 0,25 сек процедуру из списка заданий Routine R11. R11 сначала проверяла, разрешены ли отмены задач (считывая флаг LETABBIT), и в случае положительного ответа проверяла статус бита отмены. И если отмены были разрешены, а бит отмены установлен (предположительно, из-за нажатия командой кнопки Abort), P63 прекращала выполняться, основной режим бортового управляющего компьютера «Аполлона» менялся на Р70, и начинался процесс отмены.
Упрощённая блок-схема работы бортового управляющего компьютера «Аполлона» в лунном модуле
В большинстве хаков, нарушающих работу наших компьютеров, планшетов и сотовых телефонов, традиционно используется схема ввода нового кода с его последующим запуском. Стандартные и наиболее простые изменения проводятся через прямое переписывание существующего кода или ввода новых программ, влияющих на логику работы системы. Однако все программы на бортовом управляющем компьютере «Аполлона» хранились в памяти на прошитых магнитных сердечниках – необратимой версии ROM, у которой программирование встроено в железо. Изменить сердечники было невозможно.
Единственным способом создать какой-либо обходной путь было обмануть компьютер, манипулируя битами статуса и переменными так, чтобы он использовал уже существующую логику по-новому. Таким было волшебство, лежащее в основе взлома компьютера «Аполлона-14».
Во время последнего прохода корабля за Луной перед приземлением, Айлс с командой придумали гораздо более удачный подход, чем предыдущее исправление бита LETABBIT. И это второе решение можно было вводить в компьютер гораздо медленнее, благодаря чему у команды останется время на проверку правильности внесённых изменений (проверки вводимых данных на модуле интерфейса дисплея и клавиатуры не было, и любая опечатка при работе с флагами и переменными могла потенциально обернуться ужасными последствиями).
Ключ ко взлому от Айлса скрывался внутри небольшой функции R11. Сразу после проверки разрешения на отмену и нажатия кнопки, R11 проводила быструю проверку, не запущена ли уже программа отмены. Работающую программу отмены трогать не следовало, и если R11 обнаруживала, что программа отмены уже запущена, то завершала свою работу, не проводя дальнейших действий. Если таковой программы не обнаруживалось, происходил запуск Р70.
Это был прорыв. Если можно было бы обмануть R11 так, чтобы она считала, что программа отмены уже работает, то уже было неважно, нажата кнопка отмены или нет – её состояние будет проигнорировано.
Но как R11 узнавала о том, работает ли программа отмены, или нет? Ответ находился прямо на виду на модуле интерфейса дисплея и клавиатуры: дисплей основного режима под меткой PROG.
Модуль интерфейса дисплея и клавиатуры с бортового управляющего компьютера «Аполлона» (этот экземпляр использовался в проекте F-8 Digital Fly-By-Wire). Справа вверху видно лампочку рядом с меткой PROG
Вспомним, что поле PROG (и номер основного режима) в основном использовались для визуального информирования команды о происходящем. И хотя все основные программы сообщали о себе, выводя номер программы на дисплей – чтобы команда видела, какой в данный момент основной режим – компьютер и его функции редко проверяли дисплей сами. Процедура R11 уже обращалась к переменной, где хранился основной режим, MODREG, поэтому поменять её значение было задачей тривиальной. Следовательно, обмануть R11 можно было, изменив значение MODREG, что изменило бы значение на дисплее основного режима. А что самое важное, изменение значения MODREG после запуска программы посадки оставило бы самую важную программу посадки, Р63, практически без изменений.
Однако хотя это решало базовую проблему обхода замыкания кнопки отмены, у исправления были и собственные проблемы. Обычно после запуска двигателя посадки его тяга выставлялась на самый малый режим, 10% от мощности, на 26 секунд. В это время актуаторы имели возможность выровнять двигатель так, чтобы вектор тяги проходил через центр масс лунного модуля. После центровки двигателя компьютер давал ему команду перейти на полную тягу. Если бы компьютер думал, что работает программа отмены, двигатель не перешёл бы автоматически в режим полной тяги, и команде потребовалось бы вручную задать тягу в 100%.
Дальше из этого следовало то, что не будет взведён ещё один критически важный флаг, ZOOMBIT. Его взводили после того, как ПО отдавало двигателю команду перейти на полную мощность, что запускало расчёты навигационных уравнений, необходимых для спуска на Луну. Если ПО не управляло тягой, этот бит не взведётся, и компьютер не начнёт необходимые для спуска расчёты.
Айлс с командой из MIT работали над исправлением каждой из следующих проблем, а потом протестировали хак в симуляторе. Наконец, когда «Антарес» в последний раз вынырнул из-за Луны перед посадкой, Хьюстон отправил ему по радио окончательную процедуру.
Земля встаёт из-за диска Луны, вид с «Антареса» во время посадки. Крупный кратер на переднем плане – Мейтнер.
Обман самого умного компьютера в космосе
За четыре минуты до начала спуска лунного модуля компьютер вывел на модуль интерфейса дисплея и клавиатуры обратный отсчёт до зажигания. Это подтвердило, что Р63 работает, и стало сигналом для начала ввода хака. Сначала нужно было обмануть основной режим, будто бы была запущена программа Р71 («отмена использования двигателя взлёта»). Р71 выбрали вместо Р70 потому, что если бы патч не сработал и отмена всё же включилась бы, то реальную отмену можно было бы вызвать посредством Р70. И это было бы видно – индикатор основного режима на дисплее поменялся бы с обманного Р71 на реальный Р70.
Для начала команда ввела:
VERB 21 ENTER, NOUN 1 ENTER, 1010 ENTER, 107 ENTER
Команда VERB 21 загружала данные в регистры, NOUN 1 указывал на адрес переменной MODREG (восьмеричное 1010) и на новое значение, которое нужно туда записать (107 восьмеричное, или 71 десятичное). Из-за этого индикация PROG менялась с Р63 на Р71, и хак начинался.
После изменения основного режима и отображения на модуле интерфейса дисплея и клавиатуры режима, соответствующего работающей программе Р71, непреднамеренная отмена уже не могла произойти – R11 проверила бы MODREG, увидела бы, что запущена Р71, и завершила бы работу. Вывод и работа программы 63 продолжали идти в штатном режиме, несмотря на изменение индикации основного режима на дисплее. Зажигание сработало вовремя, тяга была установлена в 10% от максимума. Затем, через 26 секунд, Шепард вручную повысил тягу до 100%, и Митчелл начал вводить оставшиеся части патча.
Поскольку казалось, что основной режим – Р71, программы не знали, что двигатель работает на полную мощность, и бит ZOOMBIT не был установлен. Посадочная навигация не будет работать без ZOOMBIT, поэтому следующий шаг хака решал эту проблему:
VERB 25 ENTER, NOUN 7 ENTER, 101 ENTER, 200 ENTER, 1 ENTER
VERB 25 загружал данные во все три регистра. NOUN 7 позволял манипулировать отдельными битами. Здесь ZOOMBIT находится в 5-м слове с флагами по адресу памяти 101 восьмеричное. «200» – это 8-й бит внутри флага (двоичное 010 000 000), и он устанавливается в 1.
После установки ZOOMBIT запускалась процедура посадочной навигации, и теперь мощность двигателя контролировал компьютер. Затем Митчелл ввёл следующую последовательность:
VERB 25 ENTER, NOUN 7 ENTER, 105 ENTER, 400 ENTER, 0 ENTER
По принципу, схожему с установкой ZOOMBIT, бит в 9-м слове c флагами, обозначающий LETABBIT (адрес в памяти 105 восьмеричный) сбрасывался в 0. Когда этот бит равен нулю, нельзя запустить отмену нажатием клавиши Abort. Теперь команда была защищена от непреднамеренной отмены спуска, которая могла произойти из-за неисправной кнопки, поскольку в программах спуска бит LETABBIT уже нигде не устанавливался.
И для подчистки всего остального ввели последнюю последовательность:
VERB 21 ENTER, NOUN 1 ENTER, 1010 ENTER, 77 ENTER
Обращая первый шаг вспять, в MODREG записывали значение 77 восьмеричное (63 десятичное). Нужно было обязательно вернуть основной режим (и индикацию на модуле интерфейса дисплея и клавиатуры) в Р63, чтобы остальные программы спуска (Р64 и Р66) сработали правильно. Теперь, когда навигационные программы управляли мощностью двигателя, Шепард убрал ручную установку мощности обратно до минимума.
Это и так трудно сделать, без необходимости волноваться по поводу того, чтобы корабль не перевернулся вверх тормашками
Требование вернуть вручную выставленную мощность к минимальной было необходимым. Команда могла вручную подстраивать работу посадочного двигателя, но ручная подстройка работала так, что определяла минимальную тягу двигателей, вне зависимости от команд компьютера. Установка тяги на минимум означала, что астронавт требует не менее 10% тяги. Перевод же на максимум заставлял бы двигатель работать на 100% мощности вне зависимости от запросов навигационных уравнений. Если бы тяга на полную мощность сохранилась дольше, чем на 40 секунд после того, как двигатель должен был её уменьшить, уравнения поняли бы, что лунный модуль замедляется сильнее, чем нужно. В ответ компьютер скомандовал бы кораблю разворот на 180 градусов и двигатель начал бы его разгонять – не совсем оптимальный вариант.
Меньше чем за две минуты после начала спуска кнопку отмены успешно заблокировали, и компьютер спокойно управлял спуском. Всё говорил о том, что следующая посадка успешно завершится в течение восьми минут.
Ну больше-то уж ничего не испортится
Оставив проблемы с кнопкой Abort в прошлом, Шепард и Митчелл, казалось, шли навстречу успешной посадке. Четыре минуты всё шло очень хорошо, и лунный модуль преодолел 11 км пути над лунной поверхностью.
Судя по опыту предыдущих миссий, посадочный радар должен был навестись на поверхность луны близ точки посадки. Когда радар успешно получал сигналы, отражённые от поверхности, и мог обработать эти данные, он отправлял на бортовой управляющий компьютер «Аполлона» сигналы о том, что с измерением высоты и скорости модуля всё хорошо. Затем бортовой управляющий компьютер «Аполлона» гасил огоньки ALT [высота] и VEL [скорость] на модуле интерфейса дисплея и клавиатуры, что позволяло команде ввести данные радара в посадочный навигатор.
Однако команда и диспетчеры не подозревали, что радар переключился в режим ближнего действия, предназначенный для работы на последних тысячах метров спуска. И, оказавшись на высоте в 11 км от поверхности и в 16 км от точки приземления, близорукий радар внезапно не сумел ни на что навестись.
Компьютер и его инерциальная навигационная платформа представляли собой чудеса точности, и могли довести корабль за 400 000 км к Луне с ошибкой не более нескольких тысяч метров. Это было потрясающе, как ни крути, однако в последних фазах спуска на Луну триста метров являли собой разницу между аккуратной посадкой, отменой или аварией. Радар мог выдавать измерения расстояния с погрешностью чуть больше метра, а скорости – с погрешностью в несколько сантиметров в секунду. И поскольку радар был критически важен для посадки, отказ радара влёк за собой обязательную отмену процедуры, вне зависимости от нормальной работы всего остального оборудования.
Когда «Антарес» прошёл отметку 9700 м, Митчелл забеспокоился и сообщил диспетчерам, что радар не может навестись. Хьюстон предложил отключить радар и включить заново, и это помогло. В компьютер начали поступать правильные данные с радара, и команда быстро приняла решение им поверить. Всего через несколько минут Шепард совершил мягкую и точную посадку среди холмов Фра Мауро.
«Антарес», в безопасности стоящий на поверхности Луны
Нужно ловить правильный момент
После завершения миссии, отвечая на вопрос, попытался ли он посадить корабль без рабочего радара, известный своей настойчивостью в достижении цели Шепард, как говорят, ответил: «Мы этого никогда не узнаем». В автобиографии Джина Кранца «Провал – не вариант», он вспоминает, что полётный директор Джерри Гриффин был убеждён, что Шепард попытался бы посадить корабль без радара, и ему пришлось бы отменять посадку после того, как закончилось бы топливо.
Очевидно, что у посадки без радара были бы большие шансы на провал. Без атмосферы и далеко, и близко расположенные к наблюдателю объекты выглядят очень чётко, что полностью убивает ощущение глубины и скорости. Было бы нереалистичным надеяться посадить модуль вручную, на глаз оценивая высоту и скорость, учитывая сильно ограниченный запас топлива, которое нёс с собой лунный модуль.
А что, если бы радар сначала работал нормально, а потом отказал при приближении к Луне? В правилах миссии можно найти ответ и на этот вопрос:
Если радар откажет во время спуска после того, как выдаст несколько «адекватных» показаний, то по согласованию с консолью GUIDO в центре управления посадку можно будет продолжить, если не будет других серьёзных проблем.
Правила миссии – это библия полёта. Они составляются задолго до самого полёта, и призваны устранить любые споры, случайное или эмоциональное принятие решений во время быстро развивающихся событий. По правилам, посадку при отказе радара можно было сделать, если радар и система навигации расходятся в показаниях менее чем на 300 м. Кроме того, поскольку отказавший радар будет, вероятно, отправлять в бортовой управляющий компьютер «Аполлона» фиктивные данные, для ручной посадки необходимо было бы использовать систему управления отменой.
На высоте порядка 3700 м над поверхностью команда синхронизировала бы системой управления отменой с навигационными данными с бортового управляющего компьютера «Аполлона», и два компьютера отслеживали бы друг друга до окончания посадки. Система управления отменой, не отвлекаясь на проблемные данные радара, давала бы достаточно точные цифры для того, чтобы безопасно посадить команду.
Вид из окна «Антареса» на Фра Мауро
«Антарес» на месте посадки в Фра Мауро
Командир Шепард на поверхности Луны, прикрывает глаза от солнца
«Я командир Шепард, и это мой любимый флаг на поверхности Луны»
Митчелл занимает своё место у флага. У него на скафандре полосок нет – их добавили на скафандр командира миссии после «Аполлона-12», чтобы различать, кто где на фото
Митчелл работает с телекамерой на месте посадки
Постоянные исправления
Идея того, что единственный неисправный переключатель может привести к неудаче всей миссии, была неприемлемой. По окончанию миссии в код бортового управляющего компьютера «Аполлона» включили новую переменную, позволявшую игнорировать состояние кнопок Abort и Abort Stage. По этому сценарию предполагалось, что отказавший переключатель будет обнаружен задолго до начала спуска, и что на ввод команд для предотвращения нежелательной отмены останется время. Как и после патча для «Аполлона-14», этот вариант сделает невозможным отмену этапа нажатием кнопки, и любую срочную ситуацию пришлось бы решать при помощи системы управления отменой.
С близоруким радаром разобрались ещё проще. Во время спуска радар поворачивается в одно из двух положений, в зависимости от того, работает ли Р63 или Р64. На «Аполлоне-14» радар, скорее всего, обнаружил шум в сигнале, возможно, из-за слишком сильного отражения от поверхности, или из-за отражений от боков космического аппарата. Из-за этого радар переключился из режима дальнодействия, необходимого на том этапе, в режим ближнего действия. Схемы выбора дальности действия изменили так, чтобы радар не мог переключать режимы, не будучи правильно ориентированным.
Восстановление работы корабля после отказа кнопки отмены можно считать гениальным и героическим. Однако самую важную роль тут сыграло то, что в ПО, пусть и чертовски сложном, могли разобраться члены небольшой команды разработчиков. Современное железо и ПО, с его обширными схемами защиты, виртуализацией и динамическим управлением программами, сделали бы подобный хак невозможным. Столкнувшись с подобной проблемой сегодня, даже при тривиальном её решении наверняка потребовалось бы перекомпилировать, проверить и загрузить на корабль большие объёмы кода. А это могло бы оказаться невозможно сделать в краткий промежуток времени, за который можно спасти миссию.
В итоге, патч «Аполлона-14» был действительно характерным для «духа Аполлона», когда талантливые команды разработчиков подчас совершали невозможное.
Автор: Вячеслав Голованов
