> чтобы заставить их выводить звук с разной частотой дискретизации и уровнем квантования через одно устройство

Для этого в альсе есть dmix. А еще, используя чистую Альсу можно выводить аудио без преобразований на карточки уровня выше Риалтековских ХДА и Аудиг (это такие, которые имеют встроенный генеретор произвольной опорной частоты и способны подстраиваться под параметры входного сигнала).

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

>Что значат param1..param255 в контексте ошибки номер 138 можно прочитать в справке.
Не могу не предложить см. рис. 1.

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

>> Что значат param1..param255 в контексте ошибки номер 138 можно прочитать в справке.

Не могу не предложить см. рис. 1.

Пипец ты вежливый.

> формат данных не имеет никакого значения в концепции unix-way.

возможно, unix-way устарел.

О, прошу прощения, у вас наверное не та версия справки. Сертифицированную версию справки можно получить по телефону +3 434 3124- 434 приложив 3 лицензионных ключа и сплясав гопак.

А я за - пусть попробует!

нет, конечно - это проще. Однако, зачем-то же придумали БД, верно? И ведь ими пользуются. И их существует множество разных.

И это все несмотря на то, что plaintext формат безусловно проще, и писать туда можно printf-ами и cout-ами. Зачем же тогда огород городили с b-trees и всякой мутотенью? И сложнее, и какой-то новый язык надо изучать..

Не думаю, что мне нужно отвечать на этот вопрос.

Тут вопрос в удобстве и времени. Для десктопа (да и во всех случаях, когда объем логов заведомо мал), безусловно, сложная система логирования не нужна. Если это ваш случай, и все остальные варианты вас не интересуют, то дальше тред можно не читать.

Если же объемы логов велики (кто-то тут про 20 гб логов в день говорил), представьте что их надо сначала распаковать, потом прогрепать (это уже довольно долго), потом еще разобрать, что важно а что нет, то это уже заметные потери времени и сил на поиск проблемы. Никакие бинарные данные воткнуть в лог не получится - придется куда-то отдельно кидать дампы. Иди потом, собирай их по всему /var/log а то и хуже. Почитайте перевод, там интересные вещи написаны.

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

И кстати, насколько я понял (поправьте если не так), этот формат (приведенный в переводе пример) не так уж далек от текстового, то есть его можно будет читать less-ом. И да, много ли тут тех, кто логи не сжимает? А в сжатом файле ошибка в одном байте в плохом случае может покоцать весь файл так, что он не разожмется. Так что еще вопрос, что оптимальнее хранить. Если придумать адекватный формат файла (опять же, см. перевод - там описаны требования к формату, который еще толком не определен), то ошибка не будет влиять на весь файл - она будет локальной, но файл при этом будет читаться. Индексы можно хранить отдельно, тогда информация будет доступна даже при их отсутствии, просто поиск по ней будет дольше.

Тут вижу пример, когда выбор 10 дней из логов выполняется за 6 секунд. Это, конечно, хорошо, но когда приложение (и не одно) работает долго (месяцы) и безостановочно, найти нужное в сотнях файлов размером по 200 Мб уже далеко не так просто и быстро. А если учесть, что это «нужное» обычно является текстом, который написал человек, то угадать, как именно он это сформулировал, тоже становится отдельной задачей.

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

Осталась две проблемы: 1. Определить строго все форматы, интерфейсы и средства управления. 2. Реализовать и понять, получилось ли то, что хотели, и упрощает ли оно работу. Потому как - а вдруг все-таки заработает. Мысли-то неплохие, в принципе.

В общем, раз ему не лень, пусть попробует: если выйдет удачно - тем лучше, если нет - когда-нибудь появится свой, теплый и ламповый, true-Unix-way Linux, без пульсы, *Kit-ов, systemd и другой фигни.

Для этого в альсе есть dmix.

dmix/dnsoop не работали, как надо.

А еще, используя чистую Альсу можно выводить аудио без преобразований на карточки уровня выше Риалтековских ХДА и Аудиг (это такие, которые имеют встроенный генеретор произвольной опорной частоты и способны подстраиваться под параметры входного сигнала).

Ну вот когда sblive! использовался, то проблем не было. Но потом контора решила снизить стоимость железа...

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

Что-то пульсоподобное в современной ОС обязано быть. esound ли, jack - пофиг, но всё подряд с ними должно работать. Так вышло, что у авторов PA пороха хватило на большее.

> возможно, unix-way устарел

UNIX-way - это сохранение простого простым. Иное - оверхед и неумение проектировать софт. 40 лет принципу. Без обид, но вы его сути, по-моему, не понимаете. Почитайте что-ли Робачевского, The Art of Unix Programming или что-то в этом духе. Мозг только так прочищает от виндоподходов.

> возможно, unix-way устарел.

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

>И до сих пор вроде как миновала меня чаша сия, чему я несказанно рад.

Боюсь ты ошибаешься. На счет того что тебя миновала чаша сия.

Это такой тонкий троллинг, я понял. Зачот!

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

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

> Почитайте что-ли Робачевского, The Art of Unix Programming или что-то в этом духе. Мозг только так прочищает от виндоподходов.

Про черепашку ему скажи. Обязательно.

P.S. Не, ну и нахрена нужен этот ваш башорг? Я там так не смеялся, как здесь.

возможно, unix-way устарел

возможно ты еще не дорос до понимания концепции UNIX-way, инфа 100%

>1. journal занимается логами.

2. journal занимается ТОЛЬКО логами

journald _намертво_ приколочен к systemd и не отключается.

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

Зачем ломать то, что уже есть?

4. лог-демона вообще колебать такая абстракция как «сеть» не должна.

