Scorpius SR-M

Каждый год в предвестие Memorial Day у нас в городе проводится военный парад. На сам парад мы, правда, еще не разу не попадали (только в пробки, посвященные перекрытию дорог по поводу парада). А вот на выставку военной техники - вполне. Выставка удобно расположилась на парковке пятого по величине торгового центра в стране. Ну а чё? Наша страна сильна оружием и шоппингом. Грех не совместить… ;-)

На выставке обнаружился необычный экспонат - суборбитальная ракета Scorpius SR-M:

Scorpius SR-M

Read On →

Про наказание невиновных и награждение непричастных

В который раз встретил фразу про наказание виновных в неполадках космической техники - в этот раз в статье про Фобос-Грунт у Зеленого кота:

Согласно заключению госкомиссии, авария произошла “вследствие недооценки фактора космического пространства разработчиками и создателями межпланетной станции”. Виновные в просчёте сотрудники НПО имени Лавочкина были привлечены к административной ответственности.

Подобная фраза встречается довольно часто, обычно - в статьях изданных по результатам анализа причин той или иной аварии. Также бывает, что речь о наказании виновных заходит и в интернетных обсуждениях тех же аварий, причем частенько в контексте, что, мол, опять стрелочника наказали, а надо было кого-нибудь повыше, лучше всего - самого главного.

К сожалению, эта фраза показывает только то, насколько криво поставлен процесс разработки и/или производства. И если “диванным аналитикам” простительно не понимать таких, в общем-то, очевидных вещей, то самим разработчикам, их менеджменту и тем, кто заказывает музыку должно быть стыдно.

Read On →

Посадка первой ступени CRS-11

Нестандартное видео посадки:

Space X rocket landing (sorry for the language)

A post shared by Zachary Grannan (@zacharygrannan) on

Причины аварии посадочного демонстратора Schiaparelli

ESA опубликовало отчет о расследовании аварии посадочного демонстратора Schiaparelli, запущенного к Марсу в составе экспедиции ExoMars 2016. Посадочный модуль вошел в атмосферу Марса 19 октября 2016 года. Контакт с модулем был потерян за 43 секунды до ожидаемого момента посадки. На следующий день место посадки было сфотографировано камерами Mars Reconnaissance Orbiter. На снимках было найдено свежее большое темное пятно в ожидаемом районе посадки, а в километре от него - новое светлое пятно (парашют).

Очень занимательный отчет. Интересное начинается прямо в списке оборудования. Посадочный модуль был оборудован одним радаром и одним прибором инерционной навигации (IMU). Выход из строя любого из них означал неизбежную аварию при посадке. Я раньше думал, что на всем, что улетает дальше земной орбиты, все сенсоры резервируются в обязательном порядке.

Для симуляции и Монте-Карло моделирования посадки использовался внушительный список моделей, включая модель атмосферы, многотельное моделирование парашюта, модель теплового щита и т.д. Такой подход считается индустриальным стандартом и используется, в том числе, в NASA. Каждая из моделей, однако, требует тщательной проверки, так как одна единственная ошибка может фатально исказить результаты.

Read On →

rr

Недавно наткнулся на rr (Record and Replay Framework) от Mozilla и я вам скажу, что это просто незаменимый инструмент для ловли неуловимых багов в отладчике. Это не первый и не единственный инструмент подобного плана. Соответствующая страница проекта описывает десятка три альтернатив. Из этого списка мне раньше доводилось работать только с iDNA, который впоследствии стал Time Travel Tracing (TTT). TTT мог записать процесс выполнения программы с точностью до инструкции и воспроизвести его в точности в прямом и обратном направлении. TTT был просто незаменим для ловли сложных багов и его главным недостатком было то, что TTT был внутренним инструментом, который Microsoft так и не выпустила как отдельный продукт.

