Наткнулся на такой код в спринге:

PropertyMapper map = PropertyMapper.get().alwaysApplyingWhenNonNull();
map.from(settings::readTimeout).asInt(Duration::toMillis).to(this::setReadTimeout);
map.from(settings::connectTimeout).asInt(Duration::toMillis).to(this::setConnectTimeout);

Пришлось его скопипастить, потому, что при всей его гибкости как-то не очень он гибкий оказался там, где мне надо. Долго вкуривал, что тут написано, в итоге переписал по-простому:

if (settings.readTimeout() != null) {
  setReadTimeout(settings.readTimeout());
}
if (settings.connectTimeout() != null) {
  setConnectTimeout(settings.connectTimeout());
}

Да, я понимаю, что тут два раза вызывается геттер settings.xxx и это чисто теоретически может привести к багу… Но по-моему это мелочь. А то, что код нечитаемый получился сверху, это вообще не мелочь.

Что за моду притащили в жаву? Никогда же такого не было, писали просто и понятно. Кому это надо? Вы тоже выпендриваетесь, пытаясь в одну строчку засунуть побольше токенов?

В лиспе есть чудесное свойство: код и данные выглядят одинаково. Это позволяет очень легко и естественно писать код, генерирующий другой код. Что называется макросом.

Однако в индустрии данный подход применяется нечасто.

К примеру в С используется отдельный язык, генерирующий текст (препроцессор).

В С++ используется отдельный язык на шаблонах для метапрограммирования.

В Scheme тоже изобрели отдельный язык.

Из похожих подходов я видел только D, в котором можно написать функцию, возвращающую текст. Эту функцию можно вызывать во время компиляции и её результат компилятор тоже откомпилирует. Этот подход похож на лисп, хотя и гораздо менее удобен. Но больше нигде я такого не видел.

Если говорить про не-лисповые языки, то естественным кажется ввести официальный API для AST (по сути там ерунда) и разрешить писать функции, возвращающие этот самый AST. Это будет всё же лучше, чем текст и концептуально более похоже на лисп. Но я такого не видел. Разве что в Java есть annotation processor-ы, но и там такой подход это на уровне хаков скорей.

Можно сказать, что достаточно популярен подход, при котором генерируется исходный код перед компиляцией, к примеру из openapi спецификации. Это близко к постановке задачи, но всё же не совсем то.

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

Почему же так не делают? Зачем почти в каждом языке изобретают какие-то особые пути для метапрограммирования?

Присматриваюсь к ThinkPad T15p

Вроде нравится, но там видеокарта nvidia, мне это не надо.

Там процессор i7-12700H. На сайте Intel написано, что он «Intel® Iris® Xe Graphics eligible». Не очень понятно, что это значит.

Я хочу, чтобы линукс грузился и работал со встроенной видеокартой от Intel. А nvidia я может быть или для вычислений буду использовать, если вдруг сподобится, или винду в виртуалке запускать и туда пробрасывать.

Получится ли такой план на этом ноутбуке? Пробовать возможности нет.

У многих команд параметры можно указывать в коротком виде (например -r) или в длинном виде (например --recursive) Вроде всегда читал, что короткие параметры нужно использовать для интерактивных shell-сессий, а длинные в скриптах. Но всегда ли это так?

Как вы думаете, как лучше писать в скриптах? Несколько примеров ниже

mkdir -p a/b
mkdir --parents a/b
curl -fLsS "${url}" | tar -xzv -C /opt
curl --fail --location --silent --show-error "${url}" | tar --extract --gzip --verbose --directory=/opt

Честно говоря я в затруднении. Лично для меня mkdir -p читается и понимается проще, а что такое --parents я и не сразу соображу.

У меня есть телефон с разлоченным бутлоадером. Хочу залочить. Гружусь в fastboot, выполняю fastboot flashing lock, после этого телефон при загрузке выдаёт «Your device software can’t be checked for corruption. Please lock the bootloader.». Если разлочить, то грузится нормально. Что ему надо? Телефон Xiaomi Mi A2.

