LINUX.ORG.RU
1.использовать fluxbox 2.не использовать "менеджеры входа в систему"
anonymous
()
ну и еще иксы не использовать до кучи и грузиться в single mode :)
anonymous
()
Может кто нить это чудо на русский переведет ?
anonymous
()
> Может кто нить это чудо на русский переведет ?

запросто! %)

"туши все что не нужно" (C) IBM
anonymous
()
нет, там идея в другом, просто некоторые сервисы вполне можно запускать параллельно. Вообще IMHO это все интересно только для десктопов да и то только тех, что перегружают/останавливают часто. Сервера перегружаются крайне редко и для них скорее важнее, что бы все надежно поднялось, чем экономия 10-15 секунд.
anonymous
()
На надежность это не должно влиять.Ну, почти :)
А вообще говоря, вещь сильно полезная.
Основная трудность будет не в самой реализации, а в написании комплекта утилит для обслуги и миграции с текущей схемы.

AVL2 ★★★★★
()
Чешь полная ) это уж совсем для ЛАМ ......

creat

anonymous
()
рулезная статейка. вы прежде чем хаять почитали бы.
Сервисы стартуют паралелльно - прикольная идея заюзать make :)
anonymous
()
Чел шарит! Он предлагает исползовать 1 makefile для запуска init скриптов. Убивая этим двух зайцев. Зависимости между сервисами правильно разруливаются и загружаться могут скрипты в разы быстрее...
eXOR ★★★★★
()
Да, статья хорошая, но идея с зависимостями сервисов уже давно было реализованно в дистрибутиве Gentoo Linux; кому интересно, те могут прочитать поподробнее здесь: http://www.gentoo.org/doc/ru/rc-scripts.xml#doc_chap4

Типы зависимостей в Gentoo:
---------------------------

о Тип зависимости NEED

Используется, если зависимый сервис критичен для запуска текущего сервиса.

То есть, NEED - это "строгая" зависимость.

о Тип зависимости USE

Сервис не критичен для работы текущего сервиса, но, если он используется, то запуск его должен произойти до начала работы текущего сервиса.

То есть, USE - это "слабая" зависимость.

Если между двумя сервисами нет отношений зависимости, но необходимо (или желательно) явно запустить один сервис после другого, можно использовать отношения AFTER и BEFORE.

о Тип BEFORE

Текущий сервис начнет работу *перед* перечисленными в строке BEFORE

о Тип AFTER

Текущий сервис начнет работу *после* перечисленных в строке AFTER
e-lite
()
И еще, для пользователей Gentoo:

echo 'RC_PARALLEL_STARTUP="yes"' >> /etc/conf.d/rc

Потом попробуйте перезапустить систему.

Требования: новый baselayout.

e-lite
()
кстати в НетБСД для определения порядка в котором надо выполнять скрипты из /etc/rc.d используется rcorder http://netbsd.gw.com/cgi-bin/man-cgi?rcorder++NetBSD-current -- она просто по ключевым словам в скриптах определяет направленный граф зависимостей на них, а потом топологически сортирует.

Может быть можно сообразить как rcorder изменить чтобы он генерировал сразу и те которые можно запустить параллельно. Например он бы генерировал тот же список что генерирует, но вставлял в него специальные маркеры, типа стопы.

Можно было бы прикрутить rcorder и к линуксу.

dilmah ★★★★★
()
make для стартовых скриптов? хмм. это оригинально, к тому же make - это стандарт.
alman ★★★
()
make хуже rcorder в точности по той причине по которой на лоре постоянно обсирали старые БСД скрипты -- там нужен глобальный Makefile вырождающийся в мусорку. rcorder симпатичнее.
dilmah ★★★★★
()
У меня альтернативное предложение. Открываем в OpenOffice рисовалку. oodraw. Рисуем диаграмму зависимостей (не как попало, а по заранее разработанным соглашениям). Берем результирующий файл. Распаковываем, получаем XML. Применяем хитроумный XSLT - получаем build.xml для ant. Вместо make при запуске применяем ant (правда, не уверен, как там у ant с параллельным выполнением - если нет, нужно добавить фичу). Все.

:)

svu ★★★★★
()
Ерунда.

Для того чтобы все в нужном порядке стартовало есть номера. И тут ничего больше придумывать не нужно.

Паралельный старт. А зачем?
anonymous
()
А может все же кто нибудь переведет это статью :) Я думаю на десктопе это очень актуально... Если оно так все просто :) то почему не в одном desktop ориентированном дистрибутиве это не реализованно ? :)
anonymous
()
> Если оно так все просто :) то почему не в одном desktop
> ориентированном дистрибутиве это не реализованно ? :)

Gentoo? Читай мои посты выше...
e-lite
()
>У меня альтернативное предложение. Открываем в OpenOffice рисовалку. oodraw. Рисуем диаграмму зависимостей (не как попало, а по заранее разработанным соглашениям). Берем результирующий файл. Распаковываем, получаем XML. Применяем хитроумный XSLT - получаем build.xml для ant. Вместо make при запуске применяем ant (правда, не уверен, как там у ant с параллельным выполнением - если нет, нужно добавить фичу). Все.

Правильно!
Мы любую задачу усложним так, чтоб никому мало не показалось :)
Это ж разовая работа, зачем так извращаться?

ANDI ★★
()
Кстати если кто не вкурсе, то есть еще проект под названием kexec: http://www.osdl.org/docs/reducing_system_reboot_time_with_kexec.pdf

цель данного проекта уменьшить время необходимое для перезагрузки машины, и тем самым увеличить скорость загрузки :)

mator ★★★★★
()
> Если оно так все просто :) то почему не в одном desktop
> ориентированном дистрибутиве это не реализованно ? :)
Все тривиально. Параллельный запуск на однопроцессорной машине не приводит к уменьшению общего времени работы запуска.
А Desktop он на то и декстоп что однопроцессорный
Korwin ★★★
()
Кроме процессора - есть еще ввод-вывод, диск... Мне кажется распараллеливание может ускортить
sin_a ★★★★★
()
to mator:
Даеш 60 rpm (reboot peer minute)! :)
Skor78
()
Суть make'а в том, что он практически стандартен. Плодить новые сущности - это не unix-way. Чел, написавший статью 10 раз шарит.
eXOR ★★★★★
()
Ответ на: комментарий от Korwin
Распараллеливание поможет в случае, если поднимается какая-нибудь сетевая хрень и 10 минут ждёт (подъёма DNS сервера дебильного ISP. Сам ISP никогда не почешется, чтобы это дело поправить | когда канал поднимется). А для подъёма X с "менеджером входа в систему" оно нах не надо. Так что на части десктопных машин ускорение будет огого...
adarovsky ★★★★
()
Ответ на: комментарий от eXOR
2eXOR

Как ты будешь апдейтить Makefile? Апдейтить его в ручную это юникс-вей?? А если апдейтить его скриптом то это будет уже на порядок сложнее и запутаннее чем rcorder.

Вот использовать tsort и sort вместе с sed при написании скрипта rcorder это можно назвать юникс-вей. В НетБСД она правда на Си написана.

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

dilmah ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.