Linux без systemd

[Kopilov]

У ядра Linux есть строгая нумерация версий, которая позволяет сориентироваться, насколько серьёзны изменения.
Леннарт, похоже, вообще не заморачивается по таким пустякам.

Линус если и заморачивается, то по иному принципу.

[Bizdelnick]

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

А я говорил о сейчас или парой лет раньше. В ядре достаточно примитивов, чтобы просто реализовать полезный функционал. Если городить такой упоротый API — то да, тут, конечно, без чего-то вроде dbus не обойтись. Но ты так и не ответил на ключевой вопрос — зачем?

По твоей же ссылке объясняется

О да, время доступа к методам юнитов — крайне критичная штука. Мы же постоянно их дёргаем и передёргиваем. Страшно подумать, как система начнёт тормозить, если использовать только методы менеджера.
Табличку показывать надо?

Очевидно, systemctl.

И какую же команду надо ему дать, чтобы он напрямую вызвал метод юнита? Или ему всё равно придётся сначала обращаться к GetUnit() и потратить на это драгоценные микросекунды? Фууу, какой он неэффективный!

http://dbus.freedesktop.org/doc/dbus-faq.html#xmlrpcsoap
Для JSON-RPC абсолютно аналогично. Он просто тупо медленнее.

JSON парсится намного быстрее XML, и HTTP-прослойка для RPC вовсе не обязательна. Но согласен, и он тут не особо нужен. Я просто назвал первое, что пришло в голову.

[yoshakar]

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

[Bizdelnick]

надо просто подождать, пока аналогичную systemd штуку сделают для BSD

Не сделают, ибо

BSD-шники зря ничего не делают

Так что можете уже начинать сравнивать по принципу

Есть аналог в BSD - значит годная фича, а нету - значит вредная приблуда.

[neol]

надо просто подождать, пока аналогичную systemd штуку сделают для BSD

Не сделают, ибо

BSD-шники зря ничего не делают

Так что можете уже начинать сравнивать по принципу

Есть аналог в BSD - значит годная фича, а нету - значит вредная приблуда.

https://www.linux.org.ru/news/bsd/11075438

Вы, кстати, так и не ответили чем плох dbus.

[Bizdelnick]

https://www.linux.org.ru/news/bsd/11075438

Заголовок как-то не соответствует новости. Переделать /etc/rc.d и переделать PID 1 — это совершенно разные вещи. И переделка /etc/rc.d — куда более разумное решение задачи улучшения управления сервисами.

Вы, кстати, так и не ответили чем плох dbus.

Я не говорил, что он плох. Он просто не подходит для данной конкретной задачи, вот и всё. Я выше уже писал, что основная его фишка — мультикаст, который в systemd никак не используется. Как и практически всё в systemd, выбор протокола не следует принципу KISS.

[alv]

Заголовок как-то не соответствует новости.

Не, это новость не соответствует новости.
Хаббард последнее время пару раз высказывался в том смысле, что хорошо что-нибудь такое забабахать. А поскольку сам он непосредственно разработкой давно не занимается, это надо понимать как "хорошо бы кто-нибудь этим занялся".
Слова про "основателя FreeBSD" показывают компетентность автора новости в этой теме вообще.
А уж финальная фраза заставляет вспомнить полковника Брежнева, одобрившего план маршала Жукова.

[neol]

Заголовок как-то не соответствует новости. Переделать /etc/rc.d и переделать PID 1 — это совершенно разные вещи. И переделка /etc/rc.d — куда более разумное решение задачи улучшения управления сервисами.

Те, кто совсем не дружит с английским, вынуждены довольствоваться такими новостями. Для остальных там есть ссылка на выступление.

Кстати забавная фраза из презентации:

