Linux *

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

Это продолжение статьи Локализация своих скриптов на BASH. В ней мы используя массивы и косвенные ссылки, научились добавлять в свои скрипты дополнительные языки и переключаться между ними.

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

Уже лет десять моим основным медиаплеером на компьютере является MPD, Music Player Daemon — фоновый сервис, воспроизводящий музыку.

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

Предлагаю вашему вниманию краткий обзор (сравнительно) нового MPD-клиента для Linux/GTK под названием Ymuse, версию 0.16 которого я недавно выпустил.

В производстве и на конвейерных линиях часто возникает задача подсчета продукции или операций оборудования. Во многих случаях станки уже имеют комплекс аппаратных и программных средств, позволяющих получить данную информацию. Также существуют специализированные счетчики, адаптированные под конкретную задачу или оборудование. Но при наличии разнотипного оборудования, затраты на программное сопряжение становятся существенными. Хотелось бы иметь простой универсальный счетчик, который легко адаптируется под разное оборудование/задачи и передает события на сервер для дальнейшей аналитики. Об опыте разработке такого счетчика и пойдет речь в данной статье.

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

Возможно я бы собрался силой воли, помучился бы недельку, сделал бы все стандартными однострочниками+notepad+excel, но тут внезапно у меня случился больничный отпуск, а когда температура меня попустила, а на работу еще можно было не выходить. И я случайно вспомнил, что считаю себя спецом по bash.

И пусть я не хватаю лавры автора PIUPIU, но тем не менее встречайте:

35+ кбайт двух-панельного keystore manager на Linux shell

Создание меню на BASH — задача сама по себе не сложная: "case тебе в руки и echo в спину". Решая её в очередной раз, мне захотелось добавить возможность отображать текст на других языках. Осталось решить, как сделать сам процесс локализации меню более удобным. Если оно большое, то решение "в лоб" превратит его в громоздкую копипасту. Здесь я хотел бы поделиться тем, как решил эту проблему для себя. Надеюсь, для кого то это будет небезынтересным.

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

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

Реализация будет состоять из:

• буквенного кода языка
• массива слов
• преобразователя косвенных ссылок для обращения к массиву
• обращения к элементам массива
• создания меню

Теперь рассмотрим подробнее

Возможно, вы уже читали недавнюю статью о процессе первого запуска PVS-Studio на примере проекта GTK 4 и о первичной фильтрации предупреждений. Теперь пришло время поработать с полученным отчётом более подробно. И как уже догадались наши постоянные читатели, предлагаю вашему вниманию статью с описанием найденных в коде ошибок.

В этой статье я бы хотел рассказать о том, что Windows проекты на Delphi возможно перевести на Linux в разумные сроки и с разумными трудозатратами. Что такое SCADA-система, рассказывать не буду, а перейду сразу к делу.

Runtime ядро SCADA работает под Windows в качестве сервиса. Функции стандартные «как у всех»: сбор, обработка, архивирование данных, передача данных в другие SCADA-системы по стандартным протоколам обмена. Визуализация только через Web. Runtime ядро SCADA написано на Delphi. Решено было адаптировать исходный код под  FreePascal/Lazarus, так чтобы код под Windows компилировался и в FreePascal и в Delphi, вторым этапом было допиливание проекта непосредственно на Linux машине и переделка его в демон. В FreePascal привлекала возможность компиляции как для x64, так и для плат Raspberry pi (архитектуры ARMv7, ARM64 (aarch64)).

Конфигуратор работает под Windows в виде графического приложения. Пока решено не переводить его на Linux, в крайнем случае можно запустить под Wine.

Теперь перейдем к Runtime и будем говорить о нём. В нём применяются разнообразные компоненты:

В нашем грустном и печальном коронавирусном мире очень хочется смотреть на все таким же печальным взглядом. Ну и вот, так случилось, что приходит к нам с жалобой ооочень важный клиент. И говорит: “А у вас молоко убежало! Ваши снапшоты виртуальных машин работают ну очень медленно и печально.” В этом посте мы рассказываем, как наша команда справлялась с этой неприятностью.

В предыдущей статье мы рассмотрели сборку и установку пакета на Linux системах, в которой упомянули про Linux Kernel Module (LKM) и обещали раскрыть позднее подробности о пути к нему и его создании. Ну что ж, настало его время. LKM – мы выбираем тебя.

Всем привет! Перед Новым годом мы выпустили большой апдейт нашего продукта — CrowdSec v.1.0.X, в котором содержатся значительные изменения по сравнению с предыдущей версией. Самое главное: был введен в эксплуатацию локальный REST API и проведены соответствующие архитектурные изменения. Как следствие, значительно упростился процесс создания баунсеров и повышена их устойчивость, при этом снизилось время на обслуживание системы. 

В этой статье вы найдете основные материалы о том, как был переделан CrowdSec и, в целом, ее можно рассматривать как User Guide для тех, кто собирается попробовать наш продукт на своих системах.