давайте разберемся, так ли плох systemd?

не читал, но осуждаю

fixed

В треде светанулись любители править бут скрипты. Мне вот интересно. Как вы их потом с апстримом мержите?

никак.

кстати, как?
то есть если запустить иксы, потом пользовательские приложения, потом сессию гнома/kde и потом их прибить, процессы висеть не останутся?

вроде ж эмуляция была для софта какая-то?

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

По сравнению с BSD-style init я не увидел в нем никаких преимуществ. Распараллеливание запуска можно сделать, просто отправив сервис запускаться в фоне. Если сервисы зависят друг от друга - написать rc-скрипт, который запускает их по очереди, и отправить в фон.

4.2 Почитай хотя бы статью, что я привел. Там как раз решается возможность запускать _все_ сервисы параллельно, вне зависомости от их «зависимостей».

да, но пара debian-specific багов как-то в своё время кинулась в глаза и было не очень приятно

Мне вот интересно. Как вы их потом с апстримом мержите?

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

А мне казалось что в арче уже системд. Не?

Проблемы - случайно не апдейтнуться. Или не не апдейнтуться. Ну итп

Толстые тролли не нужны.

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

Ну-ну, в 80-х не была тормозной, а в 2012 вдруг стала? Смищно.

Есть такая штука, называется комбинаторный взрыв. Представим себе идеальную систему на скриптах bsd init, в которой куча компонентов и все интегрируются друг с другом и учитывают самые разные ситуации (так не бывает, но допустим). Увеличим число компонент в 2 раза. Во сколько раз увеличится число случаев, которые надо предусмотреть? Правильно, оно испытает комбинаторный взрыв - вместо n! комбинаций будет (2n)!

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

А вообще такие вещи доказываются и опровергаются профайлерами или, альтернативно, подробными теоретическими выкладками размером не меньше чем с исходник обсуждаемой программы. Заявлять «на 10 не тормозило, а на 20 тормозит, вы што белены объелись?» - это не серьёзно. Кнут вас за такое прутом бы выстегал.

Вот уж куда, а в дебри системы инициилизации на нормальной ОС лезть не приходится, потому как всё просто работает.

Никогда не бывает, чтобы все просто работало. Каждая система на разных машинах требует персональной настройки. Ладно когда парк одинаковых серверов в одном и том же окружении (хотя чаще всего и это миф). А для пользовательских машинок существует в пределе бесконечное количество конфигураций (сочетание железа + подключение к сети + уровень пользователя + потребности пользователя), поэтому не давать пользователю лезть в дебри системы категорически воспрещается.

Например, с BSD-style init я легко добавил скрипт, изменяющий мак-адрес, в автозагрузку. Также я добавил туда скрипт, перекопирующий содержимое нужного каталога в /dev/shm.

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

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

А мне казалось что в арче уже системд. Не?

не.

Проблемы - случайно не апдейтнуться.

apt-pinning решает,

Или не не апдейнтуться

а пересборку можно вполне себе автоматом забабахать

Просто, если в случае с шелл-скриптами всё это таки можно сделать малой кровью, то с системд придётся ещё больше извращаться

куча компонентов и все интегрируются друг с другом и учитывают самые разные ситуации (так не бывает, но допустим).

вот потому что так не бывает, не бывает и

Правильно, оно испытает комбинаторный взрыв - вместо n! комбинаций будет (2n)!

Я пробовал systemd.

Там как раз решается возможность запускать _все_ сервисы параллельно, вне зависомости от их «зависимостей».

Никто не мешает в rc.conf пририсовать у всех сервисов собачку и они все запустятся параллельно, вне зависимости от зависимостей.

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

Просто, если в случае с шелл-скриптами всё это таки можно сделать малой кровью, то с системд придётся ещё больше извращаться

я обычно еще проще делал - просто не обновлял пакет initfiles или как там его :)

А вон чувак выше пишет:

Никогда не бывает, чтобы все просто работало. Каждая система на разных машинах требует персональной настройки. Ладно когда парк одинаковых серверов в одном и том же окружении (хотя чаще всего и это миф). А для пользовательских машинок существует в пределе бесконечное количество конфигураций (сочетание железа + подключение к сети + уровень пользователя + потребности пользователя), поэтому не давать пользователю лезть в дебри системы категорически воспрещается.

Собсна системдэ позволяет и с конфигурациями справиться, и в дебри не лезть каждому себе систему настраивать. Но ССЗБ они и в африке они же.

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

так оно уже давно такое в init было, СЮРПРИЗ.

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

К тому же systemd решает проблему отваливающихся системных демонов, если такое случается.

Просто, скрипты загрузки - такие же компоненты ОС, как, скажем, какой-нибудь постфикс. По некоторым очевидным причинам «пользователи» чаще «исправляют» хрень в первом, а для второго предпочитают писать баг репорты.

Что из этого лучше - спорный вопрос, но мне кажется что второе. Круто, конечно, когда есть возможность что-то «исправить» на ходу. Но лучше если оно просто будет работать :D

Собсна системдэ позволяет и с конфигурациями справиться

Если для этого надо лезть в исходники, то это не называется _позволяет_.

не может systemd предусмотреть всякие возможные конфигурации, которых может захотеться.

Что из этого лучше - спорный вопрос, но мне кажется что второе. Круто, конечно, когда есть возможность что-то «исправить» на ходу. Но лучше если оно просто будет работ

А если не работает, и возможности исправить на ходу больше нет? Как тебе такой вариант?

