Микросервисы(async single-threaded) в эмбеддед. OpenBMC и рефакторинг «кошмара на С++» с помощью ИИ

[bkisonka]

Вот как нейросеть видит данный проект при анализе исходников (публикую только вывод, там большая портянка):

Сильные стороны:

• Архитектура микросервисов на локальной шине — образцовая: IDL-first контракты, service discovery (mapper), подменяемые реализации, нулевая связанность демонов между собой. Для встраиваемого проекта это очень высокий уровень инженерной культуры.

• Декларативность: платформа = JSON-конфиги entity-manager + выбор packagegroup-фич; логика последовательностей = systemd-таргеты. Порог входа для поддержки «ещё одной платы» низкий.

• Безопасность продумана системно: разделение привилегий по D-Bus-политикам, mTLS, Redfish-привилегии, hardened-флаги компиляции, отдельные пользователи для демонов.

• Живой процесс разработки: Gerrit + Jenkins CI, обязательные тесты и рецензии.

Слабые стороны и компромиссы:

• Сложность кросс-репозиторной разработки: добавить одну фичу часто затрагивает 3–4 репозитория (YAML интерфейса → codegen → демон → Yocto-рецепт) с синхронизацией через Gerrit. Кривая обучения крута (нужно знать Yocto, D-Bus, корутины C++20, meson).

• D-Bus брокер — единая точка отказа: при падении шины система слепнет (частично смягчено fail-monitor и рестартами systemd, но это узкое место по конструкции).

• Ресурсная цена: модель «много мелких процессов» и Boost в bmcweb тяжеловаты для BMC с 128–256 МБ RAM; bmcweb на шаблонах C++20 ещё и очень долго компилируется.

• Следы встраиваемости ощущаются буквально: пути конфигов hwmon повторяют devicetree и превышают 260 символов — при клонировании на Windows мне пришлось включать core.longpaths, checkout по умолчанию падает. Это не «баг», но показывает, что вне Linux с проектом работать тяжело.

Итог. OpenBMC — зрелый, строго модульный проект уровня инфраструктурного ПО: D-Bus играет роль, которую в облаках играют REST/gRPC, а systemd — роль оркестратора вроде Kubernetes (в миниатюре). Архитектура рассчитана на долгий жизненный цикл и массовое многовендорное переиспользование, и плата за это — высокая сложность разработки и требовательность к ресурсам целевой платформы.

По моему адекватная оценка.

[eao197]

После прочтения этого “плача Ярославны” у меня два вопроса:

• хоспади, зачем это было написано?

• хоспади, зачем я это все читал?

Человек увидел в реальном мире говнокод (еще и не самый страшный, скажем прямо) и побежал вайбкодить статью о том, что он нашел говнокод. И все.

Ладно бы показал, как этот говнокод привести в приличный вид и выиграть по всем параметрам. Так ведь нет. Просто поплакал о том, что говнокод есть, а ИИ не в состоянии пока сделать из говна конфетку.

Что до претензий к архитектуре, принятой в openBMC, то вот у авторов были свои идеи. Они их воплотили в жизнь. Видимо, им нужно было. Если у вас есть свои идеи, как вам кажется более правильные, то сделайте по-своему, выложите в OpenSource. Уверен, очень быстро найдутся другие вайб-кодеры, которые найдут в ваших архитектурных решениях фатальный недостаток, а то и не один.