> ошибочка. я прекрасно понимаю что не все так красиво. но и отрицать
> очевидное не хочу. работает и без проблем, управляется просто.Для системного ПО важно не то, что оно работает на "гномодесктопе" (как уже давно характеризуют федору сами её разработчики), а то, что оно работает всегда и по возможности даже в нештатных ситуациях. Причём мерило тут не то, сколько свистелок доступно в нормальном случае, а то, в скольки случаях на сотню или тысячу оказываешься без выхода.
> имеет набор утилит которые расскажут о системе все до последнего форкнувшегося
> процесса. при ините как бы не был он привычен такого не было.
Мало того, некоторым и не требовалось -- ну, у которых всё по контейнерам распихано было уже много лет как. При этом подход с контейнерами выгодно отличается от монолитного корня возможностью обновления по мере наличия необходимости и времени/внимания.
> вообще выяснить потомка демона не всегда было можно. в некоторых случаях
> перезапуск демона ничего не давал, он просто сам нифига не знал о своем потомке
Да, гильотина cgroups -- довольно мощное средство даже при среднередхатовой криворукости.
С /usr там примерно так же поступили -- было слишком много отвратительно собранных пакетов, где бинари из /bin линковались с библиотеками из /usr/lib, плюс слишком много багов на эту же тему в anaconda, pulseaudio и, если не изменяет склероз, в гноме.
Например, у Леннарта (ник mezcalero на LWN) был такой довод, что GUI к PA всенепременно надо показывать модель звукокарточки, которая берётся из файла pci.ids, который обычно в /usr, а инициализировать это всё надо непременно чуть ли не в initrd -- очень рано при запуске системы. То, что человек с руками из плеч и головой оттуда же сделает отложенное заполнение данных для интерфейса, который всяко не сразу после загрузки ядра появится -- почему-то не рассматривалось (ну или не заметил).
> а тут даж системная утилита ведет не только лог, но смотрит за производительностью
> и количеством потраченого времени на запуск и работу.
Вообще-то без подобного инструментария крайне тяжело искать и исправлять те же циклы, и принимать их в качестве неизбежного зла за инструментарий, который неизбежно пришлось разрабатывать в процессе изначальной борьбы с этим же злом -- я, например, не готов.
Мне тоже пришлось довольно быстро сделать трассировку выполнения makefiles и обработку при помощи graphviz, когда делал ещё ранние mkimage-profiles. По той же причине -- растущие и шевелящиеся графы быстро перестают укладываться в голове.
> не было в ините такого.
Там ещё и кофемашины нет, а http://www.bootchart.org доступен скоро десять лет как.
> да и костыли вечные для работы нужны были. либо через крон либо ат.
Почему мне не были нужны?
> либо отдельно прописывать свой скрипт что бы хоть заработало. не все сладко в ините.
Так он и не сахарница, шоб было "усё сладко".
Только есть сомненья, что тем, у кого были проблемы с инитскриптами, в долгосрочной перспективе станет легче от юнит-файликов -- система-то сложнее стала и если раньше у кого-то, кто писал не понравившийся Вам лично инитскрипт, не хватало квалификации на него -- теперь может не хватить в гораздо худшем виде: не все теорию графов изучали на досуге.
Впрочем, тут жизнь покажет.
