The Journal: жизнь после syslog

> поттеринг — это разновидность троллинга? :)

да :-)

>сомневаюсь, кде декларировало движение в противоположную сторону — к модульности

Бинарный реестр модульности никак не мешает.

> какой шлак, боже. 12 лет перевода материалов на говно, «оптимизации потребления», а понтов как у пускателя спутников.

что-то я не припомню тебя во флеймах на тему скалы

а был бы — понимал, что у r спутники бы не терялись, в отличие от фобос-грунта

> Бинарный реестр модульности никак не мешает

опять сомневаюсь

короче давай ссылку на то, что тебя пугает, почитаю

>Reference implementation будет systemd.

Придётся тогда мутировать в красноглазого шлаковарщика, ну или вообще сместить фокус на *BSD. Хоть это и тухляк, но вполне рабочий вариант.

Да они и так не теряются потому что ему не до спутников, он 20 гб плэйнтекстовых логов пытается просмотреть, занимаясь параллельно «оптимизацией потребления». Прогаживая жизнь за таким бесполезным дерьмом, до запуска спутников и за 100 лет не дорастешь. Так и будешь баннеры на сиськи в журнал максим вешать до седин.

>опять сомневаюсь

Сомневаешься в чём?

короче давай ссылку на то, что тебя пугает, почитаю

http://lists.qt-project.org/pipermail/development/2011-November/000160.html

Пора валить на *BSD... Я б свалил, только CUDA там вроде нет, по крайней мере из коробки (или из пакета). Если есть - то я плохо искал и готов к переходу.

>> Reference implementation будет systemd.

Придётся тогда мутировать в красноглазого шлаковарщика

А смысл? Какие всё же претензии к systemd, после того, как его отладят?

>а ты сомневаешься?

Я невысокого мнения о RedHat, но не думаю, что там настолько дураки сидят.

> Да они и так не теряются потому что ему не до спутников, он 20 гб плэйнтекстовых логов пытается просмотреть, занимаясь параллельно «оптимизацией потребления». Прогаживая жизнь за таким бесполезным дерьмом, до запуска спутников и за 100 лет не дорастешь.

уж не один ли ты из тех, кто эпично обосрался с фобосом?

> http://lists.qt-project.org/pipermail/development/2011-November/000160.html

судя по тому, как они подробно это обсуждают (в т.ч. Needs translators to and from plaintext so the Unix text tools and editors can be used), нет смысла беспокоится, кмк

>А смысл? Какие всё же претензии к systemd, после того, как его отладят?

Зависимость от dbus, bloatware и, естественно, кривой подход с асинхронным режимом. Ну и куча неудобных мелочей, вроде каши при загрузке и неадекватности Поттера.

> А смысл? Какие всё же претензии к systemd, после того, как его отладят?

я честно говоря не верю, что его вообще отладят — будет как пульсаудио

вместо того, чтобы сделать отлаженно работающую систему с разумным набором фич, поттеринг полез в какие-то дебри

> Зависимость от dbus

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

>судя по тому, как они подробно это обсуждают (в т.ч. Needs translators to and from plaintext so the Unix text tools and editors can be used), нет смысла беспокоится, кмк

По поводу запила dconf? Конечно нет смысла. Ибо практически факт.

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

Не понимаю всё же, чего вы так раскудахтались-то? Ну будете вместо less использовать какой-нибудь seelog FILE | less, а вместо tail -f FILE - seelog -f FILE или даже seelog FILE | tail -f. Зато вместо текстовых timestamp'ов будут бинарные значения, по которым можно применять нормальные операции сравнения даты, такие логи можно элементарно разобрать хоть на C, хоть на ассемблере даже. Опять же, ну не пишет сейчас в syslog даже Apache, абсолютное большинство софта гадят мимо сислога, так чего тем паче переживать-то?
Насчёт Pulse Audio согласен, что это Г., но назвать его основной подсистемой Linux язык не поворачивается, а, например, в YAST'е отключается запросто одной галочкой в настройках звука (что, впрочем, не умаляет общего идиотизма данного модуля Яста).

> я честно говоря не верю, что его вообще отладят — будет как пульсаудио

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

Зависимость от dbus

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

Расколько я понимаю, systemd просто умеет запускать по требованию службы, использующие D-Bus. Ничего позорного в этом я лично не вижу.

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

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

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

> Расколько я понимаю, systemd просто умеет запускать по требованию службы, использующие D-Bus. Ничего позорного в этом я лично не вижу.

если так, то да

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

зато он (возможно) зависит от всяких новых фич ядра, типа усыновления сиротских процессов юзера не инит-ом, а предназначенным для этого процессом юзера

хотя, впрочем, шансы на отладку есть

Вы об этом?

>seelog FILE | less, а вместо tail -f FILE - seelog -f FILE

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

Зато вместо текстовых timestamp'ов будут бинарные значения, по которым можно применять нормальные операции сравнения даты, такие логи можно элементарно разобрать хоть на C, хоть на ассемблере даже.

А ты что, лично готов кодить мне смотрелки на каждый чих?

>bzcat /var/log/messages.0.bz2 | less

Гениально! Хотя бы один умный человек нашёлся, который это сказал!!!
90% логов хранятся в прокрученном и сжатом виде. Не просто бинарном, который могла бы прочитать любая программа на BASIC'е, а в формате архива, который изначально представляет собой хаотическое нагромождение байт, а открывается довольно сложным алгоритмом.
Почему же десятилетиями никто не кричал «караул, проклятый logrotate превращает мои любимые текстовые логи в мусор!» ?

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

Отсутствием диктатуры? Не смеши. Попоболь вызывает как раз наличие диктатуры в виде навязывания поделок и идей одного не совсем адекватного человека. Формально признаки диктатуры на лицо.

