> все равно вы их не читатели.

Таки мы читатели. Это позволяет использовать системду эффективно и ненапряжно. Да, придется немного повтыкать в основные концепции. Зато потом я рисую кастомные юниты делающие мне довольно много продвинутой системной механики - и на скриптах я бы такое вообще зассал наворачивать. Потому что очень проблемное начинание, когда это из спичек и желудей делается.

> -- The start-up result is RESULT.
>          ^^^^^^^^^^^^^^^^^^^^^^^

Такое по идее должно быть описано в багтрекере. Впрочем, любителям sysv init и ко грех жаловаться - у них такое вообще всегда и везде было.

> ни малейшего повода размазывать это октровение всевышнего на десяток строк, когда
> и одной-то много (поскольку написана в ней очевидно ненужнейшеая мура)

Офигеть, в программах баги бывают. А ничего что в sysv init - фигней типа статуса сервисов вообще никто никогда не заморачивался? И баги в скриптах годами жили. Выхлоп программ - про...лся всегда и везде, упавший сервис мало кого колыхал, и вообще.

> аааа... ну тогда понятно, куда таким альтернативно-одаренным с текстовыми логами-то.
> действительно, переполнятся, пожалуй, пока вы там ковыряетесь. лучше удалять по кругу.

Это наиболее логичный способ лимитировать занимаемое логами дисковое пространство. При этом выбор невелик - если логи занимают больше места чем мы хотим, придется или пожертвовать чем-то, или саботировать запись новых логов, или положить систему к чертям, выжрав все свободное место. Можно подумать, другие системы логирования волшебники и могут что-то с этим сделать. Ха.

> а мы просто ловим петуха - и увольняем. И да, петух в данном случае тот,
> у кого в текстовом протоколе вдруг оказалась какая-то пакость.

Это тоже полезно - но на практике работает довольно погано. Я видел даже поимение горе-аналитиков "токсичными" данными, угарно выглядит.

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

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

Ну и вот у поцтеровской штуки есть например нормальное апи. Без каких-то особых специальных трактовок байтов. Что спасает его от множества идиотских грабель на ровном месте. Это апи позволяет например программам подвиснуть на потоке логов и осмысленно его жевать. Не гиг и через полчаса, положив все нагрузкой, а например по мере поступления, немного и плавно. А в вашей чудо-конструкции так вообще нихрена не предусмотрено.

> от пакостей гораздо более разрушительных (потому что строка нулей в консоли
> - всего лишь строка нулей, а сорванный стек в чудо-бинарном-логгере гораздо интереснее).

Строка нулей в консоли - вообще не отобразится. Консоль не может показать 0x00. А вот хитрозадое комбо кавычек и точек с запятыми может быть значительно интереснее.

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

Ну вот например, "echo 123 > trololo" или "&;?*hello<0x0d><0x0a>dude" - это вполне валидные имена файлов POSIX. Удачи однако ж их так с наскока прожевать в юниксвэйном стиле.

> практически в логи мусор писать не надо, а не надеяться что за
> тебя все сделает автор бинарноаутистфрендлилогоанализатора

Практически, лично я предпочту апи нормально относящееся к произвольным данным, а не попытки заткнуть Титаник там и тут.

> (о качестве его кода, кстати, ходят легенды)

Я бы это понял, если б не видел качество того что поцтеровский код заменяет и тамошнее качество. Кстати системдшный логгер творение не Леннарта, основная идея - тезис его братца. И кстати нормальный тезис - логи в которых tamper заметен. Хакер с должными правами всегда может саботировать логи. Но есть разница в том будет ли это замечено или нет. В текстовых логах хакер может просто подтереть за собой - и комар носа не подточит. В системд если используется ключ которого у хакера нет - придется грубо (и весьма обнаружимо) саботировать если захочется проблемную запись убрать.