Россия в очередной раз напала на Украину. Скажу только несколько вещей.
Во-первых, ложь пронизывает эту кампанию от начала и до конца. Лидеры врут про
“притеснение русских” и “базы НАТО в Украине”; пропагандисты врут про “распятых
мальчиков” и “геноцид”; а простые люди врут про “братский народ” и “свою
неспособность повлиять на события”. Так вот знайте - “простые люди” - они в
ответе за ту власть, которую они приручили. Вы хотели “прижать хохлов”? Вы
будете отвечаеть за действия своей власти.
Во-вторых, весь последний год я наблюдал удивительную трансформацию. Мир
окончательно перестал верить заявлениям России. Если ранее возмущение вызывали
только захват Крыма, сбитый боинг и отравления полонием, то сейчас любое
заявление из России воспринимается как заведомая и часто очень топорная ложь.
Мир на стороне Украины.
В-третьих, Украина безуслово готова дать достойный отпор врагу. Это будет
непросто, но Украина выстоит. Слава Україні!
Оказывается грузить свой код в чужой процесс на Linux ничуть не менее
увлекательно, чем на Windows. Я раньше не наведывался в этой темный угол, а вот
на днях заглянул. Содержимое угла привычно обнадежило: залатанный древний
загрузчик, дохлые мухи, пара растяжек, и грабли кругом. Все как мы любим. Задача
была такая. Есть несколько загружаемых с помощью LD_PRELOAD модулей.
Модули переопределяют поведение небольшого числа POSIX функций. Требовалось
перенести сборку модулей на более свежую версию GCC. Казалось что может быть
проще?.. Да, давно уже не ощущал себя насколько наивным, аж ностальгия
пробивает. Ниже следует список обнаруженных граблей.
Видео посадки марсохода “Персеверанс” (настойчивость) - это что-то неземное:
Необычнее всего выглядит “Небесный кран” (он же реактивный ранец) на фоне марсианского
неба - что-то в нем есть из классической фантастики. NASA, конечно, молодцы. Это же надо
так наловчится марсоходы засылать.
Ну и небольшой бонус. Линдсей Стирлинг (Lindsey Stirling) исполняет “Артемиду” в
Космическом центре Кеннеди:
Артемида - текущее название лунной программы NASA.
Мое мнение по этому поводу можно свести к двум тезисам:
Питон 3 не предложил ничего, что оправдало бы обратную несовместимость со вторым
Питоном.
100% покрытие кода тестами - необходимое условие для того, чтобы безболезненно
переписывать код на Питоне.
Чтобы проиллюстрировать это мнение, я собрал немного статистики по миграции небольшого
проекта на 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
пул-реквеста. Крайний и видимо не последний баг, вызванный переходом, был найден неделю
назад. Как минимум три тикета еще предстоит исправить. Вот такие дела.
В двух словах мы ищем специалистов по разработке встраиваемых систем, ядру Linux, и
систем реального времени.
Сразу скажу, что рассматриваются только жители США. Виза, за исключением уникальных
случаев, не спонсируется. Почему так можно прочитать здесь.
Понятное дело, что рекламировать позицию в США в блоге на русском не очень логично, но с
другой стороны, почему бы и нет? Глядишь у кого-нибудь знакомые заинтересуются?
Сегодня был отличный день. Испытательный полет SN8 на 12.5 км прошел гораздо лучше, чем
я ожидал. Да и шоу получилось просто отменное. В этом полете испытывалось много нового:
Полет на трех движках. Раптор еще не летал в такой конфигурации. После F9 это кажется
тривиальной вещью, но одни только акустические нагрузки чего стоят.
Выключение движков в полете, суммарный вектор тяги которых не соосен с продольной
осью ракеты.
Переворот на пике траектории.
Планирование “на пузе”. Насколько я понимаю, этого в мире еще никто не пробовал, тем
более с ракетой такой размерности. Я ожидал, что неприятности начнутся именно на этом
этапе. Тем более удивительно, что планирование прошло как по маслу.
Включение двигателей для посадки “лежа на боку”. Топливо в баках при этом
скапливается на боку ракеты - его туда толкает ускорение от торможения в атмосфере.
При посадке первой ступени F9 топливо естественным образом стекает в топливоприемник
(не уверен на счет терминологии).
Переворот в последнюю секунду перед посадкой. Неудача на этом этапе была второй
наиболее вероятной причиной неудачи по моим предположениям до теста.
Мелкие неприятности с низкой тягой при посадке и, как следствие, красивым взрывом
на посадочной площадке - это совершенно не проблема. Мы это уже порешали с при посадке
F9, порешаем и здесь.
А пока - наслаждайтесь красивым зрелищем (T-0 в 1:48:12):
P.S. А вот еще шикарный вид снизу на маневр переворота при посадке:
Недавно совершенно случайно узнал про фонтанный код и поразился насколько
элегантно работает этот алгоритм. Этот код позволяет надежно передавать данные
по каналу с потерями без обратной связи и с минимальными накладными расходами.
Более того передатчик и приемник не обязаны синхронизировать начало и конец
передачи данных. Фонтанный код позволяет передатчику генерировать бесконечный
поток пакетов, кодирующих исходное сообщение, а приемник может начать слушать в
любой момент. Все что требуется - это принять минимально необходимое для
декодирования количество пакетов. Raptor code, - одна из наиболее
практичных реализаций, требует всего лишь передать всего 0.2% дополнительных
пакетов для успешного декодирования с вероятностью 0.999999. При этом
вероятность успешного декодирования стремительно приближается к единице с каждым
дополнительным пакетом.
Зачем это нужно когда уже есть протоколы надежной передачи по двухстороннему
каналу, скажем тот же TCP/IP? Оказывается существует ситуации, когда организация
обратного канала связи требует изобретения машины времени. Когда нам нужно
восстановить данные со сбойного сектора на жестком диске, мы не можем послать
“запрос на повторную передачу” в прошлое - в то время, когда сектор нормально
читался. Все что мы можем сделать - это записать избыточные данные в другой
сектор или на другой диск заранее.
В Бока Чике сегодня летало. Громко, основательно, и очень сюрреалистично. Моих
литературных талантов не хватает, чтобы описать это событие по достоинству. Стальная
бочка высотой в десятиэтажный дом, с карикатурными мультяшными ножками, вальяжно
отрывается от стартового стола, походу разнося его в щепки, и возносится в небо с
грацией троллейбуса… Нет, не могу. Смотрите сами:
Вместе с тем этот полет - это очень серьезная веха в разработке корабля. Причем важен
даже не сам полет (хотя и он тоже), но все что происходило при подготовке к нему. Все
переносы, многочисленные попытки и остановки обратного отсчета в последнюю секунду. Это
можно сравнить с периодом времени, когда программа уже компилируется, но еще не
работает.
Другой ракурс:
Вообще интересно, насколько круто снимают “через забор” любители космоса. Прикиньте, что
эти люди потратили свой отпуск на то, чтобы просидеть у болота непонятно сколько дней
на жаре в ожидании успешного теста; приволокли кучу дальнобойных камер; раздобыли
шустрый интернет в 40 минутах езды от ближайшего приличного города; и выложили отснятый
материал в интернет.