С каждым годом всё больше приложений, которыми я пользуюсь, переезжают либо на веб-технологии, либо вообще в браузер.

Mail -> Webmail

Idea -> VS code (в браузер пока не переехал, но хочу)

Gimp -> Photopea

Ventrillo -> Discord

Вот вчера задолбал Strongbox и я переехал в KeeWeb. Причём даже ставить не стал, в браузере прекрасно работает, синхронизирируясь с дропбоксом.

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

А у вас как?

Пишу прошивку для девайса. Он в том числе взаимодействует с ПК по USB.

Имеется внешний кристалл на 25 МГц. Имеется внутренний резонатор на 8 МГц. Также имеется два внутренних умножителя и набор делителей.

Для USB-периферии я из 25 МГц получаю 48 (25 / 5 * 8 / 10 * 12).

SYS тактирование я могу выбрать либо от этих 48, либо от кристалла (25) напрямую, либо от внутреннего резонатора (8). Сейчас я беру 48.

Далее я через множитель могу это значение поделить и настроить частоту AHB шины. Сейчас я делю на 8, получаю 6 МГц. На этой частоте работает процессор.

Далее мне нужно получить частоты для шин APB1 и APB2. Сейчас я APB1 делю на 16, получаю 375 kHz и APB2 делю на 4, получаю 1.5 MHz.

Собственно это всё я настроил исходя из принципа - чем меньше, тем лучше. На 3 МГц у меня USB не завёлся, соответственно поставил 6.

На шине APB2 у меня крутится таймер, через который я делаю микросекундные задержки для USB, поэтому её тактирую повыше (таймер использует двойную частоту, 3 МГц).

