я думаю быстрее было-бы сделать на sed.

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

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

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

естественно. Но очевидно, что сабж ещё не готов для продакшена.

за пруфом далеко ходить не надо: Ошибка входа в систему.

никто даже не попытался помочь.

Но вообще здесь больше смущает именно краткость срока между 209-м и 210-м релизами.

там все "релизы" пока ещё беты. Точнее преальфы. Релизы пойдут когда его в RHEL запилят.

Но вообще здесь больше смущает именно краткость срока между 209-м и 210-м релизами.

Нет ничего странного.
210 релиз минорный к 209-му.
Когда захотели, тогда и выпустили.

Иногда даже kernel.org свои минорные релизы с одним пунктом исправлений выпускает чуть ли не через пару часов после предыдущего.

Это просто так кажется из-за единого номера версии.
Если бы нумерация была 20.9, вы бы и не обратили внимания. У всех бывает выход заплаток даже на следующий день.

Как бы сказать... "первичный" номер релиза в большинстве случаев является мажорным, т.е. 209-я версия уже должна быть по определению на каком-то уровне стабильности. А вот дальше как бы должны выходить релизы с точкой. Поэтому да, у меня диссонанс. Кстати на 20.9 я бы тоже обратил внимание. Видимо уже избалован версиями 20.9.ххх. Вот на такой релиз я бы внимания и не обратил. Но вообще здесь больше смущает именно краткость срока между 209-м и 210-м релизами.

Короче без очень быстрого поиска и такой-то матери не получалось

я думаю быстрее было-бы сделать на sed.

ну не у всех есть 32гб лишние, потому иногда и думать надо

я в свое время задолбался ковыряться в логах такого размера, и написал парсер который пихает их в БД, а там поиск и кореляции намного проще делать.

проще, но не быстрее. Если у вас память скажем 4096Мб, то с таким файлом БД займёт как минимум 8192Мб, и не влезет в память. Т.ч. это не решение.

кому он нужен? Речь как раз о дампах СУБД например. Типичная задача: имеем сервер с Over9000Mb, имеем клиент с 512Мб, и нужно на клиенте что-то найти в БД с сервера. Есть дамп, но он в Over9000Mb.

размером с RAM.

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

большие это какие?

размером с RAM.

большие файлы

большие это какие?