Это архивная статья

Почти с самого появления было понятно, что systemd претендует не на связку monit+sysv, но на гораздо большее. С анонсом systemd 215 (обсуждение на OpenNET.ru) это было объявлено официально, в виде доклада на FUDCON + GNOME.Asia (слайды и обсуждение на OpenNET.ru).

Теперь это официальная Linux-платформа, конструктор для создания Linux-системы. Логи, сеть, контейнеры, оборудование, пользователи - все поглощается systemd.

Конечно, есть недовольные, особенно учитывая, что при реализации планов не удалось обеспечить кое-что из запланированного. Например, так и не удалось сохранить полную работоспособность udev без systemd, но чего поделать? Интересно, что udev не получится использовать без systemd из-за перехода на kdbus. Отказываться от него в апстриме systemd (или даже просто делать необязательным) не желают, т.к. плюсы от него перевешивают минусы (трех недовольных гентушников).

Уже сейчас видно, что производительность kdbus существенно выше предыдущего решения, да и другие проекты тоже рассматривают использование kdbus. Например, не так давно, D-Bus (и в частности kdbus) рассматривали в списке рассылки по flow-based programming, но, конечно, гораздо более интересным был бы перевод Binder на kdbus.

С самым первым анонсом kdbus, многие заинтересованные лица рассуждали на тему перевода Binder на kdbus или объединения проектов, очень по разному оценивая шансы на материализацию таких планов. Например, известный гентушник и дистрохоппер Greg KH полагает, что это маловероятное событие, а вот другие разработчики ядра считают иначе. John Stultz, инженер Linaro и бывший инженер IBM, который уже высказывался на Linux Plumbers Conference 2013 по поводу объединения kdbus и Binder, в своей ленте Google+ повторил, что с его точки зрения плюсы в слиянии обеих проектов перевешивают минусы, и обратил наше внимание на работу своего коллеги, Takahiro Akashi - **"Benchmarking IPCs"**, в которой измеряется скорость работы обеих систем. Выяснилось, что с умолчальными параметрами kdbus в четыре раза медленнее, чем Binder (139 микросекунд против 35), но с помощью нескольких изменений в коде kdbus удалось уменьшить задержку до 48, что, учитывая большую функциональность kdbus, вполне терпимо.

Greg KH в комментариях в ленте Google+ у Takahiro Akashi уже высказал свой скептицизм.

С его точки зрения, числа тут много не решают. Он полагает, что архитектурное различие между двумя IPC устранить будет непросто (и возможно не стоит того). А для нас особенно интересным оказалось то, что мы увидели success story использования ftrace.

К сожалению, в ядрах, доступных в Fedora, kdbus отключен (мы не включаем out-of-tree патчи), но с недавних пор появился сторонний полуофициальный репозиторий с ядрами, в которых включены тестовые фичи, и среди прочего там доступен kdbus (новость уже обсуждается на OpenNET.ru).