Зачем нужны системы вроде systemd и почему скрипты запуска демонов такие сложные?

А расскажи-ка ты мне, касатик, как ты autoexec.nt Windows 8 пускал.

Пффф, не занимайся словоблудием.

Я не занимаюсь, а ты зачем-то начал.

Я не понимаю как «всё сходится».

Вместо допиливания upstart (уже включенного в RHEL) менеджмент Redhat благословляет поцеринга на systemd и его пиар. Всё еще не понимаешь?

Вот rh поддерживает rpm, и что дальше?

Я даже не понял, где ты нашел аналогию между RPM и dpkg.

Одна из любимых моих серий в SP

Ну ты понел...

systemd относительно пригодный. но я бы не стал рисковать и запиливать его на сервер.

Я не говорю, что он негодный. Методом грубой силы можно заставить работать всё, что угодно, и systemd будет работать.

Я что-то не видел чтобы redhat кого-то насильно сажала на systemd. Ты хочешь сказать что на debian, arch linux и прочих красношапка давит?

Напрямую нет. Опосредованно. Debian еще сто лет мог бы прожить даже со старой init. Вся фишка в том, что RH имеет влияние на другие проекты типа GNOME. Все очень просто: ключевые разработчики форсят какую-то им одну приятную вещь, остальное игнорируется. Ты можешь возражать, но тебя никто во внимание не примет. Скажут, что нам нужна новая система инициализации и вот по случаю ее уже написал некий сотрудник RH. Не нравится - форкайте. Получается, что Debian остается либо прощаться с GNOME (а это невероятно, так как в рядах DD есть ярые фанаты, да и сообщество не поймет), либо этот GNOME форкать (а кто это будет делать? Сопровождающий - это не разработчик в общем случае), либо начинать выбирать систему инициализации из имеющихся. Болезненный процесс, который можно с некоторым приближением назвать давлением.

Ничего хорошего в этой фрагментации всего и вся нет. Запущен по сути процесс развала всей инфраструктуры и попытка вынуждать принимать стороны довольно непопулярные для себя технические решения. Больше глобальная стандартизация никого не интересует. Все захотели стать царьками самостоятельно. Если бы проекты вырабатывали совместно стандарты, а потом им следовали, то и проблемы не было.

Они переняли стратегию Майкрософт и идут по пути получения прибыли за счет причинения страданий их клиентам. В мире оффтопика такое достигается за счет небезопасных и неоптимальных решений и процветания за счет этого «сторонних» антивирусов и прочих оптимизаторов.

В случае RHT такого эффекта планируют по-видимому добиться за счет спагетти-документации и нестабильного API.

Я что-то не видел чтобы redhat кого-то насильно сажала на systemd

Активно сажает. Посмотри значимые новости о systemd.

Тогда зачем делать journal и logind, а вместе с ними udev - неотъемлемыми частями systemd?

Вот хотя бы: какой смысл объединять udev и systemd с технической точки зрения?

Они переняли стратегию Майкрософт и идут по пути получения прибыли за счет причинения страданий их клиентам

Я не вижу страдания клиентов. Redhat хочет контролировать весь стек используемых технологий. Если в процессе получения такого контроля она напакостит конкуренту (Canonical), тем лучше.

Мне ещё интересно, почему init-ng не взлетел.

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

Я не вижу страдания клиентов

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

Тогда зачем делать journal и logind, а вместе с ними udev - неотъемлемыми частями systemd?

