>>>> Не понимаю аргумента с худшими проблемами.
>>> Да сколько угодно. Меньшая прозрачность системы, сложность отладки и т.п.
>> Прозрачность init-скриптов в дистрибутивах вызывает у меня сомнения. Особенно, если учесть
>> что я не гуру вообще, и в sh в частности.
> А у меня - нет. Как и для любого администратора -
> POSIX-shell это часть базовых знаний. Дело прежде всего даже не
> в стандартных утилитах, а в нормальном скриптовом языке, логика которого прозрачна
> и понятна.А для меня разница между sh и service файлами минимальна. Не так уж они сложны, не преувеличивайте. Человек, запомнившему порядка 50 команд с 3-5 ключами + форматы ряда разношёрстных файлов, запомнить 10-20 говорящих самих за себя директив не составит труда. Большего для подавляющего большинства сервисов не нужно.
>> Ключик запуска я конечно поменять смогу, но дебри юнитов или init-скриптов
> Вам, как пользователю - нужно просто открыть баг в дистрибутиве, и не
> лезть куда не след. Что с sysvinit, что systemd.
Вот и я о чём. Для большинства пользователей и разработчиков ничего не изменится, они заметят только то, что система стала послушнее и менее тугодумна.
>>> Главное, забыть что существуют разные способы IPC...
>> Главное не забыть, что мы говорим о сервисе и его клиентах. Между
>> сервисом и клиентом трудно представить более подходящий тип IPC, чем сокет.
> "Трудно, но можно."
Если вы таки умудрились такое сотворить, то даже в этом случае у вас есть возможность успешно запустить и управлять таким сервисом через systemd.
>> Остальные IPC, такие как shared memory и семафоры(есть еще что-то в
>> linux, что я забыл?)
> Забыли, конечно. atd вон - никаких сокетов не создает, а поди
> кому-то потребуется. Точно также, как и cron (а, возможно, мы
> захотим @reboot пускать под самый конец загрузки?).
А что, я где то говорил что сервис для systemd должен обязательно использовать сокеты? Или что socket-based активация - панацея? Чтобы реализовать все указанные вами задачи в systemd есть средства.
>> Да, к сожалению не все сервисы можно стартануть независимо. Однако то, что
>> в конфигурации запуска некоторых сервисов зависимости можно не указывать - положительный
>> фактор, который уменьшает сложность поддержки системы в целом.
> Или отрицательный - который увеличивает ее неоднородность и уменьшает прозрачность администрирования.
Не надо пытаться меня убедить, что система зависимостей в sysvinit-based системах более прозрачна. Ничего у вас не выйдет. Бардака там больше, стандартизации меньше.
>> К тому же есть возможность собрать dbus довольно
>> аскетичным способом, который сведет возможность появления дырки в безопасности по вине
>> dbus к минимуму.
> Если возможность только "есть" - видимо, ей не пользуются. Или как?
> Почему вы столь уверены, что что-то работает, если этим практически
> не пользуются? А в числе пользователей - разработчики да толпа
> мартышек (99% пользователей десктопа)...
Ваше отношение к пользователям обозначено. А практически не пользуются - сейчас ни гном ни кде чихнуть нормально не могут без dbus. Повторюсь - dbus всего лишь IPC, не больше и не меньше и был использован чтобы не изобретать велосипед. Да, изначально писалось с мыслями о десктопе, однако область применения его совсем им не ограничена, о чем сами разработчики и указывают.
>>>> Причем тут роль, которую выполняет компьютер? не знаю, чем может
>>>> помешать d-bus, даже на сервере.
>>> Бесполезностью. Лишними проблемами с безопасностью.
>> Если на сервере стоит systemd, то dbus не бесполезен. Насчет безопасности выше.
> На счет "полезности" - еще выше. Мы уже прошлись по всяким
> on-demand запускам сервисов и т.п. х-не. Выяснили, что подобная блажь
> на сервере *не нужна*.
Ничего мы не выяснили. Вы опять никаких объективных аргументов против не привели, кроме субъективных оценок и неясной боязни пары зависимостей.
И кстати, чтобы собрать минимально рабочую систему с нуля с systemd необходимо в несколько раз меньше базовых пакетов(порядка 10, против ~50). Одна из причин создания systemd - это shell-free boot. Это к вопросу о простоте sysvinit, минимализме, unix-way и прочее.
>> Нет, не всё. Во первых, вы сами привели примеры тех демонов, для
>> которых on-demand активация довольно странное решение
> А для каких - не странная. Что есть на сервере: apache,
> sshd, postfix, nginx, sendmail, etc. Честно говоря, аргументы выше работают
> для всего, что мне приходит в голову добавить в этот список.
Ну тогда не используйте ненужный вам функционал и будет вам счастье. Я уже устал это повторять.
> Может вы перестанете говорить загадками - и укажете такие, для которых "не
> странно"?
Сервис для работы например какого-нибудь hot-plug устройства, на вскидку, или просто ресурсоемкий, редко используемый, сервис. Да, не серверное применение, подходит скорее для планшета, десктопа, embedded систем, но в отличии от вашего решения, systemd одинаково хорошо отработает во всех случаях.
>> И systemd тут ни при чём, sysvinit никак вас
>> не спасёт. И в случае с sysvinit, и с systemd после
>> перезагрузки с неверным конфигом вы получаете нерабочий сервис.
> Спасет. См. ниже.
> А в случае sysvinit - *сразу после плановой перезагрузки*. Т.е. в
> четко известное "время и место". Есть разница?
Если вы проверяете работоспособность конфига сервиса перезагрузкой системы - мне вас искренне жаль. И в случае с удалённым сервером - не спасет вас sysvinit. В остальных - не вижу проблемы, изменили, пнули сервис, чтобы тот перечитал конфиг, проверили работоспособность, наткнулись на проблемы - исправили. И опять же, это не обязанность init-системы следить за корректностью конфигов, а прямая ваша обязанность как администратора. Если вы с этим спорите - вы непрофессиональны.
> Вот такой вот "принцип" и "плагины". И вы еще удивляетесь, что
> люди не в восторге от "архитектуры" systemd?
Конструктивной критики архитектуры как не было, так и нет.
>>> Ну вот когда *таких* ошибок не будет вовсе - можно подумать и о включении в дистрибутивы.
>> Пока не будет пользователей - не будет ошибок. Release often, release early?
> Это не про софт для задач такого уровня. Поспешишь - людей
> насмешишь.
Вспомните что было, когда udev только внедрялся. Сколько было вони, грязи. И недоработок. Где теперь тогдашние борцы за unix-way размахивающие портянками shell скриптов для монтирования флешек, кричащих что udev не нужен, fstab наше всё? Сейчас происходит похожее, только с systemd. История нас рассудит вобщем.
>>>>> Ну-ну. Багтрекеры дистрибутивов посмотрите...
>>>> не ковырялся.
>>> Вот-вот...
>> По логике тут должна быть ссылка. Жду.
> см., к примеру, http://bugs.debian.org/ Пакет найдете самостоятельно?
довольно странно указать дистрибутив, в котором о systemd идёт речь постольку-поскольку. А вот на форуме арча много тем с systemd и solved в заголовках. Проблемы есть, но они решаются.
>> Тогда будьте добры, в доказательство своих слов, приведите пример, когда цикл(да и
>> вообще скрипт со сложной логикой) при старте сервиса необходим.
> $ grep 'for .*in' /etc/init.d/*|wc -l
> 94
любой скрипт пожалуйста, а не статистику использования for и while.
>> Давайте обойдёмся без ярлыков. Я не являюсь фанатом, я лишь пытаюсь понять
>> причины ненависти к systemd.
> Я не испытываю "ненависти". Для меня - это просто плохое, негодное
> ПО. Почему - пытаюсь вам объяснить.
Пока у вас плохо получается.
>> А домашние задания оставьте при себе.
> Т.е. собственную точку зрения доказать на примере - не можете?
Если уж вам так это важно - httpd.service из арча:
[Unit]
Description=Apache Web Server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=forking
PIDFile=/run/httpd/httpd.pid
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl graceful-stop
ExecReload=/usr/sbin/apachectl graceful
PrivateTmp=true
LimitNOFILE=infinity
[Install]
WantedBy=multi-user.target
Даже мне понятна практически каждая строчка.
>> Видимо, профпригодные администраторы всосали manы по шеллу и стандартным утилитам с молоком матери?
> На этапе обучения. Но командная оболочка и системные утилиты - имеют
> куда больший спектр применений, чем инициализация. Вот почему замена этому
> обучению на "другое" (а почитай-ка маны systemd) - не катит, ваша
> ирония неуместна.
Командная оболочка однозначно не должна заниматься процессом загрузки системы. Не самый лучший для этого инструмент, использовавшийся только из-за отсутствия достойной альтернативы.
>>> [...] а будут - юниты для systemd. "Простота" написания оных - мифическая, как вам указали.
>> Ничего вы мне не указали. Только общие фразы.
> Где юнит для апача, как вас выше просили? Пупок развязался написать?
> То-то.
Выше. Умерьте ваш пыл и нравоучительный тон.
>> К тому же особого бардака в init-скриптах вроде нет, просто у каждого дистрибутива они
>> отличаются координально, что вносит некий диссонанс.
> Этот "диссонанс" правильно называется - бардак.
В пределах одного дистрибутива всё ок. В пределах одной системы (systemd) скорее всего тоже будет все ок.
> Если вы даже "не можете придумать" - откуда взялся квантор сущестования?
> Выглядит уже нагло, извините...
Я ответил ниже.
>> "Primarily it has two intended use cases: to allow the user to
>> temporarily enter a specific state such as "Emergency Shell", terminating current
>> services, and provide an easy way to return to the state
>> before, pulling up all services again that got temporarily pulled down."
> Ага. А в sysvinit для этого достаточно сказать telinit. А
> все почему? Потому что кто-то запускает "on-demand", без жестко прописанных
> зависимостей и т.п. всякую *****, а потом геройски решает проблемы, которых
> можно было бы не иметь вовсе...
Для фукнционала аналогичного sysvinit, в systemd тоже достаточно сказать telinit. Но также есть возможность сделать это немного по другому, что обусловлено дополнительными возможностями systemd. Вот и всё. И без этого функционала никто не стал бы начинать systemd, ибо тогда получился бы тот же sysvinit.
>>> Получается излишняя сложность, нет? Если есть и плагины, и возможность запуска сценариев - может что-то лишнее?
>> Думаю, не весь функционал systemd можно или целесообразно реализовать в рамках сценариев.
> Ну может и ну его, к бесу, этот "функционал", не? Собственно,
> такое отношение к "функционалу" и пугает в первую очередь. Как
> клептоман - тащим первую понравившуюся идею, разберемся потом...
Каждый суслик в поле агроном. Не слышите меня, прислушайтесь к другим. Неужели вы всерьёз думаете, что в rh работают люди, хуже вашего разбирающиеся в архитектуре ПО, linux и прочем? Если бы с systemd всё было так плохо - не думаю, что он так активно проникал не только в rh-проекты, но и в другие, совершенно чуждые rh дистрибутивы. Этот функционал не брался с потолка, он возник в процессе анализа существующий проблем подобных систем и запросов пользователей, а не мартышек. Об этом не раз говорилось в рассылках systemd в подобных этой нитях. Ваше или моё "не нужно" не означает "не нужно никому". И в разработке systemd участвует не один самоучка-клептоман, но и также немало людей из других компаний. Неужели вы убеждены что они такие же слепцы, как я, разработчики arch, fedora и suse, что не видят всех изъянов системы, раз они так очевидны для вас?
Извините, но я устал и я ухожу. Интерес к беседе с вами у меня пропал. И как я сказал выше - история нас рассудит.
