systemd 249

Ну так все сходится: лаконичные короткие ответы по существу против потока сознания ниочем. Также и в компутере.

Я-то всю сознательную (с момента установки Slackware)

Уже ржачно :-D

не подлежат ручной обработке в принципе. Это те же конфиги

Ты не умеешь править конфиги вручную? И что ты забыл на ЛОРе?

Ты мог бы попытаться меня переубедить?

А смысл? Дурака учить - только портить.

а вот любители системд ограничиваются простым и кратким «вы просто ничего не понимаете, идиоты»?

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

Любители systemd - это такие попугаи, которые даже не знают, что подобная история в Linux уже была, только тогда никто не кинулся писать «единственную и непогрешимую систему». Результатами они пользуются до сих пор. Хотя уже и в той работе Поттеринг нашёл фатальный недостаток…

Юниты, в отличие от конфигов, внятно читаются/редактируются только автоматикой

Я, конечно, за эти годы разные варианты тупизны на ЛОР наблюдал, но чтобы идиот не осилил ручное редактирование .ini файла… по-моему это рекорд.

Между прочим, задумался я

Не льсти себе.

надо либо читать документацию и работать

Сперва zabbal нам пишет: «юниты, как правило, не дистроспецифичны - поэтому их просто включают в апстрим и один и тот же файл используется в федоре, убунте, зузе, арче…» т.е. работать НЕ надо - всё уже сделано в апстриме один раз и для всех. А потом: «надо работать». Ты дурак или шизофреник?

почему надо смотреть в конфиг, хотя ДВЕ программы, которые работают с ним

Потому что программы исполняют написанное в конфиге. Корректность написанного их не волнует. Нужна проверка корректности? Открывай багрепорт.

Ах да, если они будут проводить валидацию конфига, то сразу прибегут анонимы, которым не нравится такое отношение разработчиков – ведь настоящий пользователь линуксов не должен бояться «порезать пальчик».

Твоему материнскому процессу со скриптом.

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

Оккам говорил, что самое простое решение всегда самое верное

Враньё, он такого не говорил. Ты, оказывается, не только про systemd врёшь.

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

Ты про конкуренцию между upstart, runit, s6, sysv и systemd в результате которой последний победил во всех немаргинальных дистрибутивах?

«Чего, бл…?!»(с)

Я тебе напомню, что ты самолично писал: «При проблемах в fstab ты загружаешься в emergency shell и смотришь journalctl, где видишь проблемы с fstab». А теперь: «если они будут проводить валидацию конфига, то сразу прибегут анонимы».

Очередное подтверждение того, что эксперты systemd сами ни хрена не знают, как этот самый systemd устроен и работает.

Осталось только понять, что проблемы с монтированием разделов по fstab вероятнее всего повлечены проблемами в fstab по приведенной выше логике, и дело с концом. Впрочем, это моя ошибка – анонимам все нужно разжевывать досконально.

Давай начнем с начала. Systemd. – Тот случай когда стоит таки поставить рядом (тоесть «сопоставить») соизмерить средства и цели, жертвы и достижения, чтобы обнаружить всю глубину стокгольмского синдрома в апологетах systemd. И спроси себя: так ли тебе нужно чтобы какая-то программа думала вместо тебя, когда тебя еще не схватил за что пришлось дедушка Альцгеймер? И спроси себя, а не опасно ли пускать в свою машину слишком умные программы слишком мунтных и хитровыделанных разработчиков в этот век, когда в «руках» машины вся твоя жизнь? Посмотри на своих спиногрызов и спроси себя: для кого ты торопишь время, когда машины будут думать вместо людей, за людей, при чем там, где их об этом не просили? – А systemd именно такой непрошеный и не званый «благодетель» в мире Linux: именно поэтому прополз в нее в образе еще одного безобидного инита, Потеринг не заикнулся о своих претензиях, о будущем systmd.

Boilingfrog – по моему так это называется то, что делал Поттеринг с поьзователем GNU/Linux, постепенно превращая его в systemd/linux – вот как жаба варится живьем, если подымать температуру постепено, – так же варился и пользователь Linux

