The Journal: жизнь после syslog

>> Ничего подобного. В Xorg напихали всякой херни (с подачки красношапочников или ими самими): DBus, HAL (теперь выпиливают), udev,

И благодаря этому в большинстве систем xorg.conf пуст. В нем по дефолту больше нет необходимости.

ВО!

Значит для достижения OS-ЗАВИСИМОЙ возможности запуска без файла конфигурации к стройной и OS-НЕЗАВИСИМОЙ X-Windows ПРИБИЛИ гвоздями монструозный (как, впрочем, и все гномоподелия последнего десятилетия, наверное) D-Bus и кривущий наколенный HAL???

Раньше были FAQ по генерации файла конфигурации. Теперь ВДВОЕ, наверное, большии количество FAQ по обходу кривоты HAL/D-Bus/udev.

А не проще было вызов автогенерилки конфига в случае его отсутствия в старт-скрипт внести???

Если твое понимание нужного не совпадает с пониманием девелоперов конкретного дистра...

1) D-Bus и HAL прибиты к Xorg. Мне искать дистриб, где их выдрали с корнем?

2) Теперь к гномосятине прибивают (уж поверьте, для нее, родимой!) systemd как раскрутку системы и менеджер сессий. А к нему - бинарные журналы. Причем и то, и другое пропитано непереносимым кодом так, что аж из монитора капает. Как следствие - ВСЕМ дистрибутам, которые хотят иметь у себя гном ПРИДЕТСЯ переходить именно на эту систему раскрутки/ведения журналов. Альтернатива - послать гном нафиг.

Смысл понятен?

>задача была - ввести новые возможности либо с сохранением текстового представления логов, либо с введением открытого бинарного формата (типа dbf).

формат в любом случае будет открытым. Конкртено dbf никак не подойдет, почему, см ранее.

естественно, никто никого никогда не заставит переписывать вызовы syslog(int,char*) на syslog(int,int,int,dword,char*), например. понятно, что нужна новая функция, типа syslog2(int,int,int,dword,char*,...). от этого - от написания новой функции - никуда не уйти, если нужна стандартизация набора данных логов. здесь вы меня просто неверно поняли.

так и сделали. Вот только вызовом syslog2 начнут пользоваться лет через 5-10.

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

а зачем, если уже есть старые текстовые логи? Какой в этом смысл?

об этом давайте подробнее. почему переменный? разве не дополненный?

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

и ещё раз - что мешает оставить хранилище текстовым?

здравый смысл. Во первых, в журнале будут не только строки, но и дампы.

Во вторых предполагается, что этот файл будет читать программа - просмотрщик журнала. Не важно, утилита journalctl, tailjournal или гуй wxjournalviewer. И эта программа будет передавать запросы в стиле sql. «Все записи» «последние N записи» «след N записей», «записи за тот-то день» «записи с таким-то типом», «записи от ткаого-то сервиса с полем таикм-то равным такому-то и полем другим не равном другому-то» и пр. и все это быстро и с живым обновлением.

Да, прекрасно подойдет xml. И к нему внешние индексы. Но это же будет адский ад...

что мешает индексы физически хранить не в том же файле, а в соседнем?

Можно, но тем сложнее переносить все это на другие компы и отслеживать ошибки в структуре самого журнала.

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

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

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

Так ведь тоже самое можно сказать и про бигтейбл для логов! Он действительно никому не нужен, кроме коллектора логов.

а в общем: сначала некоторые особо одарённые скрыли от пользователей возможность входа из dm на другой десктоп.

Как? я что-то пропустил.

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

А что делать? Когда-то точно также говорили об иксах. Мол, есть прозрачная сетевая консоль. Все быстро и легко. А тут пришли, все проги перепиши и все ради чего, чтобы кнопочки в графике рисовать?

это шоу-стопперы. никто не рад очередному шоу-стопперу.

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

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

> Да, прекрасно подойдет xml

Не подавайте поттерингу идей!

А то, не дай бог, реализует еще...

>Значит для достижения OS-ЗАВИСИМОЙ возможности

возможность как раз ОС-независима. Все, что нужно, это портировать соответствующие инструменты ее реализации.

запуска без файла конфигурации к стройной и OS-НЕЗАВИСИМОЙ X-Windows ПРИБИЛИ гвоздями монструозный (как, впрочем, и все гномоподелия последнего десятилетия, наверное) D-Bus и кривущий наколенный HAL???

попробуй сделать лучше. кто против-то?

Раньше были FAQ по генерации файла конфигурации. Теперь ВДВОЕ, наверное, большии количество FAQ по обходу кривоты HAL/D-Bus/udev

