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

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

Да, но с ними бывают такие истории.

http://www.gentoo.ru/node/29758#comment-221502

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

Да, это реализация, но в современных условиях всеобщей контейнеризации, облаков и автоматизации, - это именно то, что нужно! Сейчас важна прежде всего предсказуемость и управляемость. Если что-то пойдёт не так, то проще и быстрее автоматически убить и пересоздать модуль/контейнер/узел, чем разбираться, что там случилось…

В детстве мы своими руками собирали детекторные приёмники, а потом ламповые и транзисторные из отдельных деталей, но кто это делает сейчас?! В лучшем случае - взять и спаять несколько микросхем, и любое (радио)электронное устройство готово. Также и с автомобилями - практически невозможно отремонтировать современный автомобиль в домашних условиях, а во времена СССР это было практически нормой…

Также и в современном ИТ мире… К примеру, наша компания более 20 лет использовала Генту везде и всюду… поначалу с SystemV-подобной инициализацией и chroot подсистемами, но с появлением systemd-контейнеров мы перешли на systemd, потому что появилась возможность строить инфраструктуру более гибкой и экономичной - у нас было 4 датацентра, а стало 3, но сложность, производительность и количество сервисов значительно увеличилось на том же железе!

С прошлого года после поглощения нашей компании более крупным игроком на рынке началась миграция в облака… сейчас виртуальные КВМ-хосты для контейнеров уже не на Генту, поскольку их технологически сложно создавать и поддерживать, но сами контейнеры все еще на systemd/Gentoo, поскольку systemd/Gentoo лучше конфигурируется и управляется, а потому внутренняя инфраструктура нашего продукта (SaaS) сильно на неё завязана. Но уже очевидно, что Генту в контейнерах тоже умрёт, потому как в корпоративном мире Генту не живёт из-за сложности поддержки и более высоких требований к квалификации администраторов. Но сам предмет разговора - systemd прекрасно вписывается в корпоративную инфраструктуру!

Поэтому, на мой взгляд, SystemV-подобная инициализация имеет место быть на десктопах энтузиастов-фанатиков (у меня Генту везде: и на десктопах, и на ноутбуке, и даже на нетбуке!), а также какое-то время на встроенных устройствах типа смартфонов, домашних маршрутизаторов и прочих штуках, где важно хоть сколь-нибудь сэкономить память, но в целом она уже обречена, к сожалению. Также как и Генту, пожалуй… у них нет места в будущем динамичном мире, когда никто не может себе позволить долго возиться с индивидуальной настройкой чего бы то ни было… разве что для хобби…

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

Хорошо. Но ты признаешь, что бинарные логи могут быть проблемой?

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

Не понял, как последующий пример должен как-то оправдывать поляризацию.

ты по работе админишь системы?

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

сустемдэ - гентукапец. ну как бы вот. наслаждайтесь.

Никому не капец. Вам лишь бы похоронить.

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

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

но куда делся датацентр я так и не понял. путин отжал?

Короче говоря, systemd-networkd, systemd-homed, systemd-repart, systemd-jornald — являются опциональными компонентами и не обязательны для работы systemd?

Но мне не удалось найти упоминания невозможности загрузки OpenRC или sysVinit из-за покореженных логов.

Итого. Допустим, systemd таки модульный. Если так, я признаю, что он не переусложнен. Ладно. Но я все равно не понимаю прелести бинарных логов. Это дает возможность быстро искать. Согласен. Но система ведения логов в systemd более уязвима, чем в других инитах. Опять же, я не нашел упоминаний отказов OpenRC из-за битых логов. И завязанность systemd на линукс — это не есть хорошо.

Короче говоря, systemd-networkd, systemd-homed, systemd-repart <…> — являются опциональными компонентами и не обязательны для работы systemd?

Вполне.

systemd-jornald

Journald — условно обязателен. Технически без него всё работает, но если вдруг нет — то багрепорт твой никто рассматривать всерьёз не будет. (Но никто не мешает тебе отключить запись собственно логов.)

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

Хорошо. Нелюбимая тобой «педивикия» пишет, что базовые компоненты — это сам systemd, systemd-analyze и systemctl. В таком случае я беру назад утверждение о немодульности и переусложненности systemd. Договорились.

Здесь у чувака возникли проблемы с выходом из сна.

Rebooted, fired journalctl and I have nothing except the last boot logs.

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

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

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

А в какой документации написано, что имя пользователя не может начинаться с числа?

Э-э-э, в той на которую Поттеринг ссылается? проверяет Он никуда не ссылается. Вопрос закрыт.

Ну вот и ладненько.

Если что, стандарт POSIX:

User name: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_437

Portable character set: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282

Т.е. 0day является валидным именем пользователя.

Хотя systemd, конечно, не обязано следовать POSIX; но в любом случае, garbage на входе должен быть ошибкой, а не тихим запуском из-под рута: даже если игнорировать вопросы, связанные с безопасностью, fail-fast никто не отменял.

Не все возможные, а все существующие. Аргументов не так уж много. Больше половины уже в этом треде повторили. Меня устроит ссылка на тред где опровергнуты как можно больше из них.

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

