>[оверквотинг удален]
>> Ещё раз:
>>>> А вообще, у меня есть тонна минималистичных контейнеров, где каждый дополнительный процесс
>>>> — это неприятно.
>> У меня есть множество аргументов, начиная о жёстких проблем с диском и
>> ОЗУ (что у нас действительно наблюдается в жёсткой форме), заканчивая безопасностью,
>> но из ваших ответов другим комментаторам я понимаю, что вы просто
>> игнорируете такие аргументы. Поэтому может хотя бы такой аргумент подействует: чистые
>> контейнеры запускаются и переносятся в разы быстрее, чем грязные (замусоренные всякими
>> dbus и прочим шлаком). Для понимания, момент переноса может быть связан
>> со временем downtime-а, поэтому там каждые полсекунды решают.Вы опять игнорируете что я написал.
> Вообще это большие проблемы, если перенос контейнера связан с даунтаймом.
Ну да, проблемы. И? Содержимое большинства контейнеров определяется другими подразделениями, у которых совершенно нет времени думать о FT.
> Я не
> игнорирую такие "аргументы", а прошу написать конкретные ситуации, потому что эти
> "аргументы" можно использовать вообще для всего :)
Про безопасность вы аргумент другого собеседника не признали, хотя аргумент весьма валиден.
Вы просто забываете, что если идти по пути, который предлагаете вы, то это приведёт к очень большому количеству мусора и кроме dbus (так как вы отвергаете правила, которые служили нам много лет, см. ниже). Сам по себе dbus обычно почти не мешает (хотя бывает и мешает), но если этого мусора набрать много, то, например, появляются следующие проблемы:
1. Низкая предсказуемость (больше всякого необходимо учитывать). Например, dbus мог не стартовать из-за какой-нибудь selinux. Каждое лишнее звено -- это дополнительная точка для отказа.
2. Ниже производительность. Чем больше процессов, тем больше жрётся ОЗУ, больше времени тратится на запуск всех этих процессов и т.п.
3. Больше дыр безопасности.
4. Ниже управляемость. Каждый дополнительный пакет может строить какие-то свои зависимости, и в результате может стать сложнее сделать немного custom-ную систему под конкретную задачу.
5. (Знаю, что не признаете этот аргумент, но зря) Хуже чисто эстетически. Когда висят лишние процессы, установлены лишние пакеты и т.п., мозг администратора замусоривается лишним. Лишь например он тратит доли секнды при каждой диагностике, чтобы исключить тот же dbus из причины неполадки. Когда система минимальна, её намного проще понимать.
Есть и другие проблемы, но надеюсь, суть и так уже понятна. Существовали простые хорошо себя зарекомендовавшие правила:
1. Не плодить лишних сущностей (действительно лишних).
2. Разбивать сложную задачу на множество простых (в частности, не должно быть lock in bundle-ов).
Понимаете, это администратор сервера должен определять как всё должно работать, а не какие-то lock in-ы на пустом месте.
> Про ресурсы довольно странный аргумент, у меня например вот так, но у
> вас, может, конечно, dbus и прожорливый :)
> cpu:
> ps aux|grep dbus|awk '{SUM += $3} END {print SUM}'
> 0
> mem:
> ps aux|grep dbus|awk '{SUM += $4} END {print SUM}'
> 0
Повторяю, речь идёт на мегабайты. Из десятков разных контейнеров убиваешь по dbus-у, и уже становится лучше, ибо освобождается куча дополнительного ОЗУ под дисковый кеш. Потом ещё поубивать всякие другие бесполезные вещи (кроме dbus), так вообще сразу становится "можно жить дальше".
# grep ^Vm /proc/`pgrep dbus | head -1`/status
VmPeak: 47924 kB
VmSize: 47916 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 4040 kB
VmRSS: 2856 kB
VmData: 564 kB
VmStk: 136 kB
VmExe: 412 kB
VmLib: 5652 kB
VmPTE: 108 kB
VmSwap: 0 kB
И ответьте, пожалуйста, на вопрос тут: https://www.opennet.ru/openforum/vsluhforumID3/104726.html#178
Вопрос про то, являются ли те примеры самыми сильными из тех, что вы смогли привести.
И прошу не забывать, что systemd мне не даёт ничего, из того, что мне не даёт openrc (из того, что мне требуется по работе). И OpenRC лично на моей практике работает лучше и даёт больше технических свобод, чем systemd. Поэтому ваши аргументы по поводу того, что dbus нужно ставить для systemd мне кажутся неприемлемыми. Они лишь доказывают дополнительную лёгкую ущербность systemd.
Вообще, systemd-шники мне очень напоминают дотнетчиков. Не в плохом смысле, а скорее своими особенностями мышления. Бывают люди, которые ничего кроме дотнета не пробовали -- это, конечно грустные случаи, обычно. А бывают люди, которые перешли с других ЯП на всякие дотнеты, аргументируя это экономией человекочасов. Я понимаю, что бывают use case-ы, где дотнет (как и systemd) действительно оправдан и его нужно использовать, но данные персонажи считают, что весь мир должен стать дотнетовским. В результате они начинают применять дотнеты, даже когда они совершенно неуместны, и продолжают считать, что они экономят человекочасы. А потом всё заканчивается тем, что игрушка дико тормозит, у неё принципально нельзя сделать простой "save game" до рефакторинга (из-за странноватой культуры использования лямбда-функций и невозможности сериализовать текущее состояние) и мн. др. Тратится огромное количество времени на решение этих проблем и продукт всё равно в результате становится "так себе". И в этом, на самом деле, нет ничего особо плохого, это просто инерция мышления. Все мы ей страдаем. Просто разные люди мыслят в каких-то своих рамках. Я сам тоже творю много всякой (очевидной для другого мировоззрения) херни, о чём понимаю обычно уже слишком поздно. Но весь этот абзац тоже написан исходя из мышления в определённых рамках, поэтому тоже может быть сильно ошибочным, и я не хочу сказать ни про кого ничего плохого. Целью его написания было лишь помочь понять мою позицию.
