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

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

Давай опустимся до конкретики. Какие конкретно фичи из той статьи нужны администраторам, были повсеместно проигнорированы разработчиками приложений, но реализованы путём «унификации юнитов» и «расширенного сбора логов» на стороне системд/жорналд?

Мне кажется вы недооцениваете объем работы, который тянет Red Hat в Open Source-сообществе, и той степени, в которой Linux зависит от этой работы.

Vendor lock-in которого тут все боятся не произойдет с приходом systemd. Он в каком-то смысле произошел задолго до того как Леннарт закоммитил свой первый патч в systemd.

И остальные дистрибутивы просто боятся остаться в стороне и наедине со своими проблемами.

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

Почитал:

- Давайте поставим Xfce как DE по умолчанию.
- Нет. Это повредит имиджу проекта GNOME. Давайте лучше у нас вообще не будет дефолтного DE, а будет предлагаться список DE на выбор.
- Но все DE не влезут на один CD. Мы и так GNOME туда еле запихали.
- Давайте откажемся от CD-образов.

Куча перлов:

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

- Разработчики GNOME всё правильно делают, а вы как дети малые - пусть systemd ставится для удовлетворения зависимостей, но не используется как система инициализации.
- У нас и так полно бесполезных пакетов притянутых по зависимостям. Те же udisks и PolicyKit.
- Какая срань тащит с собой udisks и PolicyKit?
- GNOME
- А... Ну тогда тем более не вижу проблем чтобы тянуть ещё и systemd.

Я не предъявил ни одной претензии к RH по поводу решений, принятых в других дистрибутивах.

А мог бы? Коррупционные расследования тоже интересно было бы пообсуждать же.

Я только сказал, что не понимаю (не вижу) причин, побудивших разработчиков других дистрибутивов следовать RH-way.

Странно. А они видят. Или это заговор?

Попробуй сейчас заставь кого работать в xterm с sh.

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

Очень даже оцениваю. И прекрасно понимаю мотивы RH в продвижении systemd (ибо энтерпрайз и вообще). Но в какой-то момент этот объём работы, завязывающий ядро и userspace-приложение (а ведь systemd это приложение), превратит ядро Linux в нечто, неотделимое от своей userspace-обёртки.

На сегодняшний день Fedora, Arch, OpenSUSE это уже не unixway в его классическом понимании, а что-то типа Microsoft Windows Server.

Дистрибутивы, в том числе embedded, типа openwrt, не использующие systemd, дают некую гарантию того, что ядро и userspace разделимы сегодня и будут разделимы в будущем.

И да, поэтому каждый должен иметь возможность сделать собственный инит. Иначе Linux превратится в нечто типа AIX или Solaris и вымрет.

А что? Debian и Ubuntu — родственные проекты.

не совсем - идеология другая. для вторых прерогатива бабло и маркетинг, для первых - СПО.

Как раз по результатам станет видно не окончательно ли дебиан превратился в тестировочную площадку и придаток для какониклов.

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

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

Плохой вывод, имхо. Точнее слишком абстрактный. Кто и как должен обеспечить это «должен»? С помощью каких ресурсов?

На сегодняшний день Fedora, Arch, OpenSUSE это уже не unixway в его классическом понимании, а что-то типа Microsoft Windows Server.

Кстати сказать Fedora только недавно наоборот решили разобрать на части: https://fedoraproject.org/wiki/Fedora.next/boardproposal

Пока не очень понятно как это будет выглядеть правда, но сформировали группы Fedora Workstation, Fedora Cloud и Fedora Server, которые будут пытаться каждая выстроить дистрибутив в своем направлении, при этом опираясь на единое ядро (то, которое core, а не kernel).

Даже мне теперь понятно, за что его недолюбливают.

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

Замечательно, какой молодец. — пусть возьмёт пирожок с полки. А начинка с сюрпризом, да.

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

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

Ядро. Вернее, разработчики ядра. Возможностями его (ядра) применения в различных usecase'ах с использованием различных userland (в терминах *BSD).

Собственно, сейчас пока это так и есть. Конец эпохи наступит, когда от init потребуют обязательной поддержки cgroups или ещё чего-нибудь.

Странно. А они видят. Или это заговор?

Скорее, недостаток ресурсов.

Ну хотя бы подпись логов

В том виде, в каком она есть в жорналд, я так понимаю, она практически бесполезна:
В Journald добавлена поддержка криптографической защиты журналов (комментарий)
В Journald добавлена поддержка криптографической защиты журналов (комментарий)

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

невозможность подмены лога приложения другим процессом.

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

не совсем - идеология другая. для вторых прерогатива бабло и маркетинг, для первых - СПО.

Интересное мнение.

Как раз по результатам станет видно не окончательно ли дебиан превратился в тестировочную площадку и придаток для какониклов.

Опенсорсным проектам таки очень удобен коммерческий флагман. И желательно, чтобы при этом не было монополии, то есть существовало несколько конкурирующих друг с другом коммерческих флагманов (скажем, каноникал vs красношляпые).

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

В Journald добавлена поддержка криптографической защиты журналов (комментарий)
В Journald добавлена поддержка криптографической защиты журналов (комментарий)

Хотя... эту проблему несложно решить.

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

Инит уже 30 лет ничего не ломает. В ядре р рамках одной мажорной версии совместимость не ломается (примем 3ю ветку за 2.6).

Это: а) потенциальная деградация производительности; б) увеличение риска потери логов из-за ошибки в ПО; в) просто бессмысленная хрень, которая не делает ровным счетом ничего полезного.

А тем временем GNOME 3.10 оказывается спокойно работает на OpenBSD без всяких systemd
https://www.bsdfrog.org/tmp/gnome310.webm

без изобретения доселе невиданных утилит

А этот аргумент меня всегда поражает, что про systemd, что про журнал. «Неизвестные утилиты» — это же прямо непреодолимое препятствие на пути прогресса.

Для «простого юзера» чтение мана journalctl занимает пять минут времени. После чего ты узнаешь, что кроме прямых аналогов

cat /var/log/messages -> journalctl

tail -f /var/log/messages -> journalctl -f

tail -n 100 /var/log/messages -> journalctl -n 100

grep foo /var/log/messages -> journalctl | grep foo

Одного только этого достаточно, чтобы навсегда забыть о костылях в виде однострочников с cat, grep, awk и cut и сказать, наконец, спасибо за наше счастливое детство.

Смысл первого варианта в том, что второй не всегда возможен. Например приложение срет в stderr, но не в syslog. Или срет в syslog не все.

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

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

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

Спорное утверждение. У меня хоть и парк серверов меньше твоего, но проблем не имел (пока что).

За бинарные логи надо бить сильно и увесисто.

journald не мешает работе syslog.

journald не мешает работе syslog.

Тогда зачем он?

«Неизвестные утилиты» — это же прямо непреодолимое препятствие на пути прогресса.

Это ненужная энтропия.

Одного только этого достаточно, чтобы навсегда забыть о костылях в виде однострочников с cat, grep, awk и cut и сказать, наконец, спасибо за наше счастливое детство.

Так толсто, что даже не могу сформулировать ответ.

Оставаться на месте.

...коммерческий флагман... ...не было монополии...

Так не бывает. Владелец коммерческого продукта будет всегда стремиться к доминированию.

Мне кажется вы недооцениваете объем работы, который тянет Red Hat в Open Source-сообществе

Это в рамках интереса этой коммерческой конторы (и соответственно и её коммерческих интересов насчёт Linux). Только вот пусть уж она останется при своём, и не пытается пристегнуть наручнями сообщество.

в которой Linux зависит от этой работы.

Вся зависимость в Red Hat и заканчивается. Ядро Linux — продукт сообщества, коим он и останется. Гарантом выступит лицензия.

Но наивные представления о том, что Линукс - это выбор, где каждый может сделать собственный init, надо бы подредактировать.

GPL, 4 «свободы» наивны? (зря я удалил свой комментарий) Раскройте свою мысль по этим пунктам:

Vendor lock-in…
Он в каком-то смысле произошел задолго до того
Но наивные представления о том, что Линукс - это выбор, где каждый может сделать собственный init, надо бы подредактировать.

Забавно.

и не пытается пристегнуть наручнями сообщество.

Офферить функционал == пытаться пристегнуть наручнями сообщество? Интересно.

Постом выше.

А они видят.

А что ты думаешь насчёт того, что сказал предыдущий комментатор?

Кавычек там не хватает, то правда.

Не нужно форсировать, в таком виде в котором вы об этом говорите — все варианты плохи.

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

Для этого сообщество должно научиться функционировать не опираясь на RH. А оно этого сделать не может. Это и есть vendor-lock-in по большому счету.

Ядро Linux — продукт сообщества, коим он и останется. Гарантом выступит лицензия.

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

GPL, 4 «свободы» наивны?

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

