В Debian 8 «Jessie» будет оставлена возможность использования других систем инициализации вместо Systemd

Мне лично он полезен за счет:

Software mixing of multiple audio streams, bypassing any restrictions the hardware has.

Именно «like». Это обычный sysvinit с упрощённым лэйаутом скриптов. К слову, в той же OpenBSD (например) стартовые скрипты гораздо аккуратнее, чем у Патрика.

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

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

http://elinux.org/images/d/d1/Alexandre_Belloni_boottime_optimizations.pdf

Дебиан - универсальный дистр.

Как видно из текста выше, для планшетов он не вполне подходит. Анонимусы испытывают неудобство.

Software mixing of multiple audio streams

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

Именно «like». Это обычный sysvinit с упрощённым лэйаутом скриптов.

Собственно, а что ещё требуется?

Собственно, а что ещё требуется?

Точность формулировок, не? :)

Ага. «Сделай мне динамическую загрузку, и dlopen не в счёт». Отличный слив.

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

На контекст обсуждения посмотри, толстенький.

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

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

Ты случайно ответил не на тот тезис.

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

Ты обосрался и теперь тонкий? Давай, расскажи что там с контекстом.

Под гуем ты имеешь ввиду Xorg? Если да, то абсолютно согласен.

Сам посмотри. Я опровергал суждение о том, что разработчик, не осиливший graceful degradation в случае отсутствия некоторого интерфейса на шине, обязательно быдлокодер. А именно: бывает так, что этот интерфейс нужен для базовой функциональности программы.

Допустим, есть программа-гуй для настройки времени. Она может позвать /bin/date через sudo, может слинковаться с какой-нибудь либой, а может позвать timedated по шине. Во всех трёх случаях graceful degradation ты не сделаешь.

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

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

Их можно запускать от рута, можно из них через sudo запускать конкретные консольные тулзы, а можно по шине звать systemd-*d с авторизацией через polkit. Я утверждаю, что первый подход неприемлем, а второй плохо масштабируется.

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

речь шла о нужности. gimp, ardour, blender, sublime text и т.п. — нужны. смена хостнейма — не интересна.

Демон исключительно для того, чтобы слушать шину. Это не демон в привычном смысле слова, т. к. он запускается on-demand и тут же останавливается. Подход «sudo + консольная тулза» хуже масштабируется и менее гибок, чем «polkit + шинный демон».

Нет, речь не шла о нужности. Речь шла о том, чтобы привести пример обоснованной «привязки» любого приложения к какому-нибудь из API systemd (или вспомогательных, типа того же hostnamed).

Сам посмотри. Я опровергал суждение о том, что разработчик, не осиливший graceful degradation в случае отсутствия некоторого интерфейса на шине, обязательно быдлокодер. А именно: бывает так, что этот интерфейс нужен для базовой функциональности программы.

Допустим, есть программа-гуй для настройки времени. Она может позвать /bin/date через sudo, может слинковаться с какой-нибудь либой, а может позвать timedated по шине. Во всех трёх случаях graceful degradation ты не сделаешь.

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

1. Вызов /bin/date через sudo? Проверяем наличие /bin/date, проверяем наличие sudo в $PATH, проверяем код возврата вызова.

2. Линковка с либой? dlopen/dlsym/dlclose, если нужна graceful degradation

3. Вызов timedated по шине - опять же проверять коды возврата вызовов (или другим методом, который предоставляет эта шина). Я никогда не работал с timedated, но если вдруг там окажется не предусмотрено механизма сообщения об ошибках вызовов, или если шина не может сообщить, что такого вызова нет, то зачем таким говно-API вообще пользоваться?

Ты только что сам описал graceful degradation для данного сценария. Чего тут нельзя сделать то? Попробовал по шине вызвать говноД-API. Зафейлилось? Попробовал либу открыть? Зафейлилось? sudo + /bin/data? Зафейлилось? Можно сообщить и пользователю, что никак не получается, всё перепробовал, «проблемы на вашей стороне» (ц). Перебор методов в любом угодном тебе порядке делай. А лочиться на говноД-only - для быдлокодеров

я для тебя скопировал:

<<Что основного или хоть на микрон необходимого может предоставить этот интерфейс, без чего прикладной софт не сможет обойтись?>>

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

Это проблемы терминологии. «Прикладной» в твоём понимании софт (который браузеры, офисные пакеты и видеоредакторы) от API systemd никогда не зависел и вряд ли будет. А вот настроечный и служебный софт (я тоже считаю его прикладным, т. к. не ядро и не core userspace) — да.

Т.е. boulder здесь - имя хоста, на котором пользователю dgb разрешено выполнять указанные программы в роли пользователя operator.

Поправил, не благодари.

А, ну да. Вечно путаю.

MPD - это «настроечный» или «служебный» софт?

http://www.youtube.com/watch?v=LLk9_EH6Pfo

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