Even the linux die-hards have essentially grasped the necessity of systemd (even though they're going to hate on it for avail longer)

Я не говорил, что он плох. Он просто не подходит для данной конкретной задачи, вот и всё. Я выше уже писал, что основная его фишка — мультикаст, которая в systemd никак не используется. Как и практически всё в systemd, выбор протокола не следует принципу KISS.

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

[Bizdelnick]

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

А я сильно сомневаюсь, что тот же JSON-RPC поверх доменного сокета без дополнительных прослоек будет медленнее. Возможно даже быстрее. Хотя, как я уже писал выше, считать микросекунды в данном случае нет никакого смысла.

Для остальных там есть ссылка на выступление.

А расшифровки нет? Нету времени смотреть видео, и на слух я английский хуже воспринимаю.

Кстати забавная фраза из презентации

Ну ещё бы после этого Леннарт не одобрил выступление. (-:

[Rootlexx]

У systemd уже есть, как минимум, один случай гарантированного падения PID1 в сегфолт.
Приведите, пожалуйста, аналогичный пример для sysvinit.

Было множество случаев гарантированного падения ядра в kernel panic, выносящим систему с любым init. И если сегфолт systemd ещё позволяет корректно завершить работающие процессы, сохранить данные, перемонтировать ФС в режим "только для чтения" и перезагрузиться, то паника ядра - немедленная смерть. Но это почему-то не останавливает вас от его использования.
Безусловно, systemd менее надёжен, чем sysvinit, ибо гораздо функциональнее и моложе. Но это и не значит, что он будет падать на каждый чих. На практике те возможности, из-за которых на него перешли почти все дистрибутивы, перевесили немного меньшую надёжность.

Изменение API - это новая версия ядра.

А вы что, думаете, в systemd меняют API в пределах одной версии, что ли?

У ядра Linux есть строгая нумерация версий, которая позволяет сориентироваться, насколько серьёзны изменения.

Где вы были последние несколько лет? Это уже давно не так.

Спросите у Линуса. Если кто и знает, так это он.

Ну тогда я вам отвечу "Спросите у Леннарта".
Всё же прочитайте Собор и Базар.

Функция может и не отделяться. Хотя функция может быть размещена в модуле, тогда от проекта она вполне себе отделима. А вот в systemd это не просто функции, а самостоятельные программы, по крайней мере, так они заявлялись вначале. И теперь, когда оно вдруг становится неотделимым - это как минимум странно.

Какая связь между возможностью компиляции systemd без logind и возможностью использования последнего отдельно от первого?
Можно ли собрать systemd без logind? - да, можно.

Неужели? А вот Леннарт говорит, что нельзя. Кому верить?

Похоже, вы запутались. Леннарт говорил о неподдержке работы logind как самостоятельного объекта без systemd, а не о невозможности сборки systemd без logind.
Работа logind вне systemd не поддерживается (хотя и возможна, как доказали Canonical). Компиляция же systemd без logind поддерживается, в чём несложно убедиться, ознакомившись с ключами скрипта configure (--disable-logind).

А ещё более вероятно, что на тот момент logind действительно был отделимым.
И они понадеялись на ту самую модульность, о которой заявлял Леннарт.
А потом logind стал неотделимым. И вот тут-то (если по-хорошему) Леннарту надо было немножко напрячься, чтобы имеющуюся модульность сохранить. Он этого оне сделал.

Это ваши личные фантазии. Я предоставил вам достаточно информации и, как мог, постарался объяснить. Но право заблуждаться у вас никто не отнимает.

[Rootlexx]

В ядре достаточно примитивов, чтобы просто реализовать полезный функционал. Если городить такой упоротый API — то да, тут, конечно, без чего-то вроде dbus не обойтись. Но ты так и не ответил на ключевой вопрос — зачем?

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

Я выше уже писал, что основная его фишка — мультикаст, которая в systemd никак не используется.

Основная фишка dbus - это более высокоуровневый IPC, нежели разнообразные примитивы. Мультикаст и иная маршрутизация осуществляются демоном dbus, который для связи с PID 1 не является необходимым.

[Bizdelnick]

со своей реализацией аутентификации, политик, сериализации и т. д.

И зачем там всё это т. д.? Права доступа к сокету устанавливаются средствами файловой системы.

Мультикаст и иная маршрутизация осуществляются демоном dbus, который для связи с PID 1 не является необходимым.

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

[Hephaestus]

Было множество случаев гарантированного падения ядра в kernel panic, выносящим систему с любым init.

Правильно. Но разработчики ядра свои ошибки исправляли. А разработчики systemd исправлять свою ошибку отказались наотрез - предоставили это право кому-нибудь другому.
Что и вызвало очередной скандал.

сегфолт systemd ещё позволяет корректно завершить работающие процессы, сохранить данные, перемонтировать ФС в режим "только для чтения" и перезагрузиться

Я бы не стал уверенно утверждать, что это всегда возможно. Ибо была ещё проблема зависания намертво вследствие спама в логи ядра. Так вот, такое зависание вряд ли позволит что-либо завершить корректно. И опять-таки, ошибку должен исправлять кто-то, а не разработчик.

Безусловно, systemd менее надёжен, чем sysvinit, ибо гораздо функциональнее и моложе.

Когда ядро по молодости падало в кернел паник, альтернатив этому ядру просто не было. Поэтому пилили долго и терпеливо, ибо понимали, что без ядра не обойтись. Совсем. Никак.
Для systemd альтернатив существует как минимум три, причём все три рабочие. Поэтому его пилить в таком же режиме, как когда-то пилили ядро (с грубыми багами, падениями и зависаниями) - это несколько расточительно на сегодняшний день, не находите?
А с учётом того, что разработчики не хотят фиксить баги и вообще без systemd можно обойтись (сколько раз уже звучало "не хочешь - не используй"), то такая линия разработки как у systemd, выглядит совсем уж как-то неприлично.

А вы что, думаете, в systemd меняют API в пределах одной версии, что ли?

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

Компиляция же systemd без logind поддерживается, в чём несложно убедиться, ознакомившись с ключами скрипта configure (--disable-logind).

И это будет работать? И без logind можно будет обойтись? Или заменить его на что-то другое?
Если да - здорово, если же нет, то смысла в этом ключе - ровно ноль.

Это ваши личные фантазии.

Не более, чем вот это

Вероятно, Canonical посчитали, что это проще, чем тянуть на себе мёртвое ПО в то время как upstream уходит от него всё дальше.

Ваши личные фантазии.
Вы сделали своё предположение о мотивах Canonical, я сделал своё. Насколько я понимаю, истинные мотивы неизввестны нам обоим. И наши предлоложения абсолютно равноправны.

[Rootlexx]

Права доступа к сокету устанавливаются средствами файловой системы.

Так можно разрешить/запретить только всё сразу. Политики же позволяют гибче управлять доступом.

В протоколе (и библиотеке) всё, для этого необходимое, есть, но не используется. О чём я и говорю.

И? Использование любого стандартного решения в подавляющем числе случаев не покрывает 100% предоставляемой им функциональности. Что же теперь, предлагаешь в каждом таком случае изобретать собственный ни с кем не совместимый велосипед, плодя множество реализаций с во многом перекрывающейся функциональностью, и называешь это KISS? На мой взгляд, первые три буквы тут явно лишние.

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

Можно ссылку, пожалуйста?

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

Во-первых, по молодости альтернативы очень даже были, выросшие из 386BSD, да и в GNU пилили свой HURD.
Во-вторых, в ядре и поныне нет-нет да появляются баги, способные свалить его в панику. Почитайте багзиллу. Это нормально для развивающегося проекта.

Для systemd альтернатив существует как минимум три, причём все три рабочие.

Из более-менее близких по возможностям - только upstart.

Компиляция же systemd без logind поддерживается, в чём несложно убедиться, ознакомившись с ключами скрипта configure (--disable-logind).

И это будет работать? И без logind можно будет обойтись? Или заменить его на что-то другое?

Да, будет работать. Более того, logind - это обычный сервис, запуск которого можно штатным образом отключить. И systemd будет прекрасно работать.
Другое дело - приложения, использующие API logind, например, компоненты GNOME, KDE - они могут потерять часть функциональности, для которой они использовали logind, но ничего критичного. А если кто-нибудь напишет альтернативную реализацию API logind - то и без потерь.

Не более, чем вот это

Вероятно, Canonical посчитали, что это проще, чем тянуть на себе мёртвое ПО в то время как upstream уходит от него всё дальше.

Ваши личные фантазии.
Вы сделали своё предположение о мотивах Canonical, я сделал своё. Насколько я понимаю, истинные мотивы неизввестны нам обоим. И наши предлоложения абсолютно равноправны.

Отнюдь. Моё предположение не несёт в себе никакого негатива, и я не делаю из него никаких выводов. Поэтому даже если оно окажется неверным, это никак не повлияет на истинность моих утверждений. Вы же на своём предположении строите вывод, выставляющий разработчиков systemd в негативном свете, не имея на то никаких фактических оснований. Едва ли это равнозначные ситуации.

[Hephaestus]

Во-первых, по молодости альтернативы очень даже были, выросшие из 386BSD, да и в GNU пилили свой HURD.

Во-первых, HURD в каком году допилили? В 2010, кажется? Или ещё позже?
А насчет BSD Линус сам писал в своей книге, что знай он об этом проекте, свой бы не начинал. Насколько я помню, они создавались примерно в одно время.

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

Разумеется. Только отношение к этим багам в команде Линуса принципиально другое, чем в команде Леннарта.

Вы же на своём предположении строите вывод, выставляющий разработчиков systemd в негативном свете

Я? Да при чём тут я? Выставить их в негативном свете больше, чем они уже выставили себя сами - это вряд ли возможно. Вы только представьте на секунду - возникла идея скинуться на киллера(!) для Леннарта. Это ж как надо себя вести, чтобы люди о тебе вообще начали думать в таком направлении???

Можно ссылку, пожалуйста?

А есть смысл?
Вы скажете, что я неправильно понял английский текст или совсем ничего не понял, что у меня каша в голове и вообще там другое имелось в виду. Интересно, а у остальных (в том числе тех, кто лично спорит с Леннартом) тоже каша в голове?

Знаете, был такой пророк Моисей, написавший часть книг Священного Писания. И был какой-нибудь святитель Феофан, толковавший эти книги, и на его авторитет опираются нынешние богословы.
Так вот, Вы мне напоминаете такого "авторитетного святителя Феофана" - все эти Ваши "вы запутались", "вы ничего не поняли","у вас каша в голове", "не это имелось в виду" и т.п. (между прочим, на некоторых форумах подобные формулировки не разрешаются - классифицируются как "переход на личности").
Но при всём уважении к Вам, Вы всё-таки не святитель Феофан, Леннарт - не Моисей, а его тексты - не Священное Писание, чтобы для понимания их требовались некие авторитетные толкователи.

Есть чрезмерно масштабный проект, причём, разрастающийся на глазах: сначала говорили о "системе инициализации", потом это стал "системный менеджер", а теперь уже Леннарт говорит: "мы делаем операционную систему". И его обращения к дистростроителям в духе "делайте выбор, от этого зависит будущее" достаточно амбициозны - он явно чувствует себя этаким Творцом Истории.
Далее, есть факты серьёзных ошибок в огромном проекте, есть багрепорты по этим ошибкам и есть реакция команды разработчиков на эти багрепорты, мягко говоря, безответственная. А ещё есть отношение к сообществу в целом - тоже не самое образцовое. Это всё характеризует Леннарта и Ко не с самой лучшей стороны.
И неважно, правильно я там что-то понял или неправильно - ошибок от этого не становится меньше, а отвественность не возрастает.

Вы хотели пруф про безответственное отношение к багам? Вот оно, во всей красе.
Сообщают о критической ошибке, а что отвечает Леннарт? "Я с удовольствием приму патч". Чего?
Какой патч? И с какой стати? И кто вообще знает продукт лучше автора, чтобы давать какой-то патч?
То есть ошибку должен исправлять кто-то, от разработчиков ничего не дождаться.

[yars]

"Я с удовольствием приму патч"

А потом приходит Кай (от которого, кстати, патчи Линус отказывался принимать) и грохает проверку на наличие cgroups вообще. Я об этом уже говорил. Нормальная реакция, чо. Тем более, протестировать поведение кода без cgroups несложно, и много времени не отняло бы.
P.S. Я вот выходил на контакт с разработчиками blueman-applet'a, найдя пару ошибок. На одну из них времени ушло порядочно (хотя проблема была, в общем-то, пустяковая), и ради нее даже один из разработчиков поднял ВМ со Slackware, так как у него не воспроизводилось. Видно, что разработчики заинтересованы в развитии своего проекта. А Леннарт, видимо, нет, раз пишет свою мега-ось, где у него cgroups будет из коробки.

[Bizdelnick]

Так можно разрешить/запретить только всё сразу. Политики же позволяют гибче управлять доступом.

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

Использование любого стандартного решения в подавляющем числе случаев не покрывает 100% предоставляемой им функциональности.

В подавляющем числе случаев если функциональность не используется, то оверхед от её наличия отсутствует. А тут адресация вроде как и не нужна, но всё равно выполняется.

[Rootlexx]

Во-первых, HURD в каком году допилили? В 2010, кажется? Или ещё позже?

Его не допилили до сих пор, по крайней мере до более-менее серьёзного использования. Но это и не важно, ибо речь о другом: в период молодости Linux были и другие варианты, и неизвестно, что было бы сейчас, если бы столько людей, сколько пилили Linux, пилили бы HURD. А FreeBSD в 90-ых была на коне и во многом опережала тогдашний Linux. Так что о полной безальтернативности Linux в то время говорить не приходится.

Знаете, был такой пророк Моисей, написавший часть книг Священного Писания. И был какой-нибудь святитель Феофан, толковавший эти книги, и на его авторитет опираются нынешние богословы.
Так вот, Вы мне напоминаете такого "авторитетного святителя Феофана" - все эти Ваши "вы запутались", "вы ничего не поняли","у вас каша в голове", "не это имелось в виду" и т.п. (между прочим, на некоторых форумах подобные формулировки не разрешаются - классифицируются как "переход на личности").
Но при всём уважении к Вам, Вы всё-таки не святитель Феофан, Леннарт - не Моисей, а его тексты - не Священное Писание, чтобы для понимания их требовались некие авторитетные толкователи.

Сразу видно, что systemd для вас вопрос религиозный :-).
Что ж, если вы так трактуете мои попытки вам объяснить, то это занятие бессмысленное. Я рассчитывал, что показав вам ложность ваших предположений, на основе которых построена ваша позиция, я смогу убедить вас лучше изучить предмет разговора, о котором вы на данный момент имеете лишь весьма отдалённое представление. Если вы не заметили, я не просто писал "вы запутались" и "это неверно", а объяснял, почему это неверно. Если бы вы хоть немного потрудились почитать по теме, то вам не пришлось бы высасывать из пальца ничем не подкреплённые предположения и строить на них свою позицию. Но вы просто отказываетесь воспринимать информацию, не предоставляя иных аргументов кроме сводимых к "не верю" и называя мои объяснения "толкованиями". Что ж, ваше право. Если захотите, можете почитать здесь: http://www.opennet.ru/opennews/art.shtml?num=36330. А пока дискуссию на эту тему я с вами заканчиваю.

Вы хотели пруф про безответственное отношение к багам? Вот оно, во всей красе.
Сообщают о критической ошибке

Почитал. Не увидел критической ошибки. systemd падает на конфигурации, которая официально не поддерживается.
Баг ли это? - да. Программа должна корректным образом обрабатывать некорректные условия работы.
Критический ли это баг? - Нет, ибо работа на неподдерживаемой конфигурации, как ни странно, не поддерживается.
Я не согласен с предыдущим поведением, когда известно, что многое не будет работать правильно, но загрузка продолжается. Если не можешь гарантировать корректную работу - не загружайся. Better safe than sorry. Как и было сделано в конечном итоге.

а что отвечает Леннарт? "Я с удовольствием приму патч". Чего?
Какой патч? И с какой стати? И кто вообще знает продукт лучше автора, чтобы давать какой-то патч?
То есть ошибку должен исправлять кто-то, от разработчиков ничего не дождаться.

Если точнее, Леннарт написал:

Well, cgroups-less kernels are explicitly not supported by systemd. However we added some hacks to allow it to boot to a certain degree even if a lot of things will not work correctly afterwards. In this mode when you boot you will actually get a warning on screen and bootup is delayed by 10s to make sure the user understands this.

Now, this mode recently broke, and it will segfault early on. I am happy to take a patch to 'fix' this again, but I will not work on this as i dont run kernels like this, and as mentioned its not really supported anyway...

Another option is to simply be honest amd stop supporting in entirely, and refuse booting completely. And I figure this is what I will eventually do if nobody cares enough to send me a patch to fix that segfault.

Вполне разумно, если учитывать, что работа без cgroups официально не поддерживается. Это примерно то же, что негарантийный случай при сдаче в ремонт.

А потом приходит Кай (от которого, кстати, патчи Линус отказывался принимать)

А ещё Кэй пишет udev. Срочно удаляй! MAKEDEV наше всё.

Тем более, протестировать поведение кода без cgroups несложно, и много времени не отняло бы.

cgroups лежат в основе модели управления процессами systemd. Без них многое элементарно перестаёт работать.

А оно надо? Либо юзер имеет право управлять сервисами, либо нет, одно из двух.

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

В подавляющем числе случаев если функциональность не используется, то оверхед от её наличия отсутствует. А тут адресация вроде как и не нужна, но всё равно выполняется.

Во-первых, насчёт отсутствия оверхеда, это просто неверно. Даже если ты не используешь какую-то часть стандартной функциональности, соответствующая программа, её обеспечивающая, всё равно должна проверять использование данной функциональности, ибо то, что ты не будешь что-то использовать, обычно заранее не известно.
Во-вторых, и каков же оверхед от "лишней" адресации? Одна, две миллисекунды? Не ты ли недавно насмехался над экономией миллисекунд в dbus API systemd?

[Bizdelnick]

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

Об этом я писал выше: вся информация, которую отдаёт systemd, просто дублирует содержимое файлов юнита, поэтому доставать её таким путём не имеет никакого смысла. Исключение — информация о статусе сервиса, но до systemd её благополучно получали, не дёргая PID 1. Возможно ли это с systemd — я не помню.

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

Ты сейчас что-то такое умное сказал, что я ничего не понял.

Во-вторых, и каков же оверхед от "лишней" адресации? Одна, две миллисекунды? Не ты ли недавно насмехался над экономией миллисекунд в dbus API systemd?

Дело не в миллисекундах. Дело в объёме и сложности выполняемого кода и, как следствие, вероятности появления в нём ошибок. Ибо сказано: KISS.

[Hephaestus]

Сразу видно, что systemd для вас вопрос религиозный :-).

