14 января 2017 года мы гордо внедрили в офисе 10GbE, по случаю удачной покупки пары свичей от Netgear, а большинство серверов уже это умели из коробки. Также нескольким лицам, приближенным к CTO, в десктопы были впилены Intel X520/540. Реальность немного разочаровала, это был самый дурацкий апгрейд в моей жизни.
Сначала, помня переход с FE на GbE, я чувствовал себя пионером более крутой технологии, которая наконец пошла в массы по доступным ценам. Однако как же я просчитался.
- Переход с FE на GbE шел параллельно с возрастающими объемами данных. Нет, безусловно он еще где-то возрастает и сейчас, есть же Netflix, облака, магистральные провайдеры, Pornhub в конце-концов и специализированные кластера, где GbE IPC или общение с СУБД не вытягивает. Но возьмите компанию средней паршивости вроде нашей, разработчики и интеграторы. 20 лет назад объем данных нашего NAS составлял 4Tb, это была, по тем временам, довольно большая система, состоящая из пары десятков корзин. За 20 лет мы полностью отказались от пиратского софта, а затем частично и от пропиетарного и хранить стало нечего, а интернет давно стал безлимитным. Зачем хранить образ Ubuntu 16LTS, если его можно скачать? Да и зачем качать, если он уже не поддерживается. Не знаю какая там еще легасня осталась в проде, но новые интеграции или разработки уж точно на нем никто делать не будет. В результате, спустя 20 лет, мы живём с теми же 4Tb +/-, да и то пора давно половину почистить. Что уже давно влазит на одну SSD форм-фактора M2-2280.
- Изменение баланса вычислительных мощностей. Если еще 10 лет назад гонять distcc было нормой, то сегодня мой ноутбук мощнее почти любого сервера у нас в стойке. Да, оно там клепает CI/CD где-то в фоне, но для разработки в реальном времени уже давно не используется. А раз не используется - не особо интересна и скорость, в том числе скорость сети, ведь оно больше не тратит мое время.
- 10GbE карты оказались расходниками (да, и те встроенные). Несколько раз серверные платы с X552 приезжали DoA. Внезапно оказалось, что это не GbE, который может работать десятилетиями, карты стабильно дохли, иногда чаще, чем раз в год. Может конечно в 700-й серии Intel наконец починили "детские" болезни, но у меня руки до них уже не дошли.
- 10GbE карты на десктопы и ноутбуки не дошли примерно вообще. Нет спроса - нет предложения, законы рынка. Да и кто будет их постоянно менять по гарантии?
- В качестве бонуса, GbE давно уже избавился даже от юношеских болезней и чтобы получить честный гигабит не нужно прокидывать отдельный кабель, дурачиться с jumbo frames и вручную тюнить размеры окон.
Сегодня, 28 мая 2023 года я вырубил оба свича от Netgear. Не взлетело и уже не взлетит.
Сначала, помня переход с FE на GbE, я чувствовал себя пионером более крутой технологии, которая наконец пошла в массы по доступным ценам. Однако как же я просчитался.
- Переход с FE на GbE шел параллельно с возрастающими объемами данных. Нет, безусловно он еще где-то возрастает и сейчас, есть же Netflix, облака, магистральные провайдеры, Pornhub в конце-концов и специализированные кластера, где GbE IPC или общение с СУБД не вытягивает. Но возьмите компанию средней паршивости вроде нашей, разработчики и интеграторы. 20 лет назад объем данных нашего NAS составлял 4Tb, это была, по тем временам, довольно большая система, состоящая из пары десятков корзин. За 20 лет мы полностью отказались от пиратского софта, а затем частично и от пропиетарного и хранить стало нечего, а интернет давно стал безлимитным. Зачем хранить образ Ubuntu 16LTS, если его можно скачать? Да и зачем качать, если он уже не поддерживается. Не знаю какая там еще легасня осталась в проде, но новые интеграции или разработки уж точно на нем никто делать не будет. В результате, спустя 20 лет, мы живём с теми же 4Tb +/-, да и то пора давно половину почистить. Что уже давно влазит на одну SSD форм-фактора M2-2280.
- Изменение баланса вычислительных мощностей. Если еще 10 лет назад гонять distcc было нормой, то сегодня мой ноутбук мощнее почти любого сервера у нас в стойке. Да, оно там клепает CI/CD где-то в фоне, но для разработки в реальном времени уже давно не используется. А раз не используется - не особо интересна и скорость, в том числе скорость сети, ведь оно больше не тратит мое время.
- 10GbE карты оказались расходниками (да, и те встроенные). Несколько раз серверные платы с X552 приезжали DoA. Внезапно оказалось, что это не GbE, который может работать десятилетиями, карты стабильно дохли, иногда чаще, чем раз в год. Может конечно в 700-й серии Intel наконец починили "детские" болезни, но у меня руки до них уже не дошли.
- 10GbE карты на десктопы и ноутбуки не дошли примерно вообще. Нет спроса - нет предложения, законы рынка. Да и кто будет их постоянно менять по гарантии?
- В качестве бонуса, GbE давно уже избавился даже от юношеских болезней и чтобы получить честный гигабит не нужно прокидывать отдельный кабель, дурачиться с jumbo frames и вручную тюнить размеры окон.
Сегодня, 28 мая 2023 года я вырубил оба свича от Netgear. Не взлетело и уже не взлетит.
👍20😁1💩1
Типичная задача обработки событий в библиотеке с кастомными хендлерами событий (в любом языке). У вас есть некий
Неправильный вариант:
Правильный вариант: открыть HANDLERS, отклонировать всё, что собираешься запускать и отпустить Mutex. Только так, от греха.
static HANDLERS: Mutex<BTreeMap<EventKind, Vec<fn-blahblah>>>и методы add/remove handler, которые вставляют/убирают хендлер-функции для EventKind.
Неправильный вариант:
if let Some(funcs) = HANDLERS.lock().get(kind) {и строго-строго запретить в хендлерах использовать add/remove handler или приближаться к HANDLERS Mutex любым другим способом. Бесполезно. БЕСПОЛЕЗНО! Забудут, забьют, вылезет неспециально, фаза луны, уровень прилива/отлива, кодил-хендлер-по-пьяне, устал, не спал, не ел.
for f in funcs {
// call it
}
}
Правильный вариант: открыть HANDLERS, отклонировать всё, что собираешься запускать и отпустить Mutex. Только так, от греха.
👍12😁2💩2
Внезапно узнал, что в React объявили классы харам, потому что ООП говно и народ в нём путается.
Впервые зауважал что-то из мира жявоскрипта.
Впервые зауважал что-то из мира жявоскрипта.
😁30👍6💩5
У serde_json есть такая "приятная" особенность, как поддержка arbitrary precision numbers.
Оно, безусловно, хорошо в тех кейсах, где действительно нужна длинная математика. Но рассмотрим такой пример:
Alice
Но главная проблема не в этом. Из-за особенностей сборки rust/cargo, arbitrary_precision в serde_json может включиться совершенно незаметно ̶о̶т̶ ̶с̶а̶н̶и̶т̶а̶р̶о̶в̶ для вас, как только ее включит любой зависимый крейт.
Варианта решения собственно два: либо использовать serde_json::Value только с serde_json. Либо конвертировать её перед сериализацией в свой собственный Value или конкретный тип. Причем конвертация имеет следующую особенность:
- serde_json::Value::serialize - костыль останется и ничего не получится
- MyType::deserialize - будет работать правильно
Мои искренние проклятия тем, кто это имплементировал. Я когда первый раз увидел этот ужас на стороне Боба, подумал или меня хакнули или уже белка.
Оно, безусловно, хорошо в тех кейсах, где действительно нужна длинная математика. Но рассмотрим такой пример:
Alice
let val: serde_json::Value = json!({"number":1234567890});
let buf = rmp_serde::to_vec_named(&json_val).unwrap();
// send buf
Bob#[derive(Deserialize)]
struct Test {
number: i32
}
let _: Test = rmp_serde::from_slice(&buf).unwrap();
Пример будет работать замечательно, пока Alice не врубит в serde_json arbitrary_precision. После чего всё работать перестанет, поскольку serde_json::Value будет хранить уже не Number, а map вида{ "number": { "$serde_json::private::Number": "1234567890" }}
но об этом знает только serde_json. Визуально вы ничего не заметите, и даже Debug будет выдавать то, что вы ожидали. Но остальные сериализаторы на базе serde (как в нашем примере rmp) эту особенность будут игнорировать и Value будет сериализироваться в том виде, в каком ее видит serde, а не serde_json со своим набором костылей для длинных чисел. В результате, проблема а) payload возрастает в разы и б) payload на другой стороне просто невозможно десериализировать.Но главная проблема не в этом. Из-за особенностей сборки rust/cargo, arbitrary_precision в serde_json может включиться совершенно незаметно ̶о̶т̶ ̶с̶а̶н̶и̶т̶а̶р̶о̶в̶ для вас, как только ее включит любой зависимый крейт.
Варианта решения собственно два: либо использовать serde_json::Value только с serde_json. Либо конвертировать её перед сериализацией в свой собственный Value или конкретный тип. Причем конвертация имеет следующую особенность:
- serde_json::Value::serialize - костыль останется и ничего не получится
- MyType::deserialize - будет работать правильно
Мои искренние проклятия тем, кто это имплементировал. Я когда первый раз увидел этот ужас на стороне Боба, подумал или меня хакнули или уже белка.
👍13😁5🔥3💩3
Возвращаясь к вчерашней теме. Решено было с arbitrary_precision не воевать, а просто запретить. А как узнать, что какой-то крейт врубил определенную feature в другом, где-то глубоко в зависимостях? Тут поможет только cargo metadata, но можно не напрямую, а для этого, как всегда есть тоже отдельный крейт. В итоге, следующий код в build.rs запретит сборку и выведет все потенциальные крейты, которые могли feature включить:
https://gist.github.com/divi255/8575aa22df0825291933fd03194421f6
https://gist.github.com/divi255/8575aa22df0825291933fd03194421f6
Gist
Use cargo metadata to deny build if some dependency crate feature has been enabled
Use cargo metadata to deny build if some dependency crate feature has been enabled - build.rs
🔥11👍5💩3
Программирование с ChatGPT напоминает анекдот
- какой ваш самый крутой навык?
- быстро считаю
- сколько будет 843*2316?
- 74960!
- но это же нихера не правильно
- зато быстро!
- какой ваш самый крутой навык?
- быстро считаю
- сколько будет 843*2316?
- 74960!
- но это же нихера не правильно
- зато быстро!
😁22👍17💩1
И про организацию работы.
На одном большом проекте у нас есть в гите файлик TODO.todo. А у меня даже есть плагин для vim - когда я нажимаю enter, то появляется новая строчка и квадратик [ ]. А когда нажимаю на строчке пробел - в квадратик ставится буква "x" и строчка опускается вниз файла. Файлик TODO.todo прекрасно справляется со своей задачей, обеспечивая кооперацию примерно пяти человек на протяжении последних 5 лет, причем люди даже меняются. Хотя вру, мы год назад выпустили новую версию и перешли на другую репу, поэтому два файлика. Старый остался в старой репе.
На другом проекте (маленьком) интегрировали Trello. За пол года сделано очень много работы, но в основном в трелло. А код двигается со скоростью примерно полторы строчки в день.
Вчера был очередной большой митинг "почему нихуя не сделано и так медленно", по итогам которого я тоже завел там в репе файлик TODO.todo. Думаю, файлик спасет.
На одном большом проекте у нас есть в гите файлик TODO.todo. А у меня даже есть плагин для vim - когда я нажимаю enter, то появляется новая строчка и квадратик [ ]. А когда нажимаю на строчке пробел - в квадратик ставится буква "x" и строчка опускается вниз файла. Файлик TODO.todo прекрасно справляется со своей задачей, обеспечивая кооперацию примерно пяти человек на протяжении последних 5 лет, причем люди даже меняются. Хотя вру, мы год назад выпустили новую версию и перешли на другую репу, поэтому два файлика. Старый остался в старой репе.
На другом проекте (маленьком) интегрировали Trello. За пол года сделано очень много работы, но в основном в трелло. А код двигается со скоростью примерно полторы строчки в день.
Вчера был очередной большой митинг "почему нихуя не сделано и так медленно", по итогам которого я тоже завел там в репе файлик TODO.todo. Думаю, файлик спасет.
😁30👍6💩4
Американский боевой дрон с ИИ, в ходе тренировочной миссии-симуляции, пытался убить оператора, который "мешал" ему работать. После того, как в программу четко прописали, что оператора убивать нельзя, дрон стал бомбить вышки коммуникации, чтобы оператор не мог отдавать ему команды.
После того, как информация просочилась в прессу, командование стало отрицать проведение эксперимента.
https://www.bbc.com/news/technology-65789916
После того, как информация просочилась в прессу, командование стало отрицать проведение эксперимента.
https://www.bbc.com/news/technology-65789916
😁23💩2👎1
Покодил сегодня на TypeScript. Говно в целом, но понравился. Лучше чем JS.
Может хоть нормальную работу в стартапе найду, а то вожусь с вашими этими растами. Чулки продам, тыквенный латте куплю!
Может хоть нормальную работу в стартапе найду, а то вожусь с вашими этими растами. Чулки продам, тыквенный латте куплю!
😁28💩3👍2
This media is not supported in your browser
VIEW IN TELEGRAM
Открою тайну, что ж я там такое пиляю я на TS. А пиляю я плагин для HMI под графану с контролами.
Графана штука неплохая, но контроль через неё совсем говно. Первая попытка выйти в Industrial IoT у них была года 3 назад, она же пока последняя.
Схема достаточно сложная - панель конфигурит через наш плагин апку в нормальном HMI, а затем подгружает ее через iframe. Апка отвечает за все контролы (чекбоксы и кнопки проворачиваются только когда SCADA подтвердила что действие закончено и объект поменял статус), графана - только за дашборд.
Тем не менее, графана развивается. Новые backend-плагины уже умеют (пытаются) реплицировать данные в реалтайме, без дурацких рефрешей. Как стабилизируют SDK под Rust, обязательно пощупаю.
Графана штука неплохая, но контроль через неё совсем говно. Первая попытка выйти в Industrial IoT у них была года 3 назад, она же пока последняя.
Схема достаточно сложная - панель конфигурит через наш плагин апку в нормальном HMI, а затем подгружает ее через iframe. Апка отвечает за все контролы (чекбоксы и кнопки проворачиваются только когда SCADA подтвердила что действие закончено и объект поменял статус), графана - только за дашборд.
Тем не менее, графана развивается. Новые backend-плагины уже умеют (пытаются) реплицировать данные в реалтайме, без дурацких рефрешей. Как стабилизируют SDK под Rust, обязательно пощупаю.
🔥12💩2👍1
Пишем свой протокол поверх TCP. Пост для джунов, но попробую интересно.
TCP от UDP отличается в первую очередь с практической точки зрения тем, что фреймы идут потоком, а значит их нужно чем-то разделять. Кроме этого мозгоебства, требуется открыть сокет и следить за его состоянием, зато как бонус получаете строгую очередность и гарантированную доставку.
Я за свою жизнь написал наверное сотню протоколов, парочка даже зарегистрирована в IANA, а один даже имеет присвоенный порт. Вот несколько простых советов.
Handshake. Всегда делайте handshake. Протокол без handshake - мертвородженный и развития не имеет. Киньте пару байт на сигнатуру, что вы - это вы, 1-2 байта на версию, пару байт на опции и обязательно еще пару байт запланируйте резервных. Во время handshake стороны также могут договориться включить TLS (а он в наше время включается как два пальца, особенно в Rust), тем более мало ли - захотите сделать официальный релиз, а IANA давно уже новые протоколы без шифрования не принимает, даже если будете им божиться, что оно работает только на локалхосте.
Фреймы. В наше время сериализация данных обычно идет каким-нибудь cbor, msgpack, bincode или прямо predefined-структурой, аля protobuf. Поэтому фреймы не разделяются маркерами, а идут один за другим, но вначале каждого фрейма идет его заголовок. В залоговке указывается длина фрейма (если не уверены - смело ставьте 4 байта), в сетевых штуках правило хорошего тона - big endian, но про это давно никто не парится, так что little тоже сойдет. Вот тут очень важно - перед длиной обязательно зарезервируйте еще несколько байт, таким образом в будущем вы сможете, например, сообщать о формате фрейма прямо в потоке или включать кроме длины другую полезную нагрузку.
Close. Обязательно делайте close, чтобы стороны знали, что прием данных закончен, а не сдохло соединение. Поверьте, пригодится. Собственно это одна из причин, почему у фреймов данных должны быть заголовки. Хотя, если забыли заголовок у фреймов данных, close может быть что угодно, например фрейм с длиной в ноль байт.
Регистрация в IANA. Да собственно ничего сложного, протокол должен иметь вменяемую реализацию на 1-2 ЯП, описание зачем и почему его создали (IANA еще могут спросить, почему не использовали аналоги) и техническое описание форматов. Всё это можно показать, например на своём гитхабе. Номера портов - штука ограниченная, поэтому номера IANA раздаёт очень неохотно, но если у вас действительно полезный протокол и вы рассчитываете, что его будут использовать публично - порт вы получите. Причем если хотите порт весь - обязательно сделайте минимальную реализацию и для UDP (не забудьте шифрование и там).
TCP от UDP отличается в первую очередь с практической точки зрения тем, что фреймы идут потоком, а значит их нужно чем-то разделять. Кроме этого мозгоебства, требуется открыть сокет и следить за его состоянием, зато как бонус получаете строгую очередность и гарантированную доставку.
Я за свою жизнь написал наверное сотню протоколов, парочка даже зарегистрирована в IANA, а один даже имеет присвоенный порт. Вот несколько простых советов.
Handshake. Всегда делайте handshake. Протокол без handshake - мертвородженный и развития не имеет. Киньте пару байт на сигнатуру, что вы - это вы, 1-2 байта на версию, пару байт на опции и обязательно еще пару байт запланируйте резервных. Во время handshake стороны также могут договориться включить TLS (а он в наше время включается как два пальца, особенно в Rust), тем более мало ли - захотите сделать официальный релиз, а IANA давно уже новые протоколы без шифрования не принимает, даже если будете им божиться, что оно работает только на локалхосте.
Фреймы. В наше время сериализация данных обычно идет каким-нибудь cbor, msgpack, bincode или прямо predefined-структурой, аля protobuf. Поэтому фреймы не разделяются маркерами, а идут один за другим, но вначале каждого фрейма идет его заголовок. В залоговке указывается длина фрейма (если не уверены - смело ставьте 4 байта), в сетевых штуках правило хорошего тона - big endian, но про это давно никто не парится, так что little тоже сойдет. Вот тут очень важно - перед длиной обязательно зарезервируйте еще несколько байт, таким образом в будущем вы сможете, например, сообщать о формате фрейма прямо в потоке или включать кроме длины другую полезную нагрузку.
Close. Обязательно делайте close, чтобы стороны знали, что прием данных закончен, а не сдохло соединение. Поверьте, пригодится. Собственно это одна из причин, почему у фреймов данных должны быть заголовки. Хотя, если забыли заголовок у фреймов данных, close может быть что угодно, например фрейм с длиной в ноль байт.
Регистрация в IANA. Да собственно ничего сложного, протокол должен иметь вменяемую реализацию на 1-2 ЯП, описание зачем и почему его создали (IANA еще могут спросить, почему не использовали аналоги) и техническое описание форматов. Всё это можно показать, например на своём гитхабе. Номера портов - штука ограниченная, поэтому номера IANA раздаёт очень неохотно, но если у вас действительно полезный протокол и вы рассчитываете, что его будут использовать публично - порт вы получите. Причем если хотите порт весь - обязательно сделайте минимальную реализацию и для UDP (не забудьте шифрование и там).
👍52🔥4💩2
Попросили портировать некоторые наши приложения на Siemens Industrial Edge. Мы в этом году планировали выпустить отдельную версию нашей платформы под кубик, по принципу 1 контейнер - 1 сервис, так почему бы и нет. Поделюсь впечатлениями.
Siemens IE - это платформа, которая совмещает некий функционал кубика, магазин приложений и некий единый протокол, по которому эти приложения должны между собой общаться. В общем идея охуення, но.
- в качестве формата контейнеров выбран docker+docker-compose. compose - не самый удачный вариант конфигурировать приложения в проде, но выбрали почему-то его
- в качестве протокола выбран, как вы уже догадались, MQTT, причем брокера вы деплоите как отдельное приложение, причем в основном mosquitto. рассказывать про недостатки mqtt я могу очень долго, от того что попробуйте сделать на нем нормальное RPC без костылей, до того, что заставлять два приложения на локалхосте общаться через MQTT - это глупо. но мы - маленькая контора, прошли через эти ошибки 5 лет назад и плюнули, выпустив всё новое. а Siemens так не могут, поэтому тянут всё это четвертый год.
- магазин приложений - полудохлый
- сама концепция "промышленное приложение в докере" - гиблая тем, что под такую архитектуру примерно никогда не будет ничего, что работает с serial или gpio. а значит придется делать еще одну платформу, где это есть и подключать к существующей. или делать софты-железки, которые в платформу не входят, но умеют с ней общаться
Зато из плюсов:
- ко всему нарисованы веб-морды, которые даже можно пользовать
- как следует из названия, приложения не обязательно крутить в облаке. можно поставить железку-виртуалку локально, или купить железную железку от Siemens с уже даже лаунчером на борту.
- это всё гораздо проще внедрить, продав старым пиджакам в креслах директоров заводов, чем наколенку или даже наколенку с кубиком - это же Siemens! "моё приложение" и "моё приложение в Siemens IE" - это две большие разницы
- это всё же хороший старт для вашего приложения, которое должно писать/читать условный Modbus и OPC-UA, но не умеет - клиент покупает ваше приложение и коннекторы на протоколы и оно как-то работает.
Вообще, Siemens страшно не везет с open source. Сначала они в здравом уме и трезвой памяти заменили свой довольно неплохой flow на NodeRED, чем вызвали неиллюзорное гигикание инженеров всех своих клиентов. Затем несколько лет ебались, делая из Debian 10 RTOS, а пока они этим занимались - вышел Debian 11 с RT-kernel из коробки. Мне это напоминает историю Sun - кто-то в руководстве узнал про open-source и что за него не надо платить и заставил заменить ин-хаус на всякую, откровенно, не лучшую гадость, которую суппортает в свободное время "чувак из Небраски", как на той известной картинке.
Siemens IE - это платформа, которая совмещает некий функционал кубика, магазин приложений и некий единый протокол, по которому эти приложения должны между собой общаться. В общем идея охуення, но.
- в качестве формата контейнеров выбран docker+docker-compose. compose - не самый удачный вариант конфигурировать приложения в проде, но выбрали почему-то его
- в качестве протокола выбран, как вы уже догадались, MQTT, причем брокера вы деплоите как отдельное приложение, причем в основном mosquitto. рассказывать про недостатки mqtt я могу очень долго, от того что попробуйте сделать на нем нормальное RPC без костылей, до того, что заставлять два приложения на локалхосте общаться через MQTT - это глупо. но мы - маленькая контора, прошли через эти ошибки 5 лет назад и плюнули, выпустив всё новое. а Siemens так не могут, поэтому тянут всё это четвертый год.
- магазин приложений - полудохлый
- сама концепция "промышленное приложение в докере" - гиблая тем, что под такую архитектуру примерно никогда не будет ничего, что работает с serial или gpio. а значит придется делать еще одну платформу, где это есть и подключать к существующей. или делать софты-железки, которые в платформу не входят, но умеют с ней общаться
Зато из плюсов:
- ко всему нарисованы веб-морды, которые даже можно пользовать
- как следует из названия, приложения не обязательно крутить в облаке. можно поставить железку-виртуалку локально, или купить железную железку от Siemens с уже даже лаунчером на борту.
- это всё гораздо проще внедрить, продав старым пиджакам в креслах директоров заводов, чем наколенку или даже наколенку с кубиком - это же Siemens! "моё приложение" и "моё приложение в Siemens IE" - это две большие разницы
- это всё же хороший старт для вашего приложения, которое должно писать/читать условный Modbus и OPC-UA, но не умеет - клиент покупает ваше приложение и коннекторы на протоколы и оно как-то работает.
Вообще, Siemens страшно не везет с open source. Сначала они в здравом уме и трезвой памяти заменили свой довольно неплохой flow на NodeRED, чем вызвали неиллюзорное гигикание инженеров всех своих клиентов. Затем несколько лет ебались, делая из Debian 10 RTOS, а пока они этим занимались - вышел Debian 11 с RT-kernel из коробки. Мне это напоминает историю Sun - кто-то в руководстве узнал про open-source и что за него не надо платить и заставил заменить ин-хаус на всякую, откровенно, не лучшую гадость, которую суппортает в свободное время "чувак из Небраски", как на той известной картинке.
🔥12👍8💩1
Я стал меньше ненавидеть JS/TS, когда перешел с webpack на vite. Страдания с webpack надолго отбили мне охоту копаться в фронтах. Но с vite это делать стало намного вменяемей.
Особенно радует динамический импорт модулей в рантайме (аля await import('mymod.js')). Webpack материл меня страшными словами, выёбывался и ныл, а когда маты отключались, импорты внезапно переставали работать. Vite в это дело не лезет - если хозяин импортит динамически что-то чего нет в пакете, он наверное знает что делает.
Особенно радует динамический импорт модулей в рантайме (аля await import('mymod.js')). Webpack материл меня страшными словами, выёбывался и ныл, а когда маты отключались, импорты внезапно переставали работать. Vite в это дело не лезет - если хозяин импортит динамически что-то чего нет в пакете, он наверное знает что делает.
👍17😁2💩1
This media is not supported in your browser
VIEW IN TELEGRAM
Случайно соединил Simulink с нашей EVA ICS, а потом и графаной, найдя в DSP Toolbox UDP sink.
Мне начинают нравиться UDP-синки тем что они есть практически везде (даже в этом вашем NodeRED) сразу из коробки. Лабо-инженеры у клиентов давно просили кидать дату прямо из матлаба в скады. Но они не специалисты в сетях, а я не специалист в матлабе, потому что на линух-десктопах с glibc <= 2.31 он у меня не работал. Но внезапно ожил и вот.
Мне начинают нравиться UDP-синки тем что они есть практически везде (даже в этом вашем NodeRED) сразу из коробки. Лабо-инженеры у клиентов давно просили кидать дату прямо из матлаба в скады. Но они не специалисты в сетях, а я не специалист в матлабе, потому что на линух-десктопах с glibc <= 2.31 он у меня не работал. Но внезапно ожил и вот.
👍12🔥3💩1
Кстати должен выразить респект ребятам из Matworks. Есть такой патч BZ #19329, чинит проблемы датарейса в glibc у dlopen и pthread_create. Патч вышел давным-давно, ещё в 2015 году, но поскольку дистрибутивы слоупоки - некоторый софт (в основном большой и пропиетарный) падает в Ubuntu, например, аж до 22.04, где наконец это починили.
Так вот, ребята в целом не зря хлеб едят - собирают патченные glibc и выкладывают на своём гитхабе под кучу старых версий Debian, Ubuntu и некоторых других линухов, только чтобы юзеры не матерились, что ради Matlab приходится запускать винду.
Так вот, ребята в целом не зря хлеб едят - собирают патченные glibc и выкладывают на своём гитхабе под кучу старых версий Debian, Ubuntu и некоторых других линухов, только чтобы юзеры не матерились, что ради Matlab приходится запускать винду.
👍16🔥3💩1
Не люблю записывать видео (всегда текст по-дебильному написан), но справился. Интеграция EVA ICS с Matlab Simulink, полный обзор.
https://www.youtube.com/watch?v=atJtKrz6EaU
https://www.youtube.com/watch?v=atJtKrz6EaU
YouTube
EVA ICS integration: Matlab Simulink
EVA ICS Industrial IoT platform integration with Matlab Simulink to create virtual sensors which act as digital twins of fieldbus hardware
https://www.eva-ics.com/
https://www.eva-ics.com/
🔥5👍4
По батискафу на дне океана всё уже очень хорошо написал Экслер, а кому лень читать, TLDR: зумеры изобрели батискаф с контроллером от х-бокса. Но тема очень пересекается с моей, поэтому тоже напишу.
Есть промышленные стандарты, и когда девайс идет в паблик - они должны соблюдаться. Все эти скучные ISO, IEC, FIPS и прочая ерунда, из-за которых старые деды тормозят прогресс. Нельзя ставить материалы, которые не прошли сертификацию, нельзя ставить контролы, которые не дублируются. Как и нельзя ставить в mission critical софт, написанный на питоне или node.js (да и на Rust тоже пока нельзя, но его усиленно лоббируем). А если у промышленной системы всё же веб-морда - нельзя открывать её в том же браузере, где в соседнем табе крутится OnlyFans.
Точнее конечно можно, но результат может оказаться вот таким, а страховая скорее всего не заплатит. Из-за отсутсвия таковой. Потому что стандарты - это не только скучные буквы, которые могут спасти жизнь, а еще и система перекладывания ответственности, благодаря которой с технологией могут познакомиться десятки экспертов, и если есть проблемы - зарубить.
Нет, бывает конечно как фирмварь в 737 Max. Но Боинг произвел больше 10 тысяч самолетов, а из-за фирмвари упало 2. Но даже фирмварь там как раз была в порядке - PLC работали как часы и не падали. И контролы тоже работали, все эти скучные сотни кнопок а не один красивый пульт от приставки. Проблема там была в логике, которую выстроили поверх телеметрии. Но это уже другая история.
Есть промышленные стандарты, и когда девайс идет в паблик - они должны соблюдаться. Все эти скучные ISO, IEC, FIPS и прочая ерунда, из-за которых старые деды тормозят прогресс. Нельзя ставить материалы, которые не прошли сертификацию, нельзя ставить контролы, которые не дублируются. Как и нельзя ставить в mission critical софт, написанный на питоне или node.js (да и на Rust тоже пока нельзя, но его усиленно лоббируем). А если у промышленной системы всё же веб-морда - нельзя открывать её в том же браузере, где в соседнем табе крутится OnlyFans.
Точнее конечно можно, но результат может оказаться вот таким, а страховая скорее всего не заплатит. Из-за отсутсвия таковой. Потому что стандарты - это не только скучные буквы, которые могут спасти жизнь, а еще и система перекладывания ответственности, благодаря которой с технологией могут познакомиться десятки экспертов, и если есть проблемы - зарубить.
Нет, бывает конечно как фирмварь в 737 Max. Но Боинг произвел больше 10 тысяч самолетов, а из-за фирмвари упало 2. Но даже фирмварь там как раз была в порядке - PLC работали как часы и не падали. И контролы тоже работали, все эти скучные сотни кнопок а не один красивый пульт от приставки. Проблема там была в логике, которую выстроили поверх телеметрии. Но это уже другая история.
👍26
Взгляд на современный Windows человека, который его не видел 4 года.
Нет, у меня конечно есть Windows. Один где-то на сервере на виртуалке гоняет Active Directory, по которой я гоняю всякие тесты. Второй тоже где-то на виртуалке гоняет cargo build. Со вторым я общаюсь по ssh, а с первым не общаюсь вообще. Последний десктоп, где был виндовс, у меня на работе поломался где-то в 2019 или 2020 году и с тех пор руки не доходят починить.
И тут значит клиент пишет - ваш софт на 4К ужасно как-то скейлится. Не знаю, то ли что-то сломалось в билдах, то ли на 4К на Windows забыли протестировать - в общем проблема есть действительно. Поэтому я поставил Windows (11) себе в виртуалку и начал смотреть что там скейлится не туда.
Пока я чинил скейлинг, Windows занималась двумя вещами: постоянно ставила какие-то апдейты и ловила какие-то вирусы. Я теперь прекрасно понимаю, почему народ с десктопов вообще убегает, на телефоны и таблеты. Это же дико - когда у тебя проц постоянно чем-то загружен. Я как-то уже давно от этого отвык. Ничего не делаю - значит ноутбук кулерами не крутит. Сижу читаю. Что-то там загрузило проц сильно без разрешения - пошел убил.
И главное - мало того, что оно постоянно занимается вот этим вот самобичеванием, всё еще выглядеть стало ужасно. Начиная от шрифтов, ну вы сами знаете сколько в линухах настроек для антиалиасинга - все эти хинтинги, фильтры - удовлетворит любого. В шиндовс - как в 90х. Полторы настройки: или да или нет (причем "нет" уже и не найти). На морде висит этот новый непонятный прилизанный скин, при "show more options" - менюшка дропается в Windows classic, с совершенно другими настройками шрифтов. В некоторых стандартных прогах разные шрифты прямо в одном диалоге. Шиндовс всегда отличался строгостью - или у вас клоунская тема, или классическая. Но вот это вот переключение на ходу - это что вообще такое? Это примерно, как одна прога от гнома, а вторая - от кед, причем выбирать нельзя (причем гном с кедами давно можно настроить, чтобы они визуально не отличались друг от друга примерно никак).
И да, я ничего не ставил. Но у меня оказались по-умолчанию установлены клиенты для Amazon Prime, Spotify, WhatsApp и TikTok.
Microsoft, вы вообще мозгой поехали?
Нет, у меня конечно есть Windows. Один где-то на сервере на виртуалке гоняет Active Directory, по которой я гоняю всякие тесты. Второй тоже где-то на виртуалке гоняет cargo build. Со вторым я общаюсь по ssh, а с первым не общаюсь вообще. Последний десктоп, где был виндовс, у меня на работе поломался где-то в 2019 или 2020 году и с тех пор руки не доходят починить.
И тут значит клиент пишет - ваш софт на 4К ужасно как-то скейлится. Не знаю, то ли что-то сломалось в билдах, то ли на 4К на Windows забыли протестировать - в общем проблема есть действительно. Поэтому я поставил Windows (11) себе в виртуалку и начал смотреть что там скейлится не туда.
Пока я чинил скейлинг, Windows занималась двумя вещами: постоянно ставила какие-то апдейты и ловила какие-то вирусы. Я теперь прекрасно понимаю, почему народ с десктопов вообще убегает, на телефоны и таблеты. Это же дико - когда у тебя проц постоянно чем-то загружен. Я как-то уже давно от этого отвык. Ничего не делаю - значит ноутбук кулерами не крутит. Сижу читаю. Что-то там загрузило проц сильно без разрешения - пошел убил.
И главное - мало того, что оно постоянно занимается вот этим вот самобичеванием, всё еще выглядеть стало ужасно. Начиная от шрифтов, ну вы сами знаете сколько в линухах настроек для антиалиасинга - все эти хинтинги, фильтры - удовлетворит любого. В шиндовс - как в 90х. Полторы настройки: или да или нет (причем "нет" уже и не найти). На морде висит этот новый непонятный прилизанный скин, при "show more options" - менюшка дропается в Windows classic, с совершенно другими настройками шрифтов. В некоторых стандартных прогах разные шрифты прямо в одном диалоге. Шиндовс всегда отличался строгостью - или у вас клоунская тема, или классическая. Но вот это вот переключение на ходу - это что вообще такое? Это примерно, как одна прога от гнома, а вторая - от кед, причем выбирать нельзя (причем гном с кедами давно можно настроить, чтобы они визуально не отличались друг от друга примерно никак).
И да, я ничего не ставил. Но у меня оказались по-умолчанию установлены клиенты для Amazon Prime, Spotify, WhatsApp и TikTok.
Microsoft, вы вообще мозгой поехали?
👍41🔥7😁5💩5