А зачем читать, когда я пробовал systemd и оценил для себя последствия. Он сделан для того, чтобы отделить «специалистов» от «обычных пользователей», все запутав и усложнив, не более того.

Во-первых, bsd-style init позволяет не хуже распараллеливать запуск сервисов. Во-вторых, он проще в настройке. В-третьих, на современном железе systemd не дает никакого выигрыша, потому как сервисы запускаются и так быстро.

А зачем читать, когда я пробовал systemd и оценил для себя последствия.

Затем, что если бы ты прочитал, то ты бы такого не говорил:

bsd-style init позволяет не хуже распараллеливать запуск сервисов.

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

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

Ну, так что бы совсем нет - такого не бывает. Бывает что это очень сложно. В системе инициализации так даже и сложно придумать, что должно быть, что сложно было бы исправить, да так, что бы и было очень нужно. Особенно когда к ней есть исходники :D

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

я пока не вижу, как systemd решает проблемы на корню.

Более того, все что я вижу - это лишь то, что он _может_ (но не факт, что _должен_) усложнить возможность конфигурации. Пока что в этом треде никто толком не разъяснил, как именно осуществляется конфигурация systemd для старта процессов, и как это отразиться на текущем положении дел.

Ну, так что бы совсем нет - такого не бывает. Бывает что это очень сложно.

для меня вариант «сложно» эквивалентен варианту «невозможно». Причем я вполне могу считать себя очень продвинутым пользователем.

>в 80-х не была тормозной
Тогда просто никто никуда не торопился :}

>Ссылки для сравнения я уже приводил.
Фигню какую-то ты приводил.

Но лучше если оно просто будет работать :D

сразу - не будет, так что лучше когда есть возможность на коленке подправить, и писать багрепорт уже с патчем

Полезная фича systemd — попытака предоставить какой-то API к системе управления и базового наблюдения за службами

Specific баги они везде есть. Ничего не поделать.

Да профит понятен. Просто он не особо ощутим в условиях нормального железа и системы с небольшим количеством демонов. А если демонов катастрофически много - это проблема самой ОС, а не системы запуска.

Вся разница в исправлениях скриптов и исполняемых файлов при наличии исходников - в копировании output во втором случае ;)

Вариант про «сложно» — это когда нужно реверсить.

Да профит понятен. Просто он не особо ощутим в условиях нормального железа и системы с небольшим количеством демонов. А если демонов катастрофически много - это проблема самой ОС, а не системы запуска.

существуют еще и нетпуки :) А демонов достаточно и 20, что не есть много.

Потом - можно более поздно монтировать ФС.

А есть измерения, что на средней системе systemd дает реальный прирост скорости загрузки по сравнению с другими хорошо настроенными init-системами?

«Не хуже» - не значит «аналогично». Это значит, проще и с примерно той же скоростью.

Вариант про «сложно» — это когда нужно реверсить.

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

давайте разберемся, так ли толст dikiy?

починил название треда

системе systemd дает реальный прирост скорости загрузки по сравнению с другими хорошо настроенными init-системами?

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

Ну тогда исправлять что-либо — вообще сложно. Нужно же сначала понять почему оно поломалось. А для этого надо

копаться в манах
разбираться в сырцах
проверять что-то

Вся разница в исправлениях скриптов и исполняемых файлов при наличии исходников - в копировании output во втором случае ;)

Вариант про «сложно» — это когда нужно реверсить.

Глупости. Подумаешь, преобразовать input.

Поттеринг сообщал о 2 сек загрузки с SSD, от граба до рабочего стола. Инженеры интел чуть позже подтвердили. Тем временем, лучший результат винды восьмой на сферическом железе - 8 секунд, и это ещё с чистым реестром, без дров видяшки и других 3rd party вещей, без которых она просто не заработает.

Я считаю, что это успех. И возможность запускать кучу демонов, и объединение устаревших демонов - это тоже успех.

20 - это много.

У меня, например: DAEMONS=(syslog-ng acpid fakemac @network crond @dbus laptop-mode @alsa @cupsd @cpufreq @mpd)

Т.е. 5 запускаются последовательно, остальные в фоне.

Если придется заиметь около 20 демонов - я попробую написать systemd хвалебную одну.

Не понял, что именно глупости ? :]

Поттеринг сообщал о 2 сек загрузки с SSD, от граба до рабочего стола. [...] Я считаю, что это успех.

Ты считаешь, что это успех, или считаешь, что это успех systemd?

Не понял, что именно глупости ? :]

Подумай.

Реверсить - это не сложно? Ну, может быть Или разницы больше чем копирование выхлопа компилятора?

У меня грузится с SSD от граба за 1 секунду без иксов, затем еще секунду стартуют иксы, BSD-style init.

Хотя, конечно, я не пользуюсь тяжеловесными DE, которые требуют десятки фоновых служб. Поэтому мне сложно сравнивать. Но для меня systemd не дает никакого буста производительности, это точно. На старом ноуте в аналогичном раскладе даже медленнее работал.

Мистер Джобс

Так он же умер? :3

А профит от systemd именно в том, что не надо никаких зависимостей прописывать и париться по этому поводу.

Чего? И куда волшебным образом делись зависимости? Типа если зависимости захардкодили в бинарь, то парится не надо, так штоле? :D

К тому же systemd решает проблему отваливающихся системных демонов, если такое случается.

sysv init мог это уже много лет. Но от этого отказались.