Systemd 29

> systemd такое легко без скриптов и костылей может.

Это потому, что systemd включает в себя эти костыли (и еще много других).

>Гипотетический проход по списку останавливается до окончания запуска local_fs, потом - до окончания запуска network, потом пускает в параллель serv1 и serv2,

Хехе - а serv1 зависит от serv2 и они гипотетически запускаются друг за другом :) Не - в некоторых случаях это даже даст какой-то выигрышь :)

> Хехе - а serv1 зависит от serv2

Хехе, это ты сам только что придумал. В моем примере они не зависят.

> И как ты представляешь при таком раскладе за один проход запустить паралльно процессы с взависимостями ?

Порядок их просмотра задан их именами. Никаких проблем нет. Просто смотрим сверху вниз список из /etc/rc2.d/S* вида:

S00localfs
S10iptables
S15network
S20syslog
S25remotefs
S30dbus
S40sshd
S50vsftpd
S60httpd
...

В приведенном выше примере запуск будет выглядеть так:

S00localfs
S10iptables  S15network
S20syslog  S25remotefs
S30dbus S40sshd S50vsftpd S60httpd
...

> Ясно, без костылей на баше нельзя. А systemd такое легко без скриптов и костылей может.

А systemd такое делает либо таким же скриптом, либо с собственным костылем. Я уже спрашивал раньше по треду как сделать монтирование... Костылей в ответе было в два раза больше. У systemd полный /lib этих костылей, а некоторые еще засунуты в /bin и /usr/bin.

Обычный шелл, в который встроены команды вроде grep и cut.

Scheme shell спасёт отца прусской демократии.

весь интернет дружно сказал «НАХ!».

Ты ошибаешься. Фанатиков в сети много, но на «весь интернет» они не потянут.

>Я уже спрашивал раньше по треду как сделать монтирование...

Это там, где шифрованный раздел? Разработчик почему-то посчитал ненужной опцию ExecStartPre= или аналогичную в юнитах-маунтах. Поэтому было:

Костылей в ответе было в два раза больше.

У systemd полный /lib этих костылей

Когда это всё в одной программе, это не костыли.

Так тут S50vsftpd S60httpd можно было запускать вместе с S10iptables S15network а у тебя они ждут ненужные сервисы, а вдруг они по 30 минут запускаются ?

>> весь интернет дружно сказал «НАХ!».

Ты ошибаешься.

Попробуй это доказать %)

> А теперь представь - что твой скрипт уже давно обошел список за время пока поднимался net и оба serv1 и 2 оказались в очереди, как они оттуда параллельно запустятся при одном проходе ?

Один проход был по списку файлов в rc.d для того, чтобы сформировать очередь. После того, как любой из выполняющихся в очереди сервисов завершается, init-демон (или скрипт) удаляет из очереди этот сервис и снова делает по этой очереди один проход, запуская то, что теперь можно запустить.

На самом деле можно не делать полный проход по всей очереди, а сразу запустить только зависимые процессы, но мне лень объяснять, как строится граф и выполняется его обход. Так что для простоты будем считать, что мы проходим по всем сервисам очереди.

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

В процессе каждого прохода выполняются все те же требования, что выполнялись при построении очереди - сервисы, которые можно запустить параллельно, запускаются параллельно.

Не - тут я ошибся, так нельзя, но смысл в том что не обязательно сервисы с большими номерами будут зависеть от предыдущих с меньшими, а ждать будут.

>Так тут S50vsftpd S60httpd можно было запускать вместе с S10iptables S15network?

Нельзя. S50vsftpd и S60httpd не могут запускаться параллельно с S10iptables, потому что иначе есть риск поймать момент, когда S50vsftpd запустился, а S10iptables еще нет, и мы получим доступ к ftp-серверу в обход файрвола. Это недопустимо. Но без явных зависимостей ты бы этого не узнал. Зависимости рулят. :)

> но смысл в том что не обязательно сервисы с большими номерами будут зависеть от предыдущих с меньшими, а ждать будут.

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

Это можно строго доказать. Любой набор сервисов должен запускаться на одноядерной машине, верно? Значит для любого набора сервисов существует такой порядок, при котором он корректно запустится на одноядерной машине. Возьмем сервисы в этом порядке и пронумеруем их. В результате мы получим, что большие сервисы зависят строго только от меньших. А на многоядерных машинах мы сможем запускать их параллельно.

>Такая система, с одной стороны, полностью обратносовместима с sysvinit, не добавляет ни единой новой сущности, и не ломает ни одной существующей утилиты.

