В neovim 0.9 не просто выпилили pastetoggle, но еще и объявили paste mode как deprecated.

Потому что пора избавляться от анахронизмов. Оказывается, paste там давно работает нормально и без этого (см. видео пруф)

Выкатили Machine Learning kit for EVA ICS. Работа 6 месяцев наконец закончена.

Что это вообще: есть ML kit сервер и есть клиенты (Python/R)

- Сервер позволяет конвертировать метрики из SCADA-баз, которые идут в long-format, в wide-format таблицы. Задача вроде бы несложная, но он делает это адски быстро, параллельно, а при желании - из нескольких баз одновременно. Собрать таблицу на миллиард ячеек - дело пары секунд

- Таблицы передаются клиентам на Python и R в виде Apache Arrow stream (под R пока Arrow не добили), который потом можно либо юзать сразу, как arrow table, либо сказать клиенту что вам нужен Pandas или Polars

- Сервер также может работать наоборот - у вас есть Arrow или CSV, а он его может быстро раскидать по SCADA-базам. Что весьма удобно для рисерча, тестов и прототайпинга

- Если нет денег на сервер - не беда, клиенты работают и с нашим HMI API (но там медленнее)

- Python-библа также содержит абстракции над numpy/tensorflow, чтобы быстро считать linear regressions, что является основной задачей в IoT

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

- Сервер (естественно) на Rust

https://www.bohemia-automation.com/software/mlkit/

Сажусь за следующий большой проект - программирование PLC на Rust. Пока зарелизим, надеюсь у Rust уже будет всё хорошо с сертификатами. Но в крайнем случае есть RT-PREEMPT для SoHo и PikeOS для остальных.

Сегодня вышел пакет резервного копирования rustic.

Завидую таким людям, может они и про коронавирус не слышали?

Microsoft сообщила, что переписывает ключевые компоненты шиндовс на Rust.

С нетерпением ждём PANIC: called Result::unwrap() on an Err value на BSOD'ах.

Time-series база данных на ГЭС в Хаймбахе. Электростанции кстати 118 лет и до сих пор работает.

А это их SCADA. Олдскул, никаких вебморд

Я поскольку под Linux сижу, на игры особо не смотрю, а видяха у меня исключительно чтобы быстро считала тензеры. Иногда играю в Counter Strike (source). На днях внезапно узнал, что 11 лет назад вышла CS:GO, а в этом году даже выходит CS2 (под Linux, по традиции, думаю будет в следующем). Не успеваю за прогрессом.

Вопрос про гошку - в GoLang-чаты тоже геймеры периодически попадают, или это судьба только Rust?

Мой первый чат с коллегами про Rust

Мой первый онлайн по CS:GO. Надо же, 11 лет не играл ни во что, а руки-то помнят. 10 лет в кланах по батле - не шутка. Старичок потряс порохом и пошел дальше пилять свои PLC.

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