Что ж делать? Вы сами повели дискуссию в таком ключе.

Что ж, если вы так трактуете мои попытки вам объяснить, то это занятие бессмысленное.

В том виде, как Вы это пытались делать - да, бессмысленное. Потому что и явные огрехи команды разработчиков systemd и противоречивые заявления Леннарта - всё это Вы оправдываете с удивительным упорством. Да и с чего Вы взяли, что я вообще нуждаюсь в Ваших объяснениях?

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

Моя позиция основана на заявлениях Леннарта. И подкпреплена цитатами из него же.
Если Вы в этом видите ложь и противоречия - этим всё сказано, значит, его заявления действительно противоречивы и неоднозначны.

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

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

Если бы вы хоть немного потрудились почитать по теме

Читал в своё время. В статье Леннарта честно пытался найти подтверждение нужности systemd лично для меня, а заодно найти подтверждение правоты Леннарта и, соответственно, моей неправоты. Не нашёл ни того, ни другого.
Далее пробовал решить конкретную задачу. Опять не увидел ничего такого, ради чего стоило бы устраивать миграцию. Столь крупные изменения в системе как те, которые предлагает проект systemd требуют соответствующих затрат по переходу (переобучение и т.п.). Для всяких затрат нужны основания. Я их честно искал и не нашёл. И вообще, я достаточно потратил времени на совершенно ненужный мне предмет.