Siborgium, мне не нравится упражняться в остроумии и зубоскалить в твою сторону. Про стокгольский синдром это не тебе персонально и лично а об общем явлении. К данному моменту у меня все же странное впечатление, что ты ни секунды ни троль, и не от скуки развиваешь тему: действительно веришь в призрачные «преимущества» systemd. Но не от бессилия ли ты в это веришь? Не от страха ли, что все равно уже не дано тебе отказаться от systemd, а если и откажешься то все равно ты лишь «бессильная одиночка»? Возможно тебе не приходит в голову, что из таких «бессильных одиночек» и состоит мир? Нет, не от этого?

В таком случае ты просто доверчивый и очень добрый человек. Как и все добрые люди ты склонен верить людям, особенно таким «несчастным» и заплевываемым со всех сторон как Поттеринг. Хорошие люди действительно склонны верить во все хорошее. И даже в благонамеренность откровенных подонков иногда – мы это видим во множестве примеров всегда, кругом…

Поставь себе наконец слаку на виртуалочку, и покопайся в ней. Подозреваю ты сравшиваешь «преимущества» systemd не с реальными качествами GNU систем, а лишь с тем кошмаром, который разработчики systemd тебе нарисовали, чтобы пообещать избавление от него.

И да… Я не предлагаю тебе в качестве альтернативы systemd самому лично писать все на свете, и вручную настраивать. Нет. Но важно то, что systemd истребляет конкуренцию. А в конкурентной свалке разработчики – один другому волк, один другому цензор, контролер, ревизор …как там оно называется?… – ну ты меня понял. Systemd решает не твои проблемы, он решает свои проблемы. И конкуренция для него большая проблема. Поэтому он стремится на место основной зависимости, поэтому так отчаянно пожирает непрофильный функционал, подминая все под себя – он стремтся стать незаменимым. То зло, которое он несет с чисто технической точки зрения – монолитность, непрозрачность и тд – это лишь бледная тень, легкие симптомы заразы, лишь маркеры того того зла, которое заряжено в него с точки зрения долгоиграющей перспективы. Корень этого зла – МОНОПОЛИЯ.

Ещё раз, для танкистов systemd’шников. Было сделано ровно так, как вы и предлагаете, загружен ваш калечный systemd в состояние «куда шмогла» и изучен выхлоп journalctl. В котором, по твоему утверждению, при наличии каких-либо проблем с fstab должно быть прямо написано «проблемы с fstab». Так вот, ничего подобного там написано не было, про что тебе и было прямо сказано. В ответ на это ты начал вертеть жопой и даже на прямой вопрос, кто компенсирует потраченное тобой время, не ответил. В итоге ты довертелся до того, что systemd не проводит валидацию fstab в принципе из-за боязни набегания анонимов. Вертишь жопой хорошо, наверное, Поттеринг таких любит.

Враньё, он такого не говорил.

А что он говорил? Ну-ка ссылочку. Вот еще чего в рубриках systemd-треда не было: вращаем покойников в гробах всем лором.

А что он говорил?

Ну это вообще тебе надо это утверждение обосновывать.

Если ты уж про простоту, то юниты намного проще тех баш портянок, которые ты приводил. Если смотреть на «все под капотом», то тебе надо с линукса и вообще с x86 архитектуры валить.

Ну-ка ссылочку.

Вот, кстати, да - подтверди-ка свою брехню ссылкой на источник хоть раз.

Ну это вообще тебе надо это утверждение обосновывать.

ОК, раз даешь мне дорогу так я обосную. Оккам говорил именно это:

самое простое решение – самое верное.

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

Вот ПРИКИНЬ! Дано мне и все тут! Есть у меня суперабилка ПОНИМАТЬ(!w-о_0-w!) что именно и конкретно люди хотят мне сказать, даже когда они говорят предельно обобщенно, потому что говорят не только мне и не только по моей проблеме.