Первые два - зависят на 100% от системде, а с 3м не суть ясно. Сначала казалось, что это просто политическая акция (системде работает без удева, удев работает без системде), прикрытая лозунгом об упрощении билда, но сейчас мне уже кажется, что Кай действительно так думает (%

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

Во всех трех случаях - это политическая акция.

Как видите, музыка тоже воюет.

Ну и как вариант, рассмотри ситуацию когда программа полную информацию об ошибке сыпет в лог

Причем здесь systemd? Сыпать в лог должна программа. Или ты считаешь, что systemd (или journald, или еще что-то) будет перехватывать лог и менять сообщения на коды ошибок?

Тут уж без платной техподдержки производителя не обойтись.

Примерно для этого Redhat и хочет быть апстримом всего подряд. Ничего личного, только бизнес.

оперативнее всего баги ключевых компонент системы, а это компоненты systemd - сюрприз! - может закрыть только она.

Именно.

Вот, ты меня понимаешь. Вся эта возня - просто политика и никакая не разработка.

Вот, ты меня понимаешь.

Мы с тобой придумали одинаковую теорию заговора и будем в одной палате.

Вся эта возня - просто политика и никакая не разработка.

Это разработка, инициированная политикой.

Ну или политика, прикрываемая фиговым листком разработки.

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

Если в твои задачи входит просто тупо запустить что-то, то безусловно городить огород смысла нет никакого. Но представь ситуацию: у тебя запускается apache, который, например, начинает плодить по процессу на каждое соединение + порождает еще кучу процессов в виде shell cgi. Весь этот зоопарк процессов должен кем-то контролироваться и убиваться, если ты введешь команду остановки сервиса. Кроме того, если вдруг какой-то демон во время работы изволил внезапно сдохнуть, вполне можно его автоматически запустить вновь. Добавь еще сюда зависимости между различными сервисами и получишь весьма сложную задачу, решить которую только классическими шелл-скриптами довольно затруднительно. Скрипты защищают только потому, что никому нехочется насильно изучать что-то новое, особенно, когда от этого нового пахнет кривизной. Но хорошая альтернатива классическому иниту нужна, и это факт.

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

Можно просто предоставить шелл-скрипту соответствующий API - какой-нибудь killcg.

хорошая альтернатива классическому иниту нужна, и это факт.

systemd - это не альтернатива init. Это нечто гораздо большее.

Можно просто предоставить шелл-скрипту соответствующий API - какой-нибудь killcg.

Для остановки сервиса - да, вполне вариант. А вот как запустить инит-скрипт для принятия решения «что делать?» в случае, если демон упал?

systemd - это не альтернатива init. Это нечто гораздо большее.

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

Конфигурационные файлы легче читать, писать и проще валидировать.

О rc.conf слыхал?

Вместо допиливания upstart

На этот вопрос у Леннарта был ответ — оно для этого не пригодно.

глобальная стандартизация никого не интересует

В идеальном мире так бы и было. В реальности я считаю это скорее злом. Я бы сказал, надо не «один стандарт на всех», а у улучшать средства взаимодействия между конкурирующими стандартами.

проекты вырабатывали совместно стандарты

Однажды лебедь, рак да щука... У каждого же своё видение как оно должно быть.

Активно сажает. Посмотри значимые новости о systemd.

Можно ссылочку на такую новость?

Вместо допиливания upstart

На этот вопрос у Леннарта был ответ — оно для этого не пригодно.

Почему непригодно? Потому что Леннарт так сказал. Интересно, что думали по этому поводу те, кто выбирал новый init для RHEL6.

глобальная стандартизация никого не интересует

В идеальном мире так бы и было. В реальности я считаю это скорее злом.

Ахаха. А ведь Debian наверняка выберет systemd. Что там насчет глобальной стандартизации? %)

Да ubuntu не осилила даже скрипты перевести на свой upstart (сужу по 12.04, я из убунт только lts использую). Имхо, это уже показательно отношение к системе инициализации. Да, это не пруф того что upstart нельзя допилить. Но прикинь что бы с апстартом было если бы Леннарт его попытался допилить? :)

А Леннарт не просто сказал, он сделал рабочую систему которая тупо лучше. Не во всём, не всегда и не везде, да и архитектурно, на мой взгляд, хрень. Но мне с ней тупо удобнее. Если изобретут что-то получше то я с удовольствием пересяду на это что-то. А пока конкурентов просто нет. Тот же openrc коммандой reboot, судя по генту-вики, из lxc-контейнера может отправить в ребут хост.

Что там насчет глобальной стандартизации?

Когда я писал про стандартизацию я имел в виду именно rfc — когда обсуждение стандарта может затянуться лет эдак на 10. Спасибо, такого не надо.

Плюс я не считаю что один плохой стандарт лучше трёх хороших. Да и отсутствие конкуренции и альтернатив это тоже зло.

Да ubuntu не осилила даже скрипты перевести на свой upstart

А зачем их вообще переводить на upstart? Они есть и работают.

Да, это не пруф того что upstart нельзя допилить

Это повод подумать - а нафиг вообще все эти продвинутые возможности init?

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

Вот именно. А это будущий Core Linux, встречай.

Если изобретут что-то получше то я с удовольствием пересяду на это что-то.

Ты пересядешь? Ахренеть.

пока конкурентов просто нет. Тот же openrc коммандой reboot, судя по генту-вики, из lxc-контейнера может отправить в ребут хост.

Какие мелочи тебя волнуют.

Когда я писал про стандартизацию я имел в виду именно rfc — когда обсуждение стандарта может затянуться лет эдак на 10

Затянувшееся на 10 лет обсуждение - это отсуствие стандарта.

А зачем их вообще переводить на upstart? Они есть и работают.

А зачем вообще upstart? И до него всё работало.

Какие мелочи тебя волнуют.

Почему ты решил что твои проблемы c systemd не мелочи?

Ты пересядешь? Ахренеть.

Я даю личную оценку качества различных систем инициализации. Ты делаешь то же самое.

А зачем их вообще переводить на upstart? Они есть и работают.

А зачем вообще upstart? И до него всё работало.

Сам удивляюсь. Ведь работало и работает - сервисы стартуют, флешки монтируются. Откуда нужда в революциях?

Почему ты решил что твои проблемы c systemd не мелочи?

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

Я даю личную оценку качества различных систем инициализации.

Своим «я пересяду» ты даешь оценку последствий внедрения системы инициализации.

