История изменений

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

Текст - это не формат, это именно что текст. Единственное отличие от бинарных данных - в наличии знакомых буковок. Это уже текст сам по себе может быть структурирован каким-либо образом, чтобы его могла читать и анализировать машина. И вот как раз для последнего никаких less'ов недостаточно. less позволяет вам увидеть текст глазами, но он ничего не знает, например, о том, что груда символов в начале каждой строки - это timestamp. Так что по сути при машинном анализе логов вам каждый раз самому приходится задавать критерии, по которым будут выделены поля. И когда эти ваши утилиты общего назначения по регэкспам, объединяясь в конвейер (по сути в результате получается мини-программа, написанная вами на скорую руку), обрабатывают логи, они работают на порядки медленнее, нежели обработчик бинарного формата. На логах почтового сервера по 4-6Gb в день попробуйте поупражняться, например. Приплюсуем к этому само время на составление конвейера - вот вам и «целесообразность». Не стану уж говорить о том, что чистка раздела /var от логов с помощью logrotate или вручную - тоже требует времени, которое можно было бы потратить на решение более полезных с т.з. бизнеса задач. Надеюсь, вы не будете спорить с тем, что бинарные логи покомпактнее выс*ров syslog'а будут? Программа узкого плана, ориентированная на выполнение специфичной для неё задачи всегда экономит время=деньги. Вам ни то, ни другое не нужно?

P.S. непонятно только одно: почему не SQLite, почему нужно было какой-то свой формат придумывать?

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

Текст - это не формат, это именно что текст. Единственное отличие от бинарных данных - в наличии знакомых буковок. Это уже текст сам по себе может быть структурирован каким-либо образом, чтобы его могла читать и анализировать машина. И вот как раз для последнего никаких less'ов недостаточно. less позволяет вам увидеть текст глазами, но он ничего не знает, например, о том, что груда символов в начале каждой строки - это timestamp. Так что по сути при машинном анализе логов вам каждый раз самому приходится задавать критерии, по которым будут выделены поля. И когда эти ваши утилиты общего назначения по регэкспам, объединяясь в конвейер (по сути в результате получается мини-программа, написанная вами на скорую руку), обрабатывают логи, они работают на порядки медленнее, нежели обработчик бинарного формата. На логах почтового сервера по 4-6Gb в день попробуйте поупражняться, например. Приплюсуем к этому само время на составление конвейера - вот вам и «целесообразность». Не стану уж говорить о том, что чистка раздела /var от логов с помощью logrotate или вручную - тоже требует времени, которое можно было бы потратить на решение более полезных с т.з. бизнеса задач. Надеюсь, вы не будете спорить с тем, что бинарные логи покомпактнее выс*ров syslog'а будут? Программа узкого плана, ориентированная на выполнение специфичной для неё задачи всегда экономит время=деньги. Вам ни то, ни другое не нужно?