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

До systemd эти компоненты были независимы. Даже если один компонент "выходил из строя" (разраб. забросил разработку) можно всегда перейти на альтернативу. Теперь представим, что будет через 10-20 лет на примере systemd. Леня стал тех.диром Red Hat и уже не пишет софт, а занимается действительно важными вещами. Все основные контрибьютеры разбежались, а те, что остались не имеют достаточной компетенции. Вот уже имеется библиотека libsystemd, на ней завязано 100500 программ. Наступает момент, когда сам systemd (и libsystemd) уже никто не поддерживает в актуальном состоянии. Находят тучу уязвимостей и... и все ложится на плечи мейнтейнеров дистров, как обычно. Кто-то успевает патчить, кто-то не успевает. Карточный домик рушится, фактически в одно мгновение.

Такая модель не страшна, если приложение не является ключевым. Увы, systemd и его форки настолько важное звено в системе, что чуть-что и приплыли.

Я за systemd не переживаю, т.к. он под крылышком красношапок. А вот за аналоги во фряхе уже надо начинать волноваться. Если эти форки действительно важны, то они должны быть в приорите, наравне с ядром. Пока же, все расплывчато: занимаются 1.5 анонимуса, которые могут бросить проект на середине, если приспичит. По-хорошему, обычно, в таких случаях происходит детальное планирование и проектирование, за ними активное тестирование и после внедрение. В случае systemd и его аналогов почему-то все сразу принимают _любые_ реализации, чуть ли не на веру. Парадокс systemd: концепция всем понравилась, но никто не задумался о последствиях.