Но выход есть - правильные настройки thinkfan (для ThinkPad'ов) и алюминиевая подставка. Кстати, почему их практически перестали делать качественно? Лет 15 назад я купил совершенно добротную подставку от Cooler Master, весом килограмма в 3 чистого алюминия за какие-то жалкие 15$

Первое правило суппорта: все врут

- у нас система периодически виснет
- вы опять логи на nfs кидаете?
- нет, мамой клянусь!
- покажите конфиг логгера
- log: /mnt/remote/nfs/blabla
- а почему он так называется?
- не знаю. я уточню у админов...

IBM планирует уволить 7800 человек и заменить их AI. В основном сокращения коснутся HR.

Поставить смазливое фото на авку в LinkedIn и генерить сообщения, на которые никто не отвечает, может и ChatGPT.

Поскольку GPIO через sysfs в Linux давно депрекейтнули, а универсального вменяемого пока не завезли, давно хотел заняться кишками OPC UA. И у меня наконец получилось понять его дзен.

Уже как-то писал об этом чуде. Спецификация протокола занимает 600 страниц (или 800?) и на данный момент на рынке нет ни одного решения, которое бы отвечало ей на 100%. Производители спецификацию поддерживают частично, или "принимают к сведению", впрочем ситуация с совместимостью куда лучше, чем в том же Ethernet/IP.

Архитектуру OPC UA ненавидят многие - нужно иметь определенный тип ума, чтобы этим заниматься. Архитектура страшная. В своё время к ней приложила свою руку Microsoft (еще та, старая, с COM/DCOM), со всеми вытекающими, а потом полировала OPC Foundation, где около 1000 мемберов и каждый хотел что-то свое.

Начнём с соединения. Совершенно адская система авторизации, которая за многие годы включила в себя сумасшедшее количество способов и вариантов: aes128, aes256, basic128, basic256, с подписью пакетов, с подписью и шифрованием, авторизация по паролю, по ключу... В общем обрадую что на практике, если OPC крутится на fieldbus, авторизации обычно нет вообще.

Все переменные на OPC-сервере имеют Node ID. Причем оно может быть u32, String, GUID или даже Vec<u8>. Как сервера разбираются в этом чуде внутри себя - отдельная адская боль. Опять обрадую, на практике обычно используют второй вариант, иногда первый.

Node - это не только переменная. Еще есть папки у них тоже есть какая-то node. Можно вставлять одну node в другую и таким образом делать древовидные иерархии из папок, где внутри могут быть переменные. Это - единственный способ организации дерева. Но опять обрадую, на практике это больше для юзеров, которые решили залезть в OPC-сервер гуём, чтобы им не вырвало мозг. Софт работает только с node ids.

Типизация переменных. Как обычно, в попытках впихнуть невпихуемое, появились такие прелести, как XmlElement, LocalizedText (папки и display имена переменных можно, но не нужно, переводить локалями прямо на сервере) и некоторые другие. Обрадываю: на практике имеем дело только с привычными примитивами и массивами из них.

Каждая переменная имеет историю, которую может вести сервер. Когда поставили, что поставили, server timestamp, source timestamp и т.д. - попытка дидов скрестить контекст с TSDB. По сути, то что пытаются делать в Eclipse Zenoh - там зумеры переизобретают OPC (и может слава богу). Обрадываю: на практике я не видел, чтобы кто-то эту историю использовал.

Еще на серверах есть views, discovery, поддержка мульти-узлов, репликации и прочее-прочеее. Но если очень утрировать, OPC - это такая себе key/value database, правда с сумасшедшим набором легасни и непонятными в наше время наворотами. Не зря же 600 страниц (или 800?). А API - ну очень похоже на Beckhoff ADS. ADS явно строили на базе OPC, выкинув всё ненужное.

Впрочем, для продукта из 90х это круто. А еще круче, что стандарт прожил 27 лет и явно переживёт эти ваши Redis'ы.

Телефон пищит, я кручу железку, коллега:
- Там емейл пришел что кто-то в твой вконтакте зашел из Буэнос-Айрэса
- На какое имя? Александр? Юрий? Иван?
- Михаил пишут
- Михаила не помню. Пусть забирают нах

Гугл:

- ИИ это очень опасно. Нужно подождать
- Чего подождать?
- Подождать, пока мы выкатим свой. Мы мля чето протормозили...

.

Понадобилось кое-что крупное запрограмить на PL/PGSQL и встал вопрос, что писать многостраничные процедуры и функции в CLI как-то не очень весело.

Внезапно, это конечно же можно делать прямо из (neo)vim. И даже удобно.

Плагин называется https://github.com/kristijanhusak/vim-dadbod-ui

Считаю, что проц-макросы в Rust нужно запретить. Проц-макросы генерят очень эффективный код (даже лучше чем GPT3). Проц-макросы - это черный ящик, пока мы не запустим специально cargo expand, мы не узнаем, что они там наворотили (ИИ хотя бы свой код показывает).

Проц-макросы отбирают рабочие места и несут серьезную угрозу человечеству. Самое страшное - в отличие от ИИ, требующего некоторых вложений на обучение, проц-макрос может написать любой человек, не специалист (а вдруг со злым умыслом?)

Часто спрашивают "что почитать для продвинутого уровня в Rust?". Рекомендую вот эту книгу. Пошел освежить по атомикам, в результате узнал ещё некоторые вещи о потоках, которые в жизни упустил.

Если нету или жалко 40$, автор любезно приглашает прочитать всю книгу бесплатно на своём сайте. https://marabos.nl/atomics/

.

Выложил в паблик экспериментальную платформу PLC под Linux - rPLC. Пока без анонса, только тут. Потихоньку начнем анонсировать к концу месяца.

Проблема насущная - наша EVA ICS v3 была платформой, которая решала множество задач, в том числе автоматизации. v4 - это только SCADA с упором на IaC и репликацию узлов. В результате часть клиентов не могут слезть с v3, а платить деньги CODESYS за их простенький Linux-PLC не желают (я и сам не желаю). Попытки сделать что-то удобное и рабочее вел с 2020 года, но наконец паззл сложился.

Это одна из первый PLC-платформ, где Rust используется как основной (и пока единственный) язык программирования, при этом применяется классический PLC-подход: есть общий контекст переменных, программы исполняются в циклах, а I/O максимально изолировано от программиста (пока из коробки есть Modbus, OPC UA ну и полная интеграция с EVA ICS. но можно легко расширять под другое).

Код-генерация - совмещает проц-макросы для программ и codegen для I/O и контекста.

Какой jitter можно добиться на Linux? На практике, при условии что хост не имеет лишней нагрузки или использует isolcpus - в пределах 120-150us, что примерно соответствует уровню, который декларируют Beckhoff в своих IPC (причем это на Supermicro E100-9AP-IA, где стоит довольно слабый Atom E3940). Опять же на практике - у нас нет задач, где циклы бегают быстрее 10ms и нужен jitter < 1ms. Да их вообще мало у кого есть, это больше для пиара.

Какие сертификации на это можно получить? Вопрос сложный, потому что в первую очередь сертифицируется ящик. Будем пробивать бюрократию.

Планы на будущее: порт под FreeRTOS (там сейчас стало получше с Rust), плагин под VS Code, Pro-версия (менеджер isolcpus и процессов из гуя, статистика с графиками и т.д.), реалтайм-тюнинг сети. И главное - есть хорошая идея по репликации контекста между процессами. Хотя, прямо сегодня конечно можно реплицировать через OPC.

Даю линк сразу на quick start, чтобы было понятнее: https://info.bma.ai/en/actual/rplc/quickstart.html

А репа тут: https://github.com/eva-ics/rplc

Потратил целый день на тюнинг библиотеки на 200 строчек, но не жалею, так как наконец еще глубже появился повод разобраться с фьючерами в Rust.

Библиотека собственно - https://github.com/alttch/simple-pool, написал ее хз когда давным-давно. Идея простая - пул любых ресурсов, или можно с Unit использовать для ограничения количества выполняемых тасков (как рантайм-агностик семафор). Реализация сложнее.

Future, для тех кто не в курсе - это функция (точнее - объект, в котором одна обязательная функция poll), которая возвращает либо std::task::Poll::Ready<T>, если она отработала или Poll::Pending, если возвращать нечего и это просьба рантайму включить ее в лист ожидания. Из доступных инструментов общения с внешним миром у вас по сути есть только std::task::Waker. Клон waker вы можете отдать в другой объект, который, если появились новые данные, или как в нашем примере, новый ресурс, этот waker дергает и "будит" вашу функцию. Но на самом деле не будит, а только сообщает рантайму, что ее можно разбудить. Так работает в Rust весь async.

Старая имплементация моего пула просто будила сразу всех ожидающих в порядке очереди. Первый хватал ресурс, а остальные дальше выстраивались по-новому. Но рантайм порядок вызова wakers не берет как должное, а принимает к сведению, поэтому в каком порядке реально разбудятся фьючеры - только ему известно. Может разбудить сразу несколько в разных потоках, например, и они устроят между собой небольшой дата-рейс. И вот, внезапно появился проект, где очередь очень строго нужно соблюдать.

Задача кажется простой - так давайте, когда ресурс пришел в пул, дергать один первый waker и делов. И действительно, оно отлично работает. Пока вам не хочется делать фьючерам abort.

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

Промежуточный вариант, проверять жив ли фьючер перед отправкой сигнала (например через любой связанный канал), быстро отпал - мы можем послать wake, а фьючер будет абортирован, пока до него дойдет очередь исполнения и опять всё зависнет. Это работало в вакууме, но не выдержало первый же большой стресс-тест.

Итог. Единственная возможность у фьючера узнать (точнее - предположить), что его абортировали - это impl Drop. В Drop мы можем сообщить пулу, что мы дальше работать не будем и вместе решать, что делать. Если мы стояли в очереди - выбросить из нее наш waker. Если же waker уже был дернут, но мы так и не успели обработать данные - пул должен разбудить следующий Future. А с нами попрощаться.