А как же, и пользовал на arch-е пока systemd не прилетел. Но rc.conf никак от портянок старт/стоп скриптов не избавляет. Ух и поковырялся я с ними в свое время.

тоесть если раньше я левой пяткой и одним кейсом легко и непринужденно создавал сервис, то теперь я ВЫНУЖДЕН читать какие-то маны, вникать в особенности работы системы инициализации, её приоритеры, зависимости и все такое... отличное решение... эх

case "$1" in
start)
  bash /myscript.sh
  ;;
stop)
  kill `cat /tmp/mypid`
  ;;
*)
  echo "Usage: $1 [start|stop]"
  exit 1
esac

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

Откуда нужда в революциях?

Возникла нужда в увеличении предсказуемости и минимизации действий администратора системы для решения тех или иных кейсов

Я не знаю почему вы делите разработчиков на «виндузятников» и «элиту», но могу абсолютно точно сказать, что простые вещи должны делаться максимально просто. Вопрос же не в нежелании читать документацию, а в необходимости усложнять предельно простые процессы.

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

Да можешь хоть сейчас с /linuxrc стартовать. Леннарт лично мешает?

Не нравится - форкайте.

Все правильно, зачем RH думать о каких-то там перепаковщиках софта из Debian и т.п.? Хотят рулить разработкой - пускай форкают и пилят под себя. Это же open source, где выживает и развивается только действительно нужный кому-то софт.

Возникла нужда в увеличении предсказуемости и минимизации действий администратора системы

Плакал. Вот не нужно было раньше и тут БАЦ - вдруг нужно, да?

расставить ответы в примитивной анкете юнита гораздо проще.

В этой анкете ~200 вопросов %) Это не считая вопросов Exec*, в которых тот же шелл скрипт, только записанный ублюдочным образом.

Плакал. Вот не нужно было раньше и тут БАЦ - вдруг нужно, да?

Представь себе. У линакса вдруг появились ПОЛЬЗОВАТЕЛИ (%

Сумашедшая ситуация, кто бы мог подумать, но тем не менее.

В этой анкете ~200 вопросов %)

Из которых 190 - только если тебе нужно нечто странное

В systemd для такого простого кейса service-файл будет тоже очень простым:

[Unit]
Description=My Script
[Service]
ExecStart=/myscript.sh
[Install]
WantedBy=multi-user.target

приоритеры, зависимости и все такое

если все это никак не обрабатывалось в инит-скрипте, то и для systemd можно положится на дефолт

Представь себе. У линакса вдруг появились ПОЛЬЗОВАТЕЛИ (%

Ага, у RHEL _вдруг_ появились пользователи. Раньше не было? Или проблемы, которые нужно решать, раньше не решались? Перестань строить из себя plm.

Мля, каждый раз, как вижу это уебищное говноini, вспоминаю NT 4.0.

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

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

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

Из _средств_ я вообще только контейнеры и припоминаю. Но причем тут средства - вроде проблема во внезапном появлении у Линукса пользователей?

По факту, все что решает этот когломерат средств - проблему хотплага+конфигурации и раздачу прав доступа

Для решения этой проблемы точно нужны контейнеры, активация по сокетам, объединение udev и init, уебищный ini?

Кстати, у меня хотплаг работает на sysvinit.

Из _средств_ я вообще только контейнеры и припоминаю. Но причем тут средства - вроде проблема во внезапном появлении у Линукса пользователей?

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

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

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

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

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

Все правильно, зачем RH думать о каких-то там перепаковщиках софта из Debian и т.п.?

RH такие же перепаковщики, как и Debian. Если сотрудники RH участвуют в каких-то инфраструктурных проектах, то я так же могу назвать проекты, где пользователи Debian участвуют («сотрудник» к Debian вообще неприменимо). Например, разработчики XCB дебианщики, ключевой разработчки иксов - Keith Packard - матерый дебианщик, автор cairo (Carl Worth) дебианщик. Ну, думаю, достаточно. У меня предложение не пытаться назвать одних перепаковщиками, а других - богами. Debian - это дистрибутив, который поддерживается для кучи платформ, архитектур. Если взять софт из транков и тупо пытаться собрать это все воедино, то ничего не выйдет. Над Debian работают люди, основная задача которых не писать софт, а создать масштабный консистентный и связный дистрибутив.

Что касается существа, то стандартизация до сего момента шла в цивилизованном русле. Сейчас каждая шавка думает, что 1% пользователей - это большая добыча. Делят-то шкуру неубитого медведя. У классического десктопного Линукса будущего среди широкого круга пользователей не обнаруживалось, а сейчас и подавно не будет, потому что фрагментация кучки пользователей произойдет. Буквально скоро будет появляться непереносимый кроссдистрибутивно софт. Первые ласточки - DE.

RH такие же перепаковщики, как и Debian.

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

ну в арче было вроде всё rc.local, и они этим даже хвалились. потом почему-то выпилили