Опять?

Уже сто раз объясняли, включая его самого.

Я тоже этого не понимаю. Если подумать, некоторые данные в бинарном виде будут занимать меньше места (дата/время, тип события и т.д.) и их может быть проще отрабатывать (не нужно парсить текст).

А чтобы прочесть лог нужно написать «дешифратор». Тру, чо.

Толсто, конечно

Хм. А почему в такой Ъ и линуксовой ФС как ext* журнал бинарный?

Уже сто раз объясняли, включая его самого.

хм, это про его статью, которую кто-то из местных переводил, или еще что-то новенькое? Я просто выпадал на время, не следил за новостями, а интересно все равно

ФС как ext* журнал бинарный?

Ну журнал ФС люди обычно не читают(развечто какие-нить криминалисты из кина), а вот логи полезно бывает посмотреть, почему там какой-нить демон не стартует и т.д. и т.п. .

Чтобы читать текст тебе нужен less/cat/head/... . Так какая в принципе разница? Читать бинарные данные имхо проще и быстрее. Замеров не проводил, но писал код.

Сегодня решили вспомнить все срачи минувшего года? :)

ну чем его текстовый формат не устроил?

Тут расписано.

хм, это про его статью, которую кто-то из местных переводил, или еще что-то новенькое? Я просто выпадал на время, не следил за новостями, а интересно все равно

Про неё. А что, уже есть адекватный ответ на

Performance: journal operations for appending and browsing should be fast in terms of complexity. O(log n) or better is highly advisable, in order to provide for organization-wide log monitoring with good performance Minimal Footprint: journal data files should be small in disk size, especially in the light that the amount of data generated might be substantially bigger than on classic syslog.

?

___________
* Примечание: «первое не нужно, второе достигается logrotate+сжатием» адекватным ответом не считается.

А почему не сетевой, он не объяснял (эпичный тред не читал, только пару первых страниц) ?
Или «синдром Wayland'a» ?

Толсто, конечно

С четырьмя звездами то уже можно было бы привыкнуть и не обращать внимание, а? :)

А почему в такой Ъ и линуксовой ФС как ext* журнал бинарный?

А разве в ФС журнал пишется для пользователей?

А что, уже есть адекватный ответ на

не знаю, не искал. Мне журнал понравился идеей о более-менее жестком формате сообщений.

Миллион раз обсуждалось.

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

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

Специально чтобы ты спросил!

В нутростях journald не разбирался, но бинарный формат позволяет реализовать БД, с индексами и запросами. А это всяко быстрее, чем grep.

А давно у нас cat/tail бинарные данные читает?

Заметки, внезапно, пишут люди. Сислог - нет.

А давно у нас cat/tail бинарные данные читает?

А давно сообщения не читаете?

Кроме него самого этого никто не понимает.

Заметки, внезапно, пишут люди

Сохраняют тоже люди?

А давно у нас cat/tail бинарные данные читает?

А давно сообщения не читаете?

ЩИТО?

он аргументирует тем что вот иногда надо бросить бинарные данные (SMART к примеру, в лог).

а так пофиг в принципе, если разобраться..

меня больше волнует что это всё такое хорошее в теории может работать как пульсаудио (оно мне теоретически очень нравится, но на практике смущает часто).

он аргументирует тем что вот иногда надо бросить бинарные данные (SMART к примеру, в лог).

От того SMART столько данных, что RFC822 + текстовый дамп более чем справятся.

а так пофиг в принципе, если разобраться..

«Complex non-solutions for simple non-problems» (c)

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

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

Ага, т.е. мы сначала сделаем сислог, который будет генерить в надцать раз больше данных, выкромсаем из него сетевую часть, а потом, чтобы решить внезапную проблему с нагрузкой на IO, сделаем формат бинарным. Охренеть логика.

На самом деле туда надо MySQL. Жёсткой зависимостью.

потому что он дебил
или засланный казачок - ибо с его говнологами распарсить почему система например сдохла уже не выйдет
текстовые можно парсить из любой оси любой битности
его же говно потребует чрута (приехали) или наличия этого говна в лайфе/соседней системе
с его поделками скоро в убунтах/федорах и прочих дистрах, разрабатываемых олигофренами, получится винда - хер ты раскуришь что и где искать и как парсить и почему оно не работает
пульс - фэйл
системад(ерьмо) - фэйл
бинарные логи - фэйл
расстреляйте этого дебила уже!

В нутростях journald не разбирался, но бинарный формат позволяет реализовать БД, с индексами и запросами. А это всяко быстрее, чем grep.

Чем традиционный сислог, умеющий, кстати, в БД вроде Мускля и Постгреса тут проигрывает ?

Выдохнул-то ?
И так ясно, что не нужно.
Пока не будет гнать логи по сети с TLS и гейшами и не будет поддерживать складывание логов в БД, приемлемых фильтров, то на кой черт он сдался, такой модный и иновационный.

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

выдохнул, выдохнул
но ЛП не нужен!

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

Заметки придумывают и набирают руками люди, в тексте. События генерирует код, получает и записывает код. Коду удобнее оперировать бинарником.

ЩИТО?

Это ответ на сообщение zgen. Товарищ не увидел словосочетание «в принципе». Мысль была такова, что если мы таки читаем текст утилитами, то почему бы не читать логи специальной утилитой.

Я вот не понимаю, а в чём проблема сделать cat этого бинарного лога?

не забудь, чтобы его в busybox включили и чёрт знает ещё куда

Вот гад, языком умеет трепать. Уговорил. Но систмд говно. Как и пульса (ибо осс4 выкинули -_-)

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

При чём тут busybox? initrd ты хотел сказать? Туда что угодно можно включить без особых проблем.

всё с тобой ясно
профита ноль
возможности порезали
гемора добавили
всё путём, чо

профита ноль

Разве?

да
особенно если учесть огороженность
минусы в разы перевешивают даже потенциальные плюсы

Ну ты определись, профита ноль или отношение профит/проблемы неприемлемое.

и так и эдак
назови мне профит

Ну как бы по systemd тоже всё нормально с аргументацией ;) Он к тому же уже сейчас нормально работает, у меня, да. Вместе с pulseaudio :)

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

Legioner

Поттеринг хочет решить.

на этом разговор можно закончить
кстати - я спрашивал про профит от бинарей, а не вообще

На самом деле линукс становится всё более похож на солярку с её SMF, SAF, RBAC, FM.

Быстрее парсить, проще писать код парсера, индексации, некоторые типы данных занимают меньше места.

как страшно жить...

Я всё равно не понимаю, в каких ситуациях бинарные логи мешают жить?