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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.