The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Предложение по переводу системных логов lastlog, btmp, utmp и wtmp на использование SQLite

13.03.2026 08:11 (MSK)

В списке рассылки linux-api выставлено на обсуждение предложение (RFC) заменить устаревшие реализации бинарных форматов системных журналов lastlog, btmp, utmp и wtmp на новые разделяемые библиотеки, использующие SQLite в качестве бэкенда. Инициатива направлена на решение накопившихся проблем, среди которых переполнение 32-разрядных счётчиков времени в 2038 году, отсутствие расширяемости, низкая производительность запросов и отсутствие атомарности при записи.

В настоящее время для хранения данных о сеансах и попытках аутентификации в Linux используются следующие бинарные файлы, имеющие фиксированную структуру:

  • /var/log/lastlog - время последнего входа (структура "struct lastlog" с полем "ll_time" 32-разрядного типа time_t);
  • /var/log/btmp - неудачные попытки входа;
  • /var/run/utmp - текущие сеансы;
  • /var/log/wtmp - история входов и выходов.

Формат данных файлов был разработан несколько десятилетий назад и имеет ряд фундаментальных ограничений:

  • Поле "tv_sec" в структуре "utmpx" и поле "ll_time" в "lastlog" имеют тип "int32_t", значение счётчиков времени на основе которого переполнится 19 января 2038 года. Из-за требований ABI‑совместимости даже на 64-разрядных системах эти поля остаются 32-разрядными, поэтому проблема затронет все установки Linux.
  • Фиксированный размер записей не позволяет добавлять новые поля (например, идентификатор контейнера, имя сервиса, IP-адрес) без полной замены формата и перекомпиляции всех утилит.
  • Утилиты last, lastb, who и lastlog вынуждены линейно перебирать содержимое файлов. При большом размере журналов без использования индексов, позволяющих эффективно фильтровать записи, нагрузка на систему ввода/вывода и задержки при выполнении запросов становятся неприемлемыми.
  • Запись в бинарный файл не является атомарной операцией. При сбое запись может быть частично повреждена.
  • Для исключения конфликтов при одновременной записи в журнал несколькими процессами (например, sshd и login) используются flock-блокировки, которые не гарантируют атомарность и могут приводить к взаимным блокировкам.

Автор RFC предлагает полностью отказаться от бинарных форматов в пользу специализированных разделяемых библиотек, использующих SQLite. Для каждого типа журналов создаётся отдельная библиотека с единообразным C-интерфейсом: liblastlog2, libbtmp2, libutmp2 и libwtmp2. Все библиотеки работают с БД, схема которых включает 64-разрядные временные метки (тип INTEGER) и индексы по пользователю и времени. Имеется возможность добавления новых полей без нарушения совместимости (через ALTER TABLE).

Среди доводов в пользу использования SQLite упоминается использование 64-разрядного типа INTEGER для хранения эпохального времени, задействование индексов для снижения ввода/вывода за счёт выборочного обращения к записями вместо полного сканирования, возможность добавления новых полей без изменения существующих записей, поддержка ACID-транзакций, режим WAL (Write-Ahead Logging) для конкурентного доступа без блокировок, проверенная надёжность работы SQLite.

Для обеспечения плавного перехода предлагается стратегия "двойной записи" (dual-write):

  • Программы, которые пишут в бинарные файлы (login, sshd, sudo, cron и др.), модифицируются так, чтобы одновременно выполнять запись и в старый бинарный файл, и в новую SQLite-базу через соответствующую библиотеку.
  • Разрабатываются новые версии утилит (last2, lastb2, who2, lastlog2), которые читают данные из SQLite-баз, используя индексы для быстрой работы. Старые утилиты продолжают работать с прежними файлами.
  • Через несколько лет, когда подавляющее большинство систем обновятся, поддержка записи в старые форматы может быть отключена, а старые утилиты - объявлены устаревшими.

