Ну что ж, это свершилось. Мы шли к этому два последних года и вот

Представляем вам новое поколение нашей системы промышленной автоматизации: EVA ICS v4

- Первая IIoT-платформа нового поколения, полностью написанная на Rust: супер-быстрая, безопасная и стабильная

- Позволяет обрабатывать миллионы объектов на одном узле (реальный тест - 30 миллионов, дальше устали добавлять)

- Возможность выполнять действия и сценарии на любом удаленном узле в кластере

- Новая микро-архитектура ядра системы полностью расширяема и позволяет делать сетапы любой сложности для любых промышленных нужд: производство, электроэнергия, "умные города" (уже начали мигрировать всех наших клиентов-энергетиков, полет отличный)

- Полная поддержка web-SCADA приложений "из коробки"

- Репликация и взаимодействие между узлами в реальном времени

- Готовые бинарники для x86_64 и aarch64 (Linux). Поддержка FreeBSD и TwinCAT/BSD будет до конца года

https://www.eva-ics.com/

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

Есть, к примеру, такая штука, как FIPS 140. Федеральный стандарт США по сертификации криптографических модулей. Де-юре требуется, если ваша программа используется правительством США, но де-факто приветствуется везде и на более частном уровне. У частников режимы "FIPS 140" можно даже не включать - они как фарфоровый слон на тумбочке, приносят счастье сами по себе.

Так вот. Наш любимый дырявый старичок OpenSSL - давно сертифицирован по FIPS 140-2, а неделю назад они замахнулись на FIPS 140-3. Сертификация - дело недешевое, но спонсоров у OpenSSL на это дело достаточно - Убунта и RHEL тоже хотят работать в кровавом ентерпрайзе. Ну и шиндовс конечно тоже сертифицирован.

А вот у нативных Rust крейтов - сертификаций нету. Ради интереса пробежался - да, заказывают какие-то аудиты у мелких контор. Аудируют силами комьютити. Аудируют друг друга. Но чтоб вот так, на официально-высоком уровне - увы.

Пора комьюнити начинать что-то с этим серьезно делать, иначе криптография на Rust так и останется красивой игрушкой.

Немного про FIPS-140 с практической точки зрения.

Всё это больше касается разработчиков ОС и крипто-библиотек, "обычный" девелопер должен убедиться, что все крипто-библиотеки (и возможно хардварные модули), которые используются, прошли сертификацию.

OpenSSL конечно не одни в мире, кто имеет сертификации, есть и другие, например тот же весьма популярный WolfSSL (к сожалению пока не имеет вменяемых биндингов для Rust).

В OpenSSL FIPS-140 режим включается вызовом FIPS_mode_set(1) (openssl::fips::enable(true) для Rust) и по факту просто вырубает в модуле несертифицированные методы - они начинают возвращать ошибку на любой вызов. Из более-менее популярного, что рубится сейчас - работа c PKCS12. FIPS-режим должен быть включен в OC и поддерживаться версией OpenSSL, которую вы используете.

Rust-бинарники следует собирать динамическими и без openssl/vendored - в vendored FIPS нету.

Для Linux есть разные пути, чтобы включить FIPS-режим в ОС. Но если вам это нужно сугубо для тестирования - проще всего взять бесплатный ключ на Ubuntu Pro, там оно включается одной командой.

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

https://www.youtube.com/watch?v=ibnlDaPspwU

Насчёт гита. Огромное количество пользователей используют всякие надстройки, навроде адского gitlab и прочего для одной цели: ставить защиту веток.

В "голом" git это делается путем установки на хосте receive.denyNonFastForwards в true

Но вышеупомянутая опция запрещает force push во все ветки без исключений. Это было круто лет так 15 назад, но сейчас у каждого по 2-3 устройства и рабочие ветки на хосте используются не столько для бекапов, сколько для синхронизации кода.

Почему в git в коробке до сих пор нет опции для защиты конкретных веток и приходится использовать адские самописные хуки? Кроме как заговор производителей "профессиональных" решений, обьяснить не могу.

Ударяю в очередной раз лонгридом по RESTful и объясняю, почему RPC - это хорошо для сложных систем, а RESTful идеально для бложиков и фотобанков с котятами, но не более.

https://medium.com/@disserman/why-there-is-no-restful-api-in-eva-ics-v4-557b48cf1656

Реклама робота-пылесоса от Whirlpool. 1959й год.

Наш collaboration в лавке сейчас выглядит так

- а где активные таски?
- в main, файл TODO.todo
- там же все таски по проекту
- да, перед твоими стоит твой ник
- и как посмотреть только мои?
- grep

И я вам скажу, все прекрасно работает, координируется и релизится. Для остального есть email.

Продолжаем аскетизм. Сегодня две небольшие команды съехали с gitlab на pure git. Цель была перейти только на git+openssh, с авторизацией только по ключам, всё администрирование делать штатными средствами Linux. Был написан пакет из двух десятков баш-скриптов для управления, накануне всё переехало в один rust-бинарник. Логику ACL оставили простейшую - юзер либо имеет доступ к репе, либо нет. Тот, кто имеет доступ, может быть мейнтейнером и пушать в protected-ветки (кроме force), или не быть и пушать только в unprotected. По этому поводу будет другой пост, а сегодня расскажу опыт перехода.

- С ssh-ключами вышло не всё хорошо. Дают fingerprint, дают приватные. У админов было немножко работы, чтобы выдать-выклянчить нормальные, но все справились

- На утреннем собрании всеми участниками команд было заявлено, что никаких функций gitlab они не используют и к переезду готовы (как же я ошибался)

- Сам переезд прошел минут за 10, так как всё было готово и оттестировано заранее. Технических проблем не было

- Проблемы были с персоналом. Самый часто задаваемый вопрос "и где? как заходить в этот ваш git? где веб-морда, куда тыкать?" Удивление, что после git remote set-url оно работает как и раньше и пишет куда-то "в никуда". мистика

- Второй самый часто задаваемый вопрос - часть сотрудников думали, что мы едем на GitHub

- Третий - как делать пулл-реквесты? Долгие объяснения и лекции, что пулл-реквест - сущность виртуальная и делать его можно в любом виде, даже пнув коллегу в стул ногой

- Долгие дискуссии и выбор десктопных клиентов. Оказалось что git log/git diff/git show большинство умели смотреть только в вебморде

- После обеда часть команды сказала, что если всё есть в консоли - нахера эти вебморды? И за что мол берут наши деньги, если всё можно сделать и так. Другая часть требовала купить GitKraken

- К вечеру другая часть решила в дураках не оставаться и от GitKraken отказались, заявив, что в консоли смогут не хуже

- В целом, переезд удался на отлично. Если исключить человеческий фактор, с которым возились дольше всего

Кстати о человеческом факторе. И об адресации контекста в промышленных приложениях.

Филдбас-инженер - не программист. Он конечно может быть и программистом, но обычно нет. И то что его научили писать в переменные и оттуда читать - уже хорошо. А то бы сидел в своих LD (кстати у среднестатистического программиста наоборот - от ladder logic начинается вынос мозга, он привык что это где-то под капотом, размером в 15нм штука).

Филдбас-инженер хочет писать в VAR. Но при этом, когда ему понадобится вторая VAR, он хочет писать в VAR[2]. А первую адресовать как VAR[1], и чтобы VAR без индекса тоже работало, то что он раньше писал. Он не понимает, что в первом случае это переменная, а во втором - массив из перееменных. Ему это не нужно. Ему нужна одна переменная, две или десять. И максимум на что он согласен - переступить через принципы и считать индексы от нуля (поэтому они обожают MatLab, где переступать не надо).

Давайте посмотрим, как работает практически любая имплементация Ethernet/IP: VAR := 1 - работает. VAR[0] := 1 - тоже работает. Вряд-ли такой UX задумывался из коробки, тут дело в другом - в Ethernet/IP в памяти крутится простой контекст и записывать ему в переменную, в начало массива или в его нулевой индекс - наплевать.

Теперь возьмем TwinCAT. В ADS VAR[0] := 1 будет работать, только если это массив, причем из более чем одного элемента. Потому что в ADS считается, что если у массива длина 1 - это автоматически переменная. Кроме того, есть чёткое разделение, где переменная, а где массив, и API за этим следит. ADS писали программисты для программистов, причем в отличие от первого варианта, им не повезло выехать на архитектуре.

Никогда не пишите API, как будто ваши клиенты - тоже программисты. Очень часто это совсем не так.

1 ноября OpenSSL выпустят багфикс-версию 3.0.7 из-за критической уязвимости, которую пока не раскрывают.

Если у вас системный OpenSSL версии 3.х - следует немедленно обновиться.

Rust-приложения со статически слинкованной OpenSSL vendored обновлять не нужно - в vendored идут 1.1.х, которые данной уязвимости не имеют.

Поскольку коронавирус закончился, опять уехал на остров, где вспоминаю особенности MDD (Mañana driven development).

Суть техники - вы копаетесь в задаче минут 15, после чего дропаете все изменения и откладываете задачу на завтра-послезавтра. Невероятно, но факт - через несколько дней задача решается где-то в подсознании и на сам кодинг тратится на 50, а то и 80% меньше времени, чем при атаке в лоб.

Таким образом, по всем текущим задачам мы идем с лагом в 1-2-3 дня, но

- увеличиваем общую производительность
- не выгораем и готовы работать в таком режиме годами

Проверено на себе. Rioja в качестве стимулятора подсознания - приветствуется, но не является mandatory.

Я наверное единственный, кто еще не прокомментировал стабилизацию GAT'ов в Rust.