Если тебе не нравится моя рекомпиляция бритвы Оккама, если не смеешь понимать в сути а воспрнимаешь только как буквальную инструкцию, то можешь просто на спичках посчитать количество сущностей в BSD подобной системе и в Systemd. Не забуть посчитать как все файлы задействованные в systemd, – без которых моя Slackware линукс обходится до сих пор – так и все новые понятия, механизмы, зависимости, порожденные systemd. Вывод будет тот же.

то юниты намного проще тех баш портянок, которые ты приводил.

1. Это потому, что юниты есть мелко посеченные конфиги. Они просты

• для машины – которая в состоянии «держать в голове» и обрабатывать массивы мелких файлов крупным оптом.
• для пользователя, который заглянул в них чисто порукоблудить на systemd, и обрабатывать ничего не собирается

2. А «баш портянки» это на самом деле скриптуры, письмена с куда более сложными задачами и возможностями чем конфиги. Если сравнивать простоту, то я ведь выше отмечал, что

простота равна надежности, при всех прочих равных.

прочих равных.

равных.

Снизошло? «Баш портянки» выше - разумеется сложнее юнитов. Но у них функционал разный. Зато те же «баш портянки» на порядок проще благородного двоичного кода systemd, воспетого Siborgium здесь хотя решает те же задачи (если иметь в виду изначально заявленный функционал systemd) не хуже… А даже и лучше решает, если учесть что итерпретируемый язык в «баш портянках» можно править налету, без компиляторов, без чрута. Ремонтопригодность, доступность к обслуживанию, к кастомизации, видишь ли, это тоже достоинство.

– Вот пример истинно нелицемерного, искреннего, непредвзятого сравнения простоты: при учете равных прочих обстоятельств.

В моем случае, о котором я упомянул (встречался в сюзе), понадобилось просто исправить fstab – это от одной ошибки в нем система стала небутабельной – и это без каких-либо объяснений, и без возможности диагностики, ибо journald и вызывал цикличный перезапуск. Но ведь не это важно. Важно то, что этот гребаный черный ящик сходит с ума и роняет систему наглухо от очень простых вещей.

Вопрос на засыпку. Если в rc.S будет очень простой syntax error, что будет со сверх надёжной системой )

Distribution specific поведение. В любом случае в выхлопе init указание на syntax error будет, в ядро кинешь init=/bin/sh и поправишь.

Если в rc.S будет очень простой syntax error, что будет со сверх надёжной системой )

Прилетит вдруг волшебник в голубом вертолете и Исполнение инита чистосердечно выливается в консоль. Очевидно баш при исполнении укажет на место синтаксической ошибки, и остановит обработку. А потом мне придется напрячь извилины – да это больно бывает, когда за годы безмятежного юзания отвыкаеш заглядывать под капот слаквари – и исправить синтаксис…

Однако я знаю, что ошибка в синтаксисе rc.S появится сразу после того, как моя кошка соловьем запоет и врежет сальто. Твое допущение из области фантастики, либо оно – о саботаже. Но для противодействия саботажу существует система защиты прав абсолютного меньшинства – тоесть root’a.

Я согласен что система отладки bash, конечно, незаслуженно заброшена в недопиленном виде. Может потому, что язык достаточно прост, чтобы выявлять ошибки более или менее легко. Может потому что у опытного админа со временем появляется чуйка, заменяющая волшебный дебагер? А неопытный не станет совать хобот на глубину не по квалификации; да ему равно кроме локалочки врядли кто-то что-то доверит, разве что за пивом бегатьи да наблюдать за работой маэстро. В Xonotic.

Но мне bash люто бешенно нравится. Он чисто визуально очень красив и загадочен, особенно при должном приправлении регуляками перла. Пока мамка не купила мне комп и все покатилось мне любое программирование представлялось чем-то таким… – Именно тем, что я увидел, впервые взглянув на bash скриптуру. Да. Отладка говеная, функционал тривиальный… Но красо-ти-ща…. Как с профессиональными красавицами короче. Впрочем, как и с красавицами, – думать не их дело, а оператора, так что…

Подойду к вопросу с другой стороны: знаешь почему военные не любят чрезмерной инициативности подчиненных? – Потому что инициативность это источинк нежданчиков а значит ущерб надежности. Баш очень прост и понятен, кроме шуток; – он только исполняет написанное, что некоторые ораторы выше ставили ему в вину. Но я ставлю ему это в заслугу. Он делает только то, что от него требуется.