rr тоже может записать выполнение процесса с точностью до инструкции и проиграть его назад и вперед. rr требует современного процессора, причем обязательно Intel, так как использует performance counters которые не реализованы в других процессорах. ARM и другие архитектуры тоже не поддерживаются. В обмен на это, rr практически не замедляет записываемый процесс. Скорость выполнения падает в 1.2 раза - сущие пустяки. Размер генерируемой записи тоже крайне скромен - в районе гигабайта за 10-15 минут выполнения “вычислительного” кода. Практически бесплатно. В пересчете на количество выполненных инструкций получается что-то вроде 0.1 бита на выполненную инструкцию.

Что интересно, rr базируется на очень простой идее: большая часть кода выполняется всегда одинаково. Если записать все случайные события (ввод/вывод, RDTSC, системный вызовы) и начальные условия (содержимое памяти), то процесс выполнения становится полностью детерминированным. Более детально можно почитать здесь: http://rr-project.org/rr.html.

Процесс отладки с помощью rr выглядит так:

  1. Записываем процесс: rr record <program>
  2. Запускаем запись в отладчике: rr replay
  3. Проматываем до конца и смотрим чем вызван segfault.
  4. Ставим watchpoint на память из которой читается плохой указатель.
  5. Выполняем программу назад пока не сработает watchpoint.
  6. Смотрим почему в память пишется плохой указатель и повторяем шаги 4-6 до победного конца.

Дополнительный бонус заключается в том, что все адреса при повторном воспроизведении сохраняются. Если нужная переменная находится по адресу 0x123fooba, то она там будет всегда. Отпадает необходимость выяснять где в памяти находится интересный кусок каждый раз при запуске отладчика. rr также может помечать вывод в stdout метками для быстрой перемотки в нужное место. Это помогает сопоставить код с интересными местами в лог файлах.

Само собой, у rr есть куча других ограничений. К примеру, он не работает под Windows, не поддерживаются все системные вызовы, не поддерживается циклическая запись (последние несколько минут выполнения процесса), поддерживается только одно процессорное ядро, и т.д. Тем не менее, если вы столкнулись с “невозможным” багом в Linux, rr - один из наиболее вероятных способов докопаться до источника проблемы.

Мир магов, фей и драконов

Случайно наткнулся на текст, который я написал пару лет назад по следам свежих впечатлений и забыл опубликовать.

Мы живем во времена магов, фей и драконов. Сильные мира сего живут в замках, меряются длиной океанских яхт и покупают футбольные клубы ради развлечения. У них есть армии и драконы, которые могут разбомбить Багдад за неделю. Они контролируют все деньги мира, за которые могут нанять кого угодно - от лучшего кутюрье, до транснациональной корпорации.

И эти корпорации - то еще зло. На них работают целые армии волшебников менеджеров и инженеров, которые знают как сделать новый iPhone, новое лекарство или запустить еще один спутник. Однако их реальная цель - заграбастать побольше денег. А ведь с их возможностями, стоило только захотеть, - лекарство от СПИДа, а то и эликсир бессмертия, давно бы уже был в любой аптеке.

Раньше еще была надежда на книжников ученых. Те хоть сидели в своих университетах и не пытались откровенно облапошить простой люд. Теперь и они только и говорят о том, чтобы забабахать адронный коллайдер или самый большой телескоп. А зачем? И за чей счет?

Да, говорить мудреные слова они все мастаки. Понавыдумывали теорий. Один британский ученый вон написал, что человек использует свой мозг только на десять процентов. Понятное дело, конкуренция им не нужна и как бы задействовать оставшиеся 90% никто и не пытается понять. Или, скорее, пытается, но в тайне от всех. А многие направления, тех же экстрасенсов скажем, так вообще сознательно давят. Удивительно ведь. Готовый феномен - бери и исследуй. Ан нет. Все как один отмораживаться. Заговор. И ничего не докажешь ведь.

