Чем так плох systemd?

бардака в rc.d/

Вот не надо.

LSB headers чем-то хуже?

Логическая структура у сервисов - дерево, если не вообще произвольный граф, ориентированный и без циклов. А rc.d/* - это нумерованный список. Отображение одного в другое - это костыль. Он не отражает реальной структуры. И казалось бы именно тут вы должны были бы кричать про лишние сущности.

LSB headers могут быть, а могут не быть. При этом утилиты читающие эти заголовки раздают сервисам номера от балды. Итоговые номера зависят от порядка установки и от набора сервисом в системе.

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

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

Именно поэтому systemd и принимают везде достаточно единогласно.

Ну давай, опровергни мой бред. А то вот я решил поставить этот systemd, расхваленный, а он зараза не грузится, потому что dbus библиотечки какой-то не может найти, которая лежит на /usr, который ещё не подмонтирован.

Можно и /bin/sh так собрать, что без /usr работать не будет. К мейнтейнеру дистрибутива претензии свои обрати, ок? Что им мешало dbus в корень положить?

systemd создаёт лишний геморой => systemd на помойку

Твой дистрибутив создаёт лишний геморой => твой дистрибутив на помойку.

Это когда инит не просто запускает демон, но и следит за его дальнейшей работой (например, перезапуская при падении или повисании). Ведь это есть в сабже? Если нет, то проку от него мало.

Жаль только, что никто не сможет перезапустить systemd при его «падении или повисании».

Падающие сервисы не нужны.

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

Слушайте, ну хватит эти сказки рассказывать уже? Основное время загрузки десктопной машины всегда уходит на: BIOS, иксы, DE. Какой systemd? Какая быстрая загрузка? Какие инновации? Что вы тут чушь несёте с гордым видом?

как просто и надежно реализовать включение/выключение запуска сервиса из GUI/при установке пакета? Или «простому человеку» все это не нужно?

Совершенно верно. «Простому человеку» вообще не нужно устанавливать пакеты. У нас тут не ондроед с ангри бёрдс.

Речь о том, как надежно реализовать в pre/postinst скриптах внесение изменений в скрипт, в котором в принципе может быть намешано что угодно.

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

перечислением в текстовом файле или созданием/удалением симлинков.

Ознакомьтесь с системой запуска демонов да в дебиане хотя бы. Симлинки! Инновационный дизайн!

Для нормального сисадмина, который всё-таки прочитал в оригинале, чем плох отдельный /usr, systemd - это удобный, эффективный и очень качественно документированный инструмент.

Смешались в кучу люди, кони... При чем тут /usr? Какое отношение имеет к systemd? Ах да, обе идеи растут из редхата, ну конечно. Прямая связь!

набирает ругательства

не суди о людях по себе.:-)

я те так скажу - в солярке отдельный /usr - в обещм-то, зло, и давно.:)

Пруф или не было.

щито? O_o

Основное время загрузки десктопной машины всегда уходит на: BIOS, иксы, DE.

4.2. BIOS даже без Quick Boot отрабатывает секунд за 5, X'ы грузятся 3 секунды. Загрузка от init'а до консоли у меня раньше занимала секунд 40, после перехода на systemd - 8. Выключение после остановки иксов - 5, сейчас - почти мгновенно.

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

при полной неочевидности выгод.

Как же можно быть таким упертым...

Ты не понял.
«Неочевидность» это значит УМВР и мне хорошо. А тут внезапно бабах - надо курить маны, хотя лично для меня ничего не изменилось.

Загрузка от init'а до консоли у меня раньше занимала секунд 40, после перехода на systemd - 8.

Это исключительно проблемы твоего дистрибутива или твоих рук. Если у тебя сначала грузится 100500 демново, а только потом запускаются иксы, то кто тебе виноват?

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

Да, потому то у systemd бинарные файлы вместо скриптов. И править их с помощью vi, который сидит в initrd, это мученье, если вообще возможно, т.к. требуется перекомпиляция.

У тебя же /sbin/fsck, /bin/mount и т.п. — бинарники, не так ли? Часто приходится их править с помощью vi? Точно так же бинарные части systemd не нуждаются в правке. А то, что может нуждаться в правке, и так является текстовыми файлами (например, все юниты). Никаких бинарных файлов вместо скриптов systemd не содержит.

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

при упоминании поттеринга брызжут слюной со времен pshhhhaudio

кому нужна голая система?

Оно уshhhhе давshhhhно не пshhhhhhh...

но осадок-то остался

при упоминании поттеринга брызжут слюной со времен pshhhhaudio

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

а чем так плох PulseAudio?

Ничем. PulseAudio крайне хорош.

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

~/.asoundrc вполне себе это позволяет сделать, и не только это. Просто кое-кто, видимо, ниасилил

Кстати, а чем так плох PulseAudio?

тем, что его начали пихать в дистрибутивы, когда он был глючным падучим уг. Да, в этом больше вина мейнтейнеров, чем поттеринга, но тем не менее.

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

кому нужна голая система?

Извращенцам, ЕВПОЧЯ.

«ALSA is like the emperors new clothes. It never works, but people say it’s because you’re a noob.»

It never works

а по пунктам?

а, нашёл

On-the-fly output device switching: In “the old days”, you could plug in a headset and the hardware would disconnect the speakers and play through the headset only. Today, the headset might be Bluetooth or USB, so no such hacks are possible. PulseAudio lets you handle this in software!

кто мешал сделать нормальную гуйню для руления конфигом алсы (ну и научить применяться на лету)?

Per-application volume control: The ability to turn up the music without also turning up the IM notification sounds.

у звуковых приложений обычно есть регулировка громкости

If you use MPlayer with ALSA for example, 9/0 adjusts the system-wide volume, not just MPlayer’s.

4.2, -softvol кто-то ниасилил

Automatic muting of other audio on incoming phone calls, such as through Skype

да, этого alsa не позволяет (на первый взгляд)

Audio forwarding: Like X11 forwarding? Me too. With PulseAudio, you can also get application audio over the network. pax11publish lets you set PulseAudio settings like network forwarding per-display!

а для сети у меня есть jackd

Networked audio: You can transmit audio from one (or more) apps to another box.

Load Spotify on your laptop and play it via the media center’s speakers!

см выше

Combine two stereo cards into one 4 channel device. The cards don’t even have to be on the same computer!

.asoundrc

Use the monitor device to record application audio, or connect it to a visualizer

для более-менее профессиональной работы со звуком один хрен нужно использовать jackd

Загрузка от init'а до консоли у меня раньше занимала секунд 40

Это же что надо было с ситемой делать, чтобы так долго грузилась, если не секрет?

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

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

Кстати, а чем так плох PulseAudio?

Хотя бы тем что у меня в нем глючит звук в i386 софте. К счатью он легко удаляется, пока.

Wine и VLC регулярно пшикают. Причём во втором случае всё лечится самопроизвольно после N-го запуска, а в первом нужно в конфиг пульса прописывать параметр, ломающий звук в других приложениях. Очень надёжная штука, да.

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

Дык в линуксах же всё так.

Что с системд, что без него полная загрузка - 1 минута ровно.

кому нужна голая система?

не совсем голая, но я предпочитаю когда на серверах нету KDE или Unity

Я тоже Гном3 предпочитаю.

Кому и зачем это нужно?

Это нужно всем, кто не имеет желания внезапно обнаружить, что какой-то сервис тихо помер неделю назад. Вообще, когда заходит речь об альтернативных SysV системах (runit, daemontools), service supervision обычно является первым аргументом в сравнениях. Любой инит без этой фичи слегка ущербен (и не надо мне говорить про inittab).

Если демон падает или зависает, надо его чинить, а не перезапускать.

Да-да, давай, почини сервис, который падает по вине железки, для которой норма жизни производить ЭМИ, спокойно вырубающее USB-порт, который слушает демон :) И это один из великого множества возможных примеров.

Да-да, давай, почини сервис, который падает по вине железки, для которой норма жизни производить ЭМИ, спокойно вырубающее USB-порт, который слушает демон :)

значит, надо экранировать комп, а не systemd всякие придумывать

значит, надо экранировать комп, а не systemd всякие придумывать

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

Во-вторых, я вообще в своём комментарии systemd не упоминал.

Видишь ли в чем дело, service supervision, запуск по зависимостям, запуск по требованию, журналирование, multiseat support и т.п. — это всё РАЗНЫЕ функции.

init должен предоставлять service supervision, хорошо, ладно, так уж линукс устроен, что не-init-у это будет делать не совсем сподручно. А остальные велосипеды нафига?

Что появится следующее, systemd научится проигрывать звук? Или раздавать ip-адреса?

Что появится следующее, systemd научится проигрывать звук? Или раздавать ip-адреса?

тихо!!! вдруг поццерингу эта идея понравится? :) ))))

Ещё раз: я не защищаю systemd, я критикую sysvinit, причём исключительно по части service supervision, остальное меня совершенно устраивает. К systemd пока отношусь с сомнением. Будущее покажет, нужен ли он.

у меня и на десктопах нет KDE/Unity :)

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

вместо решения действительно важных проблем

Это каких?