нет, там идея в другом, просто некоторые сервисы вполне можно запускать параллельно.
Вообще IMHO это все интересно только для десктопов да и то только тех, что перегружают/останавливают часто. Сервера перегружаются крайне редко и для них скорее важнее, что бы все надежно поднялось, чем экономия 10-15 секунд.
На надежность это не должно влиять.Ну, почти :)
А вообще говоря, вещь сильно полезная.
Основная трудность будет не в самой реализации, а в написании комплекта утилит для обслуги и миграции с текущей схемы.
Чел шарит! Он предлагает исползовать 1 makefile для запуска init скриптов. Убивая этим двух зайцев. Зависимости между сервисами правильно разруливаются и загружаться могут скрипты в разы быстрее...
Да, статья хорошая, но идея с зависимостями сервисов уже давно было реализованно в дистрибутиве Gentoo Linux; кому интересно, те могут прочитать поподробнее здесь: http://www.gentoo.org/doc/ru/rc-scripts.xml#doc_chap4
Типы зависимостей в Gentoo:
---------------------------
о Тип зависимости NEED
Используется, если зависимый сервис критичен для запуска текущего сервиса.
То есть, NEED - это "строгая" зависимость.
о Тип зависимости USE
Сервис не критичен для работы текущего сервиса, но, если он используется, то запуск его должен произойти до начала работы текущего сервиса.
То есть, USE - это "слабая" зависимость.
Если между двумя сервисами нет отношений зависимости, но необходимо (или желательно) явно запустить один сервис после другого, можно использовать отношения AFTER и BEFORE.
о Тип BEFORE
Текущий сервис начнет работу *перед* перечисленными в строке BEFORE
о Тип AFTER
Текущий сервис начнет работу *после* перечисленных в строке AFTER
кстати в НетБСД для определения порядка в котором надо выполнять скрипты из /etc/rc.d используется rcorder http://netbsd.gw.com/cgi-bin/man-cgi?rcorder++NetBSD-current -- она просто по ключевым словам в скриптах определяет направленный граф зависимостей на них, а потом топологически сортирует.
Может быть можно сообразить как rcorder изменить чтобы он генерировал сразу и те которые можно запустить параллельно. Например он бы генерировал тот же список что генерирует, но вставлял в него специальные маркеры, типа стопы.
make хуже rcorder в точности по той причине по которой на лоре постоянно обсирали старые БСД скрипты -- там нужен глобальный Makefile вырождающийся в мусорку. rcorder симпатичнее.
У меня альтернативное предложение. Открываем в OpenOffice рисовалку. oodraw. Рисуем диаграмму зависимостей (не как попало, а по заранее разработанным соглашениям). Берем результирующий файл. Распаковываем, получаем XML. Применяем хитроумный XSLT - получаем build.xml для ant. Вместо make при запуске применяем ant (правда, не уверен, как там у ant с параллельным выполнением - если нет, нужно добавить фичу). Все.
А может все же кто нибудь переведет это статью :) Я думаю на десктопе это очень актуально...
Если оно так все просто :) то почему не в одном desktop ориентированном дистрибутиве это не реализованно ? :)
>У меня альтернативное предложение. Открываем в OpenOffice рисовалку. oodraw. Рисуем диаграмму зависимостей (не как попало, а по заранее разработанным соглашениям). Берем результирующий файл. Распаковываем, получаем XML. Применяем хитроумный XSLT - получаем build.xml для ant. Вместо make при запуске применяем ant (правда, не уверен, как там у ant с параллельным выполнением - если нет, нужно добавить фичу). Все.
Правильно!
Мы любую задачу усложним так, чтоб никому мало не показалось :)
Это ж разовая работа, зачем так извращаться?
> Если оно так все просто :) то почему не в одном desktop
> ориентированном дистрибутиве это не реализованно ? :)
Все тривиально. Параллельный запуск на однопроцессорной машине не приводит к уменьшению общего времени работы запуска.
А Desktop он на то и декстоп что однопроцессорный
Распараллеливание поможет в случае, если поднимается какая-нибудь сетевая хрень и 10 минут ждёт (подъёма DNS сервера дебильного ISP. Сам ISP никогда не почешется, чтобы это дело поправить | когда канал поднимется). А для подъёма X с "менеджером входа в систему" оно нах не надо. Так что на части десктопных машин ускорение будет огого...
Как ты будешь апдейтить Makefile? Апдейтить его в ручную это юникс-вей?? А если апдейтить его скриптом то это будет уже на порядок сложнее и запутаннее чем rcorder.
Вот использовать tsort и sort вместе с sed при написании скрипта rcorder это можно назвать юникс-вей. В НетБСД она правда на Си написана.
Сишный препроцессор это тоже стандарт однако пихать его во все дыры это маразм потому что СПП неадекватный препроцессор для нормальных задач.