Переход Ubuntu на Systemd

[serzh-z]

Подозреваю, что fflatx не слушал отзывы Мойши и, уж точно, сам не заглядывал в код OpenSSL, который использует каждый день. При такой логике - он бы вообще предпочёл не использовать шифрование. =)

[Rootlexx]

и поэтому не следует использовать systemd?

Да, и поэтому нет смысла менять sysvinit на systemd!

Для всех? Или всё же для вас лично?
Ещё раз: если есть решение, предоставляющее дополнительную функциональность и имеющее некоторые преимущества, но при этом успешно выполняющее и задачи старого решения, то, учитывая интерес к первому со стороны значительного количества людей, а также технические преимущества (см. выводы Технического комитета Debian), имеет смысл сделать его решением по умолчанию. Если при этом старое решение никуда не исчезнет (как в Debian), то я в упор не вижу проблемы: те, кто хочет использовать новую функциональность, используют systemd; те, кто хочет проверенное временем решение, используют sysvinit; те, кому больше нравится upstart, используют upstart; а скоро ещё и openrc прибавится. При наличии выбора то, что стоит по умолчанию, не имеет большого значения.
А вообще, те, кто дистрибутив создают, имеют полное право определять пути его развития. Что-то часто в последнее время встречаются сообщения в стиле "разработчики должны". Open source работает не так. Если человек вкладывает в разработку свои силы и время, а потом выкладывает результат в публичный доступ, последнее, на что вы имеете моральное право, это что-то требовать. Право выбора у того, кто делает (см. http://www.communitywiki.org/cw/DoOcracy).

[Hephaestus]

Вне контекста рассматривать это не имеет смысла.

Независимо от контекста goto и константы хардкодом являются плохим стилем программирования.
Об этом уже столько писалось и говорилось, что даже странно видеть такое.
По стилю напоминает Флёнова (не к ночи будь помянут), в том смысле, что Леннарт пишет код, как Флёнов пишет свои книжки.

Не вижу в этом ничего плохого, если из контекста понятно, о чём речь.

Продукт с открытым кодом? Развиваться будет? Код изменяться будет?
Предполагается, что с этим кодом будут работать и другие люди? Или как?
Мысль мою улавливаете? То, что сегодня в коде понятно из контекста, завтра - сам Леннарт не разберётся, что к чему. А другие - тем более. Особенно в отсутствие комментариев. А Вы говорите - ничего плохого.

В общем, снова нужен контекст.

Если Вам нужен контекст - возьмите и посмотрите в контексте.
Однако, Вы наверняка в курсе, что функции - это подпрограммы, логически завершенные участки кода.
И преимущество их как раз в том, что они небольшого размера - чем меньше участок кода, тем проще его отлаживать и тем меньше в итоге ошибок (это кстати, один из принципов unix-way - "маленькое - прекрасно").
А отладив однажды, функция используется много раз.
Если же функция разрастается до нескольких тысяч строк, это как минимум значит, что человек не осилил декомпозицию. Впрочем, это не удивительно, учитывая, что оператор goto для него - в порядке вещей.

Ну да. [1], [2] (в последнем некоторые пункты к системе инициализации, используемой в Debian, применимы лишь частично).

Я так и не увидел, что же такого ужасного в sysvinit.
Те недостатки, которые там упоминаются, можно с таким же успехом приписать systemd, только с обратной стороны.

Равно как и достоинства systemd могут на деле оказаться недостатками.
Например: Одним из достоинств systemd предъявляется автоматический перезапуск упавших демонов.
А ничего, что нормальные демоны просто так не падают?
И кто вообще сказал, что упавших демонов нужно автоматически перезапускать?
А разбираться в причинах падения нынче уже не модно?
Скажем, кончилось место на разделе, демон рухнул, доблестный systemd его перезапускает, тот опять падает, поскольку места нету, его опять перезапускают...
И так до бесконечности. И это то самое сокровище, за которым мы сюда приперлись?(с)

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

...и поэтому не следует использовать systemd?

ИМХО: По крайней мере, не стоит торопиться делать его умолчальной системой, пока ещё автор не наигрался и не вывел свою поделку в стабильное состояние.
В этом смысле поучительно вспомнить ту же Пульсу, которая, ещё раз напоминаю, внедрялась в нерабочем состоянии и была допилена гораздо позже, когда автор её уже забросил. Но если Пульсу можно было игнорировать (то есть попросту не ставить), то умолчальную систему инициализации (да ещё завязанную на всё и вся, вплоть до ядра) игнорировать уже не удастся.
Поэтому, ещё раз говорю: торопиться не стоит. Стабильность системы дороже, согласитесь?

Кстати, о стабильности и всяких автоматических перезапусках.

Spoiler

Цитата из того же обсуждения

Простая ситуация - на диске два партишена, прописано автомонтирование в fstab при загрузе. Возникла необходимость изменить их размер - от одного отрезать, другому добавить. На диске они расположены рядом - правда, тривиальная задача? Останавливаю приложения, которые работают с этими партишенами, делаю нужные бэкапы, отмонтирую. Запускаю gparted, корректирую партишены и запускаю переразбивку.
И в _процессе_ работы gparted - ТАДДДАМ - умный (грёбаный) системд _МОНТИРУЕТ_ОБА ПАРТИШЕНА_ !!!!! Восстановление последствий этой «новой» логики заняло много времени...

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

Но я стесняюсь спросить - как близко то время, когда прежде чем запустить какой-нибудь du или df - мне нужно будет _обязательно_ читать документацию по системд - вдруг это уже часть «модульного» системд и старая логика работы заменена на «инновационную» - подсчет размера файла выполняется его чтением и грузит проц на 146% ?

Разумеется, можно усомниться, что в случившемся виноват именно systemd.
Однако, это весьма вероятно, если вспомнить, что systemd уже целиком вобрал в себя udev.

Кто-то может сказать, мол, за systemd такого не наблюдалось и вообще, УМВР.
Так в том-то всё и дело, что неизвестно, где и когда вылезут грабли.
А система инициализации с претензией на системный менеджмент - слишком обширная и серьёзная штука, чтобы можно было столь безалаберно относиться к этим вопросам.

Вспомните мою историю с LiveCD DrWeb, который удалил данные с диска. Несколько лет бага плавала незамеченной и всё работало нормально. А потом в один совсем не прекрасный день - бац! и готово.
Это яркий пример безалаберности разработчиков.

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

[Hephaestus]

Если при этом старое решение никуда не исчезнет (как в Debian), то я в упор не вижу проблемы: те, кто хочет использовать новую функциональность, используют systemd; те, кто хочет проверенное временем решение, используют sysvinit; те, кому больше нравится upstart, используют upstart; а скоро ещё и openrc прибавится. При наличии выбора то, что стоит по умолчанию, не имеет большого значения.

А вот это мы ещё посмотрим.
Если выбор действительно будет, то никаких проблем.
Только вот есть подозрение, что не будет никакого выбора. Будет примерно как KDE3 заменили на KDE4.
То есть для использования sysvinit придётся с треском выпиливать systemd.

А вообще, те, кто дистрибутив создают, имеют полное право определять пути его развития.

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

Что-то часто в последнее время встречаются сообщения в стиле "разработчики должны".

Ни в коем случае. Эти люди делают большую работу и предлагают к использованию свои результаты.
Пока эти результаты меня устраивают - я ими пользуюсь (раз уж предлагают).
Как только перестанет устраивать - перестану пользоваться. Всё очень просто.
Я нигде и ни разу не говорил, что разработчики мне что-то должны. Совсем наоборот.

[serzh-z]

Ох... Не получилось бы как с доктором Батти. =)

