Леннарт Поттеринг: «Open Source community is full of assholes»

У меня нотифер показывается, когда например я смотрю YouTube в фуллскрине.

Нету. Если выбрать устройство типа hw:1,0, то звук все равно проходит через пульсу (пулься монополизирует звук) со всеми вытекающими.

Все вокруг — ретрограды, один Поц — модный перец! ☺

Если выбрать устройство типа hw:1,0, то звук все равно проходит через пульсу (пулься монополизирует звук) со всеми вытекающими.

Не монополизирует. Если какое приложение попробует вывести в hw:1,0, то пульса его автоматически пропустит вперед. Сам так слушаю музыку. Правда не помню, с какой версии она научилась это делать.

Если устройство вывода hw:1,0 указывается в ручную у приложения, то звук всегда идет мимо пульсы. Она просто не в состоянии взять и сама через себя его пустить. Более того, можно при желании выводить параллельно с пульсой на устройство с аппаратным микшером или в dmix.

Если же hw:1,0 указан в общесистемном конфигураторе, то он может не убрать в настройках alsa вывод через пульсу по умолчанию. В некоторых дистрибутивах этот подключаемый конфиг файл порой любят засунуть куда подальше (в deb в /usr/share/alsa/), реже просто в /etc/asound.conf.

Если устройство вывода hw:1,0 указывается в ручную у приложения, то звук всегда идет мимо пульсы.

Действительно, сейчас проверил. Спасибо за новую интересную инфу. Правда, я и dmix-то сейчас держу только ради FF (он не может нативно в 24-битный звук), а перед dmix'ом я все равно не вижу для себя профита в отдельном звуковом сервере, как ни крути.

КУДА? КУДА слать бабло на киллера?!!

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

для быстрого парсинга, бОльшей надёжности и занимают меньше места на диске. БД завоевали популярность. сейчас в продакшене практически повсюду используют базы данных, и перейти обратно на текстовые файлики, с понтом дела вам так удобнее, вы никого не сможете. да какой там продакшен, уже даже среди софтварных плееров модно хранить инфу в БД.

Сейчас курю доки по командам...
А мечтаю о: http://www.kxproject.com/shots.php?language=ru
(3 пункт)

Если в клубе фанов Ленарта у всех такая аргументация, то ненависть мне понятна.

возразить-то есть что? алсо, у меня апстарт.

Что возразить? Что твоя аргументация перехода от текстовых файлов к БД неприменима к логированию? Я кажется спрашивал про плюсы бинарного лога, а не про плюсы того что все логи собраны в одном месте.

твоя аргументация перехода от текстовых файлов к БД неприменима к логированию?

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

Какие уздечки? Ты что курил? И похоже, ты даже матчасть не знаешь, раз за всё обсуждение ничего умного и логичного ты не написал.

Нет. Из-за этого dmix пришлось писать. А пульсу написали ради кривого клонирования core audio.

Так давно же известно, что поттеринг - мразь и фашист.

Юникод тебе поможет

В том, что есть стандартный формат,который читается средством на любой вкус - текстовый.

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

В чём тогда проблема просто поставить rsyslog и скидывать логи в БД, а не в файлики формата systemd строго определенной версии?

dmix не умел в регулирование звука приложений, да и в несколько приложений умел не всегда (идеально работало только на стерео, в более сложных комбинациях уже танцы с бубном).

Программе всё равно, парсить текст или бинарь. Только текст это формат в свободной форме, и парсер всегда рискует наткнуться на какой-нибудь мусор. Плюс надо уметь определять кодировку. А бинарь — он тупой как валенок, бери да читай по спецификации.

совсем не обязательно. например, формат состоящий из элементов вида XXXXстрока\0 — где XXXX число типа int32_t вполне себе бинарный, а элемент там может быть любой длины.

нужно сравнить производительность/занимаемое место в обоих случаях. файлики системд заточены под хранение логов. БД, в которое умеет rsyslog, вероятно, справится хуже. но может и нет.

Много у тебя звуковух?

Или семь.

У тебя в ОС генерит гигабайтные логи? ЖурналД пишет в логи бинарники и дампы?

Много у тебя звуковух?

Бывало до трех.

Ужас.

Чего тут ужасного? У меня, например, 2 звуковухи + 2 псевдозвуковухи (HDMI). Удобно, однако!

Как переключаешься?

bash-скриптом. Скажем, в ноуте для переключения звука на телевизор используется простой скрипт:

cat ~/bin/ConnectTV 
#!/bin/bash
xrandr  --output LVDS1 --mode 1600x900 --pos 0x0 --output HDMI1 --mode 1920x1080 --left-of LVDS1 --pos 1600x0 
ln -sf ~/.asoundrc-HDMI ~/.asoundrc

