Фелкер выделяет три основные архитектурные проблемы systemd:

• В Unix-системах PID 1 имеет специальное назначение, в частности, PID 1 становится родителем для осиротевших процессов и поддерживает специальную семантику сигналов. В случае краха обработчика PID 1, происходит крах всей системы (kernel panic). Традиционные системы инициализации минимизируют размер кода и число функций обработчика PID 1, в то время как systemd выносит на уровень PID 1 серию демонов, реализующих вторичные функции, что приводит к общему снижению надёжности. Если традиционный init-процесс занимается лишь обработкой сигнала SIGCHLD от осиротевших процессов и реагирует на смену администратором текущего уровня запуска (runlevel), то systemd дополнительно занимается такими вещами, как управление подключением и отключением устройств, изменением точек монтирования, слежение за состоянием элементов в ФС и даже обработка запросов через DBus API.

• В защищённой системе без systemd, обычно присутствует только один привилегированный процесс, критичный для проведения атаки, - sshd. Все остальные компоненты управляются и получают входные данные только от пользователя root. В случае systemd присутствуют каналы взаимодействия с непривилегированным пользователем. Реализация расширенных функций в systemd приводит к необходимости выполнения на привилегированном уровне лишнего кода по выделению ресурсов, обработки файлов, разбору сообщений и обработке строковых данных, что увеличивает риск возникновения уязвимостей, которые могут быть эксплуатированы непривилегированным пользователем.

• Вынос на уровень системы инициализации дополнительных функций приводит к необходимости перезагрузки системы при установке обновлений компонентов systemd, обеспечивающих работу PID 1.

Источник : http://www.opennet.ru/opennews/art.shtml?num=39050

Вообще-то, включение udev в systemd вполне логично. Раз уж разработчики udev стали разработчиками systemd, то естественно, что они свои же предыдущие разработки и включили в новую. Не писать же им по второму разу одно и тоже?

наконец-то голос разума

Объединение кода udev'а с кодом systemd - это не что иное как навязывание systemd. Без вариантов.

Вообще-то, включение udev в systemd вполне логично. Раз уж разработчики udev стали разработчиками systemd, то естественно, что они свои же предыдущие разработки и включили в новую. Не писать же им по второму разу одно и тоже?

Я себе на виртуалку хочу поставить eudev и выложить пакеты со слакбилдами. И сейчас над этим работаю.

Вы бы поосторожнее, а то вдруг Red Hat пришлёт к вам отряд своих ликвидаторов. Ведь вы подрываете их планы по порабощению Линукса.

redix пишет:

Редхат вам что то навязывает?

redix, 100500 раз уже говорили. Объединение кода udev'а с кодом systemd - это не что иное как навязывание systemd. Без вариантов.

И 100500 раз пришли к выводу, что навязывание мерещится параноикам.
И про объединение кода udev и systemd тоже всё 100500 раз разжевали.

Настолько нет, что Леннарт ради целого рунета родил этот опус?

настолько нет что Леннарт написал статью. Причем, заметь, нигде в статье нет бреда о контроле "шапочников" над вселенной и общем геноциде джедаев-праведников. Статья чисто техническая, для тех кто не понимает или сомневается.

но народ довольно активно проблему обсуждает.

А где слакварщики торчат обычно? LQ?

Настолько нет, что Леннарт ради целого рунета родил этот опус?

Патрик пока отмалчивается

Чё это отмалчивается? Он же ясно сказал "не будет". 

Кому он его навязал?

Дистрибутивам. Не? А ты еще раз подумай

Объединение кода udev'а с кодом systemd

Редхат объединяет это для себя. Кому он его навязал?

Если что-то усиленно навязывают - не жди от этого добра.

Red Hat делает systemd и другие технические решения, чтобы использовать их в своих продуктах. Но при этом код открыт, а значит, другие дистрибутивы тоже могут использовать systemd, если они того пожелают. Дула у виска никто не держит.

Редхат вам что то навязывает?

redix, 100500 раз уже говорили. Объединение кода udev'а с кодом systemd - это не что иное как навязывание systemd. Без вариантов.