В связи с последними контейнерными известиями, еще более интересными становятся новости о systemd.

Недавно вышла довольно проходная версия 221, которую коллеги-аналитики уже обсуждают на Linux.org.ru. В это версии самым замечательным событием было объявление kdbus обязательным компонентом, и стабилизация sd-bus. А вот в списке разработчиков ядра уже сформировалась группа любителей юниксвэя, недовольных kdbus. Хорошо, что их фантазии озвучивает лишь один человек, и особенно хорошо, что известный хулиган и матершинник, Linus Torvalds, в целом одобряет включение kdbus в ядро, не ведясь на театральные жесты этих ретроградов. Так что близится очередная тактическая победа команды systemd, плавно перерастающая в стратегическую, когда ПО будет переписываться с использованием новой скоростной шины сообщений.

К сожалению, недовольство 221 версией не ограничилось только новой шиной. Мэйнтейнеры Debian (да и видимо не только они) упорно продолжают держаться за бессмысленную фичу "раздельного /usr", и любая попытка упростить конфигурацию сталкивается с их недовольством, мол у пользователя забирают юниксвэйную свободу выбора. Конкретно этот pull request привел к картинным заламываниям ручек в ленте Google+ проекта, хотя дальше этого дело пока не пошло. Ничего, перебесятся. Отдельный /usr все равно не работает.

Вернемся к kdbus, и sd-bus. Lennart Poettering опубликовал введение в sd-bus, где рассказал о том, как работать с новым API. Понятно, что использование sd-bus жестко привяжет ваш проект к современным Linux-ядрам, но плюсы могут перевесить этот минус. В целом kdbus/sd-bus выглядит как еще один шаг вперед, к унифицированной Linux-платформе.

Среди противников kdbus, кроме идеологически заряженных любителей технологий из 1990х, есть и люди, которые не разобрались с областью применимости самой концепции шины данных, и спрашивают о разнице между kdbus и AF_UNIX. Для них David Herrmann подготовил кратенькое описание основных различий.

Да, и о контейнерах. К сожалению, складывается впечатление, что Lennart не очень понимает (и не ценит) задачу совместной работы нескольких систем. Да, systemd довольно успешно и архитектурно грамотно выстаивает контейнерное решение, но тем не менее, складывается впечатление наличия каких-то барьеров в понимании проблематики распределенных систем. Указать на какое-то конкретное доказательство этому не получится, но по совокупности фактов складывается именно такое впечатление. Ну, вот, например, недавно, в systemd подняли тему о возможном включении поддержки CRIU в systemd-nspawn. Мы неоднократно замечали интерес к именно такому потенциальному сценарию использования, но, к сожалению, Lennart отказался оценить перспективы этого решения, т.к. мол CRIU не поддерживает 100% имеющегося ПО. Очень и очень печально, чего уж там.

Ну и напоследок, новость не о systemd, но о платформе systemd/Linux. Наши коллеги, вместе с нашими друзьями из Canonical и Debian, недавно представили уже вторую официальную версию storaged, демона, идущего на замену udisks2, но независимого от окружения GNOME и полностью управляемого по D-Bus (kdbus / sd-bus). Стандартизация стремительно наступает на юниксвэйную свободу выбора из нескольких вариантов.