systemd и будущее
Это архивная статья
Почти с самого появления было понятно, что 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).