> А для меня разница между sh и service файлами минимальна. Не так
> уж они сложны, не преувеличивайте.Проблема даже не в этом. В том, что - это лишние знания.
Сейчас - от администратора не требуется заранее учить как устроена система инициализации в конкретном дистрибутиве (в предположении использования sysvinit). Припрет - в случае проблемы всегда можно взглянуть на код в конкретном месте.
> запомнить 10-20 говорящих самих за себя директив не составит труда.
Как легко... Вы, наверно, и ЯП так учите, да? Запомнил синтаксис - и уже гуру, не?
> Вот и я о чём. Для большинства пользователей и разработчиков ничего не
> изменится, они заметят только то, что система стала послушнее и менее тугодумна.
А для меншинства, которого система инициализации касается больше (администраторы, мейнтейнеры и т.п.) - "изменится" сполна. Чиним там, где не ломали. Да еще и недоязык при этом учим забесплатно... Зашибись.
> Не надо пытаться меня убедить, что система зависимостей в sysvinit-based системах более
> прозрачна. Ничего у вас не выйдет.
Если вы предубеждены в обратном - конечно, не выйдет. А если вы знакомы с предметом - выйдет, еще как. Есть стандарты, есть дистрибутивы в которых эти стандарты поддерживаются. И, естественно, явное указание зависимостей - куда прозрачнее "автомагической" логики.
Но начинаю уже сомневаться в вашей "беспристрастности" и "желанию выяснить". Нет у вас оных...
> Ваше отношение к пользователям обозначено. А практически не пользуются - сейчас ни
> гном ни кде чихнуть нормально не могут без dbus.
Мне не нужен гном или кде на сервере. И, уверен, никогда нужен не будет.
> Ничего мы не выяснили.
Вы бот? #299 "Вы приводите пример, что не надо забывать о других ролях системы, кроме десктопа..."
> Вы опять никаких объективных аргументов против не привели,
> кроме субъективных оценок и неясной боязни пары зависимостей.
Таки приведете пример зачем on-demand на сервере?
> И кстати, чтобы собрать минимально рабочую систему с нуля с systemd необходимо
> в несколько раз меньше базовых пакетов(порядка 10, против ~50). Одна из
> причин создания systemd - это shell-free boot.
Глупая причина (приблизительно как меряние числом пакетов хз где). Система должна быть удобной, управляемой для администратора. Если ее штатной частью становится дебагер - вы не туда попали. Вам в очередь - слать аччот в редмонд...
> Это к вопросу о простоте sysvinit, минимализме, unix-way и прочее.
Скриптовые языки - часть философии unix.
> Ну тогда не используйте ненужный вам функционал и будет вам счастье. Я
> уже устал это повторять.
Так я и не использую. Вместе с systemd, который из "ненужного" состоит чуть менее чем полностью. Но тогда возникает вопрос - а зачем он *везде*, как хотят адепты?
>> Может вы перестанете говорить загадками - и укажете такие, для которых "не
>> странно"?
> Сервис для работы например какого-нибудь hot-plug устройства, на вскидку, или просто ресурсоемкий, редко используемый, сервис.
Для hot-plug есть udev.
Про "редко используемый" - годится предыдущий пример с on-demand для sshd. Не годится городить себе проблемы на ровном месте - в непредсказуемый момент времени. Если сервис потребляет ресурсы при бездействии - это либо баг, либо - кривые руки администратора, не умеющего настроить сервер (подсистему виртуальной памяти, к примеру).
> Да, не серверное применение, подходит скорее для планшета,
> десктопа, embedded систем
О!
> но в отличии от вашего решения, systemd одинаково
> хорошо отработает во всех случаях.
Хз. Вам пример с кривым поведением, благодаря on-demand - привели. Вы таки ничерта не поняли?
> Если вы проверяете работоспособность конфига сервиса перезагрузкой системы - мне вас искренне жаль. И в случае с удалённым сервером - не спасет вас sysvinit.
Я делаю перезагрузку сервера для 100500 других вещей. И да, спасет. От чего и почему - написал выше.
> В остальных - не вижу проблемы, изменили,
Упс... А тут питание отключили на ровном месте...
"Не создавай проблему в непредсказуемое время, если можно этого избежать." Можете цитировать.
> И опять же, это не обязанность init-системы следить за корректностью конфигов,
Нет, конечно. Но и городить дополнительные проблемы на ровном месте она не должна...
>> Вот такой вот "принцип" и "плагины". И вы еще удивляетесь, что
>> люди не в восторге от "архитектуры" systemd?
> Конструктивной критики архитектуры как не было, так и нет.
Куда конструктивнее. Вы писали - "все опциональное плагинами", "активация как принцип", "неважно какая" - а открутить те ее варианты, что не нужны мне - не получается. Только что "не использовать" (ц).
> Вспомните что было, когда udev только внедрялся. Сколько было вони, грязи.
Ну, уж не столько... По крайней мере, никто не кричал что "не нужен".
А вот нужен-ли вообще systemd - это большой вопрос...
> довольно странно указать дистрибутив, в котором о systemd идёт речь постольку-поскольку.
> А вот на форуме арча много тем с systemd и solved в заголовках. Проблемы есть, но они решаются.
Довольно странно, когда баги в upstream становятся дистрибутиво-специфичными.
>>> Тогда будьте добры, в доказательство своих слов, приведите пример, когда цикл(да и
>>> вообще скрипт со сложной логикой) при старте сервиса необходим.
>> $ grep 'for .*in' /etc/init.d/*|wc -l
>> 94
> любой скрипт пожалуйста, а не статистику использования for и while.
Берите любой скрипт. // Это Debian Squeeze, десктоп.
>[оверквотинг удален]
> 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
> Даже мне понятна практически каждая строчка.
А лично мне - понятно, что он *не делает* то, что я просил. Этот конфиг не является заменой init-скрипту апача в Debian. Совместимость, епт...
> Командная оболочка однозначно не должна заниматься процессом загрузки системы. Не самый
> лучший для этого инструмент, использовавшийся только из-за отсутствия достойной альтернативы.
Она и не занимается. Вы вообще представляете себе как sysvinit работает?
> Выше. Умерьте ваш пыл и нравоучительный тон.
Выше оказалось свидетельство того, что вы даже не разобрались в условиях задачи. Так ли был неуместен нравоучительный тон?
> В пределах одного дистрибутива всё ок. В пределах одной системы (systemd) скорее
> всего тоже будет все ок.
*Уже* не ок. Вы готовы скопипастить конфиги systemd для сервисов для арча из федоры? Для Debian из Gentoo?
> Для фукнционала аналогичного sysvinit, в systemd тоже достаточно сказать telinit. Но также
> есть возможность сделать это немного по другому, что обусловлено дополнительными возможностями systemd. Вот и всё.
Ну и *зачем* это? Только потому, что "дополнительные возможности" сразу обросли "дополнительными проблемами"? Так и выглядит ведь...
> Каждый суслик в поле агроном. Не слышите меня, прислушайтесь к другим. Неужели
> вы всерьёз думаете, что в rh работают люди, хуже вашего разбирающиеся
> в архитектуре ПО, linux и прочем?
Пошел давить авторитетом... Начнем с того, что и там отношение к сабжу - "разное". И заканчивая тем, что RH одним linux (и тем более СПО) - не заканчивается.
-->8--
Quite frankly, any feature that is sold with ".. and systemd can use
this fox Xyz", is a *misfeature* in my opinion. Core infrastructure
like systemd should use a *minimal* interface, not some random
extended features.
I'm starting to really dislike this whole feature discussion.
<guess who>
-->8--
> Неужели вы убеждены что они такие
> же слепцы, как я, разработчики arch, fedora и suse, что
> не видят всех изъянов системы, раз они так очевидны для вас?
Все три дистрибутива (вы перепутали suse с opensuse) - песочницы для альфа-тестеров. Со всей вытекающей политикой "поддержки", "обратной совместимости" и проч. И соответствующими комьюнити. Да и там, в сущности - точки зрения самые разные...
Так что ничего серьезного пока нет. Ждем RHEL, как обещано. Или Debian. И отучаемся смотреть в рот всяким "разработчикам" - привыкаем иногда думать собственной головой ;)