А вот так возвращаю обратно:

cat ~/bin/DisconnectTV 
#!/bin/bash
xrandr  --output LVDS1 --mode 1600x900 --pos 0x0 --output HDMI1 --off
rm -f ~/.asoundrc

На компьютере чтобы через гарнитуру фильмы смотреть у меня простой alias:

alias mp='mplayer -ao alsa:device=hw=1.0 '

И т.д., и т.п.

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

гигабайтные логи, если их хранить в БД, занимают меньше места

На таких объемах это несущественно и, в реале, зависит от контретной реализации базы. Куча форматов места жрет больше

быстрее парсятся

Нет. Как минимум потому, что их еще надо извлечь из бинаря в читабельный человеком формат. Собственно я не раз сталкивался с ситуацией, когда шелл заруливал по скорости обработки sql. Это не считая того, что как средство анализа данных он оставляет sql далеко позади.

дампы, текст такого не позволяет.

Еще как.

У тебя в ОС генерит гигабайтные логи?

Я такие видел :). Потому их лучше держать в тестовом виде.

ЖурналД пишет в логи бинарники и дампы?

В случае базы данных для этого есть блоб-поля.

Я такие видел

Я тоже, но таких машин наверное даже 5% от общего числа не наберётся. И кстати эти логи и до journald как хранили и читали, неужели его сделали только ради этих 5%?

В случае базы данных для этого есть блоб-поля

И какие именно блобы пишет journald?

неужели его сделали только ради этих 5%?

Я вот тоже вопрошаю которую страницу за каким хреном понадобился именно бинарный лог. Внятного ответа пока нет :(

И какие именно блобы пишет journald?

Например, какой-то бинарный высер он обязан записать. Опять же, бинарный формат для этого необязателен.

Собственно я не раз сталкивался с ситуацией, когда шелл заруливал по скорости обработки sql. Это не считая того, что как средство анализа данных он оставляет sql далеко позади.

какой скл? склайт? если да, то почему же тогда его всюду пихают?

Еще как.

формально это уже бинарник

что их еще надо извлечь из бинаря в читабельный человеком формат

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

какой скл?

Firebird.

если да, то почему же тогда его всюду пихают?

Потому, что как локальная СУБД, он мегарулезный, а на потенциальные тормоза можно забить.
Вопрос в том, какие возможности СУБД требуются Поттерингу чтобы пихать в бинарный лог?

формально это уже бинарник

Зато все остальное текст, который обрабатывается чем угодно.

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

огнептица

не удивлён. её мало кто умеет «готовить».

Потому, что как локальная СУБД, он мегарулезный, а на потенциальные тормоза можно забить.

путаетесь в показаниях. то шелл по удобству заруливает, то теперь СУБД удобнее настолько, что пускай тормозит, лишь бы не скрипты.

Зато все остальное текст, который обрабатывается чем угодно.

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

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

её мало кто умеет «готовить».

Все надо уметь готовить. И?

путаетесь в показаниях.

Не путаюсь. У них задачи разные

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

и насколько сложнее это будет? И насколько корректно? А если бинарник поломан?

то строковое представление ещё придётся в инт перевести

Не надо переводить. Диапазон дат выгребается и в текстовом виде за сопоставимое время.

$ du -sh 11*
245M	11.txt
$ wc -l 11.txt
266263 11.txt
$ time grep -c SEP-2014 11.txt 
14238
real	0m0.172s
user	0m0.136s
sys	0m0.032s

select a.stamp, a.statement from mytable a where a.stamp between '01.09.2014' and '30.09.2014'

Prepare time = 2ms
Execute time = 324ms
Avg fetch time = 9,53 ms

grep -c SEP-2014 11.txt

а нужная дата оказалась в формате 11/11/14. и ваш скрипт не сработал. ну ой.

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

и самое главное: к какой именно БД запрос обращался?

а нужная дата оказалась в формате 11/11/14. и ваш скрипт не сработал. ну ой.

Вообще-то я показывал, что время поиска по строке сопоставимо с временем поиска по бинарю.

попробуйте лучше сравнить диапазон дат между 05.09.2014 и 07.09.2014, к примеру

$ time egrep -c  "^[567]{1}-SEP-2014" 11.txt
390

real	0m0.203s
user	0m0.160s
sys	0m0.040s

SQL-вариант:

------ Performance info ------
Prepare time = 3ms
Execute time = 341ms
Avg fetch time = 10,03 ms

и самое главное: к какой именно БД запрос обращался?

Файрберд2.5, поле stamp индексировано. Но это не главное. Главное, что я на примере бинаря vs текст вам показал, что время сопоставимо. Причем специализированный парсер логов выдаст лучший результат, чем grep.

Ты не осилил dmix+dsnoop+plug+asym?