fflatx
Давайте не будем голословными... http://cgit.freedesktop.org/systemd/systemd/tree/src - можно примеры "плохого кода", ну кроме "ужасного goto, про который стооолько понаписано"? Ведь, наверное, этот плохой код не работает, верно?

[eddy]

Для всех? Или всё же для вас лично?

Для всех тех, кому лень заниматься переливанием из пустого в порожнее!
Седлайте своих коров сами. И скачите на них куда хотите! Флаг вам в руки и барабан на шею!!!

[Rootlexx]

Независимо от контекста goto и константы хардкодом являются плохим стилем программирования.

Это, мягко говоря, спорное утверждение. Весьма распространён следующий подход: goto допустимы при переходе вперёд, при выходе из многократно вложенных циклов и тому подобное. См. http://ru.wikipedia.org/wiki/Goto#.D0.9E.D....BD.D0.B8.D0.B5.
Также советую взглянуть: https://github.com/torvalds/linux/search?l=...o&source=cc.

То, что сегодня в коде понятно из контекста, завтра - сам Леннарт не разберётся,

Конкретно переменная r довольно часто встречается именно в таком контексте: возвращаемое значение. Точно так же, как i - счётчик. В том же OpenRC, который автор далее хвалит за качество кода, подобное тоже встречается. Да и sysvinit не исключение.

