Туманность Ориона
Dec 23, 2021 · CommentsАстрономия
Туманность Ориона, 42-я “не комета” из каталога Мессье, расположенная на расстоянии около 1344 световых лет от Земли:
Туманность Ориона, 42-я “не комета” из каталога Мессье, расположенная на расстоянии около 1344 световых лет от Земли:
Оказывается грузить свой код в чужой процесс на Linux ничуть не менее
увлекательно, чем на Windows. Я раньше не наведывался в этой темный угол, а вот
на днях заглянул. Содержимое угла привычно обнадежило: залатанный древний
загрузчик, дохлые мухи, пара растяжек, и грабли кругом. Все как мы любим. Задача
была такая. Есть несколько загружаемых с помощью LD_PRELOAD модулей.
Модули переопределяют поведение небольшого числа POSIX функций. Требовалось
перенести сборку модулей на более свежую версию GCC. Казалось что может быть
проще?.. Да, давно уже не ощущал себя насколько наивным, аж ностальгия
пробивает. Ниже следует список обнаруженных граблей.
Видео посадки марсохода “Персеверанс” (настойчивость) - это что-то неземное:
Необычнее всего выглядит “Небесный кран” (он же реактивный ранец) на фоне марсианского неба - что-то в нем есть из классической фантастики. NASA, конечно, молодцы. Это же надо так наловчится марсоходы засылать.
Ну и небольшой бонус. Линдсей Стирлинг (Lindsey Stirling) исполняет “Артемиду” в Космическом центре Кеннеди:
Артемида - текущее название лунной программы NASA.
На Hacker News давече разгорелась очередная дискуссия про трудности перехода со второго Питона на третий. Этот случай, без сомнения, должен войти в учебники как пример того, как делать ни в коем случае не надо. Очень показательно, что официальное руководство по переходу ссылается на две статьи: Питон 3: вопросы и ответы и Почему Питон 3 существует. Обе статьи признают, что переход создал множество проблем, но при этом многословно объясняют почему третий Питон был необходим. Обе статьи были бы гораздо честнее, если бы авторы просто сказали “Простите. Мы ошиблись”.
Мое мнение по этому поводу можно свести к двум тезисам:
Чтобы проиллюстрировать это мнение, я собрал немного статистики по миграции небольшого проекта на 38 тысяч строк. Проект состоит из коллекции тестов, проверяющих поведение операционной системы на целевой платформе, и обвязки, которая позволяет эти тесты запускать на железе. Код проекта покрыт юнит тестами плохо. Юнит тесты занимают всего около двух с половиной тысяч строк. Это имеет рациональное объяснение - покрывать код тестов тестами вроде как особого смысла нет. Но на легкость переписывания кода это, само собой, влияет.
Основной перевод кода с py2 на py2+py3 начался в июле прошлого года и занял ровно две недели, 14 пул-реквестов и примерно чуть более 5% измененного кода. Если включить автоматическое переформатирование кода, то дельта увеличивается до 30% кода. Для сравнения, в два раза более крупное, похожее по характеру изменение в проекте на С++ (150 тысяч строк кода) заняло 4 дня от начала до конца.
Здесь кстати есть еще один характерный момент. Переход на третий Питон - это почти всегда переход на код, совместимый с обоими версиями сразу. Просто потому, что невозможно перевести сколь-нибудь крупный проект за раз. Но, как мы помним, эти версии умышленно несовместимы друг с другом. Так что костыли вроде six просто необходимы.
Какие же изменения были сделаны за эти две недели? Да все же тот стандартный список:
int vs long.print стал функцией.sys.maxint.xrange.В случае типизированного языка, все эти несовместимости ловятся на этапе компиляции. В конце концов, компилятор компилирует 100% кода программы (слава богу SFINAE в нормальных программах используется более-менее локально). Единственный способ надежно отловить все ошибки компиляции в Питоне можно только выполнив каждую строку кода в программе. Я еще ни разу в жизни не видел ни одного реального программного проекта со 100% покрытием тестами.
Обидно, что даже самое полезное новшество - раздельные строки и байты не требует ломать
обратную совместимость. Ну совсем. Что нужно было сделать? - дать возможность явно
указать, ожидает ли код байты или строки в новом коде, а старый код обложить
диагностикой, которая ловит ошибки. Добавить специальный режим проверок во время
исполнения, если требуется. Что сделали разработчики Питона? Переименовали str в
bytes, а unicode в str. Чем сломали ожидания огромного массива существующего кода.
Однако авторам этого показалось мало и они добавили еще кучу тривиальных, и совсем
ненужных несовместимостей. К примеру убрали iteritems() или убрали оператор print.
Что мешало оставить первый и позволить второму быть и оператором и функцией - это выше
моего понимания.
Но если вы думаете, что за две недели эпопея закончилась, вы сильно ошибаетесь. Это был только первый тикет в баг-трекере. Спустя полгода их заведено уже 15. Заслано 33 пул-реквеста. Крайний и видимо не последний баг, вызванный переходом, был найден неделю назад. Как минимум три тикета еще предстоит исправить. Вот такие дела.
Read On →Пользуясь наплывом читателей по случаю красивого взрыва SN8, прорекламирую открытые позиции в моей команде:
В двух словах мы ищем специалистов по разработке встраиваемых систем, ядру Linux, и систем реального времени.
Сразу скажу, что рассматриваются только жители США. Виза, за исключением уникальных случаев, не спонсируется. Почему так можно прочитать здесь.
Понятное дело, что рекламировать позицию в США в блоге на русском не очень логично, но с другой стороны, почему бы и нет? Глядишь у кого-нибудь знакомые заинтересуются?
Read On →Сегодня был отличный день. Испытательный полет SN8 на 12.5 км прошел гораздо лучше, чем я ожидал. Да и шоу получилось просто отменное. В этом полете испытывалось много нового:
Мелкие неприятности с низкой тягой при посадке и, как следствие, красивым взрывом на посадочной площадке - это совершенно не проблема. Мы это уже порешали с при посадке F9, порешаем и здесь.
А пока - наслаждайтесь красивым зрелищем (T-0 в 1:48:12):
P.S. А вот еще шикарный вид снизу на маневр переворота при посадке:
Starship landing flip maneuver pic.twitter.com/QuD9HwZ9CX
— SpaceX (@SpaceX) December 10, 2020
Недавно совершенно случайно узнал про фонтанный код и поразился насколько элегантно работает этот алгоритм. Этот код позволяет надежно передавать данные по каналу с потерями без обратной связи и с минимальными накладными расходами. Более того передатчик и приемник не обязаны синхронизировать начало и конец передачи данных. Фонтанный код позволяет передатчику генерировать бесконечный поток пакетов, кодирующих исходное сообщение, а приемник может начать слушать в любой момент. Все что требуется - это принять минимально необходимое для декодирования количество пакетов. Raptor code, - одна из наиболее практичных реализаций, требует всего лишь передать всего 0.2% дополнительных пакетов для успешного декодирования с вероятностью 0.999999. При этом вероятность успешного декодирования стремительно приближается к единице с каждым дополнительным пакетом.
Зачем это нужно когда уже есть протоколы надежной передачи по двухстороннему каналу, скажем тот же TCP/IP? Оказывается существует ситуации, когда организация обратного канала связи требует изобретения машины времени. Когда нам нужно восстановить данные со сбойного сектора на жестком диске, мы не можем послать “запрос на повторную передачу” в прошлое - в то время, когда сектор нормально читался. Все что мы можем сделать - это записать избыточные данные в другой сектор или на другой диск заранее.
Read On →В Бока Чике сегодня летало. Громко, основательно, и очень сюрреалистично. Моих литературных талантов не хватает, чтобы описать это событие по достоинству. Стальная бочка высотой в десятиэтажный дом, с карикатурными мультяшными ножками, вальяжно отрывается от стартового стола, походу разнося его в щепки, и возносится в небо с грацией троллейбуса… Нет, не могу. Смотрите сами:
Вместе с тем этот полет - это очень серьезная веха в разработке корабля. Причем важен даже не сам полет (хотя и он тоже), но все что происходило при подготовке к нему. Все переносы, многочисленные попытки и остановки обратного отсчета в последнюю секунду. Это можно сравнить с периодом времени, когда программа уже компилируется, но еще не работает.
Другой ракурс:
Вообще интересно, насколько круто снимают “через забор” любители космоса. Прикиньте, что эти люди потратили свой отпуск на то, чтобы просидеть у болота непонятно сколько дней на жаре в ожидании успешного теста; приволокли кучу дальнобойных камер; раздобыли шустрый интернет в 40 минутах езды от ближайшего приличного города; и выложили отснятый материал в интернет.
Команда Flight Software будет отвечать на вопросы про то, как SpaceX разрабатывает программное обеспечение для Crew Dragon на reddit.com в субботу 6 июня 2020 с 12:00 до 13:30 по тихоокеанскому времени (в субботу с 22:00 до 23:30 по киевскому времени).
Read On →Успешный запуск пилотируемого Дракона к Международной космической станции заслуженно вызвал повышенное внимание со стороны как средств массовой информации, так и простых смертных. Как-никак такие события случаются нечасто. Повышенное внимание, хотя и менее заслуженное, не обошло стороной и этот блог. И теперь мой почтовый ящик лопается от поздравлений и запросов на интервью. Что гораздо хуже, известие о том, что в SpaceX работает украинец вызвало нешуточный ажиотаж в Facebook и волну слухов один другого забавнее. Позвольте мне прокомментировать моменты, которые, по всей видимости, вызвали наибольший интерес.
Но перед тем как начать, позвольте от всего сердца поблагодарить за все присланные поздравления, пожелания и высказанную поддержку. Поверьте, и моим коллегам и мне очень приятно знать, что наша работа высоко оценивается и вызывает живой интерес. Спасибо огромное и извините, что далеко не всегда могу удовлетворить ваше любопытство.
Ну, поехали. Честно говоря, никак не думал, что подобное нужно отдельно уточнять, но оказывается нужно. Нет, я не “пишу всё программное обеспечение которое отвечает за полёт Crew Dragon”. Программное обеспечение, обеспечивающие полет Crew Dragon создавалось не одной сотней людей в течении многих лет. Помимо всего прочего, это программное обеспечение включает в себя версию Linux. Я специально проверял - я совершенно точно не писал Linux. Там какой-то финский паренёк отметился.
Самое смешное, что я и разработке ПО Dragon никогда отношения не имел. Раньше я писал софт для Falcon 9 и Falcon Heavy, а теперь - для Starship. Само собой, так как софт для всех четырех собирается из одной кодовой базы, то часть моего кода используется при полете Dragon.
Идем дальше. Нет, моя должность не называется “главный разработчик”. Главный инженер (Chief Designer) у нас - Илон Маск собственной персоной. “Sr. Software Engineer” - это всего лишь “разработчик обыкновенный, просто опытный”. Эта должность не предполагает руководства людьми. Для этого есть менеджеры и руководители групп (скажем Lead Software Engineer) :-)
Я действительно отвечал за первую удачную посадку первой ступени Falcon 9 и запуск Falcon Heavy. Правда я на 98% уверен, что это факт интерпретируется совершенно не совпадающим с реальностью способом. В SpaceX активно используется понятие “Responsible Engineer” (“ответственный инженер”, “RE”). Ответственный инженер координирует взаимодействие разных групп в той или иной области. Например, инженер отвечающий за автоматическую систему прерывания полета отвечат за то, чтобы Range получил все данные, нужные для сертификации, чтобы полетный правила прошли определенный набор тестов, чтобы чуваки из Flight Software выбрали правильный протокол для навигационных данных, чтобы операторы добавили процедуру включения и проверки в нужное место пусковой последовательности. Задача ответственного инженера состоит не в том, чтобы сделать всю работу самому, а в том, чтобы вся работа (в одной определенной области) была сделана теми, кто должен её сделать. Баз такого ответственного инженера легко забыть как-нибудь важную, но малозаметную деталь. Например, запросто можно подключить только один конец кабеля или забыть выполнить какой-то важный тест.
На каждый запуск назначается ответственный инженер от каждый группы, обеспечивающий запуск. Я был инженером, отвечающим за запуск F9-21 (первая успешная посадка), FH-1 (первый запуск Falcon Heavy) и нескольких других запусков от группы Flight Software. Помимо прочего, я отвечал за то, чтобы полетный софт, загруженный на ракету, включал в себя все запланированные изменения и прошел все необходимые тесты. Большинство людей, которых вы видите в центре управления полетом, - ответственные инженеры назначенные от разных групп.
Далее, я обратил внимание, что у многих подгорело на счет моей биографии. Я веду этот блог по-русски, я родился и вырос в Украине, у меня русская фамилия, я живу в США. Если я не ошибаюсь, я сумел обидеть каждым из этих простых фактов хотя бы одного человека. Хорошо, что я хотя бы не рыжий. :-)
Почему-то людей зацепила вот эта фраза:
Я стараюсь, по возможности, сторонится политики. Главным образом из-за крайне низкого КПД подобных споров. А уж после событий последних лет – так и подавно. Так что, пожалуйста, не разводите политику в комментариях – буду банить нещадно, а самое главное – предвзято. Ну, я предупредил. :-)
Нет, я понимаю, что в 2014 году был аннексирован Крым и началась война. Но, на минуточку, этот блог существует с 2006 года, а эта фраза - с 2007, если я не ошибаюсь. Я даже нашел вот такой комментарий датированный январем 2007 года:
Обычно я стараюсь избегать “священных войн”. По уровню полезности рассуждения на темы вроде “Windows против *nix” или “Microsoft против Open Source Community” я приравниваю к спорам про политику. И те и другие одинаково быстро скатываются в эмоции, где оппоненты больше заинтересованы в уничтожении друг друга, чем в выяснении истины.
Этот блог не исключение из этого правила. Все подобные темы я стараюсь рассматривать только с технической точки зрения: как это сделано, почему, зачем и что это даёт пользователю. Темы, которые не удаётся свести к сугубо технической части, я обсуждать не буду, уж извините. И уж тем более я не хочу копаться в грязном белье: суды, нечестная конкуренция и т.п.
Как видите, и здесь идет речь о неприятии политики в этом блоге. Так что, господа, полегче со своими проекциями.
Закончу на положительной ноте. Один из частых вопросов - а много ли других выходцев из стран бывшего Союза заботает в SpaceX. Да дофига. Есть много украинцев, есть много россиян, есть масса людей из других стран. Как и в любой большой американской компании.
Read On →