systemd 201

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

Может, всё-таки, будем аргументы приводить

Аргументы к чему? К тому что можно и на баше пускалку сделать? Можно хоть на баше, хоть на руби, хоть на брейнфаке. Systemd написан на С, и это хорошо. И systemd един и универсален для всех дистров, в том числе благодаря тому, что он написан на С и является блобом, а не на баше и каждый городит свои костыли, несовместимые с другими.

И главное, systemd может запустить твой баш-скрипт.

сарказм

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

И главное, systemd может запустить твой баш-скрипт.

А баш может запустить блоб на C, и чё? Я уже спрашивал, но мне не ответили: где будут лежать такие скрипты, которые вызываются из юнитов в файловой иерархии?

Аргументы к чему? К тому что можно и на баше пускалку сделать? Можно хоть на баше, хоть на руби, хоть на брейнфаке. Systemd написан на С, и это хорошо. И systemd един и универсален для всех дистров, в том числе благодаря тому, что он написан на С и является блобом, а не на баше и каждый городит свои костыли, несовместимые с другими

Но ведь.. винда уже есть, зачем вам ещё одна?

Перечитал, переосмыслил, теперь он кажется просто глупым.

И systemd един и универсален для всех дистров, в том числе благодаря тому, что он написан на С и является блобом, а не на баше и каждый городит свои костыли, несовместимые с другими.

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

Но ведь.. винда уже есть, зачем вам ещё одна?

Та, которая есть меня не устраивает. Лицензией, политикой разработчика, концепцией разработки, отношением к пользователю, стабильностью, способами конфигурирования, способом установки софта. Да почти всем.

АПВС и с чего ты взял, что мне нужна ещё одна винда? Мне нужно удобное решение для запуска ОС, и я думаю, что системд им является.

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

В федоре есть каталог /etc/rc.d/init.d/ в котором лежат инит-скрипты, для которых ещё нет замены. ЕМНИП их там штук 6 в дефолтной поставке, и все без проблем запускаются системд. И даже LSB-заголовок системд понимает.

А баш может запустить блоб на C, и чё?

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

Тут кстати многие говорят про гибкость инит-скриптов, но вот хоть сколько-нибудь адекватного юз-кейса, с которым не могут справиться unit`ы systemd так и не предоставили.

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

Согласен, всё ещё может поменяться, да и я думаю, что системд таки форкнут. Но пока ситуация именно такова.

теперь он кажется просто глупым.

Жаль, а ведь я старался.

АПВС и с чего ты взял, что мне нужна ещё одна винда?

С того, что у вас подход «сделайте везде одинаково» противоречит духу опенсорса.

В федоре есть каталог /etc/rc.d/init.d/ в котором лежат инит-скрипты, для которых ещё нет замены. ЕМНИП их там штук 6 в дефолтной поставке, и все без проблем запускаются системд. И даже LSB-заголовок системд понимает.

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

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

И смело брать с баша тоже. О чём тут спор?

Тут кстати многие говорят про гибкость инит-скриптов, но вот хоть сколько-нибудь адекватного юз-кейса, с которым не могут справиться unit`ы systemd так и не предоставили

Тут кстати так никто и не сказал, чем заменить mysql'ный sanity_check в systemd. И уж давайте будем честными, и не будем использовать ответ «баш-скриптом».

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

«сделайте везде одинаково» противоречит духу опенсорса.

Не «сделайте везде одинаково», а «сделайте везде совместимо».

это всё-таки инит-скрипты, а не подпорки для юнитов

Я так понимаю, что подпорки будешь писать именно ты, так что ты можешь их складывать куда угодно, например в init.d. В дефолтной поставке их нет.

это явление говорит не в пользу systemd само по себе

Ну кому как, а мне совместимость кажется явным плюсом.

mysql'ный sanity_check в systemd.

Понятия не имею, что такое mysql'ный sanity_check, я так понял, что это проверка работоспособности mysql. И это явно не задача инита, а задача самого mysql (утилит для него). Так что таки да, нужна отдельная прога (например на баше), которая будет это делать. Не вижу в этом никакого криминала.

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

