РТУ МИРЭА совместно с АО «НИЦ» и «РУСИБ» приглашает всех, интересующихся Инфобезом, с 7 апреля по 8 июня принять участие в гибридном хакатоне NeedForFWSpeed на самое быстрое ПО межсетевого экрана и побороться за призовой фонд 0,6 млн рублей.
По просьбам интересующихся хакатоном, организаторы NeedForFWSpeed продлили регистрацию на мероприятие до 31 мая включительно. Если Вас заинтересует этот хакатон, то ещё есть возможность успеть в последний вагон. Пост с краткой информацией размещен здесь. Ниже ссылка на сам сайт хакатона.
Спойлер: принципиальное решение проблемы - найдено. Купил маленькую коробочку на "мейнстримной" архитектуре, на которой все цветет и пахнет.. кроме моего внутреннего(ну и внешнего, че уж там) инженера) Так что решение выкинуть железку - можно не предлагать
Так вот, пока я писал код, и готовил сборочные скрипты ничто не предвещало беды - я спокойно потестил код локально, написал Dockerfile для сборки на poetry. Настало время развернуть это все на NAS - казалось бы ARM уже давно мейнстрим, но тут понеслось
python как всегда лишь удобный биндинг к куче платформозависимого кода) подавляющее большинство python-зависимостей под arm/v7 приходится компилировать
готовых бинарников polars под arm/v7 - тоже нет
Никаких блокеров к тому, чтобы собрать polars под arm/v7 я не нашел. Но скомпилить его нативно на 4Гб ОЗУ - не получится, даже с минимальными оптимизациями. Нужна кросс-компиляция. Благо с rust и maturin(которым собирается polars) - это несложно, target armv7-unknown-linux-gnueabihf в хорошем tier-е поддержки
забегая чуть вперед указываем окружение для сборки аллокатора jemalloc(по умолчанию в polars) под 32k страницу
Итак, усложняем сборку Docker(см. repro) - используем кросс-компиляцию, энв-переменные, QEMU, охапку дров и теперь у нас есть приложка, которая успешно стартует в докере на целевой железке. Вот только за рамками самых примитивных тестов - OOM-ится, причем память точно есть, никакой OOM-киллер процесс не убивает(на всякий случай смотрим лимиты cgoup) - оно "шамо":
memory allocation of 1345920 bytes failed
(подробные логи можно посмотреть по ссылкам в конце поста)
Что же делать?
пробуем mimalloc - он использует для конфигурации рантайм(getconf), эффект - тот же
пробуем env-крутилки, в частности arena_reserve может стоит просто меньше резервировать - но нет, просто больше попыток, но по факту все равно OOM
И вот на этом месте я застрял. Я не большой спец по системному программированию - не понимаю куда копать
Общение с поддержкой QNAP свелось к
Справедливости ради они еще дали советов что попробовать, но это я уже попробовал до них
Пытался отлаживать приложение в gdb - никаких аномальных трейсбэков во время OOM не увидел: rust честно пытается аллоцировать большой raw_vec(трейс есть в вопросе на stackoverflow)
Как-то глубоко копать переменные не получается, т.к. дебаг-символы для бинарника polars получаются слишком большими
BFD: error: /app/.venv/lib/python3.12/site-packages/polars/polars.abi3.so(.debug_str) is too large (0x498a9fd1 bytes)
Я сделал небольшое repro на голом расте - там эта проблема не воспроизводится, значит базово бинарная совместимость - в порядке
Есть несколько гипотез, но я не знаю как их проверить
возможно, кривая вся адресация, но ее проверить я тоже не могу
возможно, стоит чего-нибудь половить в ядре bpf-ом, но что..
кастомное ядро 4.2.8 кастомный дистриб(QTS) не богат средствами отладки - как я понял там запускается busybox набор утилит
А мне бы хотелось все-таки дожать диагностику и однозначно ответить на вопрос: это лыжи не едутя не умею собирать приложения под нужное окружение или все-таки целевая платформа не умеет выполнять корректно собранное? Не потому что эту проблему нельзя решить по-другому, а потому что в том, чем пользуешься - хочется разбираться.
Пишите в комментах ваши соображения. Если что-то удастся прояснить - буду держать читателей поста в курсе
Isar и еще 8 систем сборки для создания дистрибутива на Linux
Isar — система сборки, представляющая собой набор скриптов для создания пакетов и дистрибутивов на базе Debian с возможностью настройки. Организация проекта Isar похожа на Yocto Project, для сборки используется Bitbake.
Перед сборкой можно настроить параметры файловой системы, ядра, модификации списка пакетов (добавление и удаление пакетов, в том числе и собственных, изменение существующих пакетов). Систему сборки разрабатывает компания ilbers GmbH.
Архитектура системы
Так как Isar основан на Bitbake, архитектура решения состоит лишь в нескольких слоях для Bitbake, реализующих сборку и установку пакетов в соответствии с конфигурацией сборки. В основе всех этих слоев и рецептов лежат утилиты Debian Build Toolchain, которые ответственны за непосредственную сборку пакетов, разрешение зависимостей и т.д.
Как проходит процесс сборки дистрибутива в Isar
Особенности решения
Аналогично Yocto требует усилий на начальных этапах для освоения инструмента.
Поддерживает загрузку готовых пакетов из репозиториев Debian.
Подходит для embedded-дистрибутивов, где необходимо сочетание Debian-экосистемы и глубокой конфигурации.
О других embedded- и desktop-решениях решениях рассказали студенты и преподаватели СПБГЭТУ «ЛЭТИ» в обзоре систем для создания Linux-дистрибутивов.
Объявлено решении включить в состав выпуска GNOME 49 видеопроигрыватель Showtime, который станет поставляться под именем GNOME Video Player и будет задействован по умолчанию вместо видеопроигрывателя Totem (GNOME Videos).
Для желающих протестировать Showtime не дожидаясь осеннего релиза GNOME 49 подготовлен пакет в формате flatpak. Программа отличается минималистичным интерфейсом, отображаемым поверх содержимого и скрываемым во время просмотра. Поддерживаются типовые элементы управления, полноэкранный режим, изменение скорости воспроизведения, показ субтитров и создание скриншотов.
Что такое быть Unix-программистом? Быть наполовину сисадмином (и вот почему)
Как вы поняли, этот пост на Хабре начался со смелого заявления. Конкретно в данном случае я не хотел бы раскладывать по полкам абсолютно все навыки, которые нужны Unix-программисту для успешной работы. Их можно получить простым запросом в поисковике или к любому чат-боту типа ChatGPT, DeepSeek и т.д. (на ваш вкус и цвет)
Я же отметил именно те, приобрести которые стоило мне многих набитых шишек. Они связаны с работой в проектах, состоящих из утилит, содержащих по несколько тысяч строк кода каждая.
Итак, навыки, правила, они же житейские мудрости, они же грабли, на которые наступал.
1. Сначала править конфиги и только потом - код. Это база
В течение практически двух лет такой работы, я часто сталкивался с ситуацией: когда возникает проблема, она находится (неожиданно) не в коде, а в конфигурации программы. Спустя десятки выполненных задач на стыке программирования и системного администрирования, я осознал одну очень важную вещь:
Сначала проверь конфигурацию и все её возможные варианты! Если все эти варианты исчерпаны, то только тогда, в последнюю очередь смотри в код!
Я очень долго привыкал к этой мысли, тратя тонны времени на чтение кода, так и не найдя там ошибки. А после приходил коллега-сисадмин, который пошарил конфигурацию, почитал документацию, поиграл с настройками и всё решил.
2. Владеть инструментами командной строки
Логично, но не очевидно на первый взгляд. В отличие от обычного программиста (в сферическом вакууме), когда ты можешь ограничиться пошаговой отладкой или логами, Unix-программист должен уметь работать с командной строкой. Хоть и не обязательно знать все команды и их опции "на зубок", но нужно понимать, для каких случаев какие утилиты полезны.
Сколько было случаев, когда работа над какой-то задачей ускорялась при использовании какой-нибудь утилиты, дающей больше информации об используемых ресурсах.
Например:
- при невозможности пошаговой отладки использовать perf, чтобы проанализировать стек вызовов
- уметь пользоваться grep'ом для поиска и выделения нужной информации из конкретных файлов
- использовать sed для формирования файлов без лишней информации (например в логах убирать строки с наличием отметок времени)
3. Уметь работать с виртуальными машинами, докером, анализаторами трафика
Например, не плодить виртуалки, а делать снэпшоты (вы скажете: "Спасибо, капитан-очевидность!", но я видел на своей практике тех, кто, не зная про снэпшоты, плодил виртуалки). Держать мастер-копии виртуалок с предварительно настроенной конфигурацией для быстрого развертывания новых машин. Понимать, для каких целей проще использовать докер-контейнер и т.д.
4. Работать с огромным количеством открытых одновременно утилит
Как ни странно, я встречал разработчиков, которые задавали вопрос: "Зачем так много всего?"
Ответ прост: когда непонятно поведение программы, нужно принимать во внимание всё.
Резюме: с таким набором навыков в какой-то момент начинаешь себя чувствовать, как оператор из Матрицы.
А какие особенности в Unix-разработке (и не только) подметили вы?
РТУ МИРЭА совместно с АО НИЦ и Ассоциацией РУСИБ приглашает всех, интересующихся Инфобезом, с 7 апреля по 31 мая принять участие в гибридном хакатоне NeedForFWSpeed на самое быстрое ПО межсетевого экрана и побороться за призовой фонд 0,6 млн рублей.
Все конкурсанты будут использовать одинаковые аппаратные платформы и одинаковые датасеты. Так что старт у всех будет с одной линии.
В качестве аппаратной платформы всем предлагается RPi CM4 MilkV с процессором архитектуры RISC V – мы стойкие сторонники OpenSource.
Зато нет никаких ограничений на ПО. Можно взять абсолютно стандартную сборку *nix и пойти с ней. Можно хорошенько пооптимизировать iptables/nftables, сетевые драйверы и настройки IP-стека и получить прирост производительности. В придачу можно поотключать в ОС и всё лишнее, можно собрать свою кастомную сборку и много чего ещё.
Можно взять и операционку полегче, ОС РВ или Нейтрино, и попытаться получить выигрыш за их счёт. Можно вообще написать свой код, взяв за основу исходники IP-стека, так сказать, BareMetal в чистом виде.
По условиям соревнований не важно, сколько человек в команде, один или пять, какой у Вас возраст и образование, какой опыт работы и какой стек технологий – значение имеет только СКОРОСТЬ РАБОТЫ МЕЖСЕТЕВОГО ЭКРАНА. Никаких взвешенных коэффициентов, призов зрительских симпатий и симпатий жюри. От жюри нужно будет одно – подписать итоговый протокол.
Вся интрига заключается в том, что команды не будут знать о планах и результатах соперников до самого последнего дня. Никаких публичных питчей!
Вопросы можно задать и здесь, можно и там. Организаторы опубликуют несколько статей, посвящённых оптимизации ПО межсетевых экранов для помощи в выборе пути интересующимся. Если Вас заинтересовало это мероприятие, то добавьте этот пост в закладки, по выходу материалов мы добавим сюда или в комментарии ссылки.
PS ... и да, среди нас есть фанаты ленты Need For Speed, и скорость межсетевого экрана нам тоже очень нужна.
🗓 14.03.1994 - Выпущeн пepвый cтaбильный peлиз Linux 1.0.0 [вехи_истории]
🗓 14.03.1994 - Выпущeн пepвый cтaбильный peлиз Linux 1.0.0
В этот день был выпущен первый стабильный релиз операционной системы Linux версии 1.0.0. Этот момент стал важной вехой в истории открытого программного обеспечения, поскольку Linux начал завоевывать популярность как надежная и гибкая операционная система.
Разработчиком ядра Linux является Линус Торвальдс, который начал работу над проектом в 1991 году. Первоначально это был экспериментальный проект, но благодаря поддержке сообщества он быстро развивался. Версия 1.0.0 включала 176 000 строк кода и поддерживала архитектуру x86, работу в многозадачном режиме и сетевые соединения. С тех пор Linux стал основой для множества дистрибутивов и широко применяется в серверах, мобильных устройствах (Android), суперкомпьютерах и встроенных системах.
💙 Интересно? Ставим лайк - и будем готовить историю про Linux)
📼 А знаете ли вы, что в основе Android лежит ядро Linux? Удивительная история Android! Вы этого НЕ ЗНАЛИ YouTube | VkVideo
$ fasm example.asm example
$ ld example -o example
$ ./example
Hello, World!
А сам код генерируется такой:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Author: alexeev-prog ;;
;; Example ASM Program ;;
;; Program generated by FLEXPASM (github.com/alexeev-pro/flexpasm) ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
format ELF64 executable 3; ; ELF64 EXECUTABLE
entry start ; Set Start Entry
;; Segment readable executable in FASM is a directive for defining a section of code with readable and executable attributes.
segment readable executable
start: ; Label start with 7 commands
MOV RAX, 4 ; Loading 4 value into RAX register.
MOV RCX, message ; Loading message value into RCX register.
MOV RDX, message_size ; Loading message_size value into RDX register.
INT 128 ; Call software interrupt 128: SYSCALL
MOV RAX, 1 ; Loading 1 value into RAX register.
MOV RBX, RBX ; Exclusive OR operation RBX and RBX using XOR
INT 128 ; Call software interrupt 128: SYSCALL
;; Segment readable writeable in FASM is a definition of a segment of program data codes, where the attributes readable (the contents of the segment can be read) and writeable (program commands can both read codes and change their values) are specified for it.
segment readable writeable
message db 'Hello, World!', 0xA ; Var message (string)
message_size = $-message ; Var message (string) length
Я его написал довольно давно, вот решил поделиться. Может кому-то пригодится. Если есть баги - создавайте PR и Issue, буду рад)
Работаю в большом проекте состоящем из более чем сотни динамически подгружаемых библиотек. OracleLinux, QtCreator, Qt, C++. Испытывал большие неудобства при загрузке приложения в режиме отладки с большим количеством точек останова (на 10 штуках старт с 30 секунд увеличивался до 2 минут). Казалось бы очевидное, но закономерность замедления обнаружилась не сразу.
При очередном подгруженном модуле происходит попытка установить точки останова в загруженный код. Чем больше кода загружено, тем дольше идет попытка. Как только все точки останова нашли свое место в загруженном коде, скорость подгрузки очередных модулей снова становится быстрой. Активность или пассивность точек останова не влияет.
Для своего проекта отлаживаемые модули перемещаю в начало загрузки (мое приложение делает это конфигурацией), скорость запуска в отладке теперь примерно одинаковая вне зависимости от разумного количества установленных точек останова.
Возможно, я озвучил очевидность. Но мне, работая в данном окружении и в большой команде достаточно давно, это озарение снизошло не сразу. Я и не сильно боролся с этим до недавних пор, сильное замедление произошло не так давно при переходе с Qt4 на Qt5 (у нас вынужденное legacy).
Разработчик под ником madprops предложил способ для быстрого поиска команд в терминале
«Я очень часто обращаюсь к истории действий в shell, чтобы снова и снова запускать одни и те же команды. Пока нет эффективного способа сделать это. Я думаю, что это проблема, которую нужно решать с помощью специализированного инструмента. Я могу попробовать сделать инъекцию оболочки с помощью rofi позже. Но сейчас я придумал трюк, который помогает в работе. Добавьте значки к командам, чтобы вы могли мгновенно распознавать их по стрелкам вверх:
: ✅;./utils/check.sh
: ⚡;./scripts/tag.py
: 📚;./scripts/makedocs.sh
Обратите внимание на двоеточия и точки с запятой. Значки не являются частью команды, они ничего не делают. Но теперь ваше зрение очень быстро распознает нужный элемент. Вместо иконок можно использовать текст, который можно легко отфильтровать позже», — пояснил madprops.
Учимся в сетевые интерфейсы на Linux: руководство по netlink
В интернете я нашел всего одну статью, где описывали мониторинг сетевых портов. Это был хороший старт, но для решения моей задачи информации оказалось недостаточно. Уже во время написания этой статьи я нашел еще пару материалов, которые, как я рассчитываю, хорошо дополнят мой. Помимо статей, нашел несколько man-страниц, в которых описаны пакеты, параметры, структуры и даже есть примеры кода. Оттуда я взял готовый код, способный получать информацию о появлении нового интерфейса и добавлении его в vlan. Но задача требовала отслеживать намного больше параметров системы.
Следующая остановка — пакет iproute2. Iproute распространяется под GNU GPL 2, так что я скачал исходники, собрал их и начал разбираться в коде на C. Чтобы проще понимать логику, я удалял некоторые участки кода, в которые при вызове моей функции программа не входила. Затем пересобирал программу и продолжал изучение и трассировку. Так я понял общий принцип обработки пакетов и сделал обработку пары дополнительных параметров. Но оставалось еще много других условий.
В какой-то момент я вспомнил про утилиту strace: с ней стало проще изучать код и ориентироваться в нем. Strace позволяла увидеть финальный этап работы функции и все ее параметры. Решая свои задачи, я копировал и адаптировал код из iproute. Я не особо вникал во внутреннее устройство протокола, но с каждым этапом разработки это становилось все сложнее и сложнее.
Наконец, я сделал обработку всех параметров кроме одного. В функции его обработки в iproute вызывалась обработка какого-то системного файла, и это было очень странно, так как я видел этот параметр в сообщении netlink через strace. Я зашел в тупик. Код выглядел очень страшно и совсем не нравился мне. Покопавшись в этом еще один день, я понял, что так продолжаться не может. Я решил переписать все заново без использования кода из iproute. Хотел сделать код красивым и максимально понятным для тех, кто будет читать его после меня.
О том, как с помощью netlink узнать, что именно делает система при настройке сетевых интерфейсов и как обрабатывать ее команды, читайте в статье Тимура Аммаева.
Системным программистам в YADRO нужно было «обмануть» драйвер в Linux: он не должен «знать», что работает в эмуляции.
Для этого ведущий инженер Никита приступил к созданию виртуального двойника Intel NTB Gen3 в QEMU, документации к которому в открытом доступе нет. Реализованная модель позволяет производить разработку и тестирование протоколов более высокого уровня, а также выполнять их качественное сравнение.
PCIe NTB не позволяет увидеть адресное пространство, которое принадлежит к подключенному по NTB соседнему устройству. Вкратце он работает так:
перенаправляет трафик PCIe между шинами как мост,
CPU рассматривает мост как конечное устройство,
CPU не «видит» все устройства на «другой» стороне, как правило, другая сторона — это другой компьютер.
Упрощенное представление PCIe NTB
С точки зрения эмуляции, нужно уделить особое внимание регистрам, прерываниям и моделированию поведения устройств.
В работе с PCI BAR необходимо обеспечить прозрачное использование Linux-драйвера Intel NTB для оптимального взаимодействия с оборудованием, которое мы эмулируем. Еще одна задача — разработать новые транспорты, которые работают поверх эмуляции: RPMSG, Virtio/Vhost, NTRDMA и другие. Также одна модель помогла найти ошибки в инициализации драйвера.
Никита подробно описывает тернистый путь создания виртуального двойника Intel NTB Gen3 в статье →
В разработке на python, особенно в DS/ML проектах, мы все сталкиваемся со сложной схемой зависимостей на специфичной аппаратной платформе. Зачастую, вести разработку удобно в том окружении, в котором в последствии запускается приложение.
Если вы вдруг vim user, то можно просто доставить редактор в контейнер с окружением и разрабатывать прямо там. Такая схема достаточно лекговесна, позволяет относительно просто держать актуальными завистимости при разработке, переиспользовать существующие сборочные конвейеры с небольшим наборов слоёв для самого редактора. Так же это может быть удобно, если вам нужно работать где то на удалённом кластере по ssh.
У меня был некоторый шаблон Dockerfile с добавкой vim с плагинами который кочует из проекта в проект и я решил поделиться с вами этой наработкой.
Неоднократно приходилось переходить с Linux на самой машине к той же версии и на той же машине, но развернутой в виртуалке в Windows. И часто замечал, что Linux в Hyper-V работает более “отзывчиво” по части GUI (vscode, chrome, firefox и т.п.). Но это были именно субъективные ощущения, особо не заострял на этом внимание предполагая, что улучшения происходят из-за каких-либо аппаратных интерфейсов, для которых Hyper-V предоставляет стандартные реализации.
Недавно решил обновить рабочий компьютер, и перед тем как выбрать какая ОСь будет основной, провел небольшой тест на сколько “тормозней” Linux в Hyperv-V.
make menuconfig #выбираем Target System (Qualcomm Atheros IPQ807x)
make -j8 download #download отдельной командой, чтобы не зависеть от сети при тесте.
time make -j8
Linux в Hyper-V:
Устанавливаем Windows 10 LTSC на ноут.
Включаем поддержку Hyper-V.
Устанавливаем Linux под Hyper-V.
В настройках виртуалки, установить кол-во CPU равным 8, выделить RAM 8-18 GB.
Далее выполняем те же действия, что и в пп. 1.2.
Вывод time после сборки OpenWrt:
Linux на ноутбуке:
попытка №1
real 30m37,765s
попытка №2
real 29m18,569s
Linux в Hyper-V:
попытка №1
real 27m12,136s
попытка №2
real 27m36,395s
Получается, что Linux в Hyper-V работает немного быстрей? Странно это, и по хорошему нужно проверять еще. Но на данном этапе меня устраивает, что могу две ОСи одновременно использовать и есть уверенность что нет дополнительных проседаний в производительности.
Так же попробовал в виртуалке установить Ubuntu 24.04 и Linux Mint 22 Cinnamon, их время было такое,real 30m59,630s и 30m37,765s соответственно.
Три проверенных метода организовать обмен прерываниями между машинами QEMU c KVM и без
Эмулятор QEMU помогает решать ряд задач, в том числе разработку и отладку любого уровня коммуникаций. Вы можете эмулировать работу не только отдельной машины, но и связывать несколько независимых машин между собой.
Быстрая работа такой связки приятна при разработке/отладке и очень важна при массовом прогоне автотестов в CI. Как оптимизировать обмен прерываниями и какой подход к организации IQI вам подойдет — узнаете из статьи. А еще разберемся c:
устройством QEMU под капотом,
реализацией модели и драйвера,
добавлением прерываний MSI-X,
результатами замеров.
На бонус: десяток полезных материалов для изучения.
Я просто оставлю это здесь, может, кому-нибудь пригодится.
Из-за того, что в последних версиях шестая плазма более-менее готова к использованию, я нашёл время стряхнуть пыль со старой темы, которую использовал когда-то для пятёрки.
Под "готова" я имею в виду, что система справляется со своими задачами в довольно жёстких условиях: на моём безвентиляторном мини-ПК с HiDPI дисплеем крутится Андроид Студия, эмуляторы различных устройств и операционных систем и прочие инструменты разработчика. Согласитесь, что это показатель.
Внешний вид темы по умолчанию (Бриз) меня в целом устраивает, а вот нижняя ("южная") панель не нравится. Поэтому тема делает две вещи:
Устанавливает тёмный (в моём случае прозрачный) фон всей панели и границу сверху.
Производители SoC, как правило, предоставляют окружение для разработки и документацию с примерами реализации универсальных решений. Но много важных деталей упускается или скрывается от пользователя. В итоге нетривиальная модификация системы требует долгих исследований и экспериментов.
Изучили все нюансы на практике за вас, реализовав проект запуска Embedded Linux на Hard- и Soft-процессорах Xilinx Zynq. Пойдем по этапам:
Подтверждена совместимость BPM-системы «Первая Форма» с «РЕД ОС»
ВРМ‑система «Первая Форма» стабильно работает на российской операционной системе РЕД ОС 8, а также на мобильной платформе РЕД ОС М. Совместимость продуктов позволяет автоматизировать бизнес‑процессы организаций, обеспечивая их выполнение на отечественной ИТ‑инфраструктуре. Чтобы повысить уровень защиты данных, поддерживается двухфакторная аутентификация и интеграция со смарт‑картами.
РЕД ОС — операционная система семейства Linux, предназначенная для серверов и рабочих станций. Она обладает сертификацией ФСТЭК России, что делает её подходящей для задач с повышенными требованиями к безопасности.
«Первая Форма» — набор инструментов для автоматизации документооборота, управления проектами, CRM, В2В2С‑решений и корпоративных коммуникаций, занимает лидирующую позицию среди российских low‑code решений для управления бизнесом.
Оба решения входят в реестр отечественного ПО Минцифры.
Подтверждена совместимость BPM-системы «Первая Форма» с «РЕД ОС»