Если подумать, то такой потенциал пропадает. Вместо реально полезных вещей занимаются всякой фигней. Ну вот какой толк от исследования звезд и телескопов этих? Их все равно руками не пощупаешь. Астрологи говорят, что температура Солнца - шесть тысяч градусов и состоит оно из водорода и гелия. А другие говорят, что там есть вода и твердая оболочка. Еще бы, если средняя плотность больше чем у воды. И ни тех, ни других не проверишь никак. С градусником к Солнцу не подлезешь. Непонятно кому верить…

Read On →

Ночной дозор

В нашем главном здании раньше собирали фюзеляжи для Boeing 747. Размах крыльев этого легкого прогулочного самолета - 60 метров, длина - чуть больше 70-и. Внутри здания их таких может поместиться не меньше двадцати и еще место на каток и палатку с шаурмой останется. Кусочек этого ангара отгородили от остального производства (чтобы расплавленный припой, значит, на мониторы не капал) и организовали “open space”, где большая часть наших офисных работников и обретается. Небольшой такой open space. Метров 150 в длину. Ну а че? Размах, то-се.

Спросите любого программиста нравится ли ему open space. Главное проследите, чтобы вокруг тяжелых, удобных для метания предметов не оказалось… По-идее open space должен помогать работникам коммуницировать (в смысле - общаться), решать, так сказать, проблемы сообща. Однако при выкатке этой идеи в продакшен что-то пошло не так. Выяснилось, что после сеанса коммуникации программисты любят погрузиться в транс. Иначе, говорят, код не пишется. А погрузится в транс не получается из-за очереди желающих покоммуницировать.

Я завел себе листочек, на котором отмечаю каждый раз когда меня отвлекли. Один вопрос - одна палка на листочке. За последний месяц случился один день, когда меня никто не отвлекал. Наверное заболели все. Норма - пять-семь палок. Текущий рекорд - двадцать. Удачный был день. Вторник.

Сегодня у нас была “no meetings Wednesday” - “среда без совещаний”. Сегодня в листочек добавилось только две палки. Главным образом из-за того, что я до своего стола добрался два раза за весь день. Остальное время ушло на совещания.

В качестве компенсации мироздание подкинуло ссылку на прекрасное: The Night Watch. Ночный дозор, то бишь. Небольшой рассказ про системных программистов. На русский не переводится принципе. Пара избранных цитат:

What is despair? I have known it—hear my song. Despair is when you’re debugging a kernel driver and you look at a memory dump and you see that a pointer has a value of 7. THERE IS NO HARDWARE ARCHITECTURE THAT IS ALIGNED ON 7. Furthermore, 7 IS TOO SMALL AND ONLY EVIL CODE WOULD TRY TO ACCESS SMALL NUMBER MEMORY.

I described the bug, which involved concurrent threads and corrupted state and asynchronous message delivery across multiple machines, and my coworker said, “Yeah, that sounds bad. Have you checked the log files for errors?” I said, “Indeed, I would do that if I hadn’t broken every component that a logging system needs to log data. I have a network file system, and I have broken the network, and I have broken the file system, and my machines crash when I make eye contact with them. I HAVE NO TOOLS BECAUSE I’VE DESTROYED MY TOOLS WITH MY TOOLS.

Enjoy. :)

Cassini's Grand Finale

Эмблема AMOS-6

На /r/spacex выложили “утекшую в сеть эмблему AMOS-6”:

Эмблема AMOS-6

В этой эмблеме прекрасно все: и падающий обтекатель, объятый пламенем и со спутником внутри, и погнутый transport erector, и вспышка выстрела снайпера, нанятого ULA, и листок клевера “на удачу”.

SES-10

Быстренько поделюсь впечатлениями, пока еще заплетык не языкается. Время запуска было удачное. Из трех предыдущих запусков Iridium-1 пускали в выходной день с утра, CRS-10 вообще был в непонятное время - не то ночью, не то утром, да еще и первую попытку отменили (опять в 4 утра вставать). Echostar 23 полетел поздно ночью, причем в один прекрасный момент окно запуска приходилось аккуратно на момент перехода на летнее время. Не то, чтобы это проблема, но логистики добавляет.

Read On →