Вопросы, выставленные для дополнительного обсуждения:

  • Целесообразность разделения на отдельные библиотеки или объединения в одну (например, libsession2).
  • Выбор имён для библиотек и утилит (сохранить исторические названия или перейти к более общим).
  • Расположение файлов баз данных (/var/lib/ как для состояния приложений или /var/log/ как для логов).
  • Механизм версионирования схемы и миграции.
  • Параметры производительности SQLite для различных сценариев (серверы, встраиваемые системы).
  • Предоставление fallback-бэкенда, хранящего журналы в упрощённом бинарном формате, для систем, на которых SQLite может оказаться избыточным (например, встраиваемые устройства с жёсткими ограничениями по памяти).


  1. Главная ссылка к новости (https://github.com/bakshansky/...)
  2. OpenNews: Для избавления Glibc от проблемы 2038 года предложено прекратить использование utmp
  3. OpenNews: Уязвимость в SQLite, позволяющая удалённо атаковать Chrome через WebSQL
  4. OpenNews: Проект Redka развивает реализацию протокола и API Redis поверх SQLite
  5. OpenNews: Эксперимент с использованием SQLite в качестве контейнера для архивирования файлов
  6. OpenNews: Google использовал большую языковую модель для выявления уязвимости в SQLite
Автор новости: Аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/64981-wtmp
Ключевые слова: wtmp, log, sqlite
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (236) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 08:25, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Чем metakit4 не угодил?
     
     
  • 2.15, Аноним (15), 08:42, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Написана на C++ - https://ru.wikipedia.org/wiki/MetaKit
     
  • 2.18, Жироватт (ok), 08:44, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Недостаточно стильно@модно@молодёжно и обновлялась не "в прошлом месяце"
    Хотя я не удивлён был бы, если бы туда по решению платинового спонсора предложили запихнуть sql server 2026 localDB
     
     
  • 3.20, Аноним (15), 08:56, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это уже перебор, хватит https://github.com/microsoft/FASTER
     
     
  • 4.32, Жироватт (ok), 09:15, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +15 +/
    Почему перебор? Самый раз. Полноценный движок баз, который потом можно будет смигрировать на

    "
    Три файла БД – для логов царственных демонов в системдишных шатрах,
    Семь – для пользовательских профилей программ и гуртовщиков мыши,
    Девять – для всеъ, облечённых в сисопские права,
    Один движок запустит Владыка на облачном троне,
    В ядре по имени linux, где уже распростёрся мрак.

    Один ms sql server в системе покорит их, он соберет их,
    скуль сервер притянет их и в чёрную цепь скуёт их
    В ядре по имени linux, где уже распростёрся мрак.
    "

     
     
  • 5.88, Аноним (88), 11:46, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но ведь можно как это любят оптимизровать sqlite инплейс заменить на Mysql, Postgres, MSSQL, Oracle наконец, чтобы было энтерпрайзненько.  
     
     
  • 6.95, Жироватт (ok), 12:31, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Но ведь можно как это любят оптимизровать sqlite инплейс заменить на

    Ну или хотя бы единый движок СУБД типа марии, который будет тянутся уже ядром, но это херит любые встраивыемые сценарии.

     
  • 3.21, Аноним (21), 08:56, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +4 +/
    - Для каждого типа журналов создаётся отдельная библиотека
    - задействование индексов
    - одновременно выполнять запись и в старый бинарный файл, и в новую SQLite-базу

    Странная система логирования. Мы точно логи пишем?

     
     
  • 4.33, Жироватт (ok), 09:16, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, для времени миграции с базы на базу - вполне.
    Далее старый способ фиксации логов отключается, когда новый уже достаточно отлажен
     
     
  • 5.44, Аноним (21), 09:46, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Уточню проблему, если кто не понял:

    - Для каждого типа журналов создаётся отдельная библиотека
    - задействование индексов

    Точно логи пишем?

     
     
  • 6.131, Аноним (131), 17:56, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >- Для каждого типа журналов создаётся отдельная библиотека

    Крохотная библиотека, генерирующая специфические SQL-запросы. Вероятно API будет обратно совместим со старым API логов.
    >- задействование индексов

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

     
     
  • 7.134, Аноним (134), 18:29, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > на производительность жалуются, без индексов выборка

    А что мы чаще делаем: пишем в лог или разбираем падения прог?

     
     
  • 8.177, Tty4 (?), 07:05, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Смотрим текстовые файлы с логами Остальное делает машина Если нужно будет для ... текст свёрнут, показать
     
     
  • 9.243, _ (??), 17:31, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    You do not use отдельную утилиту to see the test file logs ORLY - ... текст свёрнут, показать
     
  • 3.52, Аноним (52), 10:08, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Больше 10 лет - в прошлом месяце))
     

  • 1.2, User (??), 08:25, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Автор RFC предлагает полностью отказаться

    Так вроде ж и отказались уже - в пользу journald?

     
     
  • 2.107, Аноним (107), 14:23, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    systemD к GNU/Linux не имеет прямого отношения.
     
     
  • 3.118, User (??), 15:23, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > systemD к GNU/Linux не имеет прямого отношения.

    Ну, будем честны - имеет примерно такое же, как "GNU" к "linux'у": какие-то мутные перцы сделали что им надо было и на какое-то время стали стандартом de-facto.

     
  • 3.212, anoName (?), 21:15, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    ну запусти щас свой гнулинус без системду
     
     
  • 4.218, Аноним (218), 00:07, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    emerge sys-apps/openrc
     
  • 4.219, TestTestTest (?), 00:23, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну запустил.
     
     
  • 5.240, Рыло (?), 03:14, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Теперь лови
     
  • 4.234, Аноним (234), 12:26, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > ну запусти щас свой гнулинус без системду

    Вон там Devuan и Slackware. Тебе мало?

     

  • 1.3, Аноним (52), 08:28, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Запись в бинарный файл не является атомарной операцией. При сбое запись может быть частично повреждена."

    Так это и к journald относится, разве нет?

     
     
  • 2.16, Олег (??), 08:42, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да не слушай их. Программисты деградируют походу. Если записывать не больше страницы за раз, то вполне себе атомарная. А дальше уже работает журнал ФС. Sqlite хорошая штука, но зачем тащить её сюда,  не понятно.
     
     
  • 3.133, Аноним (131), 18:16, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Если записывать не больше страницы за раз, то вполне себе атомарная

    А там есть выравнивание по страницам? Если нет, то вообще нельзя предсказать произойдёт ли разрыв записи между страницами или нет. Без журнала, нельзя быть уверенным была ли завершена запись. ФС конечно старается не развалится, но она вообще не оберегает данные внутри файлов. Нужно понимать, что для HDD мы вообще не можем быть уверены на каком бите прервётся запись. В случае SSD запись производится блоками в несколько килобайт, но реальный размер на конкретном SSD абсолютно неизвестен от 4 КБ до 64 КБ.

     
     
  • 4.220, Аноним (220), 05:56, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > реальный размер на конкретном SSD абсолютно неизвестен

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

     
  • 3.193, Смузихлеб забывший пароль (?), 11:25, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Sqlite хорошая штука, но зачем тащить её сюда,  не понятно

    как будто это что-то нереально тяжеловесное

     
     
  • 4.202, Фняк (?), 14:35, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По сравнению с записью структуры в конец файла в бинарном виде - наааамного тяжеловесные. А главное что блокировки то никуда не денутся, речь ведь о потенциальной конкурентной записи
     
     
  • 5.205, Смузихлеб забывший пароль (?), 15:17, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Один инструмент со стандартной работой и зрелым механизмом запросов по параметрам, с огромным множеством проверок и использований
    Или гора самопальных велосипедов где каждый мастерит кто на что горазд( в т.ч с уязвимостями ) в т.ч и с разной структурой данных. Хотя по сути речь о СУБД причём не супер-производительной

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

     
  • 2.46, Аноним (21), 09:54, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > При сбое запись может быть частично повреждена

    Дак это и к скуляйту относится. Что они подразумевают под сбоем? Железо гикнулось? Система в панике? Приложение кривое? Первым двум скуляйт не поможет. Остаётся приложение. Если приложение глюкнуло - мы в логах ничего не увидим. Скуляйт намекает, что сервера логирование теперь нету, а записью занимается непосредственно само приложение.

     
     
  • 3.64, Аноним (64), 10:38, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, логированием занимается не приложение, а все так же система  / системный демон. Но пишет оно теперь не в конкретно-специфичный бинарный файл, а в гораздо более широко распространенном формате. Приложению (если только оно не занимается анализом тех самых специфичных бинарных файлов) что в лоб, что по лбу - оно от этой смены бэкэнда никак не зависит.

     
     
  • 4.135, Аноним (134), 18:34, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > система  / системный демон

    И какая тогда проблема с записью? Или система падает что ли чаще, чем скуляйт?

     
  • 4.213, anoName (?), 21:16, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    раньше логи писались в еще более гораздо распространённом формате - текстовом. и ничё, жили как-то
     
  • 3.143, tkzv (ok), 19:40, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >> При сбое запись может быть частично повреждена
    > Дак это и к скуляйту относится.

    SQlite сперва создаёт временный файл, затем переписывает старый. В худшем случае теряются несколько последних записей.

     
     
  • 4.231, ptr (ok), 11:45, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    SQLite создает временный файл для WAL только при journal_mode = DELETE. И как для любой транзакции, теряются полностью не зафиксированные транзакции, а зафиксированные - гарантированно сохряняются. Точнее, при очередном запуске SQLite откатит все не зафиксированные транзакции по WAL.
    В случае journal_mode = OFF или MEMORY, по понятным причинам можно потерять произвольный объем данных.
    А чтобы не дергать постоянно файловую систему, в описываемом случае логично journal_mode = PERSIST, как и в большинстве других ACID СУБД.
    А вот насколько оправдано прибитие гвоздями к SQLite - большой вопрос. Возможно, тут лучше смотрелась бы идеология подключаемых модулей. Один из них - пусть будет для SQLite, другой - Berkeley DB, третий - ещё что-то key-value или SQL.
     
     
  • 5.244, _ (??), 17:36, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Berkeley DB is dead (thanks to f**n larry@oracle!) ...
    As for me SQL engine is overkill for this purpose, took any popular and minimalistic K-V db engine ... written on C or Rust 8-)
     
     
  • 6.252, ptr (ok), 23:05, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Berkeley DB is dead (thanks to f**n larry@oracle!) ...

    Да какая разница? Всё течет, всё изменяется. Именно поэтому прибивание гвоздями к SQLite меня и смущает.

     
  • 2.80, Аноним (80), 11:38, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    GDBM как-то обеспечивает атомарность через reflink copying и создание двух файлов БД: старой и новой версии, которые меняются местами.
     
     
  • 3.221, Аноним (220), 05:58, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    И как это поможет при недозаписи новой версии?
     
     
  • 4.249, Аноним (249), 18:20, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > И как это поможет при недозаписи новой версии?

    Так и поможет - останется старая. А новую недописанную стереть - ну, не судьба, откат транзакции типа.

     
  • 2.128, morphe (?), 17:31, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    С append-only вроде journald проще убедиться что ничего не повредилось
     

  • 1.6, iCat (ok), 08:31, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Кому-то очень хочется внедрить нечитаемую систему протоколирования из мира Windows в мир GNU/Linux ?
    А зачем?
    Системды мало?
     
     
  • 2.9, Аноним (9), 08:32, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Когда свободу на хлеб, остаются и без свободы и без хлеба.          
     
  • 2.11, анон (?), 08:34, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +15 +/
    Она и сейчас нечитаемая.
     
  • 2.28, Аноним (52), 09:12, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А это "год линукса на десктопе против серверного линукса" ака "функциональность против простоты"
    И то, и другое имеет право на жизнь...
     
  • 2.36, aname (ok), 09:23, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Раст в ведро протащили, почему бы и не протащить SQLite
     
     
  • 3.92, Аноним (92), 12:06, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тогда в Unbreakable Linux будет Oracle DB для lastlog, btmp, utmp и wtmp.
     
     
  • 4.119, aname (ok), 16:06, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Тогда в Unbreakable Linux будет Oracle DB для lastlog, btmp, utmp и
    > wtmp.

    Стоит отдать должное: оно работает.
    Бтв, всегда можно пропатчить на своё. Неужели СООБЩЕСТВО™©® не осилит?

     
  • 2.121, aname (ok), 16:08, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Кому-то очень хочется внедрить нечитаемую систему протоколирования из мира Windows в мир
    > GNU/Linux ?
    > А зачем?
    > Системды мало?

    "EVTX — это
    формат бинарных файлов журналов событий Windows (начиная с Vista/7), используемый для хранения системных, прикладных записей и логов безопасности Solvusoft. Файлы представляют собой XML-структуры, упакованные в бинарный контейнер, и обычно располагаются в C:\Windows\System32\winevt\Logs" © АИ

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

     
     
  • 3.222, Аноним (220), 06:01, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > парсить, всё же, проще

    Проще, говоришь? Ну-ну. Поинтересуйся у АИ как-нибудь на досуге историей ошибок и уязвимостей в парсерах XML, и насколько на самом деле непросто его парсить. Особенно, когда это парсер для прода, а не для C:\laba1.

     
     
  • 4.232, aname (ok), 11:50, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >> парсить, всё же, проще
    > Проще, говоришь? Ну-ну. Поинтересуйся у АИ как-нибудь на досуге историей ошибок и
    > уязвимостей в парсерах XML, и насколько на самом деле непросто его
    > парсить. Особенно, когда это парсер для прода, а не для C:\laba1.

    Ошибки были сделаны и исправлены. Значит, всё, что надо, могло бы быть уже учтено.

     
  • 3.230, Аноним (230), 09:56, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    XML это пожалуй самый сложный в парсинге формат из всех которые в обиходе Особе... большой текст свёрнут, показать
     
     
  • 4.233, aname (ok), 11:54, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > А парсинг в стиле SAX - это такой сильно отдельный вид боли.
    > Во первых там тоже возможны атаки на жор ресурсов. Во вторых
    > ты даже не знаешь worst case жор ресурсов. И если атакующий
    > сделал терабайтную запись - тебе остается только молиться чтоб дефолты парсера
    > были одупляемыми и он забил на парсинг до того как все
    > загнется в аварийном виде. Не говоря о нужде трекать структуру документа
    > самому и что там где.
    > А есть еще всякая совсем-совсем черная магия - типа XSLT какого. Ее
    > почти никто не понимает, ей почти никто не пользуется - но
    > это не значит что атакующий не влепит тебе этим по бошке.

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

     
     
  • 5.245, _ (??), 17:44, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну так разбивайте на файлы.

    Won't help - see OO for proof ...
    >Бтв, винда как- то справляется.

    Nope. "Somehow" - is NOT what you want, if you have right to choose.
    >А существование XPath, как бы там ни было, это прям очень хорошо,

    Useless. Give some value for XML-monkey only :-p

     
  • 5.250, Аноним (249), 18:23, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну так разбивайте на файлы. Бтв, винда как- то справляется.

    В винде ее новый логгер стал как раз капец просто каким тормозным и кривым.

    > А существование XPath, как бы там ни было, это прям очень хорошо,

    Ничего хорошего во всей этой оверинженерии имхо нет. А XSLT гугло по сути прямым текстом вообще предложил "kill it with fire" дропанув в хроме поддержку.

     
     
  • 6.253, aname (ok), 17:25, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну так разбивайте на файлы. Бтв, винда как- то справляется.
    > В винде ее новый логгер стал как раз капец просто каким тормозным
    > и кривым.
    >> А существование XPath, как бы там ни было, это прям очень хорошо,
    > Ничего хорошего во всей этой оверинженерии имхо нет. А XSLT гугло по
    > сути прямым текстом вообще предложил "kill it with fire" дропанув в
    > хроме поддержку.

    Хз что там стало тормозным. wevtutil нормально работает. лол

    Гугло предложит тебе, обязательно, лучшую технологию. С интегрированным ИИ. Ты ж этого хочешь. Меня устраивает XPath в логах шинды- можно дёргать события ЕДИНООБРАЗНО, а не грепать, а потом ещё грепать, и ещё грепать, потому, что нитакусик пишет логи в своём формате.

    Так что да, формат логов винды- это прямо хорошо.

     
  • 2.146, tkzv (ok), 19:54, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1. С каких пор SQlite стала виндовой?

    2. Для чтения нужнен один 2-мегабайтный бинарник: sqlite3 log.db .dump | less. Можно more. Версия без поддержки UTF и Tcl существенно меньше. Программа ставится по зависимостям кучей других пакетов, включая Python, PHP, Node.js, NSS, Qt, Gnome, SVN, Cargo, MPD, NFS, Audacity, Avidemux, Hugin, Doxygen.

    3. Если бы systemd был таким же простым, вылизанным и предсказуемым, все бы давно на него перешли.

     
     
  • 3.214, anoName (?), 21:17, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    т.е. тебе нужна реляционка чтобы делать ей less?
    оригинальная идея.
     
     
  • 4.223, Аноним (220), 06:02, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    У тебя есть идеи лучше как найти то, не знаю что?
     
     
  • 5.246, _ (??), 17:50, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ehmm ... dude! Current SQLite has FTS functionality ... Google FTS5 :)
    But as for me, it sound strange and overkill for freakin simple logging :)
     

  • 1.7, Аноним (9), 08:31, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Хранение логов в тормозлайт худшая идея, какую можно придумать. Ещё это завязывает на стороннего разработчика, который неизвестно что может сделать и с продуктом и со своим форматом. Если они такие любители прокладок пусть пишут новые либы для нового бинарного собственного и если надо расширяемого формата. А не превращают всю систему в один единый тормозящий скуль.
     
     
  • 2.13, Фонтимос (?), 08:37, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Подтверждаю, линукс станет тормозом. Хотя по мне, пучть внедряют, быстрее все слиняют на ФриБиЭсДи.
     
     
  • 3.30, gz (?), 09:14, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    все ненадо, ато слиняют ведь и те внедрятели с чудесатыми предложениями сделать чтото во фряхе
     
  • 2.17, User (??), 08:43, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну, в доelastic'овскую пору - я вот вполне себе делал центральный rsyslog с хранением в mysql - вполне себе работало.
     
     
  • 3.29, Аноним (52), 09:13, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    mysql и sqlite не сравнимы по скорости
     
     
  • 4.41, User (??), 09:39, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну да - sqlite в таких сценариях прям сильно быстрее будет.
     
     
  • 5.72, Аноним (88), 11:24, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да в воображаемых сценариях, которые не встречаются в реальной жизни.
     
     
  • 6.81, User (??), 11:41, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Да в воображаемых сценариях, которые не встречаются в реальной жизни.

    Ооо, экспертная экспертиза от экспертов подкатила.
    Мускуль _может_ быть быстрее в сценариях, когда у тебя "горячие" данные\индексы в памяти и ты работаешь с ними - но в случае с аппенд-онли логами, которых может быть еще и немало? Неа.
    Может быть быстрее в случаях конкуррентной многопоточной записи - но этот ластлог сам угадай, кем-и-как пишется.
    А в сценариях "пролопатить *цать-данных" - ну вот duckdb _у меня_ прям изрядно быстрее работает.
    Такие вот дела.

     
     
  • 7.86, Аноним (88), 11:45, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Да в воображаемых сценариях, которые не встречаются в реальной жизни.
    > Ооо, экспертная экспертиза от экспертов подкатила.
    > Мускуль _может_ быть быстрее в сценариях, когда у тебя "горячие" данные\индексы в
    > памяти и ты работаешь с ними - но в случае с
    > аппенд-онли логами, которых может быть еще и немало? Неа.
    > Может быть быстрее в случаях конкуррентной многопоточной записи - но этот ластлог
    > сам угадай, кем-и-как пишется.
    > А в сценариях "пролопатить *цать-данных" - ну вот duckdb _у меня_ прям
    > изрядно быстрее работает.
    > Такие вот дела.

    То есть ты пытаешься описать сценарии, которые у нормальных людей в нормальной жизни не встречаются?

     
     
  • 8.89, User (??), 11:58, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Ээээ ну вот тебе сценарий - пишем логи в реляционную ... текст свёрнут, показать
     
  • 2.38, Аноним (38), 09:24, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Хранение логов в тормозлайт

    По сравнению с чем SQLite тормозной?

     
     
  • 3.73, Аноним (88), 11:25, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Вот прям по сравнению совершенно со всем.
     
     
  • 4.87, Аноним (87), 11:45, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Отличная аргументация.

    Может, хотя бы попробуешь ссылки какие-то найти, бенчмарки?

     
     
  • 5.125, Аноним (125), 17:22, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    То есть ты умеешь думать только чужими ссылками бенчмарками? Совет никогда не включай телевизор.
     
     
  • 6.140, Аноним (140), 18:47, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > То есть ты умеешь думать только чужими ссылками бенчмарками?

    Я умею не воспринимать всерьез набросы без какой-либо аргументации и доказательств.

    В общем, ясно-понятно: никаких доказательств тормознутости SQLite не будет - только ad hominem.

     
  • 6.154, Аноним (154), 20:22, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть ты умеешь думать только чужими ссылками бенчмарками?

    Можешь свои предоставить, в чем проблема? Бремя доказательства лежит на утверждающем.

     
     
  • 7.191, Morthan (?), 09:17, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > SQLite настолько быстр, что конкурирует по скорости с fopen.
    > В некоторых сценариях использования можно применять SQLite
    > вместо файловой системы, это может быть на 35% быстрее.

    — «Безумные и забавные факты о SQLite» (https://habr.com/ru/companies/ruvds/articles/873816/)

     
     
  • 8.215, anoName (?), 21:19, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    нечто, работающее поверх фс быстрее фс кул стори ... текст свёрнут, показать
     
  • 4.147, tkzv (ok), 19:55, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > совершенно со всем.

    Даже с grep-ом?

     
  • 3.217, ffirefox (?), 21:33, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Записки оптимизатора 1С (ч.13). Что не так в журнале регистрации 1С в формате SQLite?

    https://habr.com/ru/companies/softpoint/articles/941666/

     
  • 2.39, letsmac (ok), 09:36, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    1C в свое время такое уже пробовал. В итоге вернулись к бинарным журналам. Тормозило на больших файлах знатно.
     
     
  • 3.74, Аноним (88), 11:26, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Я даже не удивлён что они попробовали этот заведомо провальный варинт это фишка их компании.
     
  • 3.255, glebliutsko (ok), 08:20, 18/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Мало того, что тормозило, так еще и намертво вешало процесс менеджера кластера, из-за чего новые соединение не устанавливались.
     
  • 2.40, Аноним (38), 09:38, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > это завязывает на стороннего разработчика, который неизвестно что может сделать и с продуктом

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

    > Если они такие любители прокладок пусть пишут новые либы для нового бинарного собственного и если надо расширяемого формата

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

    > А не превращают всю систему в один единый тормозящий скуль

    Тем временем в новости:

    "проблем, среди которых [...] низкая производительность запросов"

    Но в пятом велосапеде обязательно получится быстро!

     
     
  • 3.75, Аноним (88), 11:28, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Да только все проблемы, может кроме переполнения даты полностью выдуманные и нужны для попивателей смузи. В остальном логи работали идеально.  
     

  • 1.8, Аноним (8), 08:31, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А в чём проблема писать условный protobuf? Быстро, дёшево, достаточно атомарно
     
     
  • 2.57, Сталин (?), 10:16, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно тем, что там нет индексов и поиск o(n), а не o(log n)
     
     
  • 3.136, Аноним (134), 18:37, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Как часто надо разбирать логи? Это точно логи?
     
     
  • 4.196, Смузихлеб забывший пароль (?), 11:42, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    действительно, зачем разбирать логи. Будто они для этого пишутся ейбогу
    ещё и запись тормозит. Писались бы они сразу в мусорку и не отвлекали достопочтенных одменов своим существованием )
     

  • 1.12, Аноним (12), 08:35, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    т.е. если все равно переписывать, то они предлагают переписать так, чтобы сразу отсечь кору дуба и embedded системы, вместо того чтобы решить проблему создать новую
     
     
  • 2.148, tkzv (ok), 20:04, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты SQlite пользовался хоть раз? Для работы ей достаточно 100 килобайт плюс размер библиотеки.
     
  • 2.181, Аноним (181), 07:23, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как именно sqlite отсекает "кору дуба"?
     
     
  • 3.195, Аноним (195), 11:41, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Никак. Вот браузер Falkon хранит свои сессии, настройки в Sqlite и прекрасно себя чувствует на Core 2 Duo.
     
  • 2.197, Смузихлеб забывший пароль (?), 11:43, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    ничего что сабж аккурат из встройщины и портативных устройств ?
     

  • 1.19, Duck Fi (?), 08:45, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Идея неплохая, но мб пора задуматься и унифицировать не только это ?
    Почти каждый файл конфигурации и данных имеет свой формат.
    Например /etc/passwd,  мб что то по типу yaml применять.
    И обязательно сохранить текстовый формат, можно потерпеть скорость, потому что тут она не на что не влияет.
     
     
  • 2.22, User (??), 09:00, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Да сделали бы сразу "реестр linux - можно поверх sqlite'а", что ли - чего стесняться-то?
     
     
  • 3.25, Аноним (21), 09:03, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > можно поверх sqlite'а

    sqlite'а обязательно в контейнере

     
     
  • 4.34, Жироватт (ok), 09:21, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Внутри особой виртуальной машины
     
     
  • 5.210, Аноним (210), 21:01, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Написанной на питоне
     
  • 3.31, Аноним (31), 09:15, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Было бы неплохо, если одним методом/способом модно было управлять настройками всего софта, как на системном, так и на пользовательском уровне. Вроде были попытки /etc в xml/json записать. Но это надо от религии отказаться. Потому что как и во всякой религии наибольшее сопротивление любому (даже самому здравому изменению) будет от упоротых фундамендалистов.
    Хотите чтобы все было как 20 лет назад? В чем проблема - скачайте из архива линукс 20 летней давности и пользуйте.

    Проблема виндового реестра в бинарности и монолитности, что легко решаемо технически. Но В еще большей мере в отсутствии документации, и зоопарком подходов чего и зачем там хранить.  

     
     
  • 4.35, Duck Fi (?), 09:21, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Спасибо, а то я уже думал что меня не поняли.
     
     
  • 5.42, Аноним (31), 09:45, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Это понимает любой, кому приходится часто лезть в потроха линуксовых систем. Ну а школота на то и школота - ей, как собачке, главное заявить о своем присутствии опИсав самый высокий столб/дерево/забор что они нашли в пределах своей видимости.
     
  • 4.43, User (??), 09:46, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А не нужно уже. Проблема "в общем" решена дополнительными уровнями абстракции в виде terraform+(ansible|salt|черт-в-ступе) - _ты_ управляешь состоянием системы плюс-минус декларативно, описывая его да-да, вот этими вот yaml'ями плюс-минус в одном месте - а то, что "под капотом" там ошмётки потрохов с 70х еще годов... Ну вот у связистов еще с 40х наследие не разгребли до конца, а у энергетиков - так и вовсе девятнаха местами, и чО? Не переделывать же, право-слово.
     
     
  • 5.69, Аноним (69), 11:14, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Раз в 40 лет можно и переделать. С учётом накопившегося опыта, так сказать.
     
  • 5.91, Аноним (64), 12:05, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну дык, о чем и речь. С уровня абстракции выше какая разница что там в потрохах ниже. Но вот кто-то решил разгрести и привести их в порядок. Я так скажу - эти бинарные файлы меня иногда раздражали, ибо их так быстро и просто не посмотришь, надо утильку соотвествующую запускать. Благо это не часто требуется. Но раз эту утильку не обойти, какая разница в каком конкретно бинарном формате оно свое барахлишко хранит. Насчет ресурсов тоже какой-то просто анекдот. Это что за линукс системы такие, что ядро там и куча юзерспейса взлетает, пользователи какие то подразумеваются (ссш там например, или консоль какая-то, не говоря уж про шелл), а вот для скулайта уже не хватает? да любой пакетный менеджер в разы больше отожрет.
     
     
  • 6.116, User (??), 15:20, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Да поздно уже, говорю же Смысл какой Если понадобилось... большой текст свёрнут, показать
     
  • 6.225, Аноним (220), 06:07, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > бинарные файлы меня иногда раздражали, ибо их так быстро и просто не посмотришь, надо утильку соотвествующую запускать

    А чтобы текстовый файл посмотреть никакую утильку запускать не нужно, ни grep, ни less, ни даже cat. Он сразу через libastral в мозг транслируется. Удобство-то какое!

     
  • 4.60, Аноним (21), 10:25, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    фиксэд:

    > Вроде были попытки /etc в xml/json записать. Но это надо религию принять. Потому что как и во всякой религии наибольшее сопротивление любому существующему инструменту будет от упоротых религиозных. Хотите чтобы всё менялось каждую неделю? В чём проблема - делайте форк от форка каждую неделю.

     
     
  • 5.65, Аноним (64), 10:42, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дык оно и меняется, каждую неделю, причем безо всяких форков. Нужно быть идиотом, чтобы требовать чтобы что-то развивалось/улучшалось, но при этом не менялось. То что не развивается - оно уже мертво и давно на свалке. А вот кому хочется чтобы все оставалось как есть - ради бога, делайте форк и держитесь за него крепко. Ибо апстрим (если он еще не сдох - см. выше) БУДЕТ меняться независимо от вашего желания.
     
     
  • 6.137, Аноним (134), 18:40, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Что такое декларация и имплементация - некоторым предстоит только узнать.
     
  • 4.236, aname (ok), 12:47, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Было бы неплохо, если одним методом/способом модно было управлять настройками всего софта,
    > как на системном, так и на пользовательском уровне. Вроде были попытки
    > /etc в xml/json записать. Но это надо от религии отказаться. Потому
    > что как и во всякой религии наибольшее сопротивление любому (даже самому
    > здравому изменению) будет от упоротых фундамендалистов.
    > Хотите чтобы все было как 20 лет назад? В чем проблема -
    > скачайте из архива линукс 20 летней давности и пользуйте.
    > Проблема виндового реестра в бинарности и монолитности, что легко решаемо технически. Но
    > В еще большей мере в отсутствии документации, и зоопарком подходов чего
    > и зачем там хранить.

    Политики храни, настройки храни.

     
  • 3.48, Аноним (52), 10:05, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Реестр linux это gconf/dconf?)
     
  • 2.96, Фнон (?), 12:36, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В мозгах линуксоидов, явно, наблюдается отход от принципов построения UNIX: "всё есть файл".
    Ещё немного, и линукс превратится в System i, где "всё есть запись в табличке в реляционной БД".
     
     
  • 3.97, Аноним (52), 12:39, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не только наблюдается - активно применяется в том же systemd.
     
  • 3.105, Аноним (64), 13:41, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Действительно, имеется проблема в мозгах отдельных линуксоидов. Некоторые не могут понять что между "все есть файл" и "все есть текстовый файл" огромная разница.
     
  • 3.226, Аноним (220), 06:15, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Да бог бы с ним, с файлом. Локалхостно конечно, но конфиги все эти меняются раз в сто лет при значительнных апдейтах, можно и "всё файл" поредактировать, корона не упадёт. Проблема не в файле, а в том, что внутри него. А внутри него миллион разнообразных форматов, каждый вася на свой лад городит. У одного xml с DTD и XSLT для трёх опций, у другого принципиально несовместимый ни с кем собственный формат для 100500 опций, у третьего набор из однобуквенных ключей командной строки и таких же по эргономичности переменных окружения для тех параметров, на которые алфавита в двух регистрах не хватило. Уж лучше реестр, его хотя бы скриптовать удобно.
     
  • 2.182, Аноним (181), 07:24, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    У меня есть готовая концепция, как именно это сделать, но название etcd уже занято.
     

  • 1.23, Аноним (23), 09:01, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Короче, нельзя поменять то, нельзя поменять сё, потому что совместимость. Тогда давайте все на sqlite переведем, ведь он остается совместимым с тем что было до него.
     
     
  • 2.49, Аноним (21), 10:05, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > все на sqlite переведем

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

     

  • 1.24, Аноним (21), 09:02, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Фиксированный размер записей не позволяет добавлять новые поля

    А текстовый формат всё позволял.

     
     
  • 2.37, Жироватт (ok), 09:24, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это не стильно, не модно, нужно знать grep+awk и иметь квалификацию повыше, чем one-button-monkey.
     
     
  • 3.50, Аноним (21), 10:06, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для чтения бинарников или скуляйта что надо знать? :)
     
  • 3.54, Аноним (54), 10:12, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Короче, нужно по-дидовски и пердольно.
     
     
  • 4.62, Аноним (21), 10:31, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пройдёт немного времени - и логи в скуляйте станут "по-дидовски и пердольно". А внуки будут топить за новое, например, логи в облачном блокчейте через торренты.
     
     
  • 5.111, User (??), 14:41, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Пройдёт немного времени - и логи в скуляйте станут "по-дидовски и пердольно".
    > А внуки будут топить за новое, например, логи в облачном блокчейте
    > через торренты.

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

     
  • 4.68, Аноним (68), 10:57, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    нее, по миллениальски кавайно и лобно-томильно-дольно
     
  • 3.123, User (??), 17:02, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Это не стильно, не модно, нужно знать grep+awk и иметь квалификацию повыше,
    > чем one-button-monkey.

    Ну и ещё море, море, море терпения чтобы грепнуть какой-нибудь десяток гигабайт. Ну и немного телепатии ещё иногда, ага. Структуры-то нет, и что там в текстовый лог могло прилететь - да ктулху его знает.

     
     
  • 4.138, Аноним (134), 18:43, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > чтобы грепнуть какой-нибудь десяток гигабайт

    У вас точно там логи?

     
     
  • 5.157, User (??), 20:38, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >> чтобы грепнуть какой-нибудь десяток гигабайт
    > У вас точно там логи?

    ээээ... у меня _на серверах_ их примерно "нет". А в эластике... Ну, скажем так - до известных событий прохладное хранение этого добра на мамазоне мы пробовали. Заказчик почему-то был уверен, что петабайты этого добра имеют ценность в течении десяти лет и порывался за это самое хранение заплатить.
    Порвался, ага. Хватило почти на два года )

     
     
  • 6.247, _ (??), 18:06, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Many financial institution in NA are obligated to keep'em for 7 (CA) or even more years. Live with it! :)
     
     
  • 7.251, User (??), 20:19, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Many financial institution in NA are obligated to keep'em for 7 (CA)
    > or even more years. Live with it! :)

    Да мне-то что? И деньги не мои, и "грепать"(ТМ) их по серверам не приходится.
    Я правда предполагаю, что _они_ хранят всякую сесурити и аудит-трейлы, а не вот это вот все - но хз

     
  • 3.227, Аноним (220), 06:17, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    О, прибежали знатоки как правильно sedеть и gawkать. Сейчас будут заливать, что все кто по памяти не может распарсить выхлоп ls недостойны называться чем-то великим, и являются чем-то презрительно низким. Вторая проблема всего айти -- вахтёры. Первая -- инфантильность.
     
     
  • 4.241, Жироватт (ok), 09:48, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > это не мы ничего не умеем, кроме ввода промта в БЯМ, это ded'ы на нас токсично и презрительно смотрят! Отмените их уже, у меня выгорание и паническая атака!
     
  • 2.61, Соль земли2 (?), 10:26, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Индексировать для быстрого поиска по полям позволял?
     
     
  • 3.63, Аноним (21), 10:33, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > быстрого

    Хинто 1: Как часто это делаешь? Сколько процессорного времени от суточного на это уходит?

     
     
  • 4.90, Соль земли2 (?), 12:01, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну благодаря индексам journald позволяет быстро найти нужный отрезок времени.
     
     
  • 5.124, Аноним (124), 17:13, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Journald даже при открытии логов за текущий запуск сервиса без логов заставляет тебя сидеть ждать, пока оно соизволит раздуплится. Поттеринговский журнал - это анти-пример того, как нужно делать логи.
     
     
  • 6.130, Соль земли2 (?), 17:37, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    нет, давайте лучше будем разбрасывать логи по всей файловой системе
     
     
  • 7.184, Аноним (181), 07:27, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Давайте!
     
  • 3.132, Аноним (132), 17:57, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так вон и по бинарникам этим ищут фуллсканом.
    Хотя мне непонятно, что мешает сбоку положить индекс, как в dBASE IV примерно из тех времён.
     
  • 2.149, tkzv (ok), 20:05, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Когда там был текстовый?
     

  • 1.26, Аноним (23), 09:08, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Предоставление fallback-бэкенда, хранящего журналы в упрощённом бинарном формате, для систем, на которых SQLite может оказаться избыточным (например, встраиваемые устройства с жёсткими ограничениями по памяти).

    А там что с изначальными ограничениями будет? Если их нет, то почему тогда этот fallback и не использовать везде вместо sqlite?

     
  • 1.27, Аноним (21), 09:10, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > не позволяет добавлять новые поля (например, идентификатор контейнера, имя сервиса, IP-адрес)
    > liblastlog2, libbtmp2, libutmp2 и libwtmp2... возможность добавления новых полей ... (через ALTER TABLE)

    Надо так: liblastlog2containerid liblastlog2servicename liblastlog2ipaddress libbtmp2containerid libbtmp2servicename  libbtmp2ipaddress libutmp2containerid libutmp2servicename  libutmp2ipaddress libwtmp2containerid libwtmp2servicename libwtmp2ipaddress

     
  • 1.47, Диды (ok), 10:04, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >Для исключения конфликтов при одновременной записи в журтал несколькими процессами (например, sshd и login) ....

    Чёт не понятно, как тут sqlite поможет

     
     
  • 2.51, Аноним (52), 10:06, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Механизм блокировки
     
     
  • 3.56, Аноним (21), 10:15, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Этот механизм эксклюзивный только для скуляйта? Больше нигде нельзя использовать?
     
     
  • 4.58, Аноним (52), 10:18, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, man flock
     
     
  • 5.79, Аноним (80), 11:36, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Звучит как шикарная возможность организовать DoS, если кто-то блокировку не отпустит.
     
  • 3.112, Диды (ok), 14:46, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так и у sqlite писатель всегда один - вроде блокировка на уровне файла базы данных
     
  • 3.185, Аноним (181), 07:28, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Просто отлично: база покарраптилась - и все системные сервисы падают. Крутяк!
     
     
  • 4.248, _ (??), 18:09, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    so ... it going to be the same as it is now?!
     

  • 1.53, Аноним (21), 10:10, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Предоставление fallback-бэкенда, хранящего журналы в упрощённом бинарном формате, для систем, на которых SQLite может оказаться избыточным

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

     
  • 1.55, Аноним (55), 10:14, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    самый лучший формат в данном случае - это текстовый.
     
     
  • 2.108, User (??), 14:31, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > самый лучший формат в данном случае - это текстовый.

    Но диды почему-то выбрали...

     
  • 2.228, Аноним (220), 06:19, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Какой из миллиона?
     

  • 1.59, Соль земли2 (?), 10:24, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Уже же есть journald, зачем этот огород?
     
     
  • 2.161, Сладкая булочка (?), 21:08, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    https://github.com/bakshansky/linux-auth-logs

    5.2.  Using systemd-journald

       journald collects all events, but:

       - it is tied to systemd, leaving systems without systemd out of the
         solution;
       - it requires libsystemd, complicating tools;
       - it lacks a simple file-based interface;
       - it does not guarantee ACID at the individual record level.

     
     
  • 3.242, Соль земли2 (?), 09:57, 16/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    В текстовых логах нет заранее известных полей. У каждой прилаги свои. Ещё и парсить надо. Нужную дату искать долго.

    journald умеет сам чистить старые логи. Не нужно мучаться с ротацией. Логи никогда не забьют всё место из-за кривой настройки. systemd перенаправляет stderr в journald, нет риска потерять важную ошибку.

     

  • 1.66, Аноним (66), 10:51, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > lastlog, btmp, utmp и wtmp

    А оно вообще нужно? Первый раз о таких слышу.

    > специализированных разделяемых библиотек, использующих SQLite. Для каждого типа журналов создаётся отдельная библиотека с единообразным C-интерфейсом: liblastlog2, libbtmp2, libutmp2 и libwtmp2

    Логгинг системных событий должен делаться через интерфейсы ОС, а не сбоку, какими-то спец. либами.

     
     
  • 2.151, tkzv (ok), 20:07, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какие проблемы? Добавят в ядро несколько мегабайт сишных файлов. Лицензия позволяет.
     

  • 1.67, Ахз (?), 10:54, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Текстовый формат это ущерб.
    Логи всегда структурированы, набор полей почти всегда предопределен. имхо очень здравая и полезная идея, когда к логам можно обратиться кверей, а не отправлять на стдин грепа тонну овна в поисках вхождения.
     
     
  • 2.76, Аноним (88), 11:32, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Кто предопределяет набор полей? Министерство логов, отдел наименования полей?
     
  • 2.93, Макан Негодяй (?), 12:26, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А ещё они должны быть зашифрованы, чтобы логи не смог прочитать злоумышленник!
     
     
  • 3.113, Абра (?), 14:58, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по предложению, злоумышленники смогут и записи удалять после себя:))
     
  • 3.141, Аноним (134), 18:49, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > должны быть зашифрованы

    Ведь в логах часто логят плейн-пароли.

     
     
  • 4.165, Макан Негодяй (?), 21:16, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >> должны быть зашифрованы
    > Ведь в логах часто логят плейн-пароли.

    Приватные ключи ещё для дебага хорошо в логи пихать. Очень помогает.

     

  • 1.70, Аноним (70), 11:14, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Из-за требований ABI‑совместимости

    Ага, вот и шиза вскрылась - api  у них нонсенс а abi железобетоно нетрогать. Биполярочка

     
     
  • 2.77, Аноним (88), 11:34, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Так это внутреннее abi, которое по кругу используют все программы и имеют жесткие связи. Как только меняешь тебе сразу прилетает. А api пользуется тот кто тебя никогда не достанет и не узнает где ты живешь.  
     
  • 2.104, Аноним (23), 13:30, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А ты разницу между ABI и API понимаешь?
     

  • 1.71, mumu (ok), 11:22, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Есть опасения насчет устойчивости к bad-секторам и т.п. проблемам, если файлы немного побились. SQL-ям от этого обычно очень плохо
     
     
  • 2.82, Аноним (88), 11:41, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +6 +/
    sqlite терял данные и потому что место на диске кончилось и просто так. Худшее решение для всего как electron.
     
  • 2.115, Аноним (115), 15:19, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть опасения

    Вы серьезно? опасения? Да им плевать на ваш хард диск, задайтесь вопросом, на кой Х нужны эти логи? Секурюрности ради? Аудита ради? Курам на смех!!! Задать надо главный вопрос, какого Х они используют без необходимости и насилуют диск пользователя?

     
     
  • 3.163, Аноним (163), 21:15, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Контора пишет.
    Зачем?
    Надо.
     
     
  • 4.175, Аноним (115), 00:13, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Контора пишет.

    Так она все пишет.

    > Зачем?

    С конторой ясно, зачем это делает линукс?

    > Надо.

    Ну хавайте тогда, и не надо удивляться если там за место скулайта пихнут постгрес.

     

  • 1.78, Аноним (78), 11:36, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Текстовые логи не пробовали?
     
     
  • 2.83, Аноним (88), 11:42, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Резиновые жесткие диски уже завезли или служебная информация в текстовом виде более красиво?
     
     
  • 3.85, Аноним (85), 11:44, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > - /var/log/lastlog - время последнего входа (структура "struct lastlog" с полем "ll_time" 32-разрядного типа time_t);
    > - /var/log/btmp - неудачные попытки входа;
    > - -var/run/utmp - текущие сеансы;
    > - /var/log/wtmp - история входов и выходов.

    Для чего из этого вам не хватает нынешних объёмов диска?

     
     
  • 4.127, Аноним (125), 17:26, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вместо даты 32 бита 4 байта ты собрался писать 10 юникод символов суммарно в 20 байт? Ты гуманитарий?
     
     
  • 5.142, Аноним (134), 18:54, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > 10 юникод символов суммарно в 20 байт? Ты гуманитарий?

    Такое только гуманитарий может написать.

     
  • 3.164, Аноним (163), 21:16, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, от 10 байт в день они порвутся, ТЕРАБАЙТНЫЕ ДИСКИ, да.
     

  • 1.84, Аноним (84), 11:43, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В принципе неплохой вариант - стандартизировать API с библиотеками. А как именно библиотеки будет хранить - это уже будет вторично (backend хоть на простых текстовых, хоть на бинарных, хоть в XML/JSON/etc.., хоть интегрируют в это journald)
     
  • 1.94, Аноним (94), 12:27, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вроде бы я когда-то видел предостережение от Мозиллы, в котором она призывала с осторожностью относиться к sqlite и не использовать его для новой функциональности. Видимо, они им очень наелись с Лисой.
     
     
  • 2.98, анон (?), 12:39, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кеды с непомуком своим мучались с sqlite-ом, мучались, а потом сказали что нужен встроенный mysql, т.к. у них не решаемые проблемы с конкурентным доступом к sqlite из разных процессов.
     
     
  • 3.100, Аноним (52), 12:42, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    https://bugs.gentoo.org/936102 возвращаются на sqlite?
     
  • 3.110, Аноним (66), 14:39, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нерешаемые для разрабов всяких некомуков с алконадями.
     
  • 2.99, Аноним (52), 12:40, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Очень интересно, можно ссылочку?
     
     
  • 3.101, Аноним (94), 12:58, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Поискал и не нашел. Давно это было, лет 10-15 тому или даже раньше. Может быть с тех пор что-то поменялось. Насколько я помню содержание статейки, основная мысль была в том, что базу надо аккуратно и грамотно обслуживать, ее нельзя оставить на самотек. Ну и, конечно, всё зависит от данных и сценариев использования, насколько часто они удаляются/обновляются. В свое время (а может быть и сейчас) в интернете были советы "как ускорить Лису" - всё сводилось к операции vacuum на разросшейся и фрагментированной sqlite-базе.
     
     
  • 4.102, Аноним (52), 13:08, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно что Chrome/ium тоже использует sqlite.
     
  • 3.153, tkzv (ok), 20:15, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ссылку не дам, но подтверждаю, что многие данные, которые логично было бы хранить в sqlite, хранятся в самопальном формате, представляющем собой JSON, пожатый LZ4 с приклеенным магическим числом. Например, список вкладок в previous.jsonlz4.
     
  • 2.156, Сладкая булочка (?), 20:30, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вроде бы я когда-то видел предостережение от Мозиллы, в котором она призывала
    > с осторожностью относиться к sqlite и не использовать его для новой
    > функциональности. Видимо, они им очень наелись с Лисой.

    Возможно вы путаете с websql? https://en.wikipedia.org/wiki/Web_SQL_Database

    К ней была критика как раз.

     
  • 2.186, Аноним (181), 07:31, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    SQLite действительно говно, database is locked если журнал не успело прожевать... а firefox не ждёт, он просто стартует. В результате "ой, у вас закладки отвалились, перезапустите Firefox"
     

  • 1.106, Аноним (106), 13:42, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Блин, можно сто угодно но не скулайт? Медленная, нанадёжная, однопоточная базёнка, без типизации, с непонятной моделью разработки от непонятного BDFL, не принимающего контрибушоны, в самописной недо vcs?
     
     
  • 2.109, Аноним (66), 14:34, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Андройд разрабам надо что-то делать.
     

  • 1.114, Аноним (115), 15:16, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    протестую, давайте сразу постгрес какой-нибудь, или куда-нибудьсразу в облако в спланк какой-то, зачем насиловать диск пользователя? зачем тратить ресурсы пользователя? На кой мне ваши эти логи если их любой может зачистить и удалить? на кой они нужны? для расследования инцидентов? да в современном мире нах никому не нужно ничего расследовать, у вас из карманов  свертки подарков достанут и все.
     
  • 1.117, Stanislavvv (ok), 15:21, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хрен бы с тем, что логи будут в БД, от Y2038 всё ж действительно надо избавляться. Но БД требует обслуживания — кто его делать будет?

    Ещё: как часто вы заглядываете в эти файлы тем или иным способом? Лично я — хорошо, если раз в неделю на подчинённых серверах и скорость доступа тут ни разу не ограничитель, несмотря на то, что на сервера есть пользователи из голого инета.

    По-моему, не в том месте оптимизируют...

     
  • 1.120, Аноним (120), 16:08, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Главное, чтобы sql injections предотвратили, когда будут в btmp писать имена юзеров.
     
     
  • 2.155, Сладкая булочка (?), 20:25, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Главное, чтобы sql injections предотвратили, когда будут в btmp писать имена юзеров.

    Тут еще орм нужен... на си, конечно.

     

  • 1.122, premium user (?), 16:39, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > переполнится 19 января 2038 года.

    Ну и чё, сделать в смотрелке логов обработку скачка на 2^31 секунд назад, если вдруг в логах появились даты из 70х - делов на 15 минут. Либо начинать сейчас хранить дату в uint32 хотя бы - хватит ещё до 2136 года. Они там 1 бит не используют.
    >  Для каждого типа журналов создаётся отдельная библиотека

    ИБД

     
  • 1.126, Аноним (124), 17:22, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Sqlite атомарность имеет ровно через тот же механизм - flock Это вообще не пана... большой текст свёрнут, показать
     
     
  • 2.235, Аноним (234), 12:30, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Бинарные форматы имеют фиксированный размер полей, следовательно для доставания последних
    > транзакций достаточно сделать lseek(SEEK_END) в файле, проверить что мы приземлились на
    > делимое на размер структуры значение (иначе откатится назад,

    Я вообще не понял. Изменить, значит, формат поля в бинарном файле - это фи, ABI меняется, и вообще. А вкатить SQLite - ABI не меняется чтоли? Или что за двойные стандарты такие?

     

  • 1.129, Аноним (132), 17:36, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > переполнение 32-разрядных счётчиков времени в 2038 году

    Кого-то волнует история входов до 1970 года? А unsigned хватит до 2106 года.

    Вместо одного каста к unsigned тащить sqlite? :) Остальные проблемы вообще надуманные.

     
     
  • 2.238, Аноним (-), 13:28, 15/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Вместо одного каста к unsigned тащить sqlite? :) Остальные проблемы вообще надуманные.

    Да даже так то - сделать его u64 и сломать _1_ раз ABI - почему бы и нет? По сравнению с новой либой на пару мегов в обязаловку (и тоже сломом ABI ессно) - сплошные преимущества. Но автор твердо решил подмахнуть агенту Bobby Tables'у нежданчиками :)

     

  • 1.139, Аноним (139), 18:45, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    1. Индексы всегда были маппингом. Зачем их тащит в формат файла?
    2. Что в формате нет места для флага размера даты в байтах? Пишите с какого-то момента в 64-битном формате или сбрасывайте 32-битный, только учитывайте флаг.
    3. использование интерфейса запросов это обслуживание и новый класс уязвимостей.
    4. получается - что знаем то и предлагаем.
    5. бинарность хороша для аппаратной реализации.
     
     
  • 2.189, Аноним (189), 08:36, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    2. Там структуры, а вы предлагаете изменить (увеличить) размер этих структур.
    Хотя, конечно, можно эти логи просто... не читать.
     
     
  • 3.207, Аноним (207), 19:32, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Формат struct можно пересмотреть через union
     

  • 1.144, Сладкая булочка (?), 19:44, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А зачем для системных логов, которые по факту временная серия, целая sql база данных?
     
     
  • 2.158, tkzv (ok), 20:40, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Приходилось когда-либо работать с логами? Всерьёз, с поиском одновременных событий по нескольким логам, сопоставлением полей из нескольких логов. В объёмах, требующих автоматизации. Мы в такой ситуации быстро пришли к выводу, что SQL-база удобнее текстового файла, а SQlite удобнее самодельного бинарного формата, который можно спроектировать за разумное время.
     
     
  • 3.159, Сладкая булочка (?), 20:59, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Приходилось когда-либо работать с логами? Всерьёз, с поиском одновременных событий по нескольким
    > логам, сопоставлением полей из нескольких логов. В объёмах, требующих автоматизации. Мы
    > в такой ситуации быстро пришли к выводу, что SQL-база удобнее текстового
    > файла, а SQlite удобнее самодельного бинарного формата, который можно спроектировать за
    > разумное время.

    Как вы сранвиваете логи на разных хостах?

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

     
     
  • 4.167, tkzv (ok), 22:14, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Как вы сранвиваете логи на разных хостах?

    У нас задачи были другие, не связанные с lastlog/btmp/utmp — несколько серверов, на каждом несколько процессов обрабатывает входящие данные с АЦП, иногда что-то падает. Долго пытались приспособить разные готовые решения, на момент моего ухода долбались с Graylog. SQlite прилепили как временную замену, но она оказалась самой надёжной, т.к. не зависит от сетевых соединений и прав. Каждый процесс пишет свой лог, по окончании он сбрасывается в общий. И это надо соотносить с логами других программ, обычно тоже текстовыми или Graylog.

     
     
  • 5.170, Аноним (139), 23:03, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Лабораторную поделку в прод?
     
     
  • 6.187, tkzv (ok), 07:40, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    По сути, да. Курсовая работа на Турбо Паскале выросла до пакета программ, приносящего в год ~100 миллионов долларов с продаж и платных обновлений. Об архитектуре первые лет 20 не задумывались — производительность компьютеров росла, рынок рос, требовалось срочно хоть какое-то решение для незанятых ниш.
     
     
  • 7.206, Аноним (206), 16:11, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    У нас на работе тоже программа на Delphi 7, приносит конечно не 100 миллионов в год а порядка 50, но все же. Тоже планируем сейчас переносить логи на postgresql.
     
  • 5.173, Аноним (134), 23:10, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    У вас кони смешались с людями. Тут налицо ошибка проектирования системы.
     
  • 3.160, Сладкая булочка (?), 21:02, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > SQL-база удобнее текстового
    > файла, а SQlite удобнее самодельного бинарного формата, который можно спроектировать за
    > разумное время.

    Есть apache arrow и прочие columnar форматы для эффективного хранения временных данных, а это они и есть?

     

  • 1.150, Анон1110м (?), 20:05, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чёто вспомнилась ОС на .NET.

    C# Open Source Managed Operating System (Cosmos) is a toolkit for building GUI and command-line based operating systems, written mostly in the programming language C# and small amounts of a high-level assembly language named X#.

    https://www.gocosmos.org/

     
  • 1.152, nrv (ok), 20:13, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я вот всегда думал:
    сначала разрабатывается ОС (хз конечно как, может на более старой ОС, на ДОС, та на ЭВМ с перфокартой). С минимальным набором средств разработки под эту ОС, ака компилятор С
    на ОС разрабатывает низкоуровневое ПО, утилиты
    потом на них высокоуровневое ПО

    чтобы иметь возможность ступить на уровень ниже - и исправить баг

    а тут, что мы имеем: включить в системное окружение ОС высокоуровневое ПО

    и я даже не против, когда-то линуксы должны же стать высокоуровневыми, чтобы на уровне пользователя чуть что не рассыпаться на набор скриптов и конфигов
    но тогда должна быть ОС, на которой ведется разработка линукс? или линукс настолько дуальный что на это дело сгодится сборка без базёнки?

     
     
  • 2.172, Аноним (134), 23:07, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > когда-то линуксы должны же стать высокоуровневыми

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

     

  • 1.162, Сладкая булочка (?), 21:10, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Написали бы тогда уж на расте новое решение. Почему нет? Заодно и проверим.
     
     
  • 2.171, Аноним (134), 23:04, 13/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чтобы написать на расте, надо:
    1. иметь исходник на Си;
    2. попросить ИИ переписать.

    Или вариант попроще:
    1. иметь исходник на Си;
    2. попросить ИИ написать обёртку над Си.

     

  • 1.168, Аноним (168), 22:45, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Мало хостов поимели через Log4j. Теперь появится возможность SQL иньекции через логи.
     
  • 1.174, Аноним (139), 23:16, 13/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Автор топика написал что-то невнятное: "заменить устаревшие бинарные форматы системных журналов ...на новые разделяемые библиотеки"
    Помогите расшифровать как совместить сущности разной природы.
     
  • 1.176, Аноним (176), 00:52, 14/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем это надо, когда есть plaintext и journald
    Вообще все логи в актуальном дистрибутиве должны быть в systemd-journald, а в альтернативной реальности в txt.
    Больше никакие форматы непонятные не нужны
     
  • 1.178, Alladin (?), 07:07, 14/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    жесть какая по идее тяжелая система выйдет
     
     
  • 2.211, Аноним (210), 21:05, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно ведь SQLite должен парсить SQL
     

  • 1.188, X86 (ok), 08:09, 14/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Почему именно SQLite, а не что-то побыстрее?
     
     
  • 2.190, Аноним (189), 08:40, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Все кому не лень - умеют плюс public-domain?
     

  • 1.192, BrainFucker (ok), 10:58, 14/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Я бы ещё весь хлам в /etc заменил бы на sqlite.
     
     
  • 2.194, Аноним (195), 11:38, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ага, даёшь в Linux бинарный реестр! И... пришло время переустанавливать Linux.
     
     
  • 3.199, BrainFucker (ok), 11:54, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И... пришло время переустанавливать Linux.

    Такое впечатление что местный контингент с виндой знаком максимум по WinXP.

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

     
     
  • 4.204, нах. (?), 14:40, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    все правильно, им эти знания как раз и пригодятся. А еще больше - 95й где все работало, но каким-то чудом.

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

     

  • 1.198, Аноним (198), 11:52, 14/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вообще у firefox половина профиля на sqlite и он уверенно фигачит гигабайты в час на SSD.

    Там конечно не только sqlite виноват, но в том числе и sqlite.

     
     
  • 2.200, Аноним (134), 12:28, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > половина профиля на sqlite

    Как бы объяснить, что "профиль фурифокса" - это не совсем "логи системные".

     
  • 2.203, нах. (?), 14:38, 14/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    с разморозочкой. фуфлофокс давным-давно вместо sqlite использует доморощенные горбатые форматы (погугли историю почему иногда ломается восстановление размера окон при перезапуске и ужаснись) - часть xml-based, а остальные просто вот м@к@ep с ветки выcpaл.

    там sqlite совсем не виноват, но это совершенно не повод тащить его туда где append-only кроме lastlog бинарные файлы примитивной и вполне разумной структуры для такой простой задачи. Кому-то просто захотелось новый грант. Работать-то оно не умеет.

     

  • 1.208, Аноним (208), 20:10, 14/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Накапливание бинарных логов предлагают переделать в задачу ведения реляционных баз, да и ту сами не осилят и будут писать хвастливые статьи как за них LLM всё сделала
     
  • 1.229, Аноним (-), 09:49, 15/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >lastlog, btmp, utmp и wtmp на использование SQLite

    А лоббирует это чудное шоу - видимо, Bobby Tables? Который теперь сможет поприкалываться - прямо в базовых системных вещах?

     
  • 1.237, Аноним (218), 12:52, 15/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сперва создают проблему, потом пытаются решать негодными средствами. Смузиподход, как он есть. Атомарности им не хватает в какой-то структурке - такие вещи в эмбедовке решены еще лет 40 назад, вообще-то.
     
  • 1.239, Аноним (239), 01:25, 16/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С учётом того что lastlog2 на склайте вмержен где-то в 2024 в util-linux, то почему бы и нет
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру