Насчёт языков такой пример приведу.

Я люблю писать движки для сайтов сам, потому что в движок вставляю кучу логики. Даже если сайт генерится полностью статиком (кто не вставляет - есть https://www.getzola.org)

Что заметил. Любой такой движок всегда начинается с "это же херня, там надо только шаблоны, ебнем jinja (tera) и поехали. Скрипт на баше справится". Через пару дней вставляется первая логика, через неделю верстка хочет минифаеры (и вставляется какое-то унылое говно на nodejs в обертке от питономодуля), через месяц "движок" выглядит так, что туда смотреть не хочется. Работает и хорошо. А если нет - хрен поймешь, что случилось, так что лучше уже не трогать.

В отличие от движков на Rust. Такие движки почему-то всегда в порядке. Их показывают джунам, как примеры кода. Их элементарно расширять, им не надо тащить говно с npmjs - комьюнити врапперы для говна не принимает.

Так что мой выбор - как бы очевиден.

Есть такая хорошая книга "Основы маркетинга" от Ф. Котлера. Я не маркетолог, но книгу давно прочитал и всем тоже советую.

Есть там одна фраза, которую я запомнил навсегда "Клиент покупает не ваш товар, ни вы, ни товар ему не нужны. Клиент покупает решение проблемы".

Приведу хрестоматийный пример с веб-серверами. В начале нулевых весь рынок держали IIS и Apache. Про IIS отдельная тема, но у Apache была своя проблема - он тормозил. А интернет требовал скоростей.

Были веб-сервера лучше Apache? Конечно были. Я одно время использовал Zeus - быстрая моща с офигенным, по тем временам просто космическим дашбордом.

Но Zeus стоил космических денег. $1699 по тем временам, примерно как сейчас 5к. Решал Zeus проблему со скоростью? Решал. Но проблема была не настолько серьезной, чтобы покупатель взял и выложил за её решение такие деньги.

Покупателю не нужен был Zeus. И не нужен был его космический дашборд. Поэтому покупатель тюнил Apache, что было намного дешевле, а потом перелез на NGINX, оплатив из кармана разовую переквалификацию персонала.

Zeus сдох.

Дамы и господа, наконец релизим наш IPC bus, в проде у клиентов уже крутится с июня. ELBUS переименован в BUS/RT, мы зарегистрировали эту торговую марку.

https://crates.io/crates/busrt

В 0.3 нового:

- полная совместимость с Windows
- привели в порядок тех. доки, перетащили в общий infosys (дока по раст-крейту на docs.rs само собой остаётся)
- поубивали немножко ненужных alloc (на скорость не повлияло, но пусть будет без них)

p.s. Торговую марку UK IPO что-то задерживали. При Карле теперь всё подписывают на неделю позже. Надеюсь, это у них временно.

Наши будни

- Дашборд подвисает!
- Да нет, всё в порядке...
- Открой вот эту страницу, поставь тут две галочки, теперь открой вот ту страницу в трех табах. Да не в двух, а в трех! Говорю, не в четырех, а в трех! Во! Видел?

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

Представляем вам новое поколение нашей системы промышленной автоматизации: 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 первого и второго и нет ничего лишнего.

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