Однако, Вы наверняка в курсе, что функции - это подпрограммы, логически завершенные участки кода.
И преимущество их как раз в том, что они небольшого размера - чем меньше участок кода, тем проще его отлаживать и тем меньше в итоге ошибок (это кстати, один из принципов unix-way - "маленькое - прекрасно").
А отладив однажды, функция используется много раз.
Если же функция разрастается до нескольких тысяч строк, это как минимум значит, что человек не осилил декомпозицию.

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

Например: Одним из достоинств systemd предъявляется автоматический перезапуск упавших демонов.
А ничего, что нормальные демоны просто так не падают?
И кто вообще сказал, что упавших демонов нужно автоматически перезапускать?
А разбираться в причинах падения нынче уже не модно?
Скажем, кончилось место на разделе, демон рухнул, доблестный systemd его перезапускает, тот опять падает, поскольку места нету, его опять перезапускают...
И так до бесконечности.

Ну что вы опять по второму кругу? Я же вам уже объяснял совсем недавно:

Я с трудом представляю себе специалиста, который назовет объективной необходимостью тупой рестарт упавшего демона даже без попытки выяснить в чём дело.
А ведь systemd делает именно это, не так ли?

Документация - для слабаков?

Restart=
...
Takes one of no, on-success, on-failure, on-watchdog, on-abort, or always. If set to no (the default), the service will not be restarted.

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

Кроме того, параметры перезапуска настраиваются. См. http://www.freedesktop.org/software/system...md.service.html, директивы RestartPreventExitStatus, StartLimitInterval, StartLimitBurst и другие.

Только вот есть подозрение, что не будет никакого выбора. Будет примерно как KDE3 заменили на KDE4.
То есть для использования sysvinit придётся с треском выпиливать systemd.

Неужели так сложно открыть рассылку и почитать, о чём идёт речь, и какие варианты рассматриваются? Всяко лучше же, чем генерировать FUD.

[Rootlexx]

По крайней мере, не стоит торопиться делать его умолчальной системой

С этим, кстати, я частично согласен: мне было бы спокойнее, если бы systemd уже прошёл обкатку в серьёзных enterprise-дистрибутивах типа RHEL, но это пока не так.
С другой стороны, учитывая, что сама Red Hat считает его достаточно стабильным для следующей, седьмой версии RHEL, что SLES 12 также будет использовать systemd, а также то, что программа (особенно такая фундаментальная, как init) имеет ну очень мало шансов продраться в stable через sid и testing (особенно в период заморозки последнего) с критичными ошибками, есть уверенность, что systemd в следующем stable будет стабильным. По крайней мере, причин не доверять разработчикам Debian у меня нет.

[Hephaestus]

Это, мягко говоря, спорное утверждение. Весьма распространён следующий подход: goto допустимы при переходе вперёд, при выходе из многократно вложенных циклов и тому подобное.

Ну вроде бы уже давно известно, что от goto вреда больше, чем пользы и всё, что позволяет goto вполне реализуемо другими способами.
Пример, которые Вы привели - это, конечно, интересно, но... здесь есть разница.
Решение Линуса на момент написания не имело альтернативы. То есть не было второго ядра, с которым можно было бы сравнить и сказать, что лучше.
В случае с Леннартом альтернатива есть и даже не одна. Леннарт не создаёт ничего такого, без чего нельзя обойтись.
Поэтому Линусу - простительно. Леннарту - нет.

Конкретно переменная r довольно часто встречается именно в таком контексте: возвращаемое значение.

Это область домыслов и гадания на кофейной гуще.
Если автор не озаботился дать переменной информативное имя, не написал комментарии в коде и не дал какой-либо спецификации, то контекст своих переменных наверняка может знать только он. Остальные могут только догадываться. Ибо даже счетчики бывают наделены разным смыслом.

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

Возможно, но в приведенной мной цитате с ЛОРа говорилось о тысячах строк. Это уже слегка другое дело.

Хороший программист не тот, кто слепо следует принятым нормам, а тот, кто понимает, когда эти нормы применимы, а когда нет.