Один проход был по списку файлов в rc.d для того, чтобы сформировать очередь...

bla-bla-bla. Дерзай, 3.14здеть не мешки ворочать.

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

>В случае сервисов всегда можно упорядочить их так, чтобы большие зависели только от меньших.

Такой изврат намного хуже элегантного systemd :-)

> Лично видел пользователей сети, которые не являются фанатиками. В общем-то таких даже большинство, почти всем пофиг на чём написана программа

Людям, от которых зависит, попадет ли программа в дистрибутив, это не пофиг // К.О.

tailgunner

Людям, от которых зависит,

Т.е. ты уже не говоришь за всю сеть? Это хорошо.

tailgunner

попадет ли программа в дистрибутив

Не все мантейнеры --- фанатики. По крайней мере не во всех дистрибутивах.

> Т.е. ты уже не говоришь за всю сеть?

Говорю, конечно. За весь значимый состав сети.

> Когда это всё в одной программе, это не костыли.

Да сколько же можно повторять. Когда все в одной программе - сама программа становися костылем. Вроде, всем очевидно, что объединять httpd, gdm, udev и git в одном демоне - это маразм. Так почему же так хочется объединить init, xinetd, udev, atd и dbus в одном systemd? (что dbus еще не в systemd? ничего, будет...)

Разные программы обслуживают разные задачи. init-демон обслуживает запуск системы и только его, демон udev обслуживает устройства и только их, xinetd обслуживает сокеты, только сокеты, а atd обслуживает только запуск по времени. У них разные задачи. Строго разные. Не пересекающиеся ни в одной точке.

Если вдруг для какой-то задачи понадобится использовать возможности нескольких демонов - не проблема, внешняя программа/скрипт выполнит нужную задачу.

Это - основа Unix. Когда программе надо нарисовать на экране окошко - она использует GTK, а не переписывает его с нуля. Когда нужна библиотека для быстрых вычислений с высокой точностью, использется libgmp, а не пишется свой вариант. И при написании gtk-калькулятора любой нормальный программист возьмет библиотеки GTK и libgmp и напишет нужные вызовы.

А невменяемый программист скажет, что GTK устарел, и напишет собственный GGK, затем добавит в этот GGK свою математическую библиотеку и начнет всех убеждать, что для математики лучше использовать GGK а не libgmp, потому что в GGK можно сделать почти все то же самое, что в libgmp, но еще там можно рисовать окошки.

Ничего не напоминает?

>Ничего не напоминает?

Напоминает - X Windows ;-)

> Дерзай, 3.14здеть не мешки ворочать.

Уже подумываю об этом. Надо лишь убедиться, что этого еще никто не сделал, чтобы не стать очередным Леннартом. К тому же всегда интересно послушать конструктивную критику на ЛОРе...

*** ugoday уходит судорожно искать слово «значимый» во фразе:

tailgunner

весь интернет дружно сказал «НАХ!».

> Напоминает - X Windows ;-)

Кто из разрабов X Window System переписывал существующие библиотеки, а потом уговаривал других перейти на их использование? И что это были за библиотеки?

> Такой изврат намного хуже элегантного systemd :-)

«Такой изврат» - это почти строгое доказательство корректности системы. Это не реализация, и даже не намек на нее, это формальная математическая логика. «Элегантный systemd» лучше логики? Хотя, в чем-то это верно. Логики в systemd не наблюдается. :)

>Кто из разрабов X Window System переписывал существующие библиотеки, а потом уговаривал других перейти на их использование? И что это были за библиотеки?

Я лично не знаком с разработчиками - но то что там счас творится - это большая куча медленного навоза которая как побочное явление умеет еще что то рисовать на экране ;-)

> *** ugoday уходит судорожно искать слово «значимый» во фразе:

Ах да, еще я не имел в виду, что роутеры умеют говорить %)

> Надо лишь убедиться, что этого еще никто не сделал,

Сделали.

>Уже подумываю об этом.

Бесполезно. Даже если твоя поделка будет в 100 раз лучше, всё равно будут юзать леннартовские костыли. И пропихивать их во все дистры.

Сцылку, пожалуйста. :)

> Сцылку, пожалуйста. :)

Погрепай мои постинги в этом топике - будет тебе 2 ссылки.

Боюсь, чтобы понять чего ты там имел в виду, мне понадобится помощь хорошего телепата. Есть один на примете, но он в отпуск уехал.

> Боюсь, чтобы понять чего ты там имел в виду, мне понадобится помощь хорошего телепата.