>В отличие от пульсы, он не зависит от железа, так что с отладкой гораздо проще.

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

>А если я хочу посмотреть это в другой программе, операционной системе?

seelog FILE | dos2unix > OS4DUMMY.txt
Не канает?

Или просто seelog FILE > FILE.log, если речь не идёт о «другой» операционной системе. Ты же как-пользуешься командами типа last, iptables -nvL, да вон даже man'ом.

Кстати, да, предлагаю обос.ать тех долюанных уродов которые написали man! Эту их документацию ни в одном текстовом редакторе с подсветкой синтаксиса не прочитаешь. А что, это было бы более справедливо, нежели в случае с логами: ведь документацию действительно всю человек должен читать, а вот из генерируемых ежедневно логов на пару-другую сотен мегабайт - человек прочитает от силы 1Кб (если конечно человек занимается ещё чем-то полезным, а не тупо в логи пялится весь день).

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

Ты вообще читал этот топик?

Да.

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

черт, об этом я не подумал

срочно ставлю обратно на то, что поттеринг сможет отладить системд

> Ты вообще читал этот топик?

а ты? тут есть мессага «альса работает, пульс с ней не работает»

> зато он (возможно) зависит от всяких новых фич ядра

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

типа усыновления сиротских процессов юзера не инит-ом, а предназначенным для этого процессом юзера

Это control groups, не такая уж новая фишка.

>> Ты вообще читал этот топик?

а ты?

Да.

Ну, судя по той же дискуссии - systemd как умолчанию там не светит. Покуда кое-кто не почешется о переносимости кода на не linux.

> Ну, судя по той же дискуссии - systemd как умолчанию там не светит

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

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

Это control groups, не такая уж новая фишка.

а ты не ошибаешься случаем?

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

Это control groups, не такая уж новая фишка.

а ты не ошибаешься случаем?

http://0pointer.de/blog/projects/systemd.html

'Well, since quite a while the kernel knows Control Groups (aka " cgroups"). [...] cgroups are very useful to keep track of daemons: cgroup membership is securely inherited by child processes, they cannot escape. There's a notification system available so that a supervisor process can be notified when a cgroup runs empty. You can find the cgroups of a process by reading /proc/$PID/cgroup. cgroups hence make a very good choice to keep track of processes for babysitting purposes.'

Я тоже читал «крайне выборочно». Но идея в том, что никто ради этой поделки kFreeBSD и Hurd из Debian не выкинет.

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

1) развлекаться с этим самостоятельно

2) поддерживать кучу разных init

3) выкинуть все не-линукс

это увы не диктатура а маркетинг демократия.

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

Это control groups, не такая уж новая фишка.

я про это http://lkml.org/lkml/2011/7/28/426

а как, по-твоему, сделать то, что я тут написал в ядре допустим 2.6.26 ?

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

На самом деле, декомпрессор можно написать на коленке, а библиотеки для потокового считывания есть уже сто лет и отполированы до блеска. Кроме того, логи только _хранятся_ в сжатом виде. Рантайм логи на ближайшие сутки или текущий сеанс - это непожатые текстовые данные, которые можно читать и писать без спецсредств. Сжатые логи нужны только для истории.

> There's a notification system available so that a supervisor process can be notified when a cgroup runs empty.

это нотификация, но усыновляет их все-таки инит, так?

> http://0pointer.de/blog/projects/systemd.html

там дата Fri, 30 Apr 2010, а я говорю про http://lkml.org/lkml/2011/7/28/426 — почему-то он вместо юзания cgroups решил патчить ядро

>> There's a notification system available so that a supervisor process can be notified when a cgroup runs empty.

это нотификация, но усыновляет их все-таки инит, так?

Не помню деталей. А какая разнца? systemd и есть init.

я говорю про http://lkml.org/lkml/2011/7/28/426 — почему-то он вместо юзания cgroups решил патчить ядро

Никаких «вместо». И systemd с PID == 1 получит SIGCLD даже без этого патча.

> Но идея в том, что никто ради этой поделки kFreeBSD и Hurd из Debian не выкинет.

Но и задерживать развитие Debian/Linux из-за них не будут.

(с) автор поста на перевод, (с) сайта откуда автор поста взял оригинал, (с) автора текста сохранены йопт

Многие из этих проблем в последнее время стали зримыми. К примеру, недавнее, горячо обсуждаемое вторжение в kernel.org из за запутанных манипуляций с файлами журнала было обнаружено благодаря случайности. К тому же, из за ограничений syslog, на текущий момент пользователи часто вынуждены доверять закрытому ПО выделять важное из собираемых логов и обеспечивать доступ к этим данным более эффективно.

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

Поделка поттеринга абсолютно никак не решит эту проблему. Можно будет не только удалить конец лога - его потом и подделать ничто не мешает.

Фиговый листик. Архивируйте логи на другой сервер - и спите спокойно. Это умеет даже убогий syslog (не без недостатков), не говоря уже о rsyslog, syslog-ng и проч.

Если портирование реально - вариант 1) вполне возможен. Но подозреваю (беглый взгяд на код), что патч будет ОГРОМЕН.

Вариант 2) точно мимо - никто параллельной поддержкой разных инитов для разных портов заниматься явно не намерян.

Upd: http://lists.debian.org/debian-devel/2011/07/msg00326.html

-->8--
c) the big problem for them about portability is not so much that i won't
accept the patches. it's primarily that porting it to non-linux is
practically impossible. about every line of it is non-portable code

i.e. we already use epoll as a main loop, already there you'll have a
hard time porting this to something else
-->8--

Вот и я углядел сразу epoll понатыканный и засумлевался.