QR код в systemd

[metaclass]

Айсед вынудил таки почитать, что за QR код сунул поттеринг в systemd: http://lwn.net/Articles/512895/

На данный момент то что там описано, для меня выглядит как жуткий security theater:
* 15 минут подписи логов по умолчанию. Это овердохера - аттакер в среднем имеет 7.5 минут чтобы стереть из текущего неподписанного лога свое присутствие
* мутный алгоритм брата поттеринга
* возможность проебать старый ключик в памяти-свопе
* возможность просто нахрен вытереть логи - и вся информация, которая у нас останется это "логи кем-то были стерты".

Comments

[permea-kra.livejournal.com]

>ну как бы и смотрелка и логер должны знать endianess платформы, на которой они выполняются, не?

а) endianess возможные глюки не исчерпываются. б) Заранее неизвестно, с какой платформы будут смотреть.

> schemaless БД.

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

>было бы здорово подкрепить этот тезис примерами из реального мира

Эм... Я затрудняюсь подкрепить примерами самоочевидный тезис.

[develop7]

а) endianess возможные глюки не исчерпываются. б) Заранее неизвестно, с какой платформы будут смотреть.

а для неизвестной целевой платформы есть http://www.freedesktop.org/wiki/Software/systemd/export/

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

уверен, разработчики PostgreSQL охотно выслушают ваши аргументированные возражения и немедленно выкинут hstore

Я затрудняюсь подкрепить примерами самоочевидный тезис.

поправьте меня, если я ошибаюсь: вы называете тезис самоочевидным, но не знаете никого, кто так делает. Я ничего не упускаю?

[permea-kra.livejournal.com]

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

>уверен, разработчики PostgreSQL
Разработчики постргреса большие мальчики и ограничения hstore они знают.

>поправьте меня,
Поправляю: когда у человека спрашивают 'покажи белый снег', стоя посередине заснеженного поля, как-то затруднительно решить, во что ткнуть пальцем. Потому что если не видно сразу, то скорее всего не увидят и после тыканья.

[develop7]

почему нельзя сразу текстовый формат использовать?

а) «чтобы быстрее и проще писать лог и фильтровать его» подойдёт? б) export format не полностью текстовый — читайте внимательно про представление блобов

Разработчики постргреса большие мальчики

Ну Это Же Совсем Другое Дело

Поправляю

По-моему, просто вертите жоюли́те. Иначе трактовать некорректную аналогию вместо прямого ответа на прямой вопрос я затрудняюсь.

[permea-kra.livejournal.com]

а) нет. б) плохо. А мог быть текстовой.

==

==

Аналогия как раз корректная.

[develop7]

А мог быть текстовой.

зачем?

[permea-kra.livejournal.com]

А зачем бинарный? Какие у него объективные преимущества?

[develop7]

с бинарным логом объективно проще работать — требуется тупо меньше кода. Но вы не ответили на мой вопрос.

[metaclass.livejournal.com]

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

[develop7]

А не однохренственно?

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

+----+-------+------+----------------------+
| ID | title | body | created_at           |
+----+-------+------+----------------------+
| 1  | arr   | 123  | 2013-12-12T12:34:56Z |
+----+-------+------+----------------------+

Нуачо, самое главное же чтобы читалось нормально, да?

Олсо сложность seeking по plaintext — минимум O(n), по journal — O(log(n)*log(n))…O(n) (зависит от поля, по которому фильтруем).
Export format обратно совместим, JSON обратно совместим. Сам .journal — предположительно нет, и внезапно быть таковым не обязан.

[permea-kra.livejournal.com]

Кода для *кроссплатформенно* сериализованного лога требуется сопоставимо. Для текста есть стандартные инструменты - cat, tail, head, wc, grep, awk, etc. Для бинарного их нет, в лучшем случае есть конвертор, которого может не быть на том, на чем приходится смотреть/анализировать логи.

[develop7]

Кода для *кроссплатформенно* сериализованного лога требуется сопоставимо

откуда вы знаете, если вы так и не привели ни одного примера?

Для бинарного их нет, в лучшем случае есть конвертор

Показательно, что вы по-прежнему не даёте себе труда изучить критикуемый инструмент и вследствие чего несёте чушь. journalctl — не «конвертор в текст», а CLI-обёртка над библиотекой libsystemd-journal, которая как раз и выдирает из логов .journal информацию.

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

разве что из политических, а не рациональных соображений — исходники-то открыты

[permea-kra.livejournal.com]

>откуда вы знаете,

Я писал сериализацию-десериализацию ручками.

> journalctl — не «конвертор в текст», а CLI-обёртка

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

>разве что из политических, а не рациональных соображений — исходники-то открыты

Тем не менее, проблема существует.

[develop7]

Аналогия как раз корректная.

продолжаете вертеть? ну-ну