Вы до такой степени уверены в Леннарте? На основании чего, интересно?

Неужели так сложно открыть рассылку и почитать, о чём идёт речь, и какие варианты рассматриваются?

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

По крайней мере, причин не доверять разработчикам Debian у меня нет.

У меня тоже не было, до недавнего времени. А теперь есть.
Проблему с отмонтированием CD/DVD мы с Вами обсуждали, не так ли?
Вы тогда же сокрушались, по поводу хардкодинга и качества решений, толкаемых в апстрим. Было?

Второй пример (я о нём уже говорил) - gwc. Без пульсы не запускается, хотя при установке её не просил - в зависимостях её нет. Видимо, подразумевается, что Пульса стоит у всех. Однако зависимости на то и существуют, чтобы ничего не подразумевать, а указывать явно. Не так ли?

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

С этим, кстати, я частично согласен

Так это ж самое главное.
Я же и говорил об этом выше в данной теме: Куда торопиться? Зачем? Зачем ломать API? И т.п.

программа (особенно такая фундаментальная, как init) имеет ну очень мало шансов продраться в stable через sid и testing

О чём это Вы? Я не понял. systemd уже в stable. Куда ему продираться?

[Hephaestus]

Давайте не будем голословными... http://cgit.freedesktop.org/systemd/systemd/tree/src - можно примеры "плохого кода", ну кроме "ужасного goto, про который стооолько понаписано"? Ведь, наверное, этот плохой код не работает, верно?

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

Да, я ссылаюсь на мнение другого человека, но я этого и не скрывал.
На данном ресурсе, например, alv писал, что ему довелось поковырять systemd, на его мнение тоже можно ссылаться. Почему нет?

Копаться же в коде самому мне нет никакого резона, по той простой причине, что он (systemd) мне нафиг не нужен. Мне достаточно отзывов других людей, потому что systemd не есть компонент первой необходимости.

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

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

[Rootlexx]

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

Избавьте меня от необходимости повторять вам всё по несколько раз. Я вам написал, дал ссылку - извольте ознакомиться.
Что же касается реализации другими способами, то, конечно, введение новых переменных для завершения циклов намного изящнее и понятнее, ага. А финализация через многоэтажные if-else - что может быть прекрасней?

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

Думаете, эти 10 с лишним тысяч goto Линус лично расставлял, да ещё и "на момент написания", о чём сейчас сильно жалеет? Это более чем стандартный код для ядра. См. также [1], [2] (Chapter 7).

Если автор не озаботился дать переменной информативное имя

То есть выкидываем sysvinit, да?

Возможно, но в приведенной мной цитате с ЛОРа говорилось о тысячах строк. Это уже слегка другое дело.

Ну так продемонстрируйте функции на тысячи строк. Репозиторий systemd тут: https://github.com/systemd/systemd.

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

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

Зачем ломать API?

Спрошу ещё раз: какой API был сломан и когда?

О чём это Вы? Я не понял. systemd уже в stable. Куда ему продираться?

На пост системы инициализации по умолчанию. Думаю, не нужно объяснять, как тщательно будут её тестировать.

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

Думаю, проверку этим условием не выдержит ни один более-менее популярный продукт.

Да, я ссылаюсь на мнение другого человека

Было бы неплохо ссылаться на аргументированное мнение, а не на голословные утверждения.

[Hephaestus]

То есть выкидываем sysvinit, да?

Не выкидываем, а просто внимательно смотрим, что к чему. И не торопимся с решениями. Всего-навсего.

Ну так продемонстрируйте функции на тысячи строк.

Спрошу ещё раз: какой API был сломан и когда?

Ответы на эти вопросы сможет дать человек, которого я цитировал. Я не смогу.

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

На пост системы инициализации по умолчанию. Думаю, не нужно объяснять, как тщательно будут её тестировать.

Здесь я могу сказать только одно: поживем - увидим.
Я консерватор и если на сегодняшний день уже существует работающее решение, тем более, проверенное временем, то я бы не торопился менять его на что-то другое.
Сейчас наша дискуссия производит на меня странное впечатление. Как будто systemd вообще не имеет ошибок, а sysvinit - наоборот, содержит кучу ошибок и поэтому его срочно нужно заменить.
Так вот, позволю себе усомниться в том, что systemd лишен ошибок, а значит, эти ошибки будут проявляться.
Их количество и характер заранее неизвестны. Именно поэтому не стоит торопиться с принятием решений.