А пока дискуссию на эту тему я с вами заканчиваю.

Я и не напрашивался. Ещё раз: посмотрите мой первый пост в этой теме и с чего начался Ваш ко мне интерес.

Почитал. Не увидел критической ошибки. systemd падает на конфигурации, которая официально не поддерживается.

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

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

Подобная логика приводит к тому, что нужно патчить нормально работающее ядро под криво работающий systemd. Этим постоянно грешит Kay Sievers (Как его прочитать? Кай Зиверс?) за что и получил в конце концов по ушам. От Линуса.

Вполне разумно, если учитывать, что работа без cgroups официально не поддерживается. Это примерно то же, что негарантийный случай при сдаче в ремонт.

Интересно, существует ли хотя бы гипотетическая ситуация, в которой Вы признаете действия Леннарта и Ко неправильными или неразумными?

[Rootlexx]

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

Не всё так просто:
* Что делать, если интересующее свойство не задано в юните, и для него используется значение по умолчанию? Смотри сам, сколько свойств у юнита типа сервис, большинство из которых в файле юнита явно не задано:

user

Код:

user@debian:~$ systemctl show dbus Type=simple Restart=no NotifyAccess=none RestartUSec=100ms TimeoutStartUSec=1min 30s TimeoutStopUSec=1min 30s WatchdogUSec=0 WatchdogTimestamp=Mon 2015-05-25 15:07:10 UTC WatchdogTimestampMonotonic=29137247 StartLimitInterval=10000000 StartLimitBurst=5 StartLimitAction=none FailureAction=none PermissionsStartOnly=no RootDirectoryStartOnly=no RemainAfterExit=no GuessMainPID=yes MainPID=848 ControlPID=0 Result=success ExecMainStartTimestamp=Mon 2015-05-25 15:07:10 UTC ExecMainStartTimestampMonotonic=29137150 ExecMainExitTimestampMonotonic=0 ExecMainPID=848 ExecMainCode=0 ExecMainStatus=0 ExecStart={ path=/usr/bin/dbus-daemon ; argv[]=/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation ; ignore_errors=no ; start_time=[Mon 2015-05-25 15:07:10 UTC] ; stop_time=[n/a] ; pid=848 ; code=(null) ; status=0/0 } ExecReload={ path=/usr/bin/dbus-send ; argv[]=/usr/bin/dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 } Slice=system.slice ControlGroup=/system.slice/dbus.service CPUAccounting=no CPUShares=18446744073709551615 StartupCPUShares=18446744073709551615 CPUQuotaPerSecUSec=(null) BlockIOAccounting=no BlockIOWeight=18446744073709551615 StartupBlockIOWeight=18446744073709551615 MemoryAccounting=no MemoryLimit=18446744073709551615 DevicePolicy=auto UMask=0022 LimitCPU=18446744073709551615 LimitFSIZE=18446744073709551615 LimitDATA=18446744073709551615 LimitSTACK=18446744073709551615 LimitCORE=18446744073709551615 LimitRSS=18446744073709551615 LimitNOFILE=4096 LimitAS=18446744073709551615 LimitNPROC=11860 LimitMEMLOCK=65536 LimitLOCKS=18446744073709551615 LimitSIGPENDING=11860 LimitMSGQUEUE=819200 LimitNICE=0 LimitRTPRIO=0 LimitRTTIME=18446744073709551615 OOMScoreAdjust=-900 Nice=0 IOScheduling=0 CPUSchedulingPolicy=0 CPUSchedulingPriority=0 TimerSlackNSec=50000 CPUSchedulingResetOnFork=no NonBlocking=no StandardInput=null StandardOutput=journal StandardError=inherit TTYReset=no TTYVHangup=no TTYVTDisallocate=no SyslogPriority=30 SyslogLevelPrefix=yes SecureBits=0 CapabilityBoundingSet=18446744073709551615 MountFlags=0 PrivateTmp=no PrivateNetwork=no PrivateDevices=no ProtectHome=no ProtectSystem=no SameProcessGroup=no IgnoreSIGPIPE=yes NoNewPrivileges=no SystemCallErrorNumber=0 RuntimeDirectoryMode=0755 KillMode=control-group KillSignal=15 SendSIGKILL=yes SendSIGHUP=no Id=dbus.service Names=dbus.service Requires=dbus.socket basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=dbus.socket systemd-journald.socket basic.target system.slice TriggeredBy=dbus.socket Documentation=man:dbus-daemon(1) Description=D-Bus System Message Bus LoadState=loaded ActiveState=active SubState=running FragmentPath=/lib/systemd/system/dbus.service UnitFileState=static InactiveExitTimestamp=Mon 2015-05-25 15:07:10 UTC InactiveExitTimestampMonotonic=29137297 ActiveEnterTimestamp=Mon 2015-05-25 15:07:10 UTC ActiveEnterTimestampMonotonic=29137297 ActiveExitTimestampMonotonic=0 InactiveEnterTimestampMonotonic=0 CanStart=yes CanStop=yes CanReload=yes CanIsolate=no StopWhenUnneeded=no RefuseManualStart=no RefuseManualStop=no AllowIsolate=no DefaultDependencies=yes OnFailureJobMode=replace IgnoreOnIsolate=no IgnoreOnSnapshot=no NeedDaemonReload=no JobTimeoutUSec=0 ConditionResult=yes ConditionTimestamp=Mon 2015-05-25 15:07:10 UTC ConditionTimestampMonotonic=29126164 Transient=no user@debian:~$

