[devel] Инициализация системы

[Anton Farygin]

И меня втянули ;)

Mikhail Gusarov пишет:
> Twas brillig at 16:27:52 06.03.2008 UTC+03 when Dmitry M. Maslennikov did gyre and gimble:
> 
>  >> Вон, ядерщики уже на это натолкнулись - см. hotplug/udev ;)
>  DMM> Не согласен с этой аналогией. Во-первых hotplug все-таки умер,
> 
> Это я специально вставил меточку. Спасибо за то, что на неё попались ;)

Т.е. - ты хочешь сказать что initng тоже умрёт ? Вполне возможно ;)

> 
>  DMM> а udev нужен в основном, чтобы обслуживать события появления
>  DMM> нового оборудования (занял вотчину hotplug), которое сейчас очень
>  DMM> часто стало подключаться и отключаться прямо во время работы
>  DMM> компьютера.
> 
> А сделать из этого следующий логический вывод?
> 
>  DMM> При этом и SysV и InitNG так же позволяют во время работы
>  DMM> компьютера поднимать или останавливать сервисы, так что их миссия
>  DMM> не заканчивается загрузкой.
> 
> for i in `seq 1 1000`; do service httpd2 stop & service httpd2 start & done
> 
> оставит систему в непредсказуемом состоянии.

а зачем ?

> 
>  DMM> Они же позволяют переключить уровень запуска, что вообще-то говоря
>  DMM> крайне редкая на desktop'е операция(мы же про desktop говорим?).
> 
> Нет.
> 
>  DMM> Какие события еще нужны?  То есть, какие по Вашему задачи могут
>  DMM> решить более "навароченные" системы инициализации на desktop?
> 
> 1. Обслуживание служб по событиям от железа (появилась wifi-сеть -
> подняли чего на неё навешано).

Этим занимается специализированный сервис.

> 2. Обслуживание служб по событиям от юзера (см. per-user gpg-agent или X11 в MacOSX)

Этим тоже.. в нашем случае - KDE/Gnome.

> 3. Обслуживание служб по другим любым событиям

Здесь согласен - могут быть службы, которые есть необходимость поднимать 
по событиям. Но это работает и сейчас и не приводит к каким-то серьёзным 
проблемам (пример - Bluetooth, который поднимается в udev).

> 
>  DMM> Более того, система запуска сервисов должна в идеале иметь
>  DMM> приличный и простой графический интерфейс управления, ведь не
>  DMM> собираемся мы обучать простых веб разработчиков премудростям
>  DMM> скриптования инит системы, чтобы они запросто поднимали
>  DMM> apache/mysql/что-то там, когда они необходимы, а не все время,
>  DMM> ведь так?
> 
> Это совершенно другой вопрос.

Все вопросы как-то связаны друг с другом. Наличие интерфейса управления 
службами необходимо.


> 
>  DMM> В случае init-ng я запросто представляю обязательную системную
>  DMM> часть записанной в system.runlevel, а опциональную в
>  DMM> default.runlevel, при этом GUI показывает все что может быть
>  DMM> добавлено/убрано в default.runlevel с описанием из
>  DMM> LSB-коментариев, это просто удобно и понятно. А как быть в случае
>  DMM> того же upstart?
> 
> Взять и написать. В чём вопрос?
> 
>  DMM> По-моему, такие системы пригодны только для ручного скриптования и
>  DMM> именно инициализации базовых системных сервисов (в которую
>  DMM> пользователю лучше не вмешиваться, так сказать обязательная
>  DMM> часть).
> 
> Необязательно.
> 
>  DMM>А вот более простые системы вроде init-ng решают проблему
>  DMM>параллельной загрузки и зависимостей простым и понятным способом.
> 
> Они решают какую-то малоинтересную задачу. Взять и распараллелить -
> слишком скучно.

Главное что бы это было весьма эффективно. Время загрузки системы 
конечно (для меня лично) не имеет никакого значения. Но всё ещё есть 
пользователи, которые каждый день выключают и включают компьютер.

Но им бы я предложил настроить suspend на disk.

> 
>  DMM> Да и со стандартом LSB очень неплохо стыкуются, по крайней мере не
>  DMM> вижу проблемы конвертора LSB -> init-ng или плагином научить
>  DMM> initng напрямую брать заголовки LSB.
> 
> LSB - не бох (c) LOR

LSB рулит. Чем меньше стандартов, тем лучше. Пускай это будет один стандарт.

А если взглянуть на жизнь более реально, то брать надо за основу "самый 
распространённый вариант". Например - посмотреть какие чаще всего 
скрипты распространяются со сторонними пакетами. В данном контексте я не 
говорю про качество этих скриптов, тут основная задача - что б работало, 
а не что б красиво.