journald эта абстракция не колеблет настолько, что он с ней и не работает. Фееричное предложение копировать логи на центральный лог-сервер средствами scp, rsync или NFS, а там браузер логов(!) сам все склеит и разберется, поражает своим идиотизмом.

5. формат данных не имеет никакого значения в концепции unix-way.

http://ru.wikipedia.org/wiki/Философия_UNIX#.D0.9C.D0.B0.D0.B9.D0.BA_.D0.93.D...

Пусть каждая программа делает что-то одно, но хорошо.

У сабжевого поциента с этим вообще беда.

Храните данные в простых текстовых файлах.

Простой текстовый файл - это не формат данных?

Используйте сценарии командной строки для улучшения функционала и переносимости.

Избегайте пользовательских интерфейсов, ограничивающих возможности пользователя по взаимодействию с системой.

В данном случае у journald все очень печально.

>Боюсь ты ошибаешься. На счет того что тебя миновала чаша сия.

нет, не ошибаюсь скорее всего.

Какие еще бинарные логи? Переводчик упоролся? Там ведь ни слова об этом нет, а формат будет по образу и подобию git. Имеется в виду то, что можно будет в логи дампы сохранять? Иначе 4.2. И там есть сетевая прозрачность. Так что все, таки 4.2.

А для чего их интерпретировать?

А какой софт, если не секрет? Не ради троллинга, просто интересно.

У меня когнитивный диссонанс от сочетания вашего ника и поста. Так и должно быть?)))

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

>Делайте что-то одно, но делайте это хорошо

возможность индексации вполне укладывается в понятие «хорошо», в отличие от «храните все в простых текстовых файлах».

Предчувствую резкий рост популярности слаки. Тут нет avahi, pulseaudio, systemd и mono.

>там же в статье как всегда написано чего не может сделать сислог и прямым текстом в ЧАВО сказано нужен сислог пользуйте сислог, мне ненужен сислог, но и не мешает, но коль скоро журнал нужен для системд и может заменить сислог то пусть будет.

И в итоге мы получае 2 демона логирования. Нафейхоа, спрашивается?

> less /var/log/messages.0.bz2 ? Много там увидишь?

bzless /var/log/messages.0.bz2

Увижу всё, что есь.

> возможность индексации вполне укладывается в понятие «хорошо», в отличие от «храните все в простых текстовых файлах».

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

Квалификация леннарта у меня лично сомнения вызывает. Я вот сходу могу обрисовать, почему его systemd говно, но не буду, потому что не охота и спать пора.

По остальным пунктам сказать нечего? И да, «храните все в простых текстовых файлах» - это значит «не используйте бинарные форматы»

возможность индексации вполне укладывается в понятие «хорошо»

Зато все остальное замечательно укладывается в понятие «плохо».

вообщето все пихают, но как и было с экст4 появится когда будет готова

+1, кажется, вы всего лишь 5й (или около того), кто прочитал перевод, помимо переводчика.

А с автоматической обработкой ошибок что делать? регекспы писать?

>Леонарт Поттеринг, известный разработкой звукового сервера pulseaudio и системы загрузки systemd
Нехорошо вот так сразу в первом предложении клеймить человека.

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

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

эвентлог был как бэ ещё на NT 3.x, школота, тока проку от него практически ноллль

Это такое простое, бытовое дело — написание язычков.

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

> А с автоматической обработкой ошибок что делать? регекспы писать?

Выражайся яснее.

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

Так ведь Леннарт примерно это и предложил, нет разве?

Нет.

Не предлагается делать совсем бинарник

Определи понятие «совсем бинарник».

Сдаётся мне, что следующим громким проектом Поттеринга станет универсальный линуксовый реестр.

Здравствуйте уважаемый ЛОР, пишет вам Пётр Ильич Кукушечкин из ПНД №1 города Угрюмска. Я узнал что так называемый линакс - это такой элитный клуб, где собираются такие же альтернативно-мыслящие гении как я.

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

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

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

Пишите мне пожалуйста, только не используйте твёрдый знак - его запатентовал мой давний оппонент, враг швабоды, копираст Щёкин из 4-й палаты. Но мы всё равно победим, с нами Стольман и Ленин!

>суть бинарного формата только в одном — в ускорении поиска и в унификации формата.

Откуда там ускорение? Его еще распаковать надо из бинарного офрмата чтобы произвести text match.

> дата_события

сабжевая_дата_1
сабжевая_дата_2

4754464f

Уважаемый! лежите в гробу (ой, в урне) и смотрите в светлую строку поиска, не надо говорить другим как там всё должно быть на кухне если вы заказываете в ресторане кекс а не готовите его, ок?

>А какой софт, если не секрет?

Да разный. Но область - печатная, видео, аудио реклама, а сейчас мобильная. Если зрел журнал Максим...

Какие еще бинарные логи? Переводчик упоролся? Там ведь ни слова об этом нет

* Будет ли формат журнала стандартизирован? Где я могу найти описание структур данных на диске?

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

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

> суть бинарного формата только в одном — в ускорении поиска и в унификации формата.

А что, индексировать текстовые файлы религия запрещает?

не всегда исчерпывающи, на тот же pppd посмотри.

Это тот что на 9 умеет дампы PDU в лог? Ню-ню.

то ли сетевуха
то ли роутер
то ли провайдер

Как минимум твой уровень знаний.

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

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

Нахрена ломать то, что прекрасно работает?

>Леонарт Поттеринг, известный разработкой звукового сервера pulseaudio и системы загрузки systemd, объяснил, чем его не устраивает syslog и предложил свою универсальную реализацию журнала логов.

Меня лично не устраивает сам факт существования Поттеринга, но я же не стремлюсь его исправить.

Пусть хоть логи в покое оставит. Говна он «наделал» на годы вперед.