Да вопрос не в саботаже, баше и не в отладке. Просто если ломать базовые вещи (такие как fstab), то система поломается. Хз о чем вы тут пол треда общаетесь :)

так и все новые понятия, механизмы, зависимости, порожденные systemd

Никакие понятия новыми не являются. Удовлетворением зависимостей в портянке занимаешься ты сам, и информацию о зависимостях держишь в голове, вместо передачи машине.

хотя решает те же задачи (если иметь в виду изначально заявленный функционал systemd) не хуже…

Я уже обосновал, почему это не так. Никаких опровержений не прозвучало, кроме попыток перейти на личности или съехать с темы.

если учесть что итерпретируемый язык в «баш портянках» можно править налету

Юниты тоже можно править на лету.

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

Ваши «куда более сложные задачи и возможности» не могут обеспечить корректный параллельный запуск нескольких сервисов.

Просто если ломать базовые вещи (такие как fstab), то система поломается

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

А представь: подходит к моему компу «администратор», к которому вечно посылает пользователя винда… Кстати скоро и systemd начнет так же посылать – можешь скринить. Так вот. Подходит сторонний наблюдатель и видит: система в мертвой петле. Затык почему-то в journald, именно на его выходе из-за печки начинается новая загрузка. Какие теперь действия этого «администратора», если journald не работает должным образом, если журналы не посмотреть когда systemd офлайн? Что «администратор» должен думать в таком случае и где искать хвосты? Боюсь при уровне «инициативности» и сложности systemd количество возможных хвостов – как песчинок в Сахаре. И едва ли он добредет до fstab к российской пенсии.

Я слыхал уже выше, между прочим, что придуманы уже какие-то костыли типа emergency shell. Но это костыли, это лишние сущности. Я все к тому, что твое сравнение – совершенно неправомерно. Ты передергиваешь. Простая система означает «предсказуемая» и «понятная», помимо прочего. Тупые ошибки синтаксиса нигде не исключены, допустим. Но в простых системах они отлавливаются легко и просто, – и не составляют вселенской проблемы, и не требуют костылей и мегадебагеров, базирующихся на мейнфреймах. И потом, ты сравниваешь ошибку в конфиге и последующее сумашествие systemd, с ошибкой в исполняемом rc.S, при которой исполнение адекватно остановится с четким указанием на проблему. Ты лукавишь.

Вам не жаль времени на этот текст?

И спроси себя, а не опасно ли пускать в свою машину слишком умные программы слишком мунтных и хитровыделанных разработчиков в этот век, когда в «руках» машины вся твоя жизнь?

Нет, потому что программы не «слишком умные».

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

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

Нет. Но важно то, что systemd истребляет конкуренцию

Дооо, нечестное истребление конкуренции предоставлением качественно лучшего продукта. Если бы победил условный s6, то это, конечно, оказалось бы честной победой.

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

Я уже обосновал, почему это не так.

Тоесть ты считаешь что systemd запускает линукс лучше чем rc.d? Стесняюсь поинтересоваться – а на сколько процентов лучше, м-м-м? В чем разница? У-меня-все-работает™

Если бы реально была какая-то разница, тебе не пришлось бы столь многословно «обосновывать» обратное. Так что разницы нет никакой, кроме как в сложности, а значит в надежности.

И потом, ты отчаянно убегаешь в пургу демагогии от главного – по моему разумению – вопроса: о долгоиграющей перспективе линукса, под управлением systemd. Вектор его развития четко указывает в одном направлении, в котором ты тупо стремишься не смотреть, дыа? Как сертифицированная блондинка, которая бросает руль и включает двойной фейспалм как только что-то на дороге пошло не так? Ты не задаешься ли вопросом

что будет дальше?

Я его уже ставил ранше, подумай над этим, исходя из сути systemd, которая описывается единственным но пока не изреченным ответом на другой вопрос.

как называется программа, которая