Каких-то требований на данный момент у меня нет (точней они такие небольшие, что подойдёт что угодно, к примеру у меня ещё будет SPI, для которого нужна скорость не ниже 110 КГц и передавать данные по USB я буду со скоростью примерно 15 КБ/с.

Есть ли какие-то соображения, по которым стоит запитать AHB шину не от делителя USB? Если запитывать от 25 МГц кристалла, то делить на ровные числа не получается, а частота в 25 МГц мне кажется избыточной, хотя изначально так и делал. Запитывать от 8 МГц резонатора кажется странным при наличии внешнего кристалла.

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

Вроде ничего особенного в нём нет, но маркдаун ломает. Использую '''c (для подсветки). Если не указывать C, то всё работает. Судя по разметке там какой-то детект XML срабатывает или что…

Не ломает:

static void enable_usart(void)
{
    uint32_t rcc_base_address = 0x40021000;
    uint32_t rcc_apb2enr_address = rcc_base_address + 0x18;
    uint32_t rcc_apb2enr_iopben = 1 << 3;
    uint32_t rcc_apb1enr_address = rcc_base_address + 0x1c;
    uint32_t rcc_apb1enr_usart3en = 1 << 18;
    uint32_t gpiob_base_address = 0x40010c00;
    uint32_t gpiob_crh_address = gpiob_base_address + 0x04;
    uint32_t gpiox_crh_mode10_0 = 1 << 8;

Ломает:

static void enable_usart(void)
{
    uint32_t rcc_base_address = 0x40021000;
    uint32_t rcc_apb2enr_address = rcc_base_address + 0x18;
    uint32_t rcc_apb2enr_iopben = 1 << 3;
    uint32_t rcc_apb1enr_address = rcc_base_address + 0x1c;
    uint32_t rcc_apb1enr_usart3en = 1 << 18;
    uint32_t gpiob_base_address = 0x40010c00;
    uint32_t gpiob_crh_address = gpiob_base_address + 0x04;
    uint32_t gpiox_crh_mode10_0 = 1 << 8;

Имеется сервис, который должен работать на определённом компьютере. Он делает HTTP-запросы и принимает HTTP-запросы. Исходящие HTTP-запросы должны идти с IP-адреса этого компьютера и входящие HTTP-запросы должны получаться с IP-адреса этого компьютера.

Хочется запускать этот сервис на другом компьютере и перенаправлять входящие и исходящие подключения соответствующим образом. Также хочется минимизировать настройки iptables и подобного и обойтись userspace-софтом.

Простой способ это сделать это ssh. Он может как перенаправлять входящие соединения с удалённого сервера на локальный, так и предоставлять на локальном сервере SOCKS-прокси, который будет перенаправлять исходящие соединения через удалённый сервер. Для разработки именно такой вариант я и использую.

Разумно ли использовать такую конфигурацию в продакшне? Настроить поднятие ssh-соединения через systemd-юнит в принципе несложно, но я никогда не видел, чтобы так делали. Насколько это разумно?

В качестве альтернативы видится поднятие специализированного прокси-сервера на удалённом компьютере, а также http reverse proxy (вроде nginx) на удалённом компьютере. Этот вариант кажется более «продакшн», но несёт с собой уйму дополнительных усилий по управлению всем этим добром, включая безопасность, которая в ssh обеспечивается автоматически.

Какой-то существенной нагрузки, способной забить канал или процессор шифрованием не ожидается. Одновременных запросов может быть максимум - десятки (на некоторые запросы ответ может приходить минутами), поэтому опасаюсь каких-то неизвестных мне особенностей ssh-туннелей.

Я тут в очередной раз пытаюсь освоить программирование микроконтролеров. Захотелось написать такой полу-ЖЖ, полу-туториал (как говорится - хочешь разобраться в чём-то, объясни это другим). Может кто почерпнёт или подскажет чего полезного.

Если интерес будет, буду продолжать.

Итак осваиваем STM32 не как нормальные люди.

Примерный план:

1. Подключить его к компьютеру и убедиться, что там что-то происходит. Использовать будем st-util и gdb.

2. Написать простейшую программу на ассемблере, которая в цикле прибавляет регистр, скомпилировать из неё прошивку, залить на плату и пронаблюдать её работу. Использовать будем binutils и st-flash.

3. Поморгать диодом (на ассемблере же).

4. Переписать осмысленный код на С (дальше всё на С).

5. Переписать моргание с использованием таймера, чтобы внести свой вклад в борьбу с глобальным потеплением.

6. Сказать внешнему миру «Hello world» через UART.

7. Переписать «Hello world» с помощью CMSIS, уже с пониманием того, что там происходит.

На этом этапе начальное освоение микроконтроллеров можно считать завершённым. Дальше, видимо, сотни страниц датащитов по записи нужных битов в нужные места, или использование готовых библиотек. В любом случае навыки из списка выше полезны при использовании любых библиотек, т.к. всё растёт из этой базы.

Сразу скажу, что в процессе будет использовано достаточно много инструментов вроде make, ld, gdb, as, gcc и тд, по каждому из них можно книги писать (и пишут). Поэтому, конечно, углубляться в них я не буду, а напротив буду использовать в максимально примитивном виде.

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

• STM32F103xx Reference Manual. Тут вся справочная информация по всем битам и байтам конкретного микроконтроллера.
• STM32F10xxx Programming manual. Тут справочная информация по ARM: все инструкции, описание работы процессора.
• GNU debugger GDB. Это отладчик.
• GNU make
• GNU linker ld
• GNU assembler as

Имеется система, аналогия которой это обработка заказов в магазине или обработка запросов в система типа jira. Некоторыми образами в систему попадает сущность, пусть будет «заказ». Объём - тысячи в день. Далее эта сущность проходит через несколько статусов. Сейчас - чуть больше 10, но число их потихоньку растёт. К примеру после того, как сущность создана, делается запрос в другую систему. Если запрос вернул данные, то данные присоединяются к сущности и переходит в следующий статус. Далее идёт запрос в другой сервис и с сущностью работают там. Там свои статусы. Какие-то переходы это просто запрос в сервис, какие-то переходы это ожидание действий пользователя (может быть до месяца). Переходы могут добавлять данные к сущности, как в примере выше. В конце концов сущность либо архивируется с успехом или по таймауту.

Всё, что выше, это абстрактное описание того, как это всё работает.

Сейчас это примерно 3 сервиса, у каждого своя база. Ну и внешние сервисы, их тоже несколько. Часть переходов между статусов это скедулеры, запускаются раз в полминуты, или в минуту, или в 5 минут. Часть переходов это непосредственно запросы от пользователя.

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

Что сейчас плохо:

1. У всего этого нет никакой формы. По сути система выросла исторически, из простой и понятной в некоего монстра. Алгоритмы перехода между статусами мало кто понимает.

2. Всякие повторы и тд реализуются на месте с переменным успехом. Где-то вообще не реализуются. Типа лежит сервис отправки смс, и фиг с ним, не очень-то и нужно. Где-то долбит раз в минуту, в итоге скапливается несколько десятков тысяч заказов, которые из-за чего-то не могут отправиться и система начинает тормозить, пока кто-то не придёт и не разберётся. Где-то сделано по уму, с экспоненциальной задержкой. Хочется, чтобы везде было по уму.

3. Логи. Все логи ведутся ну тупо в лог файлах. Текущее состояние можно посмотреть в базе, истории состояний нет. Проблемы решаются очень долго - надо долго грепать логи (а их очень много, гигабайты в день), копаться в базе, курить сорсы. В общем случае в логах, базах и сорсах нескольких сервисов. От системы хочется, чтобы была возможность найти сущность, посмотреть её историю, в идеале вообще посмотреть - какие запросы делались и какие ответы получались в определённые моменты времени. В общем чтобы суппорт писал «по юзеру иванов не отрабатывается заказ», ты шёл в дашборд, находил «user.name=иванов» его заказ, сразу видел, что он в таком-то статусе, сделал 3 попытки на такой-то сервис, получил такие-то ответы. В общем как-то так.

4. Скорость работы. Из-за того, что скедулеры отрабатывают не моментально и не раз в секунду, а в среднем раз в минуту, каждая смена статуса занимает до минуты, в итоге то, что может сделаться за долю секунды, занимает несколько минут.

5. В целом есть ощущение, что такие системы должны строиться по типовой архитектуре.

Если бы я это делал, я бы сделал как-то так:

• Есть сущность
• У неё есть статус
• К сущности прикрепляются произвольные данные по ключ-значение
• Частью статуса может служить выражение вида ключ == значение и тд. Ну чтобы не делать комбинаторный взрыв из статусов. Хотя тут спорный момент, может это и не надо.
• Куча сервисов, которые обрабатывают изменения статусов.
• Сервис триггерится либо по изменению статуса, либо по внешнему вызову. С внешним вызовом надо подумать, пока чёткого понимания нет.

При вызове сервиса можно автоматом делать повторы, причём с задержкой нужной, логгирование и тд.

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

У меня давным давно был опыт работы с Java фреймворком, который работал с BPMN. Честно говоря я не смог вспомнить его название, наверное это был jbpm. Кажется, что этот фреймворк решал похожую задачу. Там в эклипсе рисовали workflow эдакой блок-схемой, в каждом узле прописывали логику работы. Честно говоря опыт был крайне отрицательный, система была максимально геморройна для работы с ней. Но допускаю, что это была проблема конкретной реализации или старой версии. Поэтому первый кандидат, который я рассматриваю, это фреймворки с BPMN подходом.

Сразу скажу, что нужды рисовать блок-схемы в этом проекте нет. Разрабатывают программисты, по своему опыту скажу, что мне от этих упрощалок одно неудобство. Любой нетривиальный workflow скорей всего превратится в графическое мессиво.

Попытавшись поискать информацию по этой теме я часто встреваю упоминание некоего apache airflow и очень похожих на него продуктов. У меня всё же ощущение, что это похожее, но не то.

Также очень интригующий проект это temporal.io. Я его пока не осилил, он кажется очень непростым и нужно найти время, чтобы понять, что это такое. Но буду благодарен, если кто-то уже его использовал и скажет - то ли это?

Видел, как для похожей задачи применяли n8n. Там работали не программисты, это nocode инструмент. Мне не понравился, но концептуально вроде это тоже решает данную задачу.

Не хочется сложных решений, т.к. команда небольшая и не супер-профессиональная. Хочется решение простое, понятное, но в то же время решающее насущные проблемы.

Asus ExpertBook B9400, графика интел. Ранее на нём крутилась федора.

Поставил RHEL 9.2, при установке выбрал workstation. Вифи работает, внешний монитор работает, звук работает, suspend работает. Вроде wayland запускается. В целом мне понравилось. В отличие от федоры кажется нет всякого снап-хлама, шопов и прочей новомодной галиматьи. Пока с отрицательными моментами не столкнулся. Установка прошла гладко, инсталлятор такой же, как в федоре, установил с шифрованием диска. Ещё из приятного - разбивает диск по феншую, со свопом, без всякого zram и подобной галиматьи.

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

Использую developer лицензию. Предполагаю, что можно поставить Oracle Linux и получить то же самое без суеты с лицензиями, но не пробовал.

Есть сервачок, хочу, чтобы он по ночам ставил апдейты и ребутался при необходимости. Пытался разобраться, но там чёрт ногу сломит, 50 скриптов, один другого вызывает, такое ощущение, что проще засунуть apt-get update && apt-get upgrade && test -e /var/run/reboot-required && reboot в какой-нибудь /etc/cron.daily/ (а ещё лучше в systemd timer).

Какой минимальный рецепт для сабжа, на свежеустановленном облачном образе? Без всяких там отсылок почты и прочего непотребства.

Помогите найти внятную информацию, как настроить постгрес для работы в контейнере, чтобы укладывался в целевые показатели по ограничению памяти. К примеру сейчас запустил постгрес, он скушал 90 МБ. Далее в течение нескольких дней, исходя из опыта, его потребление вырастет примерно до 2 GB. При этом он вообще-то и сейчас нормально работает и было бы неплохо его ограничить, скажем, 100 МБ. Но если я просто поставлю лимит, то его грохнет OOM Killer через несколько часов.

В конфиге я вижу следующее (значения не по умолчанию):

listen_addresses = '*'
max_connections = 1000			# (change requires restart)
shared_buffers = 128MB			# min 128kB
dynamic_shared_memory_type = posix	# the default is usually the first option
max_wal_size = 1GB
min_wal_size = 80MB

Число соединений к базе со временем не растёт, с ней работает один сервис через одно соединение.

Насколько я понял, потребляется 128 MB на весь сервер + work_mem (4MB) на каждое соединение + temp_buffers (8 MB) иногда. Ещё может быть maintenance_work_mem (64 MB). Откуда тут гигабайты набегают - непонятно.

Добавьте в профиль два поля: CSS URL и Script URL. Если пользователь их заполняет, то ему в страницу добавляется <link rel=stylesheet href="${css_url}"> и <script src="${script_url}"></script>.

Мне кажется, это несложно и позволит людям легко добавлять маленькие (или не очень маленькие) твики под свой вкус. Хостить файлы и тд не надо, гитхаб у всех есть, просто URL. Это удобней аддонов к браузеру тем, что позволяет этим пользоваться с любого девайса.

https://www.securitylab.ru/news/540852.php

В 2022 году обвиняемый, будучи администратором информационной безопасности на предприятии, подключил свой рабочий компьютер к интернету и скачал из открытых источников программное обеспечение FreeRADIUS, которое он установил на сервере системы контроля доступа Cisco Secure ACS. Эта система была использована для организации безопасного доступа к информационным ресурсам предприятия, в том числе к объектам критической информационной инфраструктуры (КИИ).

Обвиняемый утверждает, что он действовал в интересах работодателя, так как система Cisco Secure ACS была устаревшей и дорогостоящей в обслуживании. Он заявляет, что он сэкономил предприятию почти 2,5 миллиона рублей за лицензию и поддержку программного обеспечения. Он также уверяет, что он предпринял все необходимые меры безопасности при подключении к интернету и использовании бесплатного ПО.

Начальник обвиняемого дал ему задание найти замену системе Cisco Secure ACS.

На мой взгляд всем айтишникам, имеющим отношение к госорганам, стоит искать новую работу. Система сошла с ума.

Как я понимаю, МРТ это катушка из сверхпроводника, залитая охладителем, который поддерживает температуру сверхпроводимости. При этом в эту катушку можно «закачать» довольно много энергии (но не бесконечно много, у сверхпроводника есть пределы тока, после которых он потеряет сверхпроводящие свойства).

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

При разрушении бочки жидкий гелий выльется и окружающая среда начнёт нагревать катушку (альтернативно в конструкции бомбы может быть детонатор, который нагреет катушку). Когда катушка нагреется свыше температуры сверхпроводимости, она начнёт нагреваться от проходящего по ней тока, что ещё более повысит её сопротивление. Это в конечном счёте приведёт (при наличии достаточного объёма энергии) к испарению проводника. Вот что дальше произойдёт - я пока не понимаю. Вроде был только что был ток, неистово нагревающий плавящуюся катушку, а тут раз, катушка превратилась в пар, а с энергией тока что случилось? Пар будет служить проводником, в котором ток до конца будет крутиться, пока полностью не перейдёт в тепловую энергию? Не понятно.

Ну помимо этого ещё и жидкий гелий перейдёт в газообразное состояние, нагреваясь от этой странной парообразной катушки. Вероятно очень сильно расширится, и получится хлопок. Причём взрыв очень холодного газа. Даже интересно, как это будет выглядеть. Наверное будут ожоги-обморожения. Хотя точно не уверен. Ну от расширения в любом случае будут разрушения.

У NbN максимальная плотность (?) тока 5e7 A/см2. Т.е. если я правильно понял, то в провод площадью в квадратный сантиметр можно накачать ток в 50 млн амперов. Иными словами через сечение провода проходит 50 млн Кл/с. Как отсюда можно посчитать, сколько энергии выделится при переходе этого тока в тепло - я не осилил, буду благодарен, если кто-то подскажет.

В общем интересно - насколько такая бомба бахнет, в сравнение с традиционными вариантами? Понятно, что ядерная мощней, зато тут всё экологично. Хотя про воронки на месте больниц, где выходили из строя МРТ аппараты, я не слыхал, но может там недостаточно сильно накачивали катушки?

На сервере (виртуальной машине) иногда начинают теряться пакеты. Примерно через 2 недели аптайма это происходит. Если перезагрузить - то всё нормально начинает работать. Куда можно смотреть? На CPU нагрузка в целом есть, но не прям перегружено. Памяти свободной много. Причём пакеты на этой неделе начали теряться в пятницу вечером, вообще не похоже, что от какой-то особой нагрузки, нагрузка идёт в рабочие дни и часы.

Пытался мониторить через ps что работает в тот момент, когда теряются пакеты - закономерности не выявил.

Вообще сервер это нода кубернетеса.

Пакеты теряются пачками примерно раз в 30-40 секунд. То работают, то теряются. Вот типичная картина:

64 bytes from 10.160.3.160: icmp_seq=1 ttl=64 time=0.343 ms
64 bytes from 10.160.3.160: icmp_seq=2 ttl=64 time=0.338 ms
64 bytes from 10.160.3.160: icmp_seq=3 ttl=64 time=0.261 ms
64 bytes from 10.160.3.160: icmp_seq=4 ttl=64 time=0.252 ms
64 bytes from 10.160.3.160: icmp_seq=5 ttl=64 time=0.265 ms
64 bytes from 10.160.3.160: icmp_seq=6 ttl=64 time=0.251 ms
...
64 bytes from 10.160.3.160: icmp_seq=24 ttl=64 time=0.241 ms
64 bytes from 10.160.3.160: icmp_seq=25 ttl=64 time=1.76 ms
64 bytes from 10.160.3.160: icmp_seq=26 ttl=64 time=0.252 ms
64 bytes from 10.160.3.160: icmp_seq=30 ttl=64 time=2318 ms
64 bytes from 10.160.3.160: icmp_seq=31 ttl=64 time=1294 ms
64 bytes from 10.160.3.160: icmp_seq=32 ttl=64 time=270 ms
64 bytes from 10.160.3.160: icmp_seq=33 ttl=64 time=0.249 ms
64 bytes from 10.160.3.160: icmp_seq=34 ttl=64 time=0.260 ms
...
64 bytes from 10.160.3.160: icmp_seq=65 ttl=64 time=0.245 ms
64 bytes from 10.160.3.160: icmp_seq=66 ttl=64 time=0.235 ms
64 bytes from 10.160.3.160: icmp_seq=67 ttl=64 time=0.234 ms
64 bytes from 10.160.3.160: icmp_seq=72 ttl=64 time=341 ms
64 bytes from 10.160.3.160: icmp_seq=73 ttl=64 time=6.38 ms
64 bytes from 10.160.3.160: icmp_seq=74 ttl=64 time=11.7 ms
64 bytes from 10.160.3.160: icmp_seq=75 ttl=64 time=12.8 ms
64 bytes from 10.160.3.160: icmp_seq=76 ttl=64 time=13.9 ms
64 bytes from 10.160.3.160: icmp_seq=77 ttl=64 time=12.8 ms
64 bytes from 10.160.3.160: icmp_seq=78 ttl=64 time=10.9 ms
64 bytes from 10.160.3.160: icmp_seq=79 ttl=64 time=0.266 ms
64 bytes from 10.160.3.160: icmp_seq=80 ttl=64 time=0.250 ms
...
64 bytes from 10.160.3.160: icmp_seq=106 ttl=64 time=0.280 ms
64 bytes from 10.160.3.160: icmp_seq=107 ttl=64 time=0.249 ms
64 bytes from 10.160.3.160: icmp_seq=111 ttl=64 time=1600 ms
64 bytes from 10.160.3.160: icmp_seq=112 ttl=64 time=576 ms
64 bytes from 10.160.3.160: icmp_seq=113 ttl=64 time=0.270 ms
64 bytes from 10.160.3.160: icmp_seq=114 ttl=64 time=0.267 ms
...
64 bytes from 10.160.3.160: icmp_seq=142 ttl=64 time=10.9 ms
64 bytes from 10.160.3.160: icmp_seq=146 ttl=64 time=811 ms
64 bytes from 10.160.3.160: icmp_seq=147 ttl=64 time=18.6 ms
64 bytes from 10.160.3.160: icmp_seq=148 ttl=64 time=11.9 ms
...
64 bytes from 10.160.3.160: icmp_seq=187 ttl=64 time=4.23 ms
64 bytes from 10.160.3.160: icmp_seq=188 ttl=64 time=0.250 ms
64 bytes from 10.160.3.160: icmp_seq=192 ttl=64 time=1051 ms
64 bytes from 10.160.3.160: icmp_seq=193 ttl=64 time=27.0 ms
64 bytes from 10.160.3.160: icmp_seq=194 ttl=64 time=13.4 ms

Иногда время отклика повышается до 10 мс. Вроде бы это от скачкообразного роста нагрузки. Периодически запускается около 20 процессов, которые потребляют весь CPU, видимо это и влияет на пинг, с этим понятно и «претензий нет». Но вот потери пакетов - это не понятно.

Через iftop смотрел - скачкообразного роста трафика в этот момент не наблюдается, сетевой интерфейс не перегружен.

Куда можно копать? Хотелось бы разобраться.

Есть ряд алгоритмов над массивами float64 чисел. Эти алгоритмы нужно применять в нескольких проектах на разных языках: JS, Go, Java. Копипастить не очень хочется. Также очень не хочется иметь нетривиальный рантайм.

Пока текущий вариант: написать алгоритмы на С. Для JS скомпилить в wasm, для остального штатными средствами.

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

Нет ли такого в природе? Как искать не придумал.

Всегда SUSE проходила мимо меня, а тут мне подсказали, что OpenSUSE Leap это тот же SLES с опциональными доп пакетами.

Выходит, если хочется энтерпрайзной стабильности нахаляву, то это хороший вариант?