> 1. Поглощение или замена системных компонентов, которые не были раньше привязаны к
> systemd (udev,cron,dbus,consolekit,syslog и т.д.). Отсюда представляется невозможным
> использовать systemd совместно с mdev, например.
>cron

у меня systemd и cron прекрасно работает. то, что в systemd появилась похожая функциональность, никому не мешает.

>dbus

он в systemd не вливается и аналогичная функциональность в systemd не планируется. последний пользуется dbus-ом, но функциональность у них не пересекается.

>consolekit

Наконец-то кто-то взялся за реализацию этого недописанного куска неподдерживаемого кода.

>syslog

journald работе сислога не мешает. более того, первый можно фактически отключить.

> 2. Бинарный журнал с собственным форматом. Я думаю, всем было бы лучше,
> если бы формат журнала мог выбирать пользователь, как это было раньше.

Свободы выбора формата локального текстового журнала у пользователя syslog не больше, ем у пользователя journald в выборе бинарного.

> 3. Отсутствие культуры разработки. В частности, полное нежелание апстрима конструктивно
> работать с сообществом. Особенно вызывает раздражение тот факт, что выносят на
> обсуждение то, что уже давно решили. Т.е. по сути ставят перед
> фактом.

С моей точки зрения, скорее, наоборот, предлагают свою помощь тем дистрибутивам, которые хотят на systemd перейти. При этом довольно продолжительное время даже засовывали в апстрим специфичные для дистрибутивов костыли, что вообще неслыханно.

> 4. Отсутствие деления веток на стабильную, где исправляются только ошибки, и для
> тестеров с добавлением новых возможностей.

Добро пожаловать в мир гибких методологий разработки. Если кому-то нужна LTS-версия, пусть поддерживают своими силами, что, кстати, в дистрибутивах и происходит.

> 5. Монолитность проекта выливается в невозможность исключения ненужной функциональности
> без пересборки с нужными ключами. От этого страдают в первую очередь
> бинарные дистрибутивы, где пользователь лишён возможности исключить ненужную ему функциональность
> путём удаления определённых пакетов. Могу предположить, что у Леннарта своё понятие
> о модульности. В других модульных проектах такой проблемы нет. Каждый плагин
> пакуется в отдельный пакет с возможностью выборочной установки под решаемую задачу.

Например ядро.

> 7. Плохая совместимость с другими системами инициализации.

Совместимость там, где майнтейнеры ей озаботились, отличная. Допиливать апстрим-софт под нужды и извращения конкретного дистрибутива - задача его майнтейнеров. Если к systemd прилаживать костыли для каждого из сотен дистрибутивов, то он разбухнет так, что ты же первый начнешь еще сильнее про блоатварность верещать. Разработчики предоставили интерфейс к lsb-init для совместимости, а остальное - проблемы индейцев.

> В частности, это приводит к
> тому, что дистрибутивы с опциональным systemd будут вынуждены как-то вытаскивать из
> systemd компоненты, которые он поглотил, а также постоянно менять альтернативные системы
> инициализации с целью обеспечения совместимости с постоянно меняющимся форматом и
> расположением файлов конфигурации systemd.

Если дистрибутив стабильный, то зачем постоянно пытаться догнать последнюю версию? Ядро еще интенсивнее меняется, однако, ты на это не жалуешься в каждой новости про его новую версию.

>Поставлять udev,dbus и т.д. отдельно товарищи из редхата почему-то не в состоянии. То ли опыта не хватает, то ли политика партии.

udev отдельно поставить можно, dbus запихивать в systemd никто не собирается.