Так что,
1. binary_cat --host… --port… — это слишком упрощенно. Этот binary_cat получится нормальной такой тулзенью со своим языком запросов.
2. До такого binary_cat надо еще дожить. Умеет ли этот journald настолько сложные логи, чтобы это имело хоть какой-то практический смысл?
Рождение теории хоть на сколько-то должно оправдываться практикой. Лично я пока не вижу практической пользы от journald и какого-то binary_cat по сравнению с обычными syslog и cat, которые есть в любой posix-системе. Экономия получается — на спичках, а геморрой от нестандартности может быть весьма ощутим.
Рождение теории хоть на сколько-то должно оправдываться практикой. Лично я пока не вижу практической пользы от journald и какого-то binary_cat по сравнению с обычными syslog и cat, которые есть в любой posix-системе. Экономия получается — на спичках, а геморрой от нестандартности может быть весьма ощутим.
ну если это будет стандартным решением... то тут возможны варианты. опять же, чисто теоретически.
если это станет стандартным решением для некоторых (не будем на них указывать пальцем) - все остальные решения автоматически перестанут быть таковыми.
один раз это уже проходили...
об чём и весь базар...
Экономия получается — на спичках, а геморрой от нестандартности может быть весьма ощутим.
а не получается IRL никакой экономии: ну может в версии 1.0 оно и получится, а как вносить изменения в логе для версии 2.0? Ещё и конвертор писать из формата 1 в 2? И конвертировать все 100500 строчек с каждым обновлением? Или напихать костылей как в венде, где DWORD это вовсе не понятное двойное слово, а НЕХ? И потом разбросать в каждой строчки эти костыли DWORD/STRING/BOOL и т.д.? И где тут "экономия"?
Зато будет "как в винде". Что и требуется. Никто из сообщества добровольно в этом говне копаться не будет, а RedHat снова окажется "впереди планеты всей".
