уже увидел

спасибо

Burning Man. Так хочется попасть туда...

Basic networking course

Доступна запись шестой лекции по сетям от Сергея (@SergeyPRS) — продолжение серии лекций по CCNA.

Данная лекция состоит из четырёх частей, и во второй части, которую мы сейчас публикуем, рассматриваются следующие темы:
1. Подготовка комплектующих для отправки в место проведения работ.
2. Сопровождение работ по монтажу СКС.
3. Сопровождение работ по монтажу оборудования.
4. Организация резервного канала управления.

Лекция была записана в режиме offline, и доступна по ссылке: https://youtu.be/9eg5GbED8kY

Список ссылок по теме лекции — в описании на YouTube.

На Reddit прошла Ask me anything-сессия разработчиков ПО из SpaceX. Один из наших читателей, SP, собрал интересные тезисы из их ответов пользователям. Возможно, чуть позже мы подготовим текст с более подробным разбором, а пока держите вот такие краткие итоги:

- Кодеры SpaceX подтвердили, что на мониторах в драконе крутится GUI на Chromium и Javacript. сначала они этот вариант сделали для презентации НАСА, а потом им самим понравилось
- Пока игр на Crew Dragon нет, но в будущем их скорее всего добавят
- Симулятор стыковки не имеет ничего общего с реальным софтом, его начали только как шуточный проект
- Управление "Драконом" не имеет ничего общего с Tesla
- "Старлинки" сейчас генерируют в районе 5 терабайт телеметрии сутки, миссия Dragon -- сотни гигабайт
- Софт Starlink сейчас обновляют примерно раз в неделю. Получается, что ПО на выведенных спутниках новее, чем на тех, что находятся в процессе запуска
- Спутники Starlink это скорее датацентр с серверами, чем космический аппарат
- Каждый запуск 60-ти Starlink'ов -- это вывод более 4000 компьютеров с линуксом. На данный момент в группировке на орбите более 30К компьютеров и 6К контроллеров
- Про алгоритмы посадки рассказывать не могут - секрет :)
- Много программистов пришли в SpaceX из геймдева, из-за похожей математики и умения решать проблемы с производительностью

- Используемые языки программирования:
-- основной С/С++, сторонние библиотеки используют по минимуму, предпочитая писать собственные для контроля качества кода, применяют в основном ООП, хотя любят также упрощать код;
вебстек для дисплеев - HTML / CSS / JS + веб-компоненты + собственный фреймворк;
-- python для тестирования и автоматизации
- на бортовых компьютерах RTLinux (linux ядро с патчем PREEMPT_RT, превращающим ее в ОС реального времени), на контроллерах голый код;
- GUI в ЦУПе основаны на LabVIEW
- Качество кода обеспечивается модульными тестами и интеграционными тестами в том числе и на летных образцах
- Управление Драконом создано исходя из принципа минимального взаимодействия с пилотом
- Спутники Старлинк настроены переходить в режим высокого аэродинамического сопротивления при долгом отсутствии связи с землей для быстрого схода с орбиты.
- В SpaceX есть мощный инструмент для сопоставления программы полета с симулятором. Можно полностью смоделировать миссию или любые сценарии сбоя даже на оборудовании, разложенном на столе.
- Наземное ПО для Старшипа основано на вебстеке и GUI Дракона, оно же будет использовано и в интерфейсах самого Старшипа.
- Возможно скоро поделятся скриншотами с дисплеев Дракона
- Система безопасности полета работает не на бортовом компьютере, а исключительно на контроллерах и сама взаимодействует с датчиками. Эта система отвечает за прекращение полета, к примеру когда ракета сходит с курса

Ну и ответ на самый важный вопрос: "Of course we play KSP :)"

Круто, спасибо.

"Симулятор стыковки не имеет ничего общего с реальным софтом, его начали только как шуточный проект" - ну значит они шутники )

самое забавное про ui контролы. вроде риалтайм ос, а гуи из разряда гражданского по..

Там, скорее всего, UI не управляет ничем критическим

Он скорее для просмотра и наблюдения

Это да, но допустим датчик CO2 чутка подзависнет... А у меня сколько раз уже хром тупо крашился на пустом месте...

конечно там есть дублирующие системы. так что норм

Дык датчики на RTLinux обрабатываются

Например, вот в АСУ ТП может быть контроллер реального времени, а картинка выводиться через ICONICS GraphWorX, где логика пишется на, прости господи, VBA

Я бы использовал простые узлы которые по несколько тысяч раз по типовым ситуациям прогнали для выявления случаев отказа

Смущает, что у них на корабле не настоящая RTOS, а линуховый костыль

Я участвовал в проекте, где мы сравнивали производительность RTLinux, Xenomai и QNX.  RTLinux не уступал QNX, насколько помню.

Там не в производительности дело, а в критичных ситуациях высокой нагрузки, где у RTLinux не совсем реалтайм, в отличие от QNX

Я неправильно выразился.  Конечно, не производительность сравнивали, а именно отклик на внешние сигналы.