Нет. Он загрузился и понял, что старые логи исчезли. Либо у него вместо файла нули (тут никто не поможет), либо это баг в journalctl (старые логи должны читаться, если они физически как-то существуют). Судя по тому, что тред 6-летней давности — вполне может быть, что и баг.

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

Бесспорно. Но если уж какая-то другая программа (не важна какая, системд это или нет), имеет дело критичными данными (а имя пользователя таковым и является), то оно просто должно иметь проверку на правильность. Иначе это даже не ошибка, это дыра, размером с слоновью задницу :) И выше, кстати есть ссылки, что является нормальным именем, что нет. Впрочем, если с точки зрения какого либо софта, оно такое - не переваривает, оно тем более должно об этом явно предупреждать. Т.е. - обрабатывать, в любом случае.

убрана поддержка недокументированных вариантов syslog и syslog-console

Интересно, сколько демонов в результате отвалится?

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

useradd?

Или сразу в ядре?

AIX прекрасно живет без systemd. Это к вопросу о том, что без systemd ну никак невозможно было и вообще отсталость и беспросветность.

При этом в AIX есть волшебный smitty, который действительно улучшает и без него таки да, тлен и беспросветность. Лучше б в линуксе аналог smitty запилили.

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

Пульса не вызывает такой реакции, потому что там меньше наркомании.

Сколько лет назад Поттеринг перестал над ней работать? Сколько лет назад отключили багофичу, делающую максимальную громкость?

 Баш это полноценный ЯП, на нем можно что угодно реализовать

Да? Прям таки Тьюринг-полный?

Да, полный, вроде.

налил там кучу отсебятины,

Являются ли ограничения аддитивными?

bash однозначно полон по Тьюрингу. На нем можно писать примитивно-рекурсивные ф-ции, этого достаточно.

И в контейнерах всё равно не используется система инициализации вообще.

Что не мешает пихать её в контейнеры.

А Линус разбирается в том монстре, которого породил?

Присылаемые патчи понимает. Что как работает — объясняет.

А Столлман разбирается в том монстре, которого породил (я про emacs или gcc)?

Пока мэйнтэйнил — разбирался. Потому и ушёл.

А Тео разбирается в том монстре, которого породил (я про опёнка, включая весь юзерспейс)?

Именно потому что не осиливает всё, препятствует включению некоторых программ.

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

Судя по ссылкам в https://blog.darknedgy.net/technology/2020/05/02/0/index.html — именно «чуток». Много забывает и путает. Тем не менее, он в нём разбирается лучше всех, и может сообщить много интересного, чего нет в мануалах.

уже без всякого юмора начинаешь задумываться о том, что windows server уже и не такая монстродавная, а стройная и приятная штука, вместе со своим AD

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

Напишу тогда уж одну из моих текущих жалоб на systemd: невозможность указывать зависимости из других сплайсов. Конкретно мне хочется в user units делать After/Before/Requisite/PartOf для системных юнитов (по понятным причинам, Wants/Requires/BindsTo сделать не получится). А то надоело в ExecStartPre делать systemctl status ...; while ! systemctl is-active ...; do sleep 1; done

Каюсь, невнимательно прочел :) Но у меня есть еще претензия. systemd не кроссплатформенный. В него не заложена возможность портирования. Для опенсорса это не есть хорошо.

И вопрос с 0day остается открытым.

А что за вопрос?

Выше была дискуссия про имя пользователя 0day. systemd некорректно его обрабатывает и демону даются права суперпользователя. Это может быть опасно. Было возражение, что POSIX не предусматривает подобные имена. Но должна быть защита от дурака. А ты привел ссылку, что 0day допустимое имя пользователя.

А, понятно. Ну для меня вопрос закрыт (уже давно): Поттеринг неправ, systemd говно. От этого я не перестану им пользоваться, потому что портянки отлаживать видал я в гробу, там всё ещё хуже.

Но я все равно не понимаю прелести бинарных логов.

Как минимум, journald сохраняет намного больше информации, нежели стандартный syslog. Если все эти данные хранить в обычном текстовом виде, то логи будет невозможно нормально читать. journalctl по умолчанию отображает лишь часть доступной информации à la syslog, а остальную - по запросу.

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

Так их и сейчас без journalctl читать не очень. Нужно вытаскивать текст из файлов с помощью strings или ещё каких костылей. Так что так себе аргумент.

Мне кажется, кроме скорости индексации и уменьшения объема никаких аргументов нет.

Я тоже считаю, что Поттеринг неправ. Это банальная защита от дурака. И к тому же, если мы свято веруем в позикс, то нужно немедленно переписать весь системд в строгом соответствии с ним (и обеспечить портируемость). А если POSIX допускает подобные имена, то реакция Лени выглядит просто неадекватной.

Быстрый поиск (индексация) по произвольным полям.

И при чём тут текстовый формат? Индекс всегда отдельно от хранилища. Так же как и индексация по времени. Проблема логов – не проблема инита. Проблема индексации, не проблема /var/log/%filename%.log.

Собственно претензии как раз из-за такого вот подхода – всё в кучу. Принципы unix преданы. И так далее.

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