Я слыхал уже выше, между прочим, что придуманы уже какие-то костыли типа emergency shell. Но это костыли, это лишние сущности. Я все к тому, что твое сравнение – совершенно неправомерно. Ты передергиваешь. Простая система означает «предсказуемая» и «понятная», помимо прочего.

Мои передергивания - это твои фантазии. Все что я написал - если поломать что-то важное, система сломается )) Я ни слова не написал про предсказуемость и понятность.

Если всунуть в rc.S exit 0, reboot -f или что-нибудь еще, тоже будешь долго вспоминать что делал до этого. Разумеется, нет ни одной логичной причины это делать. Так же нет ни одной разумной причины /вообще/ лезть в fstab в системе с системде. Да, системде не умеет говорить «елки палки, в fstab какая-то наркомания».

если журналы не посмотреть когда systemd офлайн

Для просмотра журналов не нужен работающий системде.

Тоесть ты считаешь что systemd запускает линукс лучше чем rc.d?

Да, потому что концептуально лучше.

У-меня-все-работает™

Работает – славно.

И потом, ты отчаянно убегаешь в пургу демагогии

Ни одного опровержения не услышал от тебя, но демагог – я. Интересно.

вопроса: о долгоиграющей перспективе линукса, под управлением systemd

Долгоиграющую перспективу линукса определяет не система инициализации, а корпорации, пишущие ядро.

Я его уже ставил ранше

Скажите, вы уже прекратили пить коньяк по утрам?

Затык почему-то в journald, именно на его выходе из-за печки начинается новая загрузка. Какие теперь действия этого «администратора», если journald не работает должным образом, если журналы не посмотреть когда systemd офлайн?

В настоящем продакшене все подобные проблемы с любой системой инициализации решаются одним способом – нажатием кнопки «переналить» в управляющей системе. Никто не будет разбираться почему и где что-то сломалось, если проблема носит единичный характер и проявилась на одной из сотни машин, разбираться с таким – очень дорого.

Кстати проблем именно с journald или с каким-либо другим компонентом systemd ни разу не встречал, а машин у нас тысячи. Больше вероятность, что рейд не соберется после перезагрузки.

Вам не жаль времени на этот текст?

Я могу себе позволить такой, вбивая 350 символов в минуту. И потом, для меня это отдых и удовольствие, как для бабушки вечернее вязание. Осваивайте слепую машинопись, и для вас набор текста – осбенно разумного, доброго, вечного – будет тем же.

То, что это отнимает время от работы – пичалька. Но от работы кони дохнут. И потом… Это не просто текст. Это истина. Которая рождается в качественных спорах. По крайней мере наше времяпровождение очень многое иллюстрирует не только о systemd, но и о важности конкуренции, и о сути монополии, и о важности спора в принципе.

нечестное истребление конкуренции предоставлением качественно лучшего продукта

Начнем с начала? ОК начнем. Что именно предоставил systemd, вы хоть помните? Я же говорил про frogboiling выше – не дошло? Еще раз: вспомните что именно «предоставил» Поттенг под лейблом systemd. У вас кажется мозги таки сварились наглухо, с тех пор. Это разве «более качественный init»? Снова вернусь к вопросу, как называется такой тип программ

И еще я задам вопрос: какое пользователю должно быть дело до качества™ трояна, уничтожающего линукс как явление?

В настоящем продакшене все подобные проблемы с любой системой инициализации решаются одним способом – нажатием кнопки «переналить» в управляющей системе. Никто не будет разбираться почему и где что-то сломалось,

Переустановка наше все? Тоесть я опоздал с опасениями что systemd превратит линукс в винду? Это уже случилось, по крайней мере в головах пользователей, верно?

Снизошло? «Баш портянки» выше - разумеется сложнее юнитов. Но у них функционал разный. Зато те же «баш портянки» на порядок проще благородного двоичного кода systemd, воспетого Siborgium здесь хотя решает те же задачи (если иметь в виду изначально заявленный функционал systemd) не хуже… А даже и лучше решает, если учесть что итерпретируемый язык в «баш портянках» можно править налету, без компиляторов, без чрута. Ремонтопригодность, доступность к обслуживанию, к кастомизации, видишь ли, это тоже достоинство.

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