* Существуют так называемые шаблонные юниты, каждый экземпляр (instance) которых вообще не существует как файл. Например:

user

user@debian:~$ systemctl status getty@tty1 ● getty@tty1.service - Getty on tty1 Loaded: loaded (/lib/systemd/system/getty@.service; enabled) Active: active (running) since Mon 2015-05-25 15:07:12 UTC; 13min ago Docs: man:agetty(8) man:systemd-getty-generator(8) http://0pointer.de/blog/projects/serial-console.html Main PID: 1059 (login) CGroup: /system.slice/system-getty.slice/getty@tty1.service ‣ 1059 /bin/login -- user@debian:~$

* Есть множество свойств, которые по своей природе сугубо runtime, например, время, когда сервис был запущен, или его статус.
* Юниты могут быть в /lib, /run и /etc, а в каждом из этих каталогов могут быть подкаталоги вида юнит.d с переопределениями, в которых может быть множество файлов. Предлагаешь просматривать всё это, да ещё и в нужном порядке? systemctl cat существует не просто так:

user

user@debian:~$ systemctl cat dbus --no-pager # /lib/systemd/system/dbus.service [Unit] Description=D-Bus System Message Bus Documentation=man:dbus-daemon(1) Requires=dbus.socket [Service] ExecStart=/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig OOMScoreAdjust=-900 # /run/systemd/system/dbus.service.d/50-CPUQuota.conf [Service] CPUQuota=42% user@debian:~$