Тогда объясняю простым языком, специально для лиспотроллей: если бы systemd был написан на Лиспе, его бы не запихивали в дистры с такой силой. Если бы он еще и требовал писать юниты на Лиспе, его вообще можно было бы не принимать во внимание.

>Боюсь, чтобы понять чего ты там имел в виду, мне понадобится помощь хорошего телепата.

ugoday

Юзернейм как бы намекает ;)

> Погрепай мои постинги в этом топике - будет тебе 2 ссылки.

Это? http://wiki.debian.org/LSBInitScripts Сходу показалось, что там обсуждается только выдача сервисам номеров по зависимостям. Ищу реализацию.

Тогда объясняю простым языком

Другой разговор, гораздо лучше чем загадки и полунамёки.

если бы systemd был написан на Лиспе, его бы не запихивали в дистры с такой силой

Странное утверждение, а главное --- обоснованное.

писать юниты на Лиспе

юниты на С это конечно гораздо-гораздо лучше.

Парадокс, но я терпеть ненавижу когда собеседник ленится/не умеет явно сформулировать свои тезисы и мне приходится клещами из него вытаскивать чего же он конкретно хотел сказать.

>> Погрепай мои постинги в этом топике - будет тебе 2 ссылки.

Это? http://wiki.debian.org/LSBInitScripts

http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot - это вторая. Первая - simpleinit.

> юниты на С это конечно гораздо-гораздо лучше.

Ага. Си знает больше народу. Впрочем, «юниты на Си» - это, насколько я могу судить, миф.

>http://wiki.debian.org

Кстати - а откуда идут мифы о стабильности дебиана ? В последний раз когда мне нужно было ставить что-то дебианоподобное я выбрал убунту - потому что установилась она без проблем. Я сначала купился на мифы и начал с дебиана - на обоих ноутбуках дебиан не установился - это был образ netinstall версии 5.06. Он долго качал пакеты устанавливал а в конце зависал намертво, после перезагрузки была нерабочая система. Такие дела.

> Кстати - а откуда идут мифы о стабильности дебиана ?

От людей, у которых он стабильно работает.

начал с дебиана - на обоих ноутбуках дебиан не установился - это был образ netinstall версии 5.06. Он долго качал пакеты устанавливал а в конце зависал намертво, после перезагрузки была нерабочая система. Такие дела.

Не понравился ты Дебиану. Видно, не крепок ты в вере. Молись Столлману, донейти свободному софту - может, и понравишься ты Дебиану, и установится он на твои ноуты.

>Вроде, всем очевидно, что объединять httpd, gdm, udev и git в одном демоне - это маразм. Так почему же так хочется объединить init, xinetd, udev, atd и dbus в одном systemd?

Ты мне лучше скажи, а какого чёрта команды pidof и mountpoint делают в пакете sys-apps/sysvinit? Какая связь init, pidof и mountpoint, что их запаковали в 1 пакет? Это такой же маразм, как «объединять httpd, gdm, udev и git в одном демоне».

Си знает больше народу

Я заранее боюсь того что будет, когда это «больше народу» ломанётся писать на С загрузочные скрипты.

> Я заранее боюсь того что будет, когда это «больше народу» ломанётся писать на С загрузочные скрипты.

Да понятно... у лисперов и должны быть всякие прикольные фобии.

>Я заранее боюсь того что будет, когда это «больше народу» ломанётся писать на С загрузочные скрипты.

А я боюсь если бы их писали на липсе - загрузка до сих бы только до процесса init доходила ;-)

>какого чёрта команды pidof и mountpoint делают в пакете sys-apps/sysvinit?
Этот вопрос нужно задавать ментейнерам твоего дистрибутива.

>Этот вопрос нужно задавать ментейнерам твоего дистрибутива.

Это во всех дистрибутивах.

> Это во всех дистрибутивах.

В Debian pidof в sysvinit-utils, mountpoint - в initscripts.

>В Debian pidof в sysvinit-utils, mountpoint - в initscripts.

sysvinit-utils собирается из исходников sysvinit. В дебиане любят разбивать один пакет на много кусков.

Но факт в том, что если взять апстримовые исходники SysVinit, собрать и установить, то pidof и mountpoint таки в пакете вместе с init. Значит, SysVinit объединяет в себе совершенно несвязанные программы. Как сказал анонимус, «объединять httpd, gdm, udev и git в одном демоне - это маразм». Объединять pidof, mountpoint и init в одном пакете - это тоже маразм. Так что этот ваш святой SysVinit ещё хуже, чем вы себе представляете systemd. В systemd хоть прослеживается связь между компонентами, а какая в SysVinit связь между pidof, mountpoint и init?