Для этого сообщество должно научиться функционировать не опираясь на RH. А оно этого сделать не может.

Ох, даже так.

Просто скопировав код из репозитория ты этого не получишь.

Получат рабочий код. +Единомышленники, и voila!.

Но к коду должна прилагаться инфраструктура, разработка и поддержка.

У Debian нашлась, у Arch нашлась, у Gentoo…

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

Нет, они будут работать с другой стороны: есть замечательная возможность ФОРКа (это может быть крайним случаем), и если некий проект не может/не хочет/*множество причин* предоставить возможность «нечто», то рождается новый проект. Как-то так.

Получат рабочий код. +Единомышленники, и voila!.

А единомышленники с потолка берутся?

У Debian нашлась, у Arch нашлась, у Gentoo...

Если бы она нашлась, не было бы столько стонов на тему как RH «принуждает» других использовать его решение. В Arch и Gentoo не нашлась. Debian ещё не решил, конечно, увидим.

они будут работать с другой стороны: есть замечательная возможность ФОРКа (это может быть крайним случаем), и если некий проект не может/не хочет/*множество причин* предоставить возможность «нечто», то рождается новый проект

абстрактные они? самозарождается? Ну да, я тоже стараюсь в это верить.

абстрактные они?

Имелись в ввиду 4 «свободы». (4 «свободы» (они) будут работать с другой стороны…)

А единомышленники с потолка берутся?

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

самозарождается

Может быть. (У APT'а например несколько оболочек)

Имелись в ввиду 4 «свободы». (4 «свободы» (они) будут работать с другой стороны…)

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

Именно поэтому я (морально :) ) поддерживаю разработку openrc, но комментарии типа «я не вникал, но костыли и потому ненужно» не люблю.

Задала вопрос в G+ про то, меняются ли Data Object при добавлении.

Один толковый человек отписал:

«there are three areas that are non-append. One is the file header, the other is data hash table and field hash table which are always exactly one per journal file.

When payloads are being added, in the header the object counter value is increased. Also, when the data objects are appended, they are appended intact, and an entry is being written to the hash table. Please note that the hash table is pre-allocated and its areas are being written over, no shifting performed (also because all offsets are absolute from the beginning of the file, it would be a royal PITA to recalculate them all). »

Так что Data Objects действительно неизменные.

OpenRC

Так что Data Objects действительно неизменные.

Серьезно? А что тогда делается в else-ветке journal_file_link_data()? http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journal-file.c

journal_file_move_to_object() запишет в «o» указатель на серединку Data Object, и затем будет произведена его модификация. Примерно то же написано в комментарии.

Кстати, качество кода в journal-file.c оцениваю как «удовлетворительно-паршивое». Где-то 6 баллов из 10, если за 1 принять девственный школий холлуворлд.

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

В ответ на мое указание на неспособность леннарта к коммуникации, ты сказала, что " «редхатовский менеджмент» собрал всех главных действующих лиц этой драмы в одной комнате". Специалистов по системным логгерам собрали, да. А специалистов по бинарным индексированным хранилищам не собирали. Видимо потому, что те безо всяких истерик и драм молча положили болт на очередной леннартов высер. Так вот: соберите. Наверное, Теодор Тсо был бы идеальным ревьювером (ФС — это ведь иерархическая СУБД), но мне страшно представить, сколько денег он захочет за свои услуги, если вообще согласится тратить своё время на это говно. Я слышал, что разрабы postgresql подрабатывают консалтингом, примерно 3 килобакса/день. Ну или у Шишкина узнайте, кого он порекомендует в ревьюверы (если сам не возьмется смотреть). Эта возня устранит очередной симптом хронической болезни, но и только.

Avahi как 5 лет назад в дебиане отжирал 100% cpu (лень билетик гуглить), так и по сей день отжирает: https://bugzilla.redhat.com/show_bug.cgi?id=952193 . А сколько было у всех проблем с пульсаудио? Допускать такого разработчика до «системообразующего демона» — это просто верх безответственности (и безумства).

да, смешно было надеяться..

s/journal_file_move_to_object() запишет в «o» указатель на серединку Data Object/journal_file_move_to_object() запишет в «o» указатель на Data Object в середине файла/

да, смешно было надеяться..

А я всё еще надеюсь на RH. Не зная, что там творится под капотом, со стороны создаётся впечатление, что всё держалось на Ульрихе: он ушел, и говно хлынуло через край. Но я надеюсь, что еще не поздно, для всех нас...