А комьюнити воет воем. На Reddit зайдешь - везде GAT'ы. Человек вчера использовал полтора дженерика, а сегодня уже уверен, что GAT'ы его спасут, не хуже вакцины от известного вируса.

Если вы не знаете, зачем вам GAT'ы (и даже не знаете, что это - Generic Associated Types), оно вам скорее всего и не нужно. Rust был до GAT'ов и Rust будет после GAT'ов. На Rust можно было писать без GAT'ов и можно будет дальше писать без GAT'ов, как многие пишут вообще без дженериков и совершенно этого не стесняются.

Сначала GAT'ы пойдут в std и в разные популярные крейты, где они действительно нужны. Дальше - набьется практика применения, а практика - это не три, и даже не десять полуабстрактных примеров. А "вот тут и тут с GAT'ом красиво а без GAT'а - не очень".

Keep calm и всё будет хорошо. Хватит GAT'ов и на наш век. Всем хватит. Если у вас еще нет GAT'ов в коде - вы не лох.

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

При использовании Rust+Tokio, есть элегантный выход из положения - включать трейс-логи например только для тех RPC-вызовов, которые нужно отдебажить. В этом поможет tokio::task::LocalKey.

При установке LocalKey, фьючер и все его дочерние вызовы получают в своей области видимости переменную, недоступную для остальных. После чего, при вызове этими фьючерами стандартных макросов log::trace! или log::debug!, логгер приложения может использовать эту переменную как флаг для понижения фильтрации и пропускания трейсов, а также дополнительно собирать трейс-логи в указанное место, например скидывать их в выбранный клиентом топик pub/sub-сервера.

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

По просьбам трудящихся, описал call tracing в асинхронных Rust-приложениях подробнее:

https://medium.com/@disserman/api-call-tracing-in-high-loaded-asynchronous-rust-applications-bc7b126eb470

в конце статьи Gist с полным кодом

.

Иногда коллеги спрашивают, что я использую в Rust для веб-серверов. Я использую только Hyper.

Опираясь на личный опыт поддержки проектов годами и даже десятилетиями. Обычно через долгое время проект представляет собой монстра, в котором "живут" несколько поколений совершенно разных API, а статика отдаётся по какой-то дикой логике. Из фреймворка давно выпилен роутер и заменен на что-то кастомное. А остальное - обвешено десятками модулей, функционал которых рано или поздно всегда упирается в API этого самого фреймворка и что-то делается костылями, а что-то вообще никак. В особо тяжелых случаях фреймворк приходится форкать, со всеми вытекающими.

В Hyper у меня один handle, в который пришел Request и некоторые параметры коннекта, по желанию. А я должен отдать Response. Поддерживаются стримы для body первого и второго и нет ничего лишнего.

И это прекрасно. Мой веб-сервер - мои правила.

Протестировал Mold (https://github.com/rui314/mold) и как он дружит с Rust. Это альтернативный линкер, который быстрее обычного, за счёт грамотных алгоритмов распараллеливания и прочего.

Тестировал на нашем PSRT (https://github.com/alttch/psrt), собирал только сервер. Проц Core i7-11800H (16 ядер).

В обычном режиме - Mold однозначно выигрывает по скорости, примерно 20-30% (5 секунд на линковку против 7). При включении LTO - разницы нету, иногда даже проигрывает стандартному.

Вердикт: хорошо использовать при разработке, если у вас в проекте один большой бинарник или shared lib, время линковки оно ускорит. Причем чем больше бинарник, тем больше будет эффект. Для сборки релизов, если включены LTO и прочие оптимизации - смысла нет.

Себе пока ставить не буду - при сборке сам Mold требует std::span, а он есть только в C++ 20, на моей Ubuntu 20.04 LTS его еще не изобрели.

Немного исследований по поводу machine learning в IoT:

- основная цель ML в промышленных процессах - accident prevention и predictive maintenance. остальное - либо баловство, либо уже не только промышленное

- не смотря на то, что в 99% случаев применяется LSTM, не существует универсальной конфигурации нейросети, которая решит любую задачу

- как и в любой другой области, сталкиваясь с незнакомым состоянием системы, нейросеть начинает генерить полный бред и пока не может заменить человека-оператора. Нейросеть руководствуется только "опытом", человек - знаниями, интуицией, в конце концов есть звонок другу

Я кстати получал магистра в Computer Science именно в Artificial intelligence и впервые за 25 лет наличия диплома делаю что-то вменяемое по специальности.

Тогда, 25 лет назад, никакого этого вашего TensorFlow не было и в помине. Нас учили немножко анализировать руками матрицы и графы на прологе, и очень много C и С++, потому что (цитирую) "С помощью С/С++ вы сможете заработать на хлеб, а искуственный интеллект - профессия далекого будущего, дай бог чтобы студенты ваших студентов делали хоть что-то на практике..."