Леннарт Поттеринг: «Open Source community is full of assholes»

Про фальсифицируемость слышал, дорогой?

И в чём проблема с фальсифицируемостью теории заговора? Она вполне опровержима, а следовательно, вполне научна.

Это чушь. Но при помощи amixer можно скриптовать.

оставляя при этом, звук в остальных приложениях

Вообще бред.

Если тебе хочется жрать бодягу вместо борща — твое право.

Хорошо вам там в идеальном systemd-мире. У нас в реальности линуксом пользуются не только админы.

Pulseaudio:

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

АЛСА-филы, осилите набросать мне конфиг?

Ах, да, это изврат и не нужный юз-кейс.

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

лал затраллели

У нас в реальности «не только админы» тем более не различают tail от journalctl, и с религией у них проблем нет. И мне им посоветовать набрать journalctl -b гораздо проще, чем объяснить как в простыне /var/log/messages найти лог последней загрузки иксов. И это мы ещё про всё безобразие с grep и awk не начали говорить.

Проблемы в основном у тех, кто как бы не админ, но зато «unix-way». Вот им в наше время трудно, притесняют по всем фронтам.

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

В какой это реальности не-админам надо срочно прочитать лог сломанной системы?

Леннарт молодец!

Любо-дорого смотреть на батхёрт идиотов с вахтёрным синдромом, мечтающим запретить неугодным программистам разрабатывать ПО.

Почему же тогда в OO/LO OpenDocument по умолчанию? Почему не txt?

Вообще-то odf как раз Plain Text, зазипованный правда.

Из того, что я наблюдал основная критика у неотключаемого бинарного лога.

Это — плановая экономика: либо жри дерьмо, либо расстрел.

Это - командно-административная экономика

У бинарного лога только одна критика — его нельзя открыть текстовым редактором. И обычно даётся аргумент «а вот вдруг мне срочно понадобилось открыть лог, а система лежит и у меня кроме текстового редактора ничего нет», что IRL маловозможно и легко устранимо (если ставишь систему с журналом, то и livecd с журналом можешь заранее подготовить). Но вообще есть такая критика, да.

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

Любо-дорого смотреть на батхёрт идиотов с вахтёрным синдромом

Любо-дорого смотреть и на идиотов, которые прутся от чужого баттхерта.

То есть эти люди способны достать лог с упавшей системы, но неспособны открыть его чем-то кроме текстового редактора (читай: не умеют достать rescue-образ с нужным пакетом)? ИМХО, это слишком надуманный пример.

У бинарного лога только одна критика — его нельзя открыть текстовым редактором.

А может стоит посмотреть на ситуацию с другой (нормальной) стороны? СистемД упрощает запуск сервисов, отлично профит ясен, говнокод потерпим. А что такого замечательного делает журналД, что требует использования бинарного лога, в чем профит?

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

Официальная позиция — там есть защита от подделок, его проще парсить (т.е. journalctl должен быстрее работать), возможно он занимает меньше места (но это я уже сам додумал, я не помню чтобы такое заявлялось). Да, это нужно не всем, тут согласен.

его нельзя открыть текстовым редактором

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

Кому-то надуманный, а кто-то на это потратил рабочее время.

Если кто-то не догадался обзаботиться нужным rescue-образом, то кому-то надо учиться пользоваться компьютером. А если он не хочет быть админом, пусть несёт компьютер специалистам.

т.е. journalctl должен быстрее работать

быстрее чего? Почему?

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

Почему следует? Бинарный формат проще парсить софту, чем текст.

Я и говорю, хорошо в вас в идеальном системД-мире, где систему админят только админы.

Бинарный формат проще парсить софту, чем текст.

Нет, не сильно проще и не быстрее.

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

Работать с ним удобнее. Не надо искать в какой лог пишет сервис, не надо грепать его сообщения из этого лога.

Конструкция "хочу увидеть логи ntpd за сегодня с 10 до 11:30 утра" превращается в простую команду

journalctl -el --since=10:00 --until=11:30 -u ntpd

Конструкция «хочу увидеть логи ntpd за сегодня с 10 до 11:30 утра» превращается в простую команду

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

Не надо искать в какой лог пишет сервис

Наверное потому, что все пишут в один лог.

Конструкция «хочу увидеть логи ntpd за сегодня с 10 до 11:30 утра» превращается в простую команду

Чем бинарный лог в этом случае лучше обычного лог-парсера?

А что нужно?

Plain text хватает с головой. Кроме того бинарный файл легче сыпется и хуже восстанавливается

благо минусов использования пуьсы никаких

Нету прямого доступа к звуковушке (например я не хочу чтобы звук откуда-то появился, когда слушаю музыку). Неотключаемый ресемплинг (хорошо, что хотя бы недавно добавили опцию alternative-sample-rate, но оно все равно не подходит, если нужно производить три и больше разных частот).

Чем бинарный лог в этом случае лучше обычного лог-парсера?

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

Ты передёргиваешь. Если человек может загрузиться в упавшую систему и достать оттуда лог, то и journalctl запустить он может. Для этого не нужно быть мегаадмином.

Наличие утилиты для парсинга логов в systemd не отвечает на вопрос почему сам лог-файл должен быть бинарным.

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

Если человек получил доступ к логам упавшей системы, то система из которой он загрузился может не иметь journalctl; В системе в которую он сделал chroot этот самый journalctl может оказаться неработоспособным. Второй вариант, конечно, менее вероятен, чем первый.

journalctl -el --since=10:00 --until=11:30 -u ntpd

На самом деле тут один положительный момент есть. Єто стандартизация бардака. Но это все легко делается в рамках plain text.

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

Легко:
1) поломался сам бинарь
2) сменился формат бинаря и его не прочитать имеющейся утилью.

Для этого придумали помехоустойчивое кодирование.

1) Спецы по восстановлению данных тебя одобряют. Особенно зная качество кода Поттеринга
2) сделать сложно ума много не нужно. Прослойка в виде бинаря - єто как раз сложно.

Но ещё раз повторяю, что для этого нужно время, а у большинства линукс десктопов journalctl'а нет.

у большинства линукс десктопов journalctl'а нет

Как раз благодаря «пропихиванию» у большинства он как раз есть :)

journalctl - это не бинарный лог, это читалка бинарных логов. Я спрашиваю про профит от самого бинарного лога.

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

Но почему все эти люди хотят его убить?

Шаблон рвется. Поттеринг сделал непростительное в фундаменталистской среде - посягнул на священную корову идеологии.

Здесь я имел ввиду то, что в сломанной системе утилита могла помереть. Кстати, как долго они собираются обеспечивать обратную совместимость между версиями своей утилитки?

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

А всё потому что Open Source community is full of assholes.

смерть утили событие намного менее важное и вероятное, чем смерть самого бинаря с логом.

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