С multiseat я не сильно знаком, но вроде это и до говноД как-то делалось. Тут главный вопрос - зачем эту логику запиливать в инит, почему нельзя это вынести в отдельный демон, который также мог бы работать с говноД, а мог бы и без него?

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

Я в упор не вижу «привязки к системе инициализации». Все эти интерфейсы спроектированы так, чтобы их можно было независимо заимплементить (см. systembsd). Следовательно, чтобы не получалось xkcd://Standards, в прикладных приложениях стоит использовать только этот интерфейс, а плюрализм должен достигаться посредством независимых реализаций.

Я предвосхищаю вопрос вида «а чем этот интерфейс лучше уже существующего sudo /bin/date, что нужно именно его всем использовать?». Ответ таков: важно не то, чем он лучше (потому что преимущества могут быть видны не всем), а чем он хуже. Отсюда встречный вопрос: чем он хуже?

Кхм, так и сделано. logind — отдельный демон, который общается с инитом по опубликованному стабильному API. Проект systemd-shim (в сабже) как раз тем и занимается, что позволяет запускать logind с другими инитами.

А при чём тут mpd? Он уличён в жёсткой зависимости от systemd?

Следовательно, чтобы не получалось xkcd://Standards, в прикладных приложениях стоит использовать только этот интерфейс, а плюрализм должен достигаться посредством независимых реализаций.

Ответ таков: важно не то, чем он лучше (потому что преимущества могут быть видны не всем), а чем он хуже. Отсюда встречный вопрос: чем он хуже?

ты сам не видишь, что сам себе противоречишь?

Где? В упор не вижу.

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

:: ~ » apt-cache depends mpd | grep systemd
  Depends: libsystemd-daemon0

Оно, конечно, пока ещё сидит в сторонке и молчит в тряпочку, но чем чёрт Лёнчик не шутит.

Отсюда встречный вопрос: чем он хуже?

Хуже он тем, что ЛП любит ломать интерфейсы. «Stable API is a nonsense» (ц) же ведь. Только что можно кернел-девелоперам, говнокодерам не положено. Вон, API logind уже намеренно (т.е. конечно же «из-за крайней необходимости») сломали после того, как в Ubuntu его переимплементили для Upstart.

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

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

А это единственный бэкенд? Нет? Вызови другой. Ни один не заработал? Значит «работать дальше» = «сообщить о проблеме/ошибке».

Следовательно, чтобы не получалось xkcd://Standards, в прикладных приложениях стоит использовать только этот интерфейс, а плюрализм должен достигаться посредством независимых реализаций.

Следовательно, надо игнорировать говноД и использовать нормальные интерфейсы.

jack

потерингохейтерам из треда в тред нужно объяснять одно и тоже.

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

По твоей ссылке весь юзерленд - одно приложение.

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

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

Я бы посоветовал подучить матчасть. libsystemd-daemon — это «интерфейсная» библиотека для оповещения systemd о готовности демона. Она по определению ничего не делает на системах без systemd.

Откуда вещества? Я могу сказать, что не «намеренно», а «вынужденно», ввиду переработки cgroups в ядре.

он уже изобретён

Ага, ща погодь, изобрету ещё один интерфейс, а ты потом всё под него переписывай, он же «уже изобретён».

arguably более гибкий

Аргументы?

более гибкий

Вот тут подробнее.

Я считаю, что дбас+polkit+timedated гибче, чем «sudo /bin/date». По аналогии для всего остального.

Я понял что ты так считаешь, но не понял почему.

Как по мне использование трёх трудных в отладке сложных сущностей хуже чем использование двух простых в отладке простых сущностей.

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

Я считаю, что дбас+polkit+timedated гибче, чем «sudo /bin/date». По аналогии для всего остального.

Чем оно гибче? Или тут вариант ответа «гибче, чем sudo»? LOL

По каким критериям оно гибче?

Это у тебя проблемы с логикой, иначе бы ты не притащил решение из мира встроенных систем в тред про десктоп. Загрузи мне кде или гном и всю их обвязку (иксы и т. п.) за секунду, потом кричи про важность времени загрузки ядра, которое в десктопных системах составляет не более 10% общего времени. Как называется твоя мегабыстрая система инициализации на шелловских скриптах? А то, вон, в генте openrc, как раз голимые шелловские скрипты, сливает systemd в разы. Ох, уж эти лоровские сказочники...

библиотека
для оповещения systemd о готовности демона

Эээ... сокеты? ДИБАС, на худой конец? Зачем тащить с собой ажно цельную отдельную динамически подгружаемую библиотеку, которая в итоге ничего не делает?

и жду на 10 секунд

Однозадачный? :)

Вечером ткнул кнопку, пошел кефиру выпил - опа а он уже загрузился. Утром ткнул кнопку, пошел умылся - опа а он уже загрузился.

Зачем пялиться в монитор и ждать биос, загрузчик, ведро, загрузку DE? Инит на десктопах во времени общей загрузки это не такое уж узкое место... А уж если ssd...

Спящий режим работает через раз на моем железе

чем хвалишься то? :)