Возможность такая присутствует, но думаю, что до юнитов таки не дойдут. Хотя кто их знает. Поживем - увидим.

Надо base.xml
xml

ну ты понел

Я ничего не понял. Я сам ввел этот файл в xkeyboard-config. И он является основным местом хранения мета-информации.

Не «сделайте везде одинаково», а «сделайте везде совместимо»

Юниты не будут совместимы точно так же, как и баш-скрипты, прими это.

Я так понимаю, что подпорки будешь писать именно ты, так что ты можешь их складывать куда угодно, например в init.d. В дефолтной поставке их нет.

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

Ну кому как, а мне совместимость кажется явным плюсом

Причём тут совместимость? Я о том, что до конца на systemd так никто и не переехал, зато шума то.

Понятия не имею, что такое mysql'ный sanity_check, я так понял, что это проверка работоспособности mysql. И это явно не задача инита, а задача самого mysql (утилит для него). Так что таки да, нужна отдельная прога (например на баше), которая будет это делать. Не вижу в этом никакого криминала.

Ну как сказать, если я запускаю mysql, а мне в консоль говорят, что вы не создали базу и не мигрировали, и мне не надо лезть в лог, чтобы понять, что что-то не так, по-моему, это прекрасно.

Юниты не будут совместимы точно так же, как и баш-скрипты, прими это.

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

которому можно сделать workaround через доп проверку в скрипте

Я не знаю, как поступят в дистрах, могу предложить следующее:

Скрипт с проверкой идет как утилита в составе пакета, устанавливается в /usr/bin или туда, куда устанавливается исполняемый файл пакета, а потом вызывается в ExecStartPre. После исправления бага это все выпиливается с обновлениями. С инит-скриптами ситуация была бы по сути той же, только менее наглядной.

до конца на systemd так никто и не переехал,

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

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

Сейчас проверить не на чем, но есть предположение, что при неудачной попытке запуска руками, системд вывалит вывод не запустившегося сервиса, в котором будет написано ровно тоже. Если это не так, то обо всём произошедшем тебе расскажет systemctl status mysqld.service или journalctl -u mysqld.service, заметь без всякого копания.

И разумеется всё через так ненавистные бинарные логи.

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

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

С инит-скриптами ситуация была бы по сути той же, только менее наглядной.

Это, конечно, на вкус и цвет, но фи же! Нафига мне этот хлам в PATH?

Вообще, мне абсолютно пофиг на systemd, пусть будет, те дистрибутивы, что я использую, на него переходить не планируют, что намекает на то, что дистрибутывы _для себя_ я выбрал правильно. Не радует только, что оно лезет везде, куда его не просят, что, конечно же, сказывается на всех, вот это печалит. Если бы не это, пользуйтесь вы там хоть launchd, кому какое дело? А так получается виндовс вей, зачем оно здесь?

Нафига мне этот хлам в PATH?

Ну в принципе согласен, в PATH он лишний, можно в init.d засунуть. Но в целом мне пофиг.

мне абсолютно пофиг на systemd, пусть будет

Ну и хорошо.

Не радует только, что оно лезет везде, куда его не просят

Ну если брать самое вопиющие, завязку Gnome на systemd, и подготовку подобной системы для KDE, то технически оно вполне оправдано, ИМХО. А в остальном, люди просто не хотят делать работу дважды, так что если у тебя нет systemd, будь добр, предоставь аналоги и поддерживай их сам. Тут ситуация как с открытыми дровами на видео, kms и его отсутствием в разного рода BSD.

так что если у тебя нет systemd, будь добр, предоставь аналоги и поддерживай их сам

Так делается всё так, чтобы это было максимально затруднено. Вот зачем, скажите мне, завязывать init на конкретный journal?

можно в init.d засунуть

Им там не место.

В видео LVEE 2012, Why Systemd? всё выглядит красиво. Такой вопрос - а конфиги так и будут в стиле ini файлов или их сделают модными мозголомными xml? xml как бы не предназначен для человеческого редактирования.