Леннарт Поттеринг (Lennart Poettering), сотрудник компании Red Hat, создавший в свое время звуковой сервер PulseAudio, официально представил (http://lists.freedesktop.org/archives/systemd-devel/2010-Jul...) первый релиз системного менеджера systemd (http://www.freedesktop.org/wiki/Software/systemd). systemd является альтернативной системой инициализации Linux, вобравшей в себя достоинства классического System V init и более современных launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, Fedora), но при этом лишенной многих их недостатков.
systemd (system daemon) реализует принципиально новый подход к инициализации и контролю работы системы. Одним из ключевых новшеств этого подхода является высокая степень параллелизации запуска служб при инициализации системы, за счет активного использования возможностей сокетов, что в перспективе позволяет добиться гораздо более высокой скорости, чем традиционный подход с последовательным запуском взаимозависимых служб, используемый, на...URL: http://lists.freedesktop.org/archives/systemd-devel/2010-Jul...
Новость: http://www.opennet.ru/opennews/art.shtml?num=27218
>>Также подготовлены сборочные скрипты для дистрибутивов Arch и Gentoo.На лоре такой срач устроили в теме "OpenRC ищет нового разработчика" (Gentoo), а как оказалось для генту есть свежая альтернатива.
Что-то я восторга не разделяю, запускать по мере надобности службы это круто, и запускать не последовательно тоже не плохо. Но после перелистывания мануала как-то не впечатлился.
>Что касается Ubuntu, то разработчики этого дистрибутива не проявили никакой >заинтересованности в проекте, и поэтому поддержка инфраструктуры и готовые >пакеты для данного дистрибутива отсутствуют.Так какой им смысл менять шило на мыло, если upstart себя прекрасно зарекомендовал?
Вообще, это парад суверени^wcистем инициализации, последее время, стал меня настораживать. Что-то одно доделайте уже да? ;)
Сколько еще велосипедов нам предстоит увидеть?
>Так какой им смысл менять шило на мыло, если upstart себя прекрасно
>зарекомендовал?Пусть работает гораздо медленее, пусть умеет на порядок меньше, но зато своё, родное.
>Вообще, это парад суверени^wcистем инициализации, последее время, стал меня настораживать. Что-то одно
>доделайте уже да? ;)
>Сколько еще велосипедов нам предстоит увидеть?Естественный отбор, знаете ли, работает тем лучше, чем больше доступных вариантов.
>>Пусть работает гораздо медленее, пусть умеет на порядок меньше, но зато своё, родное.У вас так долго грузятся init скрипты? У меня в Debian/upstart они грузятся за 5 секунд, это при том, что комп перезагружается раз в неделю. Вам жалко 5 секунд? А монтирование on-demand и прочее не создаст ли ситуацию с загрузкой как в винде? Типа рабочий стол уже появился, но пользоваться им нельзя, т.к. эта умная система инициализации подгружает потроха, которые ей было лень подгрузить сразу во время работы init.d скрптов. Тогда нафик эту систему, которую ещё попоробуй подебаж - это ж уже совсем не скрипт rc.
>У вас так долго грузятся init скрипты? У меня в Debian/upstart они
>грузятся за 5 секунд, это при том, что комп перезагружается раз
>в неделю. Вам жалко 5 секунд?На роутере с ме-е-едленным процом, где не 5 секунд, а 50-70 - да. Отправляешь железку в ребут (от долгой и тяжелой работы в эфире они почему-то иногда сходят с ума) и ждешь, пока она вернется, добрую минуту. Правда, дело с DIR-300 (эстеты - можете начинать корчить рожицы и плеваться) и OpenWRT, где совсем не upstart. Но, гм, и мой N900 (а вот там upstart) грузится далеко не 5 секунд, а порядка 30.
Правда, да - все это совсем не то железо, чтобы перезагружать, но если уж что-то напортачил и перезагружаешь - хочется чтобы это было шустро.
На слабом железе вам и от systemd толку не будет.
Но будем посмотреть... время покажет.
>На слабом железе вам и от systemd толку не будет.Откуда такая уверенность?
Смысл параллелизации в том чтоб процессор не простаивал пока что-то с диска загружается. Если процессор слабый, то он и так не простаивает. Ну или не долго.Есть правда еще одно отличие роутера от компьютера - это носитель данных. Жесткий диск против флеш памяти. Скорость чтения с флеш памяти примерно 1-2 мегабайта, с диска - примерно 50, так что вполне возможно, что даже слааабенький процессор простаивает пока dma-чип читает с мтд-устройства данные в память.
> У меня в Debian/upstart они грузятся за 5 секундА если systemd позволит загрузиться за две секунды? Все равно гнать на него будете?
>Вам жалко 5 секунд?
Очень. На слабом железе эти 5 секунд могут запросто превратиться в 500.
>А монтирование on-demand и прочее не создаст ли ситуацию с загрузкой как в винде?
Если вам этот подход не нравится, можете заменить automount для хомяка на железный mount. И вместо персонально вашего стола _вся_ система будет грузиться дольше. Впрочем, это выбор прежде всего разработчиков дистрибутива.
А с upstart вы можете еще до кучи подождать, пока монтируется двухгиговый шифрованный контейнер, или сетевые каталоги. Или монтировать их вручную, как в прошлом веке.
>Тогда нафик эту систему, которую ещё попоробуй подебаж - это ж уже совсем не скрипт rc.
Подучите матчасть, что ли. А то так смотришь на вас, и грусть берет...
>>А если systemd позволит загрузиться за две секунды? Все равно гнать на него будете?2 и 5 секунд - это не то время, ради которого я буду что-то делать в системе
>>Очень. На слабом железе эти 5 секунд могут запросто превратиться в 500.
тогда не надо позиционировать systemd как замену sysv на всех системах. Так и напишите - это решение для слабых машин. Иначе OpenSUSE опять вставят это чудо толком не разобравшись.
>>А с upstart вы можете еще до кучи подождать, пока монтируется двухгиговый шифрованный контейнер, или сетевые каталоги. Или монтировать их вручную, как в прошлом веке.
нет, похоже это вы не владеете матчастью. Там не надо ничего ждать.
>>Подучите матчасть, что ли. А то так смотришь на вас, и грусть берет...
я знаю матчасть, спасибо
>2 и 5 секунд - это не то время, ради которого я буду что-то делать в системеТ.е. если вам дадут систему с systemd, который грузится две секунды, вы не станете менять его на любимый upstart, который грузится пять секунд? Глядя на вас, верится с трудом.
>тогда не надо позиционировать systemd как замену sysv на всех системах. Так и напишите - это решение для слабых машин.
Т.е. для быстрых машин можно не париться с написанием эффективного кода? Вот этот конкретный костыль в данных конкретных условиях работает быстро - отлично, значит, костыли рулят.
Вам в Майкрософте работать надо. Они там тоже любят сильное железо.>Иначе OpenSUSE опять вставят это чудо толком не разобравшись.
Думаю, в openSuSE выберут наиболее взвешенный и оптимальный вариант, а не будут слушать бледных юношей с горящим взором вроде вас.
>Там не надо ничего ждать.
>я знаю матчасть, спасибоВы уж определитесь, либо вы знаете матчасть, либо не знаете.
>>Т.е. если вам дадут систему с systemd, который грузится две секунды, вы не станете менять его на любимый upstart, который грузится пять секунд? Глядя на вас, верится с трудом.вы потеряли контекст разговора. Откуда вдруг появилось, что мне кто-то даст какую-то систему? Ещё раз - ни на своей ни на "даденой" машине я менять в плане sysv ничего не буду, я не занимаюсь тем, что перезагружая компьютер каждые десять минут.
>>Т.е. для быстрых машин можно не париться с написанием эффективного кода? Вот этот конкретный костыль в данных конкретных условиях работает быстро - отлично, значит, костыли рулят. Вам в Майкрософте работать надо. Они там тоже любят сильное железо.
С логикой у вас дорогой явно туговато. Можно подумать upstart или даже ещё более старый sysv в Etch требовал сильное железо. Нет, не требовал. Вопрос стоял в распараллеливании.
Причём тут вообще Майкрософт?
>>Думаю, в openSuSE выберут наиболее взвешенный и оптимальный вариант, а не будут слушать бледных юношей с горящим взором вроде вас.
Нет, один раз уже послушали. Боюсь послушают ещё раз.
>>Вы уж определитесь, либо вы знаете матчасть, либо не знаете.
Я знаю матчасть, т.к. я сам этим пользуюсь. Ничего там "ждать" не надо.
>Ещё раз - ни на своей ни на "даденой" машине
>я менять в плане sysv ничего не буду, я не занимаюсь
>тем, что перезагружая компьютер каждые десять минут.Иными словами: вам пофиг на скорость загрузки. С чего вы решили, что всем остальным тоже пофиг?
>С логикой у вас дорогой явно туговато. Можно подумать upstart или даже
>ещё более старый sysv в Etch требовал сильное железо. Нет, не
>требовал. Вопрос стоял в распараллеливании.При менее эффективной организации процесса загрузки, как в sysv или upstart, рядовому юзеру Васе, чтобы наслаждаться быстрой загрузкой, необходимо более сильное железо, чем при более эффективной организации (launchd, systemd).
>Причём тут вообще Майкрософт?
Подход у вас их фирменный. Ваша левая пятка считает, что скорость загрузки не важна - значит, пусть тысячи юзеров подождут.
>Я знаю матчасть, т.к. я сам этим пользуюсь. Ничего там "ждать" не надо.
Если бы вы знали матчасть, вы бы не противоречили себе в одной и той же строчке.
>>Там не надо ничего ждать.Ну я не знаю как "там", а у меня монтирование 1 тб раздела в ext3 без всякого шифрование занимает около 10 сек
>У меня в Debian/upstart они грузятся за 5 секунд, это при том, что комп перезагружается раз в неделю.Это на вашем компе, с вашим набором служб. У рядового юзера Васи можеть быть другой комп и другой набор служб, который будет грузиться минуту.
Вы предлагаете тысячам юзеров ежедневно ждать лишние несколько минут только потому, что _персонально у вас_ всё грузится быстро?
>Тогда нафик эту систему, которую ещё попоробуй подебаж - это ж уже совсем не скрипт rc.
Ну подебаЖте свой upstart.
>>Это на вашем компе, с вашим набором служб. У рядового юзера Васи можеть быть другой комп и другой набор служб, который будет грузиться минуту.
>>Вы предлагаете тысячам юзеров ежедневно ждать лишние несколько минут только потому, что _персонально у вас_ всё грузится быстро?Во первых, если старт системы будет занимать несколько минут из-за запуска каких-то волшебных сервисов, то я однозначно предпочту стартовать их сразу при загрузке, нежели в процессе работы иметь такие же задержки при первичном обращении к нужным ресурсам.
Во-вторых, CONCURRENCY=makefile.
Вот вам самый простой сервис. Он стартует в параллели. Когда иксы с рабочим окружением уже загружены, он всё ещё выполняется. А когда я приду с чашкой чая утром (та ситуация, которую вы описываете?), он уже выполнится, и никаких on-demand запросов с задержками.
#!/bin/sh
### BEGIN INIT INFO
# Provides: sleep
# Required-Start: $syslog
# Required-Stop: $syslog
# Should-Start:
# Should-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Long sleep
### END INIT INFO. /lib/init/vars.sh
. /lib/lsb/init-functionsdo_start()
{
log_action_msg "Sleeping service"
sleep 100
}case "$1" in
start)
do_start
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
# No-op
;;
*)
echo "Usage: $0 start|stop" >&2
exit 3
;;
esac
>Во первых, если старт системы будет занимать несколько минут из-за запуска каких-то
>волшебных сервисов, то я однозначно предпочту стартовать их сразу при загрузке,
>нежели в процессе работы иметь такие же задержки при первичном обращении
>к нужным ресурсам.Кто сказал, что ждать должны персонально вы? При правильной настройке, on-demand должны монтироваться файловые системы, которые нужны всяким фоновым демонам, непосредственно не взаимодействующим с юзером. А демоны не нервные, могут и подождать.
Те файловые системы, которые нужны пользователю и базовой системе, можно монтировать непосредственно во время загрузки.
>Во-вторых, CONCURRENCY=makefile.
>
>Вот вам самый простой сервис. Он стартует в параллели. Когда иксы с
>рабочим окружением уже загружены, он всё ещё выполняется. А когда я
>приду с чашкой чая утром (та ситуация, которую вы описываете?), он
>уже выполнится, и никаких on-demand запросов с задержками.Это вы к чему вообще?
это циклическое развитие
сначала создается многообразие сущностей, затем выживают только сильнейшие и достойные
затем снова создаются, и снова умирают
> Вообще, это парад суверени^wcистем инициализации, последее время, стал меня настораживать. Что-то одно доделайте уже да? ;)
> Сколько еще велосипедов нам предстоит увидеть?Вы вот не застали колличество програм а'ля telnet но с шифрованием - вот где было разгуляться, но остался один протокол - ssh, так что все нормально.
>>Что касается Ubuntu, то разработчики этого дистрибутива не проявили никакой >заинтересованности в проекте, и поэтому поддержка инфраструктуры и готовые >пакеты для данного дистрибутива отсутствуют.
> Так какой им смысл менять шило на мыло, если upstart себя прекрасно
> зарекомендовал?
> Вообще, это парад суверени^wcистем инициализации, последее время, стал меня настораживать.
> Что-то одно доделайте уже да? ;)
> Сколько еще велосипедов нам предстоит увидеть?Когда этот #грязное ругательство# начнет писать kernelbike, linux переименуют в linopus. Дистрибутивы начнут выпускать с пометкой most-stable-pre-alpha.
хреновина линукс онли
Да еще и не во всех линухах видимо будет. Бардак разводят, тудыть-растудыть. А так - возможности интересные, но думается дьявол будет в деталях, особенно учтя что это писал тот же кто и пульсаудио, зарекомендовавшее себя как очень проблемная и дырявая штука... ;(
>Да еще и не во всех линухах видимо будет. Бардак разводят, тудыть-растудыть.Точно. Нужно оставить один дистрибутив (сами знаете какой), а все остальные - уничтожить.
А их разработчиков - сжечь на кострах, чтобы другим неповадно было.>А так - возможности интересные, но думается дьявол будет в деталях,
>особенно учтя что это писал тот же кто и пульсаудио, зарекомендовавшее
>себя как очень проблемная и дырявая штука... ;(Если бы мейнтейнеры всем известного дистрибутива не были такими криворукими, PulseAudio зарекомендовал бы себя гораздо лучше.
>А их разработчиков - сжечь на кострах, чтобы другим неповадно было.Да нет, просто могли бы посидеть сообща и принять решение в духе "а давайие вместе сделаем штуку, которая всех устраивает по фичам". Но, видимо, синдром "not invented here" бывает не только у нокии :).
>Если бы мейнтейнеры всем известного дистрибутива не были такими криворукими, PulseAudio
>зарекомендовал бы себя гораздо лучше.А эксплойты для повышения прав, сроду юзающие это самое пульсаудио - тоже криворукие майнтайнеры всем известного дистра писали? Это пульсаудио выглядит как лишняя дырень в системе, однако.
Программерам, которые к тому же пишут "фор фун", очень сложно принять одну простую вещь: "есть люди умнее их". :) Созданное своими мозолями детище они будут пестовать и защищать - это нормальный псих.эффект. Отсюда, посторонним помощникам сложно пробить более лучшее решение и они, закономерно, делают свой форк, а то и новый проект - по башке настучать-то некому оригинальному автору! К тому же, если улучшение в корне меняет архитектуру, то действительно проще сделать отдельный проект.PS
"Not invented here" - это синдром мелкософта. :) Что забавно, даже собственные поделки внутренние команды с удовольствием переизобретают.
>оригинальному автору! К тому же, если улучшение в корне меняет архитектуру,
>то действительно проще сделать отдельный проект.Тем не менее...
1) Мне не очевидно нафиг нужно пульсаудио, но вот то что его юзают сплойты - медицинский факт. Других почему-то не юзают. Напрашивается вывод что архитектура могла бы быть и лучше...
2) Мне не очевидно нахрен надо каждому изобрести свой велосипед как последние проприетарщики вместо того чтобы взять какой-то один и допилить до устраивающего всех состояния. Переизобретать велосипеды любят как раз проприетарщики, им это привычно т.к. они привыкли что конкуренты свои велосипеды не дают посмотреть - приходится самим с нуля собирать. А в итоге каждый будет таскать свою систему запуска демонов.>PS
>"Not invented here" - это синдром мелкософта. :) Что забавно, даже собственные
>поделки внутренние команды с удовольствием переизобретают.Я слегка видел что там у них. У них там такой крантец творится что правая рука не знает что делает левая. А то и просто откровенно перетягивают друг у друга канат. Результатом становится полное УГ. Большая помойка. Все нормальные спецы оттуда ушли. И все новые и талантливые - тоже туда не идут. Не почетно и перспектив роста и развития мозга там нет. Там остались только унылейшие индусы готовые работать от звонка до звонка. Все что такие могут - генерить glue-код между функциями дотнета и т.п.. Результат понятен. Посмотрите на любой софт от MS за последние 5 лет. Это ж трындец а не софт. На хабре статейки есть про их состояние дел. В общем MS просирает рынок за рынком. Да и туда и дорога имхо.
>хреновина линукс онлиПотому что современные технологии, на которые она опирается, есть только в линуксе.
Гда в виндах и проч. cgroups, autofs, udev или хотя бы их более-менее полноценные аналоги?
кхм, видимо там же, где и в линуксах качественные приложения для офиса, монтажа\обработки видео и графики, звука...Хотя что это я, это же такая дремучая и бесперспективная мелочь в сравнении с autofs!
>кхм, видимо там же, где и в линуксах качественные приложения для офиса,
>монтажа\обработки видео и графики, звука...Хотя что это я, это же такая
>дремучая и бесперспективная мелочь в сравнении с autofs!Угадайте, на каких платформах первыми появились профессиональные приложения для монтажа\обработки видео и графики)
MacOS PPC ?
>кхм, видимо там же, где и в линуксах качественные приложения для офиса, монтажа\обработки видео и графики, звука...Честно говоря, насчет таких приложений не знаю, т.к. профессионально этим не занимаюсь.
А как они, простите, позволяют повысить скорость загрузки?
Ухххх.... Как все запущено.
А в AltLinux будет?
В альте будет все, но работать не будет ничего
Стиль BSD init намного лучше SysV. Нечего изобретать велосипеды - есть простое и логичное решение.
А оно умеет параллельный запуск сервисов? И что из упомянутых в новости фич поддерживает? Только не надо орать "не нужно!". Если не нужно - можно старичком Init пользоваться вообще и не греть себе мозг. Вот только если вы скажем камеру наблюдения перезагружаете (а линух встречается много где, в том числе и там), есть некоторая разница - прервет она наблюдение на 5-10 секунд или на полторы минуты, правда? :)P.S. вы мягко говоря не очень оригинальны с ником :-). Еще бы систему типа Bree FSD выпустили, принципиально новую и все такое :)
>>Вот только если вы скажем камеру наблюдения перезагружаете (а линух встречается много где, в том числе и там), есть некоторая разница - прервет она наблюдение на 5-10 секунд или на полторы минуты, правда?Ну если будет стоять только то, что надо, а не всё то, что в дистрибутиве встречается, то особой разницы не будет, потому что ненужных сервисов не будет, а те которые нужны так или иначе запустятся.
>А оно умеет параллельный запуск сервисов?Чисто BSD-style инита ты уже нигде не найдёшь. И распараллеливание есть.
расскажите про распараллеливание или дайте ссылку почитать
http://wiki.archlinux.org/index.php/Daemons#Starting_Daemons...
Конечно, если буквоедствовать до конца, то старт демонов не параллельный, а асинхронный, указанные демоны стартуют, не дожидаясь конца запуска предыдущего.
>Стиль BSD init намного лучше SysV. Нечего изобретать велосипеды - есть простое
>и логичное решение.Речь здесь идёт не о стиле, а о реализации.
Кстати, systemd использует свой собственный стиль конфигурирования, непохожий ни на bsd init, ни на sys v. Просто потому, что оба этих стиля недостаточно эффективны для решаемой задачи.
systemd умеет много вещей, недоступных другим существующим системам инициализации.В общем, толсто троллите, уважаемый.
О какой задаче речь? Я так понимаю, о быстрой загрузке системы. Следовательно, если верить вам, то ни SysV, ни BSD-init, мало подходят для этой цели.
>О какой задаче речь? Я так понимаю, о быстрой загрузке системы. Следовательно,
>если верить вам, то ни SysV, ни BSD-init, мало подходят для
>этой цели.Современные модификации BSD init, AFAIK, теоретически позволяют распараллеливать запуск процессов. Но, как и upstart, это паллиатив. Качественный скачок пока сделали только launchd и systemd - речь идет об использовании возможностей сокетов.
Кроме того, systemd является не просто "еще одним быстрым велосипедом на тему инита", а полноценным решением для контроля над системой и сеансами пользователей, позволяющим гибко управлять монтированием и работой с устройствами.
>>О какой задаче речь? Я так понимаю, о быстрой загрузке системы. Следовательно,
>>если верить вам, то ни SysV, ни BSD-init, мало подходят для
>>этой цели.
>
>Современные модификации BSD init, AFAIK, теоретически позволяют распараллеливать запуск процессов. Но, как
>и upstart, это паллиатив. Качественный скачок пока сделали только launchd и
>systemd - речь идет об использовании возможностей сокетов.Интересно, может кто-нибудь сравить это с OpenRC? (Последний мне очень понравился. Стартап ускорил приблизительно в 3-4 раза).
Все обозримые задачи не требуют такого изврата. Это просто еще одна больная фантазия "разработчика"
>Нечего изобретать велосипеды - есть простое и логичное решение.
>Нечего изобретать велосипеды - есть простой и логичный самокат.fixed
Жестоко плюсую. Keep it simple. Ядрышко укладывается в один короткий шелл-скрипт. В сочетании с обрезанным /bin/sh работает более чем удовлетворительно. Всё остальное от лукавого.
###
Keyword and unmask required packages including systemd:
echo sys-apps/systemd >> /etc/portage/package.keywords
echo dev-lang/vala >> /etc/portage/package.keywords
echo dev-libs/libcgroup >> /etc/portage/package.keywords
echo sys-fs/udev >> /etc/portage/package.keywords
echo x11-libs/gtk+ >> /etc/portage/package.keywords
echo sys-kernel/linux-headers >> /etc/portage/package.keywords
echo dev-libs/glib >> /etc/portage/package.keywords
echo sys-apps/systemd >> /etc/portage/package.unmask
echo dev-libs/libcgroup >> /etc/portage/package.unmask
echo dev-libs/atk >> /etc/portage/package.keywords
###Ну вот нахрена ему GTK?!
наверно гуй на нем сделан. а что не опционален так это недоработка скриптов конфигурирования.
а если USE="-gtk" что будет?
# emerge sys-apps/systemd
Calculating dependencies... done!emerge: there are no ebuilds to satisfy "sys-apps/systemd".
Откуда дровишки?
http://en.gentoo-wiki.com/wiki/Systemd
>http://en.gentoo-wiki.com/wiki/SystemdАга.
layman -a keruspe
Ну я это и хотел узнать)
ну а кто уже сравнил с openrc, что быстрее?
Кто знает, где можно найти нормальные маны по настройке этого чуда? Где все подробно описано, а не пару слов а ля emege -av systemd ?
>сотрудник, создавший в звуковой сервер PulseAudio, представил релиз системного менеджера systemd
>создавший в звуковой сервер PulseAudio
>PulseAudioЯблоко от яблони обычно... Не дай бог, короче.
не любите PulseAudio? - вы просто не умеет его готовить)ЗЫ: сам пользуюсь PulseAudio и очень этим доволен
А он почему-то очень зависимый от харда, хоть и сидит поверх алсы. Вы его, наверное, ни разу на Audigy или Audigy 4 запускать не пробовали. Это АдЪ. Натуральный АдЪ.Возможно, что и на других звуковых картах с хардварным микшированием он себя ведёт так же.
Ну а у меня он в младенчестве целый год имел любовь к падениям, да не простым, а с зажором одного ядра CPU до 100%.Баг не есть проблема архитектуры. Сам по себе PA в меру адекватен. По крайней мере это не уродец ALSA, за которого действительно хочется убивать.
А что плохого в ALSA? По мне так она со своими функциями справляется.
>А что плохого в ALSA? По мне так она со своими функциями
>справляется.Да хоть тем, что она совсем Linux-only. И ни один разумный человек тащить ее в другие ОС (включая свободные) не будет.
Долго распространяться, тут все описано: http://4front-tech.com/hannublog/?p=5
С поправкой - дядька разработчик OSS, так что следует к его словам подходить критически (например, про колбэки в API я бы сказал что это плюс, а не минус. но вот само API, по сравнению с простым UNIX-way с /dev/dsp, весьма мерзенькое, как не крутить)
>С поправкой - дядька разработчик OSS, так что следует к его словам
>подходить критическиС учетом что они конкуренты, то очень критически. ты бы еще привел рассуждения о linux на сайте мс :)))))))))))))
>С учетом что они конкуренты, то очень критически. ты бы еще
>привел рассуждения о linux на сайте мс :)))))))))))))Я же специально написал - читать мнения, анализировать и думать своей головой. Про колбэки пример привел еще. Полторы тыщи функций API от этого никуда не пропадают, скажем, как и то, что оно linux-only. И т.д..
Мнение "а, они ж конкуренты, ничего умного там написано быть не может" слишком порочно, я бы сказал. Понимая же, что выбраны минусы и вещи, которые при определенных ситуациях и взглядях можно ими считать, а плюсы скрыты, можно читать спокойно.
Ну а вопрос и был "что плохого". Не "почему X лучше Y", а "что в X можно посчитать плохим". За таким мнения конкурентов, при учете адекватного восприятия и критического подхода с перепроверкой фактов - по-моему, самый хороший ресурс.
Хорошо, но если смотреть на то, что есть в данный момент. Есть ли профит для пользователя в OSS на GNU/Linux, вместо ALSA?
А так то согласен, что как только появился OSS4, ALSA надо было перестать развивать. Почему так не сделали, непонятно.
Камменты к статье доставляют.
>не любите PulseAudio? - вы просто не умеет его готовить)Зато в мандриве умеют http://svn.mandriva.com/svn/packages/cooker/pulseaudio/curre.../ Для Ъ: на него наложили более 70 патчей, чтобы хоть как-то заставить работать.
+1
"создавший в свое время звуковой сервер PulseAudio" меня тоже настораживает...
>>Проект Debian, как всегда, неторопливА тов. Леннарт не боится, что по поводу этого systemd не будет столько же воплей, как по поводу PulseAudio, в самых продвинутых дистрибутивах, которые вставляют софт, даже не тестируя?
>>>Проект Debian, как всегда, нетороплив
>
>А тов. Леннарт не боится, что по поводу этого systemd не будет
>столько же воплей, как по поводу PulseAudio, в самых продвинутых дистрибутивах,
>которые вставляют софт, даже не тестируя?А чего бояться, когда твою поделку проталкивают дяди из редхат. Вон пульсаудио уже практически не выковыривается. Так будет и с systemd. Протолкнут в апстрим и не заметят.
ну и в догонку. лучшеб плагины к альсе писал с функционалом пульса, чем пусль, чесн слово..
>ну и в догонку. лучшеб плагины к альсе писал с функционалом пульса,
>чем пусль, чесн слово..Альсу давно пора закопать, а вы к ней плагины писать просите.
Образцом качества до сих пор остается OSS4 - красивый, простой и логичный API, все плюшки, UNIX-way (а не линупс-ойвэй), портируемость. Но, увы, им занимается слишком мало людей.
А с помощью PA я с друзьями игрался в радио. Вещал icecast'ом (через gstreamer, слушающий на null sink "Вещание") музыку, время от времени подмикшируя туда VoIP, и все это время оно еще и крутило в наушники служебные сигналы (уведомления IM, предупреждения об окончании плейлиста и т.п.). Да, есть, конечно, JACK, и он неплох, но для него мне пришлось бы перелопатить кучу всего, и быть более разборчивым в софте (чтобы софт JACK понимал, или строить велосипеды в духе jack-over-alsa-emulation), а нафига это мне надо, когда PA отлично и просто справлялся с задачей? Кроме команды для gstreamer все, по сути, "рисовал" мышкой. Какая, тут, простите, ALSA?
Модераторам за запрет анонимного комментирования темы желаю зла. На всякий случай.
>Но, увы, им занимается слишком мало людей.Ну да, костылями занимается гораздо больше.
закопать пора не ALSA, a PA. Он просто не нужен, бесполезная прослойка.
> Он просто не нужен, бесполезная прослойка.А Вы, простите, вообще в курсе целей, задач и функционала PA? Или «толпа кричала "не нужен" — видать так и есть»?
И какие же задачи и цели я не смогу достичь без него?
ОК, скажем по другому - МНЕ не нужен! :)
>ОК, скажем по другому - МНЕ не нужен! :)Ну так и пишите прямо - "МНЕ оно не нужно, так что пусть сдохнет". Все свои, все поймут.
товарищь, а что есть PA, если ненадстройка над основным сервером звука? общую мысль ты надеюсь уловил?
Ну и как всегда редхат в своём стиле. Одна из самых важных компонентов системы зависит от сомнительного демона. Ну и наличие vala в завимисомостях тоже ни о чём хорошем не говорит.
Сомнительный этот systemd, самое главное, чтобы выбор был, мне стабильность важнее скорости. А вообще лучше бы systemV допилили до поддержки параллельной загрузки сервисов и этого бы хватило.
>...высокая степень параллелизации запуска служб при инициализации системы, за счет активного использования возможностей сокетов...Извините, а каким боком там сокеты? Или имеются ввиду только сетевые службы? Так их и так не проблема запускать параллельно.
>Извините, а каким боком там сокеты? Или имеются ввиду только сетевые службы?Так нет, многие демоны используют UNIX-сокеты, чтобы общаться друг с другом и всякими управлялками. И systemd эти сокеты умеет заранее создавать, чтобы если демон A зависит от демона B только тем, что хочет ему в сокет нагадить — сокет был создан заранее, A запускался не ждя B, ну а B получил все желаемое как только запустится.
Пример - ну, скажем, DBus. Честно говоря, я по диагонали читал вчера, и в сонном виде, так что лучше не буду врать. Сходите по ссылке.
>И systemd эти сокеты умеет заранее создавать, чтобы если демон A зависит от демона B только тем, что хочет ему в сокет нагадить — сокет был создан заранее, A запускался не ждя B, ну а B получил все желаемое как только запустится.Тут и возникает вопрос, а нафига ему DBUS? Или зависеть от ещё одного демона сейчас модно?
>>И systemd эти сокеты умеет заранее создавать, чтобы если демон A зависит от демона B только тем, что хочет ему в сокет нагадить — сокет был создан заранее, A запускался не ждя B, ну а B получил все желаемое как только запустится.
>
>Тут и возникает вопрос, а нафига ему DBUS? Или зависеть от ещё
>одного демона сейчас модно?Читаем вдумчиво:
>Пример - ну, скажем, DBusЧеловек привел пример службы, где использование systemd (для запуска этой службы) может ускорить запуск.
Человек НЕ имел в виду, что systemd зависит от DBus.