Дело не в миллисекундах. Дело в объёме и сложности выполняемого кода и, как следствие, вероятности появления в нём ошибок. Ибо сказано: KISS.

Такова плата за все те преимущества, что даёт использование стандартного решения.
Кроме того, ещё не известно, где вероятность ошибки больше: в большом стандартном решении, которое используется и таким образом всячески тестируется на самых разных конфигурациях во множестве проектов, или в небольшом частном решении, которое используется и тестируется только тобой.

[Bizdelnick]

Да я и не собираюсь спорить, что systemd позволяет решать кучу проблем, до появления systemd не существовавших.

[yars]

А еще Кэй пишет udev

Писал, теперь пишет systemd-udev. А сам udev мертв, но есть eudev, uselessd и некоторые другие проекты, которые сделают то же, что systemd, только лучше.

[Rootlexx]

Моя позиция основана на заявлениях Леннарта. И подкпреплена цитатами из него же.

Нет, ваша позиция, касающаяся logind и Canonical, основана на вашей вольной интерпретации заявлений Леннарта и на взятых с потолка предположениях. Ложность того и другого я уже показал, и в этом может убедиться любой независимый наблюдатель, обладающий достаточными знаниями английского и "матчасти", пройдя по моим ссылкам или найдя свои источники. Независимо от вашего признания сего факта.
Меня удивляет другое: почему вы сами пальцем не пошевелили, чтобы проверить собственные высказывания? Неужели было так трудно набрать в Google "ubuntu logind" и найти всю нужную информацию, в том числе эту статью (на русском!), в которой написано ровно то, что я писал вам, только подробнее. Также в этой статье есть ссылка на предупреждение Леннарта, в котором он пишет:

While using the mechanisms such as localed, hostnamed, timedated outside of systemd proper is certainly feasible (and we list them as such on our interface stability/portability chart in the +systemd wiki) doing the same for logind is, well, to say the least, tough...

The interfaces logind, and especially libsystemd-logind expose practically breathe systemd-specific functionality. For example, they are closely bound to the name=systemd cgroup hierarchy. Then, logind will auto-spawn getty services on the VTs, via systemd bus commands. It does shutdown/reboot with systemd services, and much more. Wanting to support that without actually running systemd, that's not going to be fun... It basically means you need to set up a systemd-like environment in quite some detail, without actually setting up systemd itself.

Что полностью согласуется с тем, что я говорил про изначальную разработку logind без расчёта на его использование вне systemd, и не согласуется с вашим "а ещё более вероятным" предположением обратного.

Если Вы в этом видите ложь и противоречия - этим всё сказано, значит, его заявления действительно противоречивы и неоднозначны.

Если в вашем понимании его заявлений присутствуют "ложь и противоречия", то есть два варианта:
1. Заявления Леннарта "лживы и противоречивы".
2. Ваше понимание его заявлений неверно.
Почему вы сразу приняли первый вариант в качестве единственно верного, а возможность вашей ошибки даже не рассматриваете? Ведь проверить собственные заявления - плёвое дело. Я, например, уже несколько раз загружал LiveUSB Debian 8, чтобы проверить работу предложенных мной service-файлов, попробовать собрать systemd без logind, отключить его и т. д., дабы не быть голословным.

Если бы вы хоть немного потрудились почитать по теме

Читал в своё время. В статье Леннарта честно пытался найти подтверждение нужности systemd лично для меня, а заодно найти подтверждение правоты Леннарта и, соответственно, моей неправоты. Не нашёл ни того, ни другого.
Далее пробовал решить конкретную задачу. Опять не увидел ничего такого, ради чего стоило бы устраивать миграцию. Столь крупные изменения в системе как те, которые предлагает проект systemd требуют соответствующих затрат по переходу (переобучение и т.п.). Для всяких затрат нужны основания. Я их честно искал и не нашёл. И вообще, я достаточно потратил времени на совершенно ненужный мне предмет.

Заканчивайте передёргивать. При чём тут всё это к ссылке, что я повесил на слово "потрудились"? К разговору о Canonical и logind?
И, кстати, миграция с Debian на Slackware в связи с переходом первого на systemd по умолчанию затрат и переобучения не потребовала?

Да я и не собираюсь спорить, что systemd позволяет решать кучу проблем, до появления systemd не существовавших.

Всего лишь красивая фраза, не содержащая никакого конкретного фактического смысла. Отличный способ что-нибудь ответить, когда ответить нечего.
Зато это хороший пример, иллюстрирующий главную проблему таких вот критиков systemd, в своё время - udev (помню-помню все эти дискуссии в стиле "У меня в /dev есть файлы устройств на все случаи жизни, и так всё работало уже много лет, зачем мне эта лишняя сущность, которую ещё и изучать надо?", хоть и менее жаркие - но и пользователей тогда было намного меньше) и ещё много чего, к чему сейчас все привыкли и пользуются. Проблема эта заключается в лишь поверхностном погружении в суть вопроса. На первый не особо вдумчивый взгляд всё кажется таким простым и понятным: накатаем скрипт, напишем цикл, убъём все процессы или выставим права на сокет - и всё, проблема решена. И это даже иногда может работать. Вот и не видят такие критики сути: systemd привносит то же, что в своё время привнесли менеджеры пакетов после ./configure && make && make install: систематизацию подхода. (Кстати, объединение процессов (hint: файлов) в одну логическую единицу: сервис (hint: пакет), выражение связей между логическими единицами в виде зависимостей между сервисами (hint: пакетами) - ничего не напоминает?) Да, это влечёт за собой наличие функциональных возможностей для решения проблем, с которыми вы лично скорее всего не сталкивались. Однако из этого вовсе не следует, что их "до появления systemd/upstart/whatever не существовало". (Упомянутый upstart тоже был создан для решения этих проблем, а вовсе не просто так на пустом месте, и с отведённой ему ролью в основном справлялся, и жаль, что из-за своей огороженности (CLA) не взлетел: конкуренция это хорошо.) Так что я могу понять, если вам лично systemd не нужен, но дистрибутивы, принимая решения о переходе, ориентируются не исключительно на ваши личные потребности, такова жизнь. И для перехода на systemd у них были свои основания, общую суть которых я и пытаюсь вам объяснить. До того же, чем там вы лично пользуетесь, мне нет никакого дела, равно как и наоборот.
Думаю, в ближайшие годы systemd никуда не денется, и если что и придёт ему на смену, так что-нибудь ещё более функциональное и совершенное, а уж никак не "обратно на sysvinit". (Посмотрим, лучше ли из меня предсказатель, чем из тебя :-).)