Переустановка наше все?

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

Какое нахер восстановление

Наверняка обычное дело на «уникальных, вручную настроенных» системах.

Это не просто текст. Это истина.

Корона не жмет?

Начнем с начала? ОК начнем. Что именно предоставил systemd

Вы умеете читать? Я уже несколько раз написал про предоставление системе информации о зависимостях, и я не буду повторяться.

трояна, уничтожающего линукс как явление

Линукс = правка инит скрипта на коленке?

Да, системде не умеет говорить «елки палки, в fstab какая-то наркомания»

4.2, умеет. В очередной раз убеждаемся, что эксперты systemd в восхваляемой системе не знают ничего.

Для просмотра журналов не нужен работающий системде

Это если journal их выплюнул в какой-то текстовый формат типа /var/log/messages. Если у него очередной приступ «нишмагловости» - таки тащи хоть какую-то систему с systemd, чтобы прочитать что он там себе в свой криптобинарный формат понаписал.

Это если journal их выплюнул в какой-то текстовый формат типа /var/log/messages. Если у него очередной приступ «нишмагловости» - таки тащи хоть какую-то систему с systemd, чтобы прочитать что он там себе в свой криптобинарный формат понаписал.

Зачем тебе какая-то другая система с системде, если у тебя уже есть поломанная? Или как ты собрался /var/log/messages читать, методом телепатии?

Это если journal их выплюнул в какой-то текстовый формат типа /var/log/messages

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

для меня это отдых и удовольствие

А седалище тогда у тебя почему так горит?

Зачем тебе какая-то другая система с системде, если у тебя уже есть поломанная?

Может быть потому, что эта - поломанная и лежит трупиком?

Или как ты собрался /var/log/messages читать, методом телепатии?

System rescue image, boot, less ….

System rescue image, boot, less ….

System rescue image, [chroot, journalctl|journalctl -D]

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

На предыдущих страницах мы выяснили, что это не unix-way’но. Все логи надо printf’ом шарашить в stdout.

Очевидно баш при исполнении укажет на место синтаксической ошибки, и остановит обработку.

Очевидно, что ты ни одного скрипта сложнее echo «hello world» не писал. И уж тем более ни разу не отлаживал скрипты, раз пишешь такую чухню.

И доставай балалайку, потому что гарантий, что system rescue cd и поломанная система имеет хотя бы одну и ту же разрядность тебе никто не давал.

Все логи надо printf’ом шарашить в stdout.

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

+1. Все традиционные юникс-шеллы - адский трэшак в плане отладки.

Ну, теоретически конечно у тебя может быть x86 бут образ, который передаётся от отца к сыну, а на поломанной тачке amd64. Да, такое возможно )) Придется init=/bin/bash пихать, что поделать )

ты уже второй раз вывалил стену говна, которая вообще не несет никакой смысловой нагрузки. если для тебя 350 символов говна в минуту - это достижение, то… а в принципе мне насрать. продолжай себя утешать тем, что ты умеешь в мозг. но мы то знаем, что это не так.

Вот ведь… «А как дысал»(с)

А дальше их подберёт специально обученная программа

Которой, как опять же было выяснено на предыдущих страницах, нет.

Но вот эта дрочка на плейнтекстовые локальные логи бессмысленна

Ты там эта, присядь чтоли. Открываю тебе страшный секрет: printf - он в этом самом плейнтексте шарашит! Валидольчику прими, ага.

при расследовании инцидента, когда дым уже рассеялся

А при самом инциденте, когда всё в дыму, что делать? В TeamCity (или чем Вы там рукоблудите) строить новый билд? Откатывать к предыдущему? Хорошо системы деплоя и прочую подобную срань писал не Поттеринг, а то все крутые интерпрайзнеги уже давно бы застрелились от бинарных портянок в окне браузера. :))

Которой, как опять же было выяснено на предыдущих страницах, нет.

Есть. Называется systemd-journald. Или systemd-journal-gatewayd. Новость почитай, блин…