>> Если ты про sysvinit - то там нету скриптов вовсе.
> Да, они есть у тех кто потом прописывает старт демонов.
>> Любуйся: http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/?ro...
> Кого вы хотите надуть? Меня не интересуют ваши жонглирования формальностями.Ну, если тебя не интересуют факты...
>> Можно пример того, что ты считаешь "этажерками, писанными укурками"?
>> Конкретно, с сайта debian.org.
> Да пожалуйста! Как тебе нравится скрипт udev, с параметрами конфигурации на второй
> странице? Здорово, правда?
О каких конкретно "параметрах" в данном случае идет речь? (Разбиение на страницы для меня ровно никакой информации не несет, ты хоть это понимаешь?) "Скрипт udev" - это который?
> Если инсталлить какую-нибудь
> программу не из репов дебиана - можно и более веселые примеры
> найти, где скрипт думает что у меня есть какое-нибудь /opt, при
> том чтобы его переубедить его в этом - надо лезть в
> середину скрипта и фиксить.
Debian не использут /opt. Но этот каталог должен у тебя быть по FHS. Если ты его удалил, то буратин именно ты, а уже во-вторых - автор deb-а "не из репов дебиана" (для таких авторов, собственно, /opt и предназначен).
> А если это творчество кулсисопа который до
> тебя сервак админил - там вообще волосы на ж...е от ужаса
> могут шевелиться.
Учитывая вышесказанное - я бы на твоем месте задумался о *своей* профпригодности в первую очередь.
>> После чего "этого"?
> После натыкания на некоторые поделки которые выпернули под init некоторые индивиды. Так
> что без фиксинга не работает, а фиксинг достаточно мерзкий, ибо конфигурация
> бывает размазана по всей простыне.
В принципе, init-скрипты в том же Debian считаются конфигурационными файлами. Но реально практика их модификации не поощеряется, ты должен использовать /etc/default. Если какой-то пакет данное правило игнорирует - есть багтрекер.
>> Это проблемы конкретных дистрибутивов (или даже конкретных пакетов).
> Меня как админа совершенно не интересует как и кто отбрешется от проблем.
Тогда убеди руководство купить RHEL с поддержкой Premium. Ты сможешь спокойно уволиться, а проблемы в дистрибутиве будут решаться - вне зависимости от того какая "Маша" из вашего офиса будет им слать аччтоты об ошибках.
systemd не решит всех проблем, пора бы это уже понять. Особенно те, что техническими вовсе не являются. Он не отменит необходимости сообщать о проблемах в багтракер, следить за их статусом и вообще участвовать в их решении (для community-driven дистрибутивов) и т.д.
> Меня интересует фактические затраты усилий на администрирование. В том числе и
> в случае "собрали программу которой не было в репах", например.
Много раз приходилось просто писать новый инит-скрипты в таких условиях. В 99% - достаточно элементарной модификации /etc/init.d/skeleton. Откуда такие адовы проблемы, можно реальный пример?
>> Типовые и стандартные вещи решаются типовыми и стандартными способами.
> И где эти решения?
sysvinit, cron, at, udev, monit, скрипты shell. Разные задачи, разные инструменты, разные языки. Это нужно быть *очень* большим фанатом поттцеента, чтобы у****ский INI-формат был для тебя адекватной заменой простому кронтабу (при эквивалентном функционале).
> а я бы предпочел держать все
> что связано с запуском программ более-менее в одном месте.
Угу, я понял, в реестре Windows.
>> Зачем тут еще запихивать cron в свой разжиревший "автопилот"?
> Затем что я не вижу большой разницы - взлетит ли программа по
> критерию "о, сетка появилась!" или "о, наступило полшестого".
Я правильно понял, что если я выделил в emacs текст и хочу натравить на него aspell - это теоретическое приложение для systemd? "Взлет программы" наличествует, критерий есть. Ы?
> Лично мне не нравится что запуск программ настраивается в куче разных закоулков.
В дебиан - это настраивается в /etc.
>> подходящий термин!) - слыхал, в Fedore так уже sshd пущают.
> Не вижу чем это так плохо.
Вот в этом и дело. Что ты "не видишь" очевидных (для любого профессионального системного администратора) проблем: отложенный запуск sshd - это отложенная активация мины. Тупо конфиг sshd побит: может твои кривые ручки постарались перед предыдущим перезапуском сервиса, может файл поврежден. Ты не узнаешь об этом в заранее предсказуемый момент времени (напр., плановый ребут).
> Только поумнее надо сделать, чтоб порткнокинг
> еще до этого был.
Вот-вот. Что еще в systemd потянете - OpenOffice?
PS:
С НГ!