Думаю, проверку этим условием не выдержит ни один более-менее популярный продукт.

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

Было бы неплохо ссылаться на аргументированное мнение, а не на голословные утверждения.

А что Вам не нравится?
Человек с ЛОРа поковырял код, высказал мнение. Почему он должен что-то доказывать?
Я его процитировал, только и всего. Почему я должен что-то доказывать?
Почему Леннарт ничего не должен доказывать?
Почему мнение ЛОРовца голословно и требует подтверждения, а мнение Леннарта не подлежит сомнению?

Если бы Леннарт дал нечто новое и полезное, к нему бы не было никаких претензий. Потому что его поделка была бы единственной в своём роде. Как ядро Линуса.
Но Леннарт создает замену существующим решениям. Причём, работающим решениям. Зачем? Кто его просил? Вы можете мне сказать?
Он ведь не Бог, а человек, не так ли? Следовательно, может ошибаться. А значит, его решения в перспективе могут оказаться хуже, чем то, что есть сейчас.

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

[Bizdelnick]

Если при этом старое решение никуда не исчезнет (как в Debian)

Вот как раз в этом самая большая проблема. Если использовать sysvinit-скрипты, профит от systemd сомнителен, если подерживать и скрипты, и сервисы systemd, то это слишком большая нагрузка на сопровождающих. Остаётся вариант поддерживать только systemd, как делают во всех дистрибутивах, где его внедрили по умолчанию. Как раз из-за этого вопроса больше всего споров в Debian, а вовсе не из-за того, что по умолчанию будет.

[Red Gremlin]

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

Чего? init-скрипты порой десятилетиями не меняются, а если меняются, то незначительно.

Остаётся вариант поддерживать только systemd, как делают во всех дистрибутивах, где его внедрили по умолчанию.

Для примера возьму nginx в OpenSuSE. Начиная с 12.1 там systemd по умолчанию. 12.1 — nginx только init-скриптом, 12.2 — только скриптом, 12.3 — и скриптом и .service, 13.1 — и скриптом и сервисом, будущая 13.2 — пока и скриптом и сервисом. Так что далеко не все дистрибутивы спешат выкинуть поддержку sysv, даже перейдя на systemd, почему дебиан должен стать исключением?

[Bizdelnick]

Для примера возьму nginx в OpenSuSE. Начиная с 12.1 там systemd по умолчанию. 12.1 — nginx только init-скриптом, 12.2 — только скриптом, 12.3 — и скриптом и .service, 13.1 — и скриптом и сервисом, будущая 13.2 — пока и скриптом и сервисом. Так что далеко не все дистрибутивы спешат выкинуть поддержку sysv, даже перейдя на systemd, почему дебиан должен стать исключением?

Меж тем sysvinit в openSuSE официально не поддерживается с версии 12.3. Что инит-скрипты пока не из всех пакетов вычистили - ничего не значит.

[NickLion]

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

Выкиньте ядро. Да-да, в Linux полно goto, более того это поощряется:
https://www.kernel.org/doc/Documentation/CodingStyle см. Chapter 7.

[Женя Подсыпальников]

Chapter 7

Идея очень важная у раздела, достойная поощрения.
Жалко лишь, что способ её реализации таким представили

[NickLion]

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

С чего это вдруг? Оба проекта пишутся на языке Си, ничего лучше goto всё равно нет. Это же не C++, где конструктор/дестуктор сделал, RAII учёл и готово, goto не нужен?

Chapter 7

Идея очень важная у раздела, достойная поощрения.
Жалко лишь, что способ её реализации таким представили

Какая реализация на языке Си будет лучше?

[Женя Подсыпальников]

Какая реализация на языке Си будет лучше?

Конечно, С - ещё та кеся-меся...
Но я б, наверное, пожертвовал их "профитом" уменьшения нестинга

Оба проекта пишутся на языке Си

О... Разочарован, что оба... Представлял иначе...

[Hephaestus]

С чего это вдруг? Оба проекта пишутся на языке Си, ничего лучше goto всё равно нет.

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

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

Так вот с systemd может оказаться ровно то же самое (в смысле его нужности), но подозреваю, что "не использовать" будет значительно сложнее.
Вот в этом вся проблема.