А еще Кэй пишет udev

Писал, теперь пишет systemd-udev.

Стало быть, пока udev был отдельно от systemd, Кэй был молодец и писал хороший и полезный udev, а как только udev перенесли в systemd, Кэй квантовым скачком стал коряво писать страшный, кривой и бесполезный systemd-udev. Я всё правильно понял?

А сам udev мертв, но есть eudev, uselessd

Ахах. Посмешили, спасибо. Только забыли сказать, что Debian мёртв, а есть Devuan (или как его там).

[Hephaestus]

Заканчивайте передёргивать. При чём тут всё это к ссылке, что я повесил на слово "потрудились"?

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

Я мог недостаточно разобраться в конкретном вопросе (logind и Canonical), допустим здесь я неправ (я действительно глубоко не вникал), но это не значит, что во всём остальном я тоже автоматически неправ.
Я уже говорил, есть факт безответственного отношения к багам со стороны команды systemd.
И этот факт зафиксирован даже не мной, а другими людьми, чьё мнение гораздо ценнее моего.
С моей точки зрения, это единственная серьёзная проблема у команды systemd - слишком легкомысленное отношение к большому и сложному проекту. Именно это я и утверждал в первую очередь. Всё остальное - частности.

И, кстати, миграция с Debian на Slackware в связи с переходом первого на systemd по умолчанию затрат и переобучения не потребовала?

Это были другие цели и, соответственно, другие затраты.
Миграция на Slackware произошла не только из-за systemd. Systemd был не единственной и даже не главной причиной. Главной причиной было то, что некоторые программы нужно было собирать из исходников, так как не устраивали версии из репов. Число таких программ постепенно увеличивалось и я задумался о переходе на дистр, более ориентированный на такой режим работы. Выбирал между Slackware и Gentoo.
Slackware привлекала больше, как один из первых дистров, ну и ручное разруливание зависимостей тоже вызывало интерес. Поэтому мое решение о миграции было ещё до того, как systemd утвердили системой инициализации по умолчанию. Я уж почти год как на Slackware перешёл. А Debian когда на systemd перешёл?

[yars]

пока udev был отдельно от systemd, Кэй был молодец

Да, так и было

страшный, кривой и бесполезный systemd-udev

Ну, может и не страшный и не совсем бесполезный, но если у разработчиков systemd есть большое желание патчить ни в чем неповинное ядро, когда systemd заспамливает очередь сообщений ядра, вызывая при этом панику последнего, я склонен думать, что первый таки кривой. Да, Кай тоже человек, и Линус тоже человек, может быть, излишне категоричный, но в данной ситуации прав Линус, разве нет?
И таки да, udev мертв, поскольку теперь он интегрирован в systemd. А альтернативные реализации - это хорошо. На волне ажиотажа вокруг systemd для Slackware начали адаптировать как сам systemd, так и openRC и Runit. Глядишь, со временем появится что-то получше systemd.

[Red Gremlin]

есть факт безответственного отношения к багам со стороны команды systemd.

«А был ли мальчик?» ©
Багзилла не совсем показатель, там чего только не встречается и кто только не заходит, не думаю, что я бы вёл себя тихо и культурно при виде откровенной чуши в тексте бага и явно неадекватного баг-репотртера. Но я глянул тут для интереса пакеты в дебиане и генту, в дебиане накладывают около 200 патчей, из них примерно 3/4 являются бэкпортом из апстрима, часть оказывается дебиано-специфичной и буквально несколько можно считать сторонними патчами вне апстрима. Подобная же ситуация в генте — патчи появляются и дропаются с появлением одной из следующих версий systemd. Так что, как минимум, с разработчиками дистрибутивов работа ведётся плотная и их баги апстрим охотно чинит.

[Red Gremlin]

И таки да, udev мертв, поскольку теперь он интегрирован в systemd.

Рукоплескаю. А md5sum, надо полагать, мёртв, потому что является частью coreutils?

но есть eudev, uselessd и некоторые другие проекты, которые сделают то же, что systemd

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

[Hephaestus]

«А был ли мальчик?» ©

Был. Ссылка есть выше.

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

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

[yars]

Red Gremlin
Аналогия не та. Чего непонятного: раз udev прекратил свое существование как отдельный проект, значит он мертв. А systemd-udev - это совершенно другая программа, предшественником которой был udev.

eudev даже не является форком udev, всего лишь небольшим патчсетом, позволяющим собирать udev вне дерева сорцов systemd

Для этого есть другой способ, а eudev таки форком является.