Леннарт Поттеринг, ведущий разработчик перспективной системы инициализации systemd (http://www.opennet.ru/opennews/art.shtml?num=26447), рассказал (http://0pointer.de/blog/projects/systemd-update.html) о ключевых достижениях в разработке данного программного продукта:- В настоящее время systemd уже принят в состав выпуска Fedora 14 и отлично зарекомендовал себя в предварительном тестировании, поэтому скорее всего именно он будет использоваться в Fedora 14 в качестве системы инициализации по умолчанию.
- Добавлены новые конфигурационные единицы (юниты): timer-юниты для активации событий по таймеру (в стиле cron), swap-юниты, позволяющие централизованно управлять swap-разделами и swap-файлами, и path-юниты, обеспечивающие реагирование на события inotify (например, изменение заданного файла или появление файлов в определенном каталоге).
- Реализована поддержка SELinux: создаваемым объектам (каталогам, сокетам, FIFO) автоматически присваиваются корректные метки безопасности.
- В...URL: http://0pointer.de/blog/projects/systemd-update.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=27721
Впечатляет. Только вот штука получаться уж больно навороченная. Интересно насколько проста и прозрачна она будет для пользователя.
Больше пугает пихание всего, чего только можно, в один демон. Работа всей ОС будет от него зависеть. Будем рады ошибиться, но как-то это не по unixway'у.Ещё и отсутствие необходимости наличия шелла объявлено труЪ-путём. Что ж, теперь стартовые скрипты будет уже вот так запросто не прочитать и не поправить?
P.S. Оригинальную документацию не читали, согласны, что это могут быть пустые тревоги... Но могут быть и нет..
"отсутствие необходимости наличия"
Эээ..?
ввиду присутствия отсутствия наличия на этапе загрузки человекочитаемого кода возникают определённые опасения.
действительно впечатляет, попробовать что ли...
Также благодарность переводчику!
>Особый интерес эта возможность представляет для встраиваемых систем, в которых теперь можно обходиться вообще без демона системного логаДа ви шо? А ничего что он с собой dbus и libxml тянет которые как-то существенно больше банального syslog :]
> А ничего что он с собой dbus и libxmlНадеюсь, когда нибудь Святая Инквизиция приравняет создателя XML к антихристу. Такие шутки, как XML, раньше себе мог позволить отпускать только дьявол.
XML сам по себе вещь хорошая. Но как и любой инструмент, его можно применять не правильно.
sauron, ну злодей
XML не идеален, но он является универсальным средством описания иерархии и структуры данных. Я, например, не знаю адекватной замены ему. Ты наверняка тоже.
Lisp-списки существовали задолго до XML-ов, и продолжают существовать и теперьЕсли кто-то чего-то не знает - то надо этому учиться, а не радоваться незнанию
>Lisp-списки существовали задолго до XML-ов, и продолжают существовать и теперьИ что? Они более читаемы, чем XML? Нет. В них есть спец. синтаксис для описания внутренних ссылок? Нет. Может быть они при сериализации занимают меньше места? Да, немного. Из-за отсутствия имени закрываемого элемента в конце. По этой же причине невозможно установить, у какого конкретно элемента пропущена закрывающая скобка.
>Lisp-списки существовали задолго до XML-ов, и продолжают существовать и теперьДа, кстати. Если хочешь заменить XML, заодно придумай замену для сопутствующих технологий: XSLT, XPath, XPointer, DTD. Удачи ;)
>>Lisp-списки существовали задолго до XML-ов, и продолжают существовать и теперь
>
>Да, кстати. Если хочешь заменить XML, заодно придумай замену для сопутствующих технологий:
>XSLT, XPath, XPointer, DTD. Удачи ;)Папа, а зачем нам всё это в зоопарке? В смысле, в системе начальной инициализации?
>Папа, а зачем нам всё это в зоопарке? В смысле, в системе
>начальной инициализации?Конкретно тут может и незачем. Так речь-то шла об универсальности XML в широком смысле. По твоему лучше иметь зоопарк форматов хранения данных?
А также существенное значение имеют известность, популярность, распространённость среди пользователей и разработчиков ПО некоторого средства представления данных, наличие большого количества инструментов для работы с ним.
> Я, например, не знаю адекватной замены ему.www.yaml.org
>www.yaml.orgOK. Осталось подождать широкого внедрения.
Опять придется читать многотомный талмуд, чтобы отключить или включить сервис при загрузке.
То груб2, то апстарт. Какая-то нехорошая тенденция.
>То груб2, то апстарт. Какая-то нехорошая тенденция.upstart то еще нормально. Но в нем до сих пор не выпилен слой совместимости с sysvinit причем, при отключении этого слоя нет возможности банально выключить или перезагрузить компьютер.
>Опять придется читать многотомный талмуд, чтобы отключить или включить сервис при загрузке.Чтобы сказать systemctl enable/disable, достаточно прочитать небольшой man systemctl.
Что-то, IMHO, запахло глобализацией и mono-полизацией.
All-In-One... Следующим шагом будет графическая оболочка?
Следующим шагом можно будет загрузить Grub 3 и работать сразу в нём )
Для чтения текстовых файлов на extX или ntfs разделе уже не требуется грузить систему) grub2 вполне справляется с файловыми системами и русскими кодировками ;)
>Что-то, IMHO, запахло глобализацией и mono-полизацией. All-In-One...Вы любое монолитное ядро вспомните (linux, solaris, *bsd) - вот это действительно суперкомбайн.
На их фоне systemd выглядит на редкость узкоспециальной тулзой.
>Следующим шагом будет графическая оболочка?Не поверите, она уже есть. В смысле, гуевая настроечная тулза для блондинко-админов.
Ну плазмоиды к systemd появятся наверняка ;)
если учесть что разраб openrc подался в касту геймеров, то это очень хорошая новость.
он судя по блогу просто свалил на openbsd, если мне память не изменяет. но openrc продолжают пилить, так что не все так плохо. авось таки и дождемся baselayout-2 с нардами и библиотекаршами.
ну и сколько секунд занимает загрузка системы?
>ну и сколько секунд занимает загрузка системы?Ещё до выпуска первой версии systemd грузил fedora за ~20 секунд, а upstart - за ~30.
Сечас, наверное, systemd ещё быстрее стал.
Разработчики Убунты сделали же хорошую весч upstart. А редхатовцам, блин, свое нужно сделать.
А если учесть, что этот Поттеринг главный разработчик pulse-audio, то совсем уже грустно становтся.
От upstart же systemd отличается более высокой степенью параллелизации, и как следствие, более высокой скоростью загрузки. Например, если демон A требует для работы сокет, открытый демоном B, то upstart сначала запустит демона B, а затем демона A, в то время как systemd создаст сокет сам и запустит обоих демонов одновременно, что занимает примерно в два раза меньше времени. Используемый в upstart принцип, когда ключевыми событиями является лишь запуск и остановка демона, Леннарт и его коллеги считают изначально неэффективным. http://www.linux.org.ru/view-news.jsp?tag=upstart
И демон А упадет :)
попробуйте сделать connect на unix socket когда на другой стороне никто не слушает ?
быстро получите connection refused ;-)
А дальше зависит от того как это обработано - будет ли А долбиться постоянно или нет.
Это не FIFO ;-) с FIFO такой трюк прошел - с unix socket - нет.
Это раз.запуск 2х паралельных демонов будет быстрым только при 2х CPU, в случае одного CPU или когда второе ядро это эмуляция через HT (представьте себе еще такие есть) - будет так же или медленее.
Это два.И по сути - RedHat как обычно пропихивает разработки нужны только в серверном сегменте. Не заботясь о домашних пользователях. Ровно так же как пропихнули свой шедулер, вместо шедулера который написал Колинс - который лучше работает на домашних машинках, но на серверах ведет себя хуже.
Вот так то.
>попробуйте сделать connect на unix socket когда на другой стороне никто не слушает ?Вы бы документацию чуть-чуть почитали, прежде чем других жизни учить.
Все сокеты принадлежат systemd, и он перенаправляет запросы демонам только в том случае, если демон жив. Если нет - демон запускается, а на время его запуска инфа лежит в буфере.
Этот подход протестирован в Mac OS X launchd и показал великолепные результаты.upstart и близко такой гибкости и надежности не обеспечивает, кстати.
>в случае одного CPU или когда второе ядро это эмуляция через HT (представьте себе еще такие есть) - будет так же или медленее.
Если вас послушать, таким системам и upstart будет злейшим врагом (он ведь тоже использует параллельный запуск, хотя и не так эффективно).
А на деле - systemd даже на однопроцессорных системах позволяет, пока инициализация службы чего-нибудь ждёт, запускать другие службы.
>И по сути - RedHat как обычно пропихивает разработки нужны только в серверном сегменте.
Да ну? А зачем серверам, которые годами работают без перезагрузок, быстрый процесс загрузки? А тот факт, что проект хостится на freedesktop.org, вам ни на что не намекает?
>Ровно так же как пропихнули свой шедулер, вместо шедулера который написал Колинс - который лучше работает на домашних машинках, но на серверах ведет себя хуже.
Это было решение Линуса и Ко - для них linux является прежде всего серверной системой.
да да почитать документацию ;-)
php в режиме fcgi создает сокет - nginx к нему конектится. и где тут systemd ? ;-)
а что делать с сокетами которые вобще не имеют отображения на файловой системе ?:)
Может он еще и tcp сокет на себя возьмет ?:) прикинется сервером и тп..
Сказочник вы ;-)>А на деле - systemd даже на однопроцессорных системах позволяет, пока инициализация службы чего-нибудь ждёт, запускать другие службы.
На деле даже старый system-v style позволял все запускать в паралель.
Как только процес форкнулся - дальше пошли по очереди запускать.
пока первый запускается - смотрим кто у нас дальше.
посматривая на бритву окама - выходит что systemd никому не нужен ;-)
а делается RedHat для своих целей.>Ровно так же как пропихнули свой шедулер, вместо шедулера который написал Колинс - который лучше работает на домашних машинках, но на серверах ведет себя хуже.
>Это было решение Линуса и Ко - для них linux является прежде всего серверной системой.И сотрудник RedHat Индиго - совсем к этому руку не приложил ?:) опять сказочник вы ;-)
"мне тут индиго сказал что он доделает свой шедулер - а посему нафик нам второй"
>php в режиме fcgi создает сокет - nginx к нему конектится. и где тут systemd ? ;-)systemd не является монополистом по сокетам, и не запрещает создавать сокеты другим программам. Другое дело, что в большинстве случаев программы не смогут управляться с этими сокетами столь же эффективно. Поэтому Леннарт и озаботился написанием документации по правильной разработке демонов с учетом возможностей systemd.
>а что делать с сокетами которые вобще не имеют отображения на файловой системе ?:)
>Может он еще и tcp сокет на себя возьмет ?:) прикинется сервером и тп..Вы не поверите, но именно так он сейчас и запускает sshd и многие другие сетевые сервисы.
Сама идея не нова - см. (x)inetd. systemd лишь предоставляет большую гибкость в настройке, и xinetd ему явно проигрывает (собственно, именно из-за недостатка гибкости (x)inetd так и не стал системой инициализации по умолчанию для всех сетевых служб).>На деле даже старый system-v style позволял все запускать в паралель.
Отнюдь не всё. sysv и upstart не обучены эффективно использовать возможности сокетов, и поэтому проигрывают systemd и launchd по времени раза в два.
>посматривая на бритву окама - выходит что systemd никому не нужен
Бритва Оккама говорит, что sysv место на серверах, systemd - на десктопах, а upstart - на помойке.
>И сотрудник RedHat Индиго - совсем к этому руку не приложил
Если разработчик из rh написал хороший серверный планировщик задач, не вижу тут ничего предосудительного.
За Линусом оставался выбор - включать в ядро тот или иной планировщик или нет.
Или вы утверждаете, что rh шантажировал Линуса его интимными фотками, чтобы продавить "свой" шедулер?
ты действительно не различаешь запуск через [x]inetd и в обычном режиме?
Тогда стоит перечитать ;-)
демон запускаемый через inetd - по сути даже не демон, а просто приложение которое читает stdin пишет в stdout, и запускается каждый раз когда требуется соединение.
Можно ускорить запуск за счет однократной загрузки - но нельзя передать сокет приложению если оно не умеет принимать его.
Так что рассказывать сказки многие могут, но есть реальные ограничения которые не обойти.А на счет планировщика - Линукс имеет немалый объем акций в RedHat, так что будет делать в первую очередь то что приносит ему профит :) Это было хорошо заметно и раньше, если были конкурирующие разработки - то преимущество давалось ребятам из RH так как в них он не сомневается ;-)
>ты действительно не различаешь запуск через [x]inetd и в обычном режиме?Разве я говорил, что standalone и inetd-режимы - это одно и то же? Фантазируете.
>запускается каждый раз когда требуется соединение
Даже такой примитив, как xinetd, умеет оставлять процессы и использовать их повторно.
>нельзя передать сокет приложению если оно не умеет принимать его
Да, авторы таких приложений достойны сожаления.
К счастью, среди служб, запускаемых при инициализации системы, подобных уродцев немного, и стараниями Леннарта и его компании становится всё меньше.>есть реальные ограничения которые не обойти
Есть проблемы, которые можно решить, только и всего.
>А на счет планировщика - Линукс имеет немалый объем акций в RedHat
Если вам это не нравится - юзайте *bsd, solaris или windows, им пофигу на rh.
>>ты действительно не различаешь запуск через [x]inetd и в обычном режиме?
>
>Разве я говорил, что standalone и inetd-режимы - это одно и то
>же? Фантазируете.перечитайте первый пост мой ;-)
я привел пример php в режиме fcgi & nginx :) то что принципиально не имеет inetd режима, а вы зачем-то его приплели, и вспомнили sshd который этот режим умел изначально.>
>>запускается каждый раз когда требуется соединение
>
>Даже такой примитив, как xinetd, умеет оставлять процессы и использовать их повторно.
>ага, щааас. по требованиям к этому "протоколу" - процесс обязан вызвать exit по концу обработки :)
может у вас какая-то паралельная вселенная - где exit не убивает процес ?
>
>>нельзя передать сокет приложению если оно не умеет принимать его
>
>Да, авторы таких приложений достойны сожаления.
>К счастью, среди служб, запускаемых при инициализации системы, подобных уродцев немного, и
>стараниями Леннарта и его компании становится всё меньше.LOL. php-fcgi & nginx достойны сожаления и являются уродцем? да у вас самомнения слишком много ;-)
Можно для примера взять любой другой набор - досточно что бы приложение не крутилось в бесконечном цикле пытаясь законектится.>
>>есть реальные ограничения которые не обойти
>
>Есть проблемы, которые можно решить, только и всего.:-) можно решить - но паралельности от этого не добавится.
Можно мониторить создание объекта (сокета, fifo и тп) - которые являются признаком конца инициализации. Но ничего революционного тут не добавляется - определение очередности и не более того.>
>>А на счет планировщика - Линукс имеет немалый объем акций в RedHat
>
>Если вам это не нравится - юзайте *bsd, solaris или windows, им
>пофигу на rh.А вас устраивает что есть привилегированная контора - которая тестирует продукт на кроликах и продает потом исправление ошибок за деньги ?
>я привел пример php в режиме fcgi & nginxА я в своем ответе заметил, что такие приложения работают неэффективно.
>php-fcgi & nginx достойны сожаления и являются уродцем?
Совершенно верно. Defective by design (c). Баба Шура и то лучше с сокетами работает =)
Впрочем, Леннарт их скоро пропатчит.А авторов можно понять - когда они писали свой софт, из реализаций такого подхода был только убогий xinetd.
>да у вас самомнения слишком много ;-)
Самомнение не нужно. Здравый смысл рулит.
>Можно мониторить создание объекта (сокета, fifo и тп) - которые являются признаком конца инициализации.
Это подход в стиле upstart, тоже defective by design.
В стиле systemd - самостоятельно создавать такие объекты. В результате клиент может отправлять сообщения, не дожидаясь завершения инициализации сервера.>А вас устраивает что есть привилегированная контора - которая тестирует продукт на кроликах и продает потом исправление ошибок за деньги ?
Вы так говорите, как будто это что-то плохое.
Отличная бизнес-модель, позволяющая коммерческим клиентам для своих серверов получать стабильный софт, а простым юзерам для их десктопов - свежие версии.
Мда.
вы меня извените - но подход который реализован в inetd - никаким боком не подходит для нагруженого сервиса - которым является nginx :)
Даже не хочется смеяться.
Все написавшие почтовые сервера, www/ftp сервера, дефективны по дизайну - прошу простить но это ничего кроме смеха не вызывает.
Давайте вы мне расскажете почему введение дополнительной прослойки ввиде stdin/out поверх сокета - лучше прямого чтения из сокета ;-)
А так же расскажите что постоянные fork + exec грузят машину слабее чем preforked или вобще обработка в одном потоке :-)
А так же расскажите что обработка в одном потоке тысяч сокетов - это быстрее чем обработка каждой группы сокетов в своем приложении :)
смешно ж..
>амомнение не нужно. Здравый смысл рулит.Простите но со здравым смыслом тут как раз таки проблемы ;-)
Методы которые применимы для слабо нагруженых сервисов - коим является sshd/telnet/etc.. слабо подходит для сильно нагруженых - почтовых серверов и тп.
> Вы так говорите, как будто это что-то плохое.
>Отличная бизнес-модель, позволяющая коммерческим клиентам для своих серверов получать стабильный софт, а простым юзерам для их десктопов - свежие версии.А вас устраивает ситуация что для того что бы получить стабильный софт надо обязательно платить деньги?
Почему-то до ядер версии 2.6 прекрастно обходились - стабильная и нестабильная ветки..
А вот после появления 2.6 доходы RH поползли в гору..
>вы меня извенитеИзвиняю, вы все равно не поняли моей мысли.
>но подход который реализован в inetd - никаким боком не подходит для нагруженого сервиса - которым является nginx
Совершенно верно. Поэтому ее совершенно необязательно применять во время работы сервера.
Но что касается запуска - подход inetd в реализации systemd дает большую скорость подъема всех служб, и поэтому более эффективен. Достаточно, чтобы nginx (или кто там еще) смог принять сокет от systemd и корректно обработать запросы из него, после чего он может запускать и организовывать свои процессы и потоки как ему заблагорассудится.>Все написавшие почтовые сервера, www/ftp сервера, дефективны по дизайну
Очень многие сервера умеют работать в inetd-стиле. Гораздо больше, чем вы думаете.
>А вас устраивает ситуация что для того что бы получить стабильный софт надо обязательно платить деньги?
Я юзаю centos и никому ничего не плачу. ЧЯДНТ?
Блин.. ну как вам объяснить что сокет может быть унаследован только чилдом после форка :)
ну еще и между тредами. может вы таки почитаете книги по программированию в unix системах?в остальном сокет как и файловый дискритор - ЛОКАЛЬНЫЙ ОБЪЕКТ ДЛЯ КАЖДОГО ПРОЦЕССА.
для обхода этого ограничения был сделан inetd style, но он никогда не рекомендовался для тяжело нагруженных приложений так как накладные расходы на создание 1 сокета (1 файлового дискритора) и 3х (1 сокет + stdin/stdout для приложения) - это совсем разные вещи :)Для 20 последовальных соединений это фигня, а вот для 20к уже нет или для 100к. (если мой склероз не изменяет - структура описывающая файловый дискритор занимает в памяти 500 байт - теперь оцените расходы в 50мб ядерной памяти, или 150мб - при том что в 32bit режиме весь объем ядерной памяти ограничен 300мб, остальное это highmem, vmalloc area и тп)
Поэтому не один из сервисов которые расчитаны на работу с такими потоками - не делают как inetd style.
Возмем для примера прокси сервера (squid/oops), web, балансировщики нагрузки и тп.
Так что upstart это клева - может быть, но не применимо там где высокая нагрузка :)
>Блин.. ну как вам объяснить что сокет может быть унаследован только чилдом после форка :)
>может вы таки почитаете книги по программированию в unix системах?Может, вы таки почитаете документацию по systemd?
Он и запускает службы через fork+exec. Это же не systemv init, там нет шелл-костылей.
(Точнее, поддержка костылей есть, но только для обратной совместимости.)Это НЕ inetd-style в чистом виде (хотя и он поддерживается, для sshd, например).
>>Даже такой примитив, как xinetd, умеет оставлять процессы и использовать их повторно.
>ага, щааас. по требованиям к этому "протоколу" - процесс обязан вызвать exit по концу обработки :)
>может у вас какая-то паралельная вселенная - где exit не убивает процес ?Почитайте про опцию wait в man xinetd.conf. Говорят, она работает и в нашей вселенной.
>Разработчики Убунты сделали же хорошую весч upstart.Они сделали ужасную вещь. Как это обычно делается в ubuntu.
>А редхатовцам, блин, нормально нужно сделать.
//fixed
>А если учесть, что этот Поттеринг главный разработчик pulse-audio, то совсем уже грустно становтся.
Заметим, что за пределами ubuntu на pulseaudio никто не жалуется. Что как бы наводит на мысли.
>>Разработчики Убунты сделали же хорошую весч upstart.
>
>Они сделали ужасную вещь. Как это обычно делается в ubuntu.
>
>>А редхатовцам, блин, нормально нужно сделать.
>
>//fixedредхатоцам надо сделать как удобно им на серверах.
>
>>А если учесть, что этот Поттеринг главный разработчик pulse-audio, то совсем уже грустно становтся.
>
>Заметим, что за пределами ubuntu на pulseaudio никто не жалуется. Что как
>бы наводит на мысли.вы не пробывали набрать skype + pulseaudio в google? ругань на кривую эмуляцию oss по всему инету и что автор сказал ? правильно - исправлять ошибки не буду - пусть skype правит.
или конфликты pulse vs alsa и тпВобщем pulseaudio это первое что отключается при установке, а потом уже жить можно.
>редхатоцам надо сделать как удобно им на серверах.Freedesktop.org - именно здесь разрабатывается ведущее серверное ПО! Бггг.
>вы не пробывали набрать skype + pulseaudio в google? ругань на кривую
>эмуляцию oss по всему инету и что автор сказал ? правильно
>- исправлять ошибки не буду - пусть skype правит.Разработчик pulseaudio отказался исправлять ошибки в skype? Всё правильно сделал.
Пускай сперва исходники выложат.>Вобщем pulseaudio это первое что отключается при установке ubuntu
На самом деле, при установке ubuntu нужно отключить очень многое, чтобы нормально жить.
Так много, что проще сразу другой дистр поставить.
>>редхатоцам надо сделать как удобно им на серверах.
>
>Freedesktop.org - именно здесь разрабатывается ведущее серверное ПО! Бггг.
>
>>вы не пробывали набрать skype + pulseaudio в google? ругань на кривую
>>эмуляцию oss по всему инету и что автор сказал ? правильно
>>- исправлять ошибки не буду - пусть skype правит.
>
>Разработчик pulseaudio отказался исправлять ошибки в skype? Всё правильно сделал.
>Пускай сперва исходники выложат.разработчик pulseaudio отказался исправлять ошибку oss эмуляции в своем детище.
Если вам так страшно skype, давайте вернемся к более открытому детищу - vlc, тоже требует специально заточки под pulseaudio:
>>>VLC
If you are having audio problems with the audio playback of DVDs in VLC, uninstall VLC and install the vlc-nightly package from the AUR, and set the audio output method to Pulseaudio.
Alternative: vlc-pulse from AUR.
>>>mplayer тоже не мог работать с тем вариантом oss который предоставлял pulse.
да, сейчас эти программы дописали прямую работу с pulseaudio - но это не мешает говорить что oss эмуляция там сделана дерьмово.
>
>>Вобщем pulseaudio это первое что отключается при установке ubuntu
>
>На самом деле, при установке ubuntu нужно отключить очень многое, чтобы нормально
>жить.
>Так много, что проще сразу другой дистр поставить.Да ? а почему тогда в Fedora и RHEL4/5 тоже приходилось отключать pulseaudio ?
Тоже карма плохая?
>VLC
>If you are having audio problems with the audio playback of DVDs
>in VLC, uninstall VLC and install the vlc-nightly package from the
>AUR, and set the audio output method to Pulseaudio.
>Alternative: vlc-pulse from AUR.Разработчики vlc таки решили проблему. Это вам не скайп.
>mplayer тоже не мог работать
Судя по прошедшему времени, разработчики mplayer не отстают от разработчиков vlc.
Из того, что эта проблема возникла в нескольких приложениях, и в них же была и пофикшена, можно сделать однозначный вывод, что она состояла в использовании недокументированных возможностей и/или ошибок предшествующей реализации oss. Неудивительно, что Леннарт не захотел повторять ошибки предшественников.
>Да ? а почему тогда в Fedora и RHEL4/5 тоже приходилось отключать
>pulseaudio ?Вы не поверите, но в этих дистрах даже не приходится париться по поводу выхода звука. Все просто работает. В том числе и pulseaudio. Это же не убунта, авторы которой считают комп чем-то вроде резиновой женщины (для секса, а не работы и отдыха).
> Из того, что эта проблема возникла в нескольких приложениях, и в них же была и пофикшена, можно сделать однозначный вывод, что она состояла в использовании недокументированных возможностей и/или ошибок предшествующей реализации oss. Неудивительно, что Леннарт не захотел повторять ошибки предшественников.вы читаете что вам пишут?
Вам не приходит в голову что одинаковая проблема которая возникла в нескольких приложениях - это таки проблема не приложения, а эмуляции? И эту ошибку автор не признавал - но она есть. Можно оправдываться что это было раньше кривое я вот поправил - но факт что из-за переделок связаных с pulseaudio перестали работать почти все приложения работавшие с OSS.
И исправлена эта ошибка путем отказа от OSS и перехода на native pulseaudio, что стоило другим проектам работы, и все это только по тому что один чудак на букву "М" не признавал свою ошибку.
Wine не мог выводить звук, и тп. не много ли кривых проектов? один только pulseaudio прямой.
PS Ровно тот же эфект вызвала "починка" tty кода в ядре - когда отвалилось куча приложений - ksudo / emacs и тп. Тоже авторы приложений виноваты ?
> Вы не поверите, но в этих дистрах даже не приходится париться по поводу выхода звука. Все просто работает. В том числе и pulseaudio. Это же не убунта, авторы которой считают комп чем-то вроде резиновой женщины (для секса, а не работы и отдыха).вы не поверите - но в этих дистрибутивах пришлось выключать pulseaudio что бы в kde работал микшер и запись с микрофона.
>И эту ошибку автор не признавал - но она есть.Если бы так действительно было - проект бы уже давно форкнули. Или исправили ошибку в дистрибутивных патчах. Или просто выкинули из дистров.
На практике мы не наблюдаем ни того, ни другого, ни третьего. Следовательно, ваши домыслы необоснованны.Были программы, криво выводящие звук. Теперь это в них поправили. Вот и всё.
>вы не поверите - но в этих дистрибутивах пришлось выключать pulseaudio что бы в kde работал микшер и запись с микрофона.
Не поверю, конечно. У меня в centos/kde микшер нормально работал.
>>И эту ошибку автор не признавал - но она есть.
>
>Если бы так действительно было - проект бы уже давно форкнули.если он кому-то нужен. хотя на моей памяти уже вроде собираются писать замену ему.
> Или
>исправили ошибку в дистрибутивных патчах.вот народ говорит что в мандриве идет более 50 патчей на pulseaudio. видимо от хорошей жизни ;-)
И там совсем нет багов.> Или просто выкинули из дистров.
>На практике мы не наблюдаем ни того, ни другого, ни третьего. Следовательно,
>ваши домыслы необоснованны.да да, ниже вот народ говорит что кучи патчей в мандриве, постоянно звук плавает и неработает с некоторыми картами.
Видимо всем им мерещится?
>
>Были программы, криво выводящие звук. Теперь это в них поправили. Вот и
>всё.LOL - сотня программ и все неправильно. Может таки что-то в консерватории не то?
>
>>вы не поверите - но в этих дистрибутивах пришлось выключать pulseaudio что бы в kde работал микшер и запись с микрофона.
>
>Не поверю, конечно. У меня в centos/kde микшер нормально работал.Повезло :) вот ниже народ пишет что везет не всем и не всегда.
>если он кому-то нужен.Да-да, этот совершенно ненужный проект распихан по большинству дистров.
>уже вроде собираются писать замену ему.
И где можно скачать собранные пакеты этой замены? Или хотя бы тарбол?
>вот народ говорит что в мандриве идет более 50 патчей на pulseaudio.
А в centos их сколько, если не секрет? При том, что там все хорошо работает.
>Видимо всем им мерещится?
А я сейчас побегу по всем форумам кричать, что у меня в альсе звук плавает и карты не видятся (кстати, без шуток, звук из альсы напоминает совковый телефон). Это тоже типа научно установленная истина будет?
>LOL - сотня программ и все неправильно.
Решительно не вижу ничего смешного.
>Повезло :) вот ниже народ пишет что везет не всем и не всегда.
Ну да, конечно. Просто везение, ничего больше.
>>если он кому-то нужен.
>
>Да-да, этот совершенно ненужный проект распихан по большинству дистров.
>И? Миллионы мух не могут ошибаться? Или у редхата такой вес, что может продавить даже пульсаудио?
Чем конкретно не устраивала ALSA? Все работало как часы, никакой звук не отваливался. На самых разных машинах. Теперь куда не плюнь - везде особенности. Никогда не слышали треск вместо звуковой дорожки, ПРОСТО ПОТАСКАВ ПОЛЗУНОК ГРОМКОСТИ, БЛИН. И до перезагрузки любимого во все щели пульса. Не отрывается он из гнома нового, хоть плачь, хоть смейся. И разработчик - я все сделал правильно - а все остальные криворукие косорезы.
видимо skype и исправил, по тому как у меня отлично все пашет, общаюсь с многими и на работе и дома стоит пульс. А еще часто настраиваю себе музыку на блютуз а игры или телек на колонки для дочи тоже через пульс.
>видимо skype и исправил, по тому как у меня отлично все пашет,
>общаюсь с многими и на работе и дома стоит пульс. А
>еще часто настраиваю себе музыку на блютуз а игры или телек
>на колонки для дочи тоже через пульс.исправил, начиная с какой-то версии они включили native поддержку для pulseaudio.
но oss эмуляция как работала криво, так и работает.
>но oss эмуляция как работала криво, так и работает.Ну oss сейчас в линуксе мало кто использует, а вот задержка 200 мс напрягает, да. Как, впрочем, и ненужный слой апстракции, который непонятно что делает.
PS: может повторюсь, но в той же мандриве на пульс наложено около 90 патчей. Оно и понятно, автор получил деньги за разработку и дальнейшая судьба его детища ему мало интересна. А вот редхат бабло таки отбашлял и вряд ли признает, что сделал это зря. Поэтому продолжим кушать кактус.
cогласен в целом.А на счет OSS - как можно использовать то что глючит? Я чуть выше приводил примеры приложений которые пришлось переписать из-за несовместимости с тем режимом эмуляции который предлагает pulseaudio.
skype, vlc, mplayer, wine, xmms, audicaty (или как там его - клон xmms) ... все эти приложения изначально были заточены под oss, и прекрастно работают с oss при отключеном pulseaudio. Но как только pulse в памяти - начинаются чудеса и необходимость использовать pulseaudio plugin.
>Но как только pulse в памяти - начинаются чудеса и необходимость использовать pulseaudio plugin.Да там с альсой чудеса тоже случаются и даже с native pulse бывает иногда. Например, звук в mplayer ни с того ни с сего начинает "плавать" относительно изображения. А на некоторых звуковых картах так и вообще не работает. Разработчик, естественно, в курсе.
>Заметим, что за пределами ubuntu на pulseaudio никто не жалуется.Это только потому, что его там трудно выпилить со всеми потрохами. В остальных же дистрах он вполне отключается или вообще не ставится по дефолту.
Скажите, а хоть кто то есть кто смог завести это "чудо" на gentoo ? И если есть, то как? О_о
мдя....поковырял конфиги, почитал вики, обновили там....
Итог: Kernel Panic, и самое странное не понятно почему ?? , в логах ничего найти не могу...
Ядро 2.6.34
Я на генте поставил. Оно запускается в принципе, но до состояния, когда его можно будет использовать, еще ой как далеко.
Ubuntu за 5 секунд загружается и совместимость с init есть, зачем этот велосипед не понятно.
Для чего все эти пляски с загрузкой, панацея ???; для распространения Linux'а??? вряд ли это увеличит его долю; лучше бы игры пилили и не забивали себе и другим мозги.ПС: чисто моё мнение.
Для игр приставки существуют, или вы серьезно считаете, что линукс пилят, чтобы на нем было счастье хардкорным геймерам?
Совершенно идиотское замечание про приставки. Приставки,только для аркад, всяких казуальных игр.
>Ubuntu за 5 секунд загружаетсяУ вас, с минимальным набором служб, может, и пять, а у юзера Васи служб дофига, и ubuntu грузится полминуты. Думаю, он будет рад, если это время сократится в два раза.
>и совместимость с init есть,
Очень хреновая. В частности, upstart не понимает описания зависимостей в lsb-заголовках, и ему нужно указывать зависимости вручную. Если так и дальше "совместимость" развивать, то скоро upstart будет только выводить сообщение вроде "Ну вы сами там запустите, какие вам службы нужны, а я пойду в sleep".
>зачем этот велосипед не понятно.
Действительно, непонятно, зачем нужен upstart?
>лучше бы игры пилили и не забивали себе и другим мозги.
Замечательно! Вот и займитесь. И не забивайте себе и другим мозги.
Что то не совсем понятно про буфферизацию пакетов клиентских запросов... Теперь у серверов не будет возможности получать пакет сразу в свой буфер? Будет дополнительный memcpy?
Такой бы энтузиазм и на благие цели пустить.
>Такой бы энтузиазм и на благие цели пустить.Энтузиазмом тут и не пахнет. systemd делается за вполне хорошую зарплату. Вот сдаст Леннарт systemd и его кинут на следующий проект. Такое ощущение, что у редхат много денег и их надо куда-то потратить.