[serzh-z]

Неужели так сложно открыть рассылку и почитать, о чём идёт речь, и какие варианты рассматриваются? Всяко лучше же, чем генерировать FUD.

Я заметил, что противникам PulseAudio/systemd свойственно вытеснение и отрицание: http://ru.wikipedia.org/wiki/%D0%92%D1%8B%...B3%D0%B8%D1%8F) - они не видят аргументов, не видят ссылок. Просто у человека возникла стойкая неприязнь и теперь он будет сраться до потери пульса, цеплясь за какие-то смешные чужие аргументации, а когда эти аргументации будут разваливаться, то будут делать вид, что ничего не проихошло и переключаться на следующую, опять же чью-то, аргументацию. =) Ну это как примерно, если кто-то мне начнёт расписывать удобство и преимущество макбуков и MacOS. Я могу логически понимать аргументы ЗА, но стойкая подсознательная неприязнь к Apple не позволит мне эти аргументы принять. =)

На данном ресурсе, например, alv писал, что ему довелось поковырять systemd, на его мнение тоже можно ссылаться. Почему нет?

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

[NickLion]

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

Обошёлся без каких-то настроек. По умолчанию в openSUSE, всё работает. А пока была ALSA я не мог победить flash, который захватывал монопольный доступ и пока не был закрыт, звук в системе не работал. Да, может если хорошо поработать напильником, это и можно было бы победить, но факт в том, что у меня Pulse работает из коробки, а ALSA — нет.

[alv]

Если при этом старое решение никуда не исчезнет (как в Debian)

Вот как раз в этом самая большая проблема.

На самом деле это как раз не проблема. Просто этого не может быть, потому что этого не может быть никогда
В том-то и дело, что systemd ни с чем более сосуществовать не может.
Именно поэтому так

делают во всех дистрибутивах, где его внедрили по умолчанию.

Научены опытом openSUSE: там на протяжении двух релизов можно было штатно переключаться с systemd на sysV и обратно
сначала это работало
то есть срабатывало один раз: можно было переключиться на sysV и жить беззаботно
если переключаться туда-сюда - рано или поздно начинались проблемы
в следующем релизе переключение на sysV создавало их сразу: при старте то звук отваливался, то сеть
в ещё следующем штатную возможность переключения убрали, но руками сделать это можно было - с тем же печальным результатом
подозреваю, что это можно сделать и в 13.1, не проверял, но результат, я думаю будет вааще.
Так что на счёт выбора не обольщайтесь, ребята.
Systemd - как блатхата: вход - рупь, выход - червонец

Для примера возьму nginx в OpenSuSE. Начиная с 12.1 там systemd по умолчанию. 12.1 — nginx только init-скриптом, 12.2 — только скриптом, 12.3 — и скриптом и .service, 13.1 — и скриптом и сервисом, будущая 13.2 — пока и скриптом и сервисом. Так что далеко не все дистрибутивы спешат выкинуть поддержку sysv, даже перейдя на systemd, почему дебиан должен стать исключением?

Меж тем sysvinit в openSuSE официально не поддерживается с версии 12.3. Что инит-скрипты пока не из всех пакетов вычистили - ничего не значит.

Совершенно верно. Потому что в системе, заточенной под systemd, sysV НЕ РАБОТАЕТ

[Hephaestus]

Я заметил, что противникам PulseAudio/systemd свойственно вытеснение и отрицание - они не видят аргументов, не видят ссылок.

Не совсем так. Пульсу я щупал по необходимости. Не понравилось.
Буквально на пустом месте возникли нестыковки, которые пришлось устранять.
Ради какой высокой идеи мне нужно было бы этим заниматься, я так и не придумал.
К systemd отношусь настороженно, отчасти потому, что автор тот же, что и у Пульсы, отчасти под влиянием отзывов, виденных в Сети (однозначного восторга не наблюдаю).
Ну и потому, что systemd - не просто какой-то там новый пакет, который можно было бы и не ставить, а целая большая неведомая хрень, которая предлагается как вариант по умолчанию и требует ознакомления, освоения, которая может содержать баги и вообще неясно, как будет работать.
Опять же, не могу придумать, для чего бы мне это было нужно. Мне гораздо дешевле остаться на том, что есть сейчас.

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

Консерватизм - не самый тяжкий грех.

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