Динамическая конфигурация всегда сложнее. Но нельзя же вечно оставаться на статике и все прописывать руками.

1) D-Bus и HAL прибиты к Xorg. Мне искать дистриб, где их выдрали с корнем?

сред тех разрабов, которые считают, что это жизненно важно - выдрать с корнем. Или самому. Как вариант, старый дебьян.

Альтернатива - послать гном нафиг.

я так и сделал. Уже два года как...

>Не подавайте поттерингу идей!

просили текстовый лог. Получите.

хорошо, что поттеринг пока оставил нам возможность не использовать его поделия :)

> Динамическая конфигурация всегда сложнее. Но нельзя же вечно оставаться на статике и все прописывать руками.

Итак, дык чем плоха динамическая ГЕНЕРАЦИЯ конфига при запуске???

Вставили-бы xorg-os-config какой-нить с скрипт запуска. И на осестроителя возложили труд его написания.

Вопрос остается прежним - НАФУЯ гвоздями-то прибивать?

Альтернатива - послать гном нафиг.

я так и сделал. Уже два года как...

Не в смысле - из установки. В смысле - из дистрибутива. Как debian в сове время KDE выкорчевал.

>хорошо, что поттеринг пока оставил нам возможность не использовать его поделия :)

Собственно говоря, это главное его преимущество. Он не столько пишет софт, сколько гениально его внедряет.

O(logN), решения это только деление базы, создания разделов таблиц в любом случае телодвижений и проблем больше, нежели чем с файлами

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

> хорошо, что поттеринг пока оставил нам возможность не использовать его поделия :)

Ключевое слово «ПОКА» ? :-)

ибо (что вероятнее) будет менее выразительно, чем он

Это нам подходит, спасибо. Мне не нужны поэмы о любви в системном журнале

> Тупо выделение нового блока. Если выставить большой размер блоков...

О! Лучше с автоудвоением размера. И size_t как единица размера. Потом отладить на 64-х битной системе и удивляться, почему оно на 32-х битах лагает...

>Итак, дык чем плоха динамическая ГЕНЕРАЦИЯ конфига при запуске???

А в чем вопрос? Именно так и делается.

Вставили-бы xorg-os-config какой-нить с скрипт запуска. И на осестроителя возложили труд его написания.

Не пойдет.

если клавиатура/джойстик/планшет/монитор etc воткнуть в компьютер, когда иксы уже стартовали? Пролет или ребут компьютера?

Вопрос остается прежним - НАФУЯ гвоздями-то прибивать?

а как иначе?

Не в смысле - из установки. В смысле - из дистрибутива. Как debian в сове время KDE выкорчевал.

ну тоже вариант. где-то иксы вычеркивают, кто а где-то гном выкинут. Была бы мотивация. В чем проблема?

> если клавиатура/джойстик/планшет/монитор etc воткнуть в компьютер, когда иксы уже стартовали? Пролет или ребут компьютера?

syskeyboard, sysmouse, DPMI и т.п. Не?

Есть подозрение, что из-за перьев приделали, но могли и еще один интерфейс приделать. Не уневерсально-монструозный.

где-то иксы вычеркивают, кто а где-то гном выкинут. Была бы мотивация. В чем проблема?

Графику хоцца на десктопе. Форточки не хоцца (давно ими не пользуюсь, лет 15, наверное). А выбора, походу, не оставят... :-(

xml - это ни разу не текстовый, а только таким кажется.

Святая простота.

О! Лучше с автоудвоением размера. И size_t как единица размера. Потом отладить на 64-х битной системе и удивляться, почему оно на 32-х битах лагает...

Плюх!

Мне неловко говорить, но эти проблемы решены давно. Тебе LARGE_FILES что-нибудь говорит?

Святая простота у тебя на аватаре. А я просто мыслю реальными категориями.

Пусть использование journal будет опциональным, и все будут довольны.

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

Я отвечал на возможности повторного использования. И то и другое нужно только для старта системы, я предпочту systemd тому зоопарку глючных init.d скриптов, который есть сейчас. При недоступности интернета какой-нибудь bind или openvpn может задержать загрузку системы на 10 минут, что я считаю недопустимым.

delete можно делать после бэкапа на другой, бесконечный носитель.

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

Ты уже выкинул xorg?

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

есть какая то программа для этого - module

module load ...
module use...
module avail...

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

> delete можно делать после бэкапа на другой, бесконечный носитель. и пусть вместо одной проблемы будет много проблем.

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

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

logrotate естественно не используется, да?

> как то не вериться в допиливаемость GNU/Hurd

Теоретически оно должно быть намного более допиливаемо в силу своей модульной структуры. Другое дело, что до недавнего времени это было никому нафиг не нужно. Но поскольку монолитный линукс с каждым годом всё тяжелее и тяжелее, просыпается интерес к альтернативам - Minix3 и Hurd.

Не зря же выпускают Debian GNU/Hurd...

Прочитал всё по диагонали. Понял только что:

• О кросс-платформенности можно забыть, так как всё будет прибито к linux в видении красношапки (а если я хочу хранить и анализировать логи на винде или в какой qnx то ой)
• О реализации анализаторов логов в железе например на микроконтроллерах тоже можно забыть (например прозрачный аппаратный watchdog)
• Весь unix-way совместной работы фильтров, врапперов, пайпов и сокетов летит к чертям и подменяется куцым api. Что ломает совместимости со старым инструментарием и делает нетривиальной генерацию нового. (интересно Поттеринг вообще читал литературу по nix или осилил только спецификацию на си)
• «Замыкание на вендоре» в виду неповторяемости инструментария из за закрытости/нестабильности конечного формата (чтение исходников сомнительный вариант)
• Необходимость генерации специальных конвертеров в независимый от инструментария формат для длительного хранения логов или какой-то спецобработки ( генерация ещё одного костыля чтобы не потерять логи из за несовместимости версий чудного логгера или возможности обработки логов)
• Никакой помехозащищенности, малейшие ошибки на диске или в памяти проявятся потерей базы логов
• Затруднённость анализа человеком для нетривиальных случаев ( как это проявляется в «оптимизированных системах логирования» видно по винде) Буквально все перечисленные так называемые недостатки syslog реализуемы в рамках существующих принципов unix-way. Преимущества jornald надуманны и нужны только для пропихивания красношапки во все дыры. И меня удивляют защитники этого пути которые даже весомой аргументации так и не привели. Надеюсь я просто невнимательно прочитав не так понял истинного светоча мысли Поттеринга. Иначе страшно жить.

я слышал что ядро minix3 в разы тормознее линуксового несмотря на теоретическое превосходство

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

Проблема в том, что если ты не Потт^w сотрудник крупной манетизированной компании то твой syslog никому как правило не нужен.

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

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

т.е. для каждой новой программы менять таблицу логов? Или для каждой программы своя таблица? И каждая программа пишущая в сислог, должна предоставлять sql-скрипт для обновления своей схемы?

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

если твой сислог не уг, и ты сможешь доказать это, то наверняка найдутся люди кто заметят его.

Я так понял для каждого формата предлагается вводить свод UUID. Ничто не мешает создать по таблице для каждого UUID'a (самый тупой вариант, можно реализовать за пару дней)

А вас wtmp/btmp не беспокоят?

Если бы он мог создать не-уг сислог, он бы не вопил тут, а уже давно создал бы его.

ты взялся бы сделать это для всех существующих программ?

Интерес не просыпается, а откапывается. Ему еще метров 5 копать.

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

>О кросс-платформенности можно забыть, так как всё будет прибито к linux в видении красношапки (а если я хочу хранить и анализировать логи на винде или в какой qnx то ой)

Не думаю что перенести библиотеку для работы с логами будет сложно для того, кто на самом деле хочет разбирать логи на венде (но зачем?)

Весь unix-way совместной работы фильтров, врапперов, пайпов и сокетов летит к чертям и подменяется куцым api. Что ломает совместимости со старым инструментарием и делает нетривиальной генерацию нового. (интересно Поттеринг вообще читал литературу по nix или осилил только спецификацию на си)

logviever --errors | grep ... | awk ... | sed ...

«Замыкание на вендоре» в виду неповторяемости инструментария из за закрытости/нестабильности конечного формата (чтение исходников сомнительный вариант)

Где написано, что формат не будет документирован (в итоге, после отладки)? В любом случае, остается возможность использовать библиотеку.

Никакой помехозащищенности, малейшие ошибки на диске или в памяти проявятся потерей базы логов

Надо подкинуть Поттерингу идею об избыточности

О реализации анализаторов логов в железе например на микроконтроллерах тоже можно забыть (например прозрачный аппаратный watchdog)

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

Я думаю когда Красношляпы это допилят, начнут внедрять в энтерпрайзе (вместе с системами анализа логов и мониторинга, заточенными на журнал), софтописатели сами потянутся.

не могу с Вами не согласиться

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

А почему текущие уг?

Мне это не нужно. Уж есть десятки лет есть всё необходимое. Нужно только уметь этим пользоваться.

я не компетентен в данном вопросе. Время рассудит