Резюмируя, повторю ещё раз: Не нужно спешить с принятием решений, тем более таких, которые касаются всей системы. Вот и всё, чего бы мне хотелось. Неужели это много?

[Женя Подсыпальников]

Не нужно спешить с принятием решений

Не смог найти целевого адреса вести

[Bizdelnick]

serzh-z
Что, обсудим ещё и PA? Он, по-твоему, очень полезен?
Моё мнение таково: 1) единственный профит от него заключается в возможности независимой настройки звука для разных приложений, что бывает нужно нечасто; 2) если допустить, что такая настройка человеку нужна, ему придётся основательно посношаться с ужасным pavucontrol (другой морды не видел, а в нём улучшений за последние 5+ лет не заметил ни одного), а то и поправить конфиги вручную (во втором лично для меня ничего трашного нет, но это расходится с утверждениями многочисленных сторонников PA, что он just works). Учитывая, что это всего лишь прослойка поверх ALSA, которая представляется полезной только в отдельных случаях, зачем она везде по умолчанию ставится - не понимаю.

[Hephaestus]

Обошёлся без каких-то настроек. По умолчанию в openSUSE, всё работает. А пока была ALSA я не мог победить flash, который захватывал монопольный доступ и пока не был закрыт, звук в системе не работал. Да, может если хорошо поработать напильником, это и можно было бы победить, но факт в том, что у меня Pulse работает из коробки, а ALSA — нет.

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

[NickLion]

serzh-z
Что, обсудим ещё и PA? Он, по-твоему, очень полезен?
Моё мнение таково: 1) единственный профит от него заключается в возможности независимой настройки звука для разных приложений, что бывает нужно нечасто;

Хоть и не ко мне, но да очень полезен. Как уже говорил, только с PA я избавился от блокирования звука в системе. Это ещё один профит. Далее — возможность повысить уровень звука выше 100%. Да, программно, но для тихих источников без необходимости привлечения софта редактирования (особенно для видео актуально) — замечательная штука.

2) если допустить, что такая настройка человеку нужна, ему придётся основательно посношаться с ужасным pavucontrol (другой морды не видел, а в нём улучшений за последние 5+ лет не заметил ни одного), а то и поправить конфиги вручную (во втором лично для меня ничего трашного нет, но это расходится с утверждениями многочисленных сторонников PA, что он just works). Учитывая, что это всего лишь прослойка поверх ALSA, которая представляется полезной только в отдельных случаях, зачем она везде по умолчанию ставится - не понимаю.

Да, pavucontrol выглядит кривовато. Я обычно KMix использую. Все каналы есть, можно по одельности рулить и отключать что надо, менять уровень.

[alv]

Алексей - тот ещё консерватор

Нет, он просто довольно немолодой человек с очень хорошим иммунитетом против пропаганды. Приобретённым в советское время.
И там, где вы видите всякие технические мелочи, типа goto и unit'ов, он видит первопричину явления
потому что наблюдал это в жизни множество раз
а причина эта политическая: чтобы в нашем кошерном RHEL не было классово чуждого upstart.
Вот и всё.
А уж что это будет и кто это напишет - не важно
После этого начинается пропагандистская кампания в стиле:
ты против systemd? - значит, консерватор
ты не любишь Поттеринга? - ты против советской власти
ты не поёшь осанну systemd'у? - значит, ты против советской власти
примеры такого рода аргументации можно найти, не выходя за пределы этого топика
собственно, она вся к таким аргументам и сводится
так что обсуждать проблему systemd в техническом ракурсе - бесполезно
она возникла политически
и обсуждать её нужно с учётом того
а вот почему все ринулись на него переходить - это уже вопрос этнопсихологии
или, если угодно, этологии

PS в общем, кажется, надо написать мне последний памфлет на эту тему - и занести слово systemd в свой мысленный блэк-лист
чтобы лет через 5-7, если доживу, удовлетворённо сказать: а ведь я предупреждал...

[Bizdelnick]

только с PA я избавился от блокирования звука в системе.

Сталкивался с подобным у ALSA, но это было давно. Неужели до сих пор встречается?

возможность повысить уровень звука выше 100%

ИМХО это не фича, а баг. Мои бедные уши такого издевательства не переносят (когда жена в vlc задирает громкость выше 100%, это люто бесит). Кому медведь по ушам потоптался ещё сильнее, чем мне, - могу лишь посочувствовать.