Devuan Excalibur 6

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

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

Персонально мне совершенно по барабану, что там с альтернативными инитами, я лишь говорю, что они не нужны, потому что systemd решает проблему управления ресурсами системы,

Это всего лишь твой use case.

и делает это хорошо.

Далеко не всегда.

Нежелающим использовать systemd и ищущим альтернатив, рекомендуется так же перейти и на какую-нибудь альтернативу линуксу, например Debian GNU/Hurd,

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

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

systemd монополию можно, а по ядрам нельзя ? :)

Это всего лишь твой use case.

Нет. Это объективный факт для подавляющего большинства эмбеда, рабочих станций и серверов.

Далеко не всегда.

Нет. Почти всегда. А что не всегда - можно и нужно пофиксить.

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

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

systemd монополию можно, а по ядрам нельзя ? :)

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

Нет. Это объектиивный факт для подавляющего большинства эмбеда, рабочих станций и серверов.

Даже страшно представить systemd для критически важной инфры.

Нет. Почти всегда. А что не всегда - можно и нужно пофиксить.

Хоть обфиксись, там столько жира, что поможет только липосакция.

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

С моей стороны это было всего лишь реакцией, ты первый начал ;)

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

Правильнее было бы сказать: когда ты указываешь (а не предлагаешь как я в части Devuan) другим, что и как им делать ...

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

Очевидно же, ядро для поддержки оборудования, производительности, виртуализации и контейнеризации.

А systemd ненужно на оркестраторах и гипервизорах, поэтому.

Даже страшно представить systemd для критически важной инфры.

Забавно, что именно для критически важной инфры systemd подходит лучше всего, с его развитыми функциями слежения за здоровьем процессов. Например, ты знал, что оборудование Ubiquiti содержит в себе systemd? Теперь знаешь.

Хоть обфиксись, там столько жира, что поможет только липосакция.

В чем выражается жир?

С моей стороны это было всего лишь реакцией

Ну вот, пошли оправдания: «Я не хамло, это просто реакция!!11».

А systemd ненужно на оркестраторах и гипервизорах, поэтому.

У нас мир состоит из оркестраторов и гипервизоров?

Последний пассаж вообще пушка, конечно. «Ядро нужно для чего-то, потому что нужно вообще, а systemd не нужен, потому что не нужен в каком-то юзкейсе». Логика уровня «помидор красный, потому что у трактора дверь открывается вот так».

Последний пассаж вообще пушка, конечно. «Ядро нужно для чего-то, потому что нужно вообще, а systemd не нужен, потому что не нужен в каком-то юзкейсе». Логика уровня «помидор красный, потому что у трактора дверь открывается вот так».

У тебя какие-то проблемы с логикой?

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

У тебя какие-то проблемы с логикой?

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

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

Где я пришёл к выводу о ненужности в общем случае?

Уже упоминал в этой ветке, что использую systemd внутри LXC контейнеров и иногда внутри виртуалок, ты пропустил?

В частном случае на физических хостах оркестраторов и гипервизоров IMHO systemd вреден, потому что сам является очень жирным оркестратором сервисов. А для надёжной и предсказуемой работы даже всего лишь docker-compose куда полезнее самый лайтовый инит с супервайзингом только докера и возможно ещё пары-тройки сервисов, чем этот монстр systemd, в котором даже docker работает невсегда предсказуемо.

Если у меня уже есть наипрекраснейший оркестратор локахоста docker-compose и incus, то зачем мне твоё систем дно, которое в таком случае только пакостит?

Где я пришёл к выводу о ненужности в общем случае?

Перечитай внимательно свои же сообщения.

Если у меня уже есть наипрекраснейший оркестратор локахоста docker-compose и incus

А, ты у нас контейнерный фанбой, вопросов больше не имею.

Познай, наконец, что это абсолютно разные уровни управления сервисами, и что systemd не является оркестратором, а предназначен для управления системой над ядром.

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

Формально systemd - это init-система и менеджер сервисов.

systemd организует запуск и управление множеством сервисов, что похоже на мини-оркестрацию сервисов на локалхосте. Он ещё и контейнеры умеет спаунить.

Формально systemd - это init-система и менеджер сервисов.

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

systemd организует запуск и управление множеством сервисов

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

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

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

Т.е. если systemd - это системный менеджер (общее), то менеджером сервисов (частное) он не является? Противоречишь своим же собственным придиркам относительно частного/общего?

Можно назвать systemd менеджером сервисов, когда говорю о его подсистеме управления юнитами.

Опять же, следуя твоей корявой логике, любой развитый init является средством «мини-оркестрации».

А почему нет для некоторых из них?

Любой развитый init, который умеет:

• запускать несколько сервисов с зависимостями
• перезапускать при падении
• запускать по таймеру, событиям и условиям

т.е. формально делает часть функций оркестрации на локальном хосте?

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

Почему по твоему мини-оркестратор локал хоста обязан деплоить обязательно самостоятельно? Разве мини-оркестратор не может заниматься только доп. настройкой и управлением процессов?

И таки systemd-spawn помогает деплоить, если уж на то пошло?

Т.е. если systemd - это системный менеджер (общее), то менеджером сервисов (частное) он не является? Противоречишь своим же собственным придиркам относительно частного/общего?

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

Можно назвать systemd менеджером сервисов

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

т.е. формально делает часть функций оркестрации на локальном хосте?

Да. Системой оркестрации, при этом, не являясь.

мини-оркестратор

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

И таки systemd-spawn помогает деплоить, если уж на то пошло?

Нет, он не имеет никакого отношения к деплою, только к запуску.

Ты даешь неполное (частичное) определение, и на этом основываешь все свои рассуждения.

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

Нет. У тебя проблемы с логикой, я же говорю.

Получается таки у тебя проблемы.

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

Ты не смог этого убедительно доказать.

Получается таки у тебя проблемы.

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

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

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

Мы с тобой только что выяснили, что проблемы именно у тебя.

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

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

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

Вау, а ведь действительно немало обновили, молодцы. Считаю объединённый /usr глупостью, я всегда топлю за чёткие разделения, но остальное - класс

systemd неделим на части

Вполне себе делим. Например, networkd прекрасно работает без остального systemd.

они трудно заменими или вообще незаменимы при использовании systemd

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

Это тебе лишь кажется

Мне не интересны твои домыслы.

Для моих рассуждений было достаточно и неполного определения

Недостаточно. Ты делаешь заявление уровня «автомобиль - это двигатель», и дальше строишь на этом свою убогую логику.

делает твою позицию в споре ещё намного хуже

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

Я помог тебе выяснить, что systemd является модульным системным менеджером, а не системой инициализации, это новая для тебя информация. Далее мы выяснили, что системой оркестрации он не является, а термин «мини-оркестратор» ты придумал сам.

Осталось научить тебя пользоваться общепринятой терминологий - и наступит полный катарсис.

Networkd - да.

Остальное - нет.

Сстемд не модульна практически, а из этого следует, что вместо запуска 5-ти нужных прог, в которых по одной фиче, ты запускаешь 1 прогу с сотней фич, из которых надо тебе 5, а остальное просто место занимает

IMHO и по словам тех, кто уже ставил Devuan v6, в нём до сих пор остаётся серьёзный недостаток в неполноте реализации OpenRC, потому что в /etc/init.d находится старинный говнокодинг из SysV

А например, в Alpine Linux в /etc/init.d ставятся «из каропки» настоящие трушные компактные легко читаемые скрипты для OpenRC.

Надеюсь, со временем разработчики Devuan заменят древний лапшекод сервисных инит скриптов на настоящие как в Alpine и Gentoo.

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

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

системд не модульна практически

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

вместо запуска 5-ти нужных прог в которых по одной фиче, ты запускаешь 1 прогу с сотней фич, из которыхтнадо тебе 5, а остальное просто место занимает

Нет. Мне нужна сеть - я запускаю networkd. Нужен DNS - запускаю resolved. Для управления временем я запускаю timesyncd. И так далее. Подсистемы четко разделены, и запускаются при необходимости, никто ничего не занимает.

Да, я девуан к сожалению ещё не юзал, однако в alpine и gentoo реализация openrc работает великолепно, надеюсь, все дистрибутивы перейдут на openrc, прекрасная инитка.

Осталось научить тебя пользоваться общепринятой терминологий - и наступит полный катарсис.

Он давно наступил, и проявляется в том, что systemd обычно ненужен, достаточно оркестраторов типа docker-compose и kubernetes без systemd.

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

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

Модули не обязаны работать с чем-то другим.

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

Сстемд не модульна практически, а из этого следует, что вместо запуска 5-ти нужных прог, в которых по одной фиче, ты запускаешь 1 прогу с сотней фич, из которых надо тебе 5, а остальное просто место занимает

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

программа была не огромным целым куском кода

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

systemd-хейтера

Я люблю systemd для игры с ним в LXC.

Забавно, что ты всё еще не понимаешь, что это несколько разные уровни управления ресурсами ОС.

Забавно, что ты всё еще не понимаешь,

что мне удобнее и достаточно того, как работает БЕЗ systemd

что мне удобнее и достаточно того, как работает БЕЗ systemd

Когда у клоуна в руках кубернетес молоток - всё вокруг ему кажется гвоздями.

Когда у клоуна в руках кубернетес молоток - всё вокруг ему кажется гвоздями.

Упоминания docker ты предусмотрительно пропустил, отличный тролль.

Распихивать системные сервисы в докер - это идиотизм примерно того же уровня.

А еще клоунам часто кажется, что разумные люди, оппонирующие их чуши, являются троллями. Что поделать, ошибка восприятия-с.

Распихивать системные сервисы в докер - это идиотизм примерно того же уровня.

Уже упоминал, что из критически важных долго живущих системных сервисов на Linux мне нужны только оркестраторы docker и incus, жирнод им только вредит.

Долгоживующие системные сервисы без контейнеров прекрасно себя чувствуют в соседнем OpenBSD и доступны по сети.

из долго живущих системных сервисов мне нужны только оркестраторы docker и incus, жирнод им только вредит

Точно-точно? А ntpd ты тоже в контейнер засунешь, чудо мое?

А ntpd ты тоже в контейнер засунешь, чудо мое?

Ранее я уже упоминал про ещё пару-тройку сервисов, жирнод опять мимо.

Вот так мы и приходим к нужности systemd, который должен обеспечивать доступность этой пары-тройки сервисов (на самом деле как минимум десятка) и инициализации ОС, пока не запустится докер. Без systemd тебе придется городить огород из скриптов и обмазываться мониторингами. Нет смысла этим заниматься, если systemd уже написан.

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

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

Блобом в смысле проприетарности?

Предлагаешь мне самому отпилить от жирнод лишнее прямо в миллионах LoC его сорцов?

Или ты хотел сказать монолитом?

Блобом в смысле проприетарности?

А эта чушь как в твоей голове зародилась? Сходи проверь лицензию.

Или ты хотел сказать монолитом?

Blob = binary large object. В обиходе systemd-хейтерков, вроде тебя, этим словом в том числе принято называть systemd, потому что вы, как правило, не знаете, что systemd не представляет собой единый бинарный монолит.

Доступно?

OL, а разве эти вытираны не полыхали пердаками что это нововведение systemd неприемлемо?

Потом и journald распробуют :)

Blob = binary large object. В обиходе systemd-хейтерков, вроде тебя, этим словом в том числе принято называть systemd,

Я так ни разу его не назвал в этой ветке, ты же его так назвал, но при этом определил в группу называния systemd блобом меня, а не себя.

В твоёй извращённом терминологии теперь блобом можно назвать чуть менее, чем все большие файлы дистрибутива?

жирнод - жирный, не потому что один бинарник, а потому что архитектурно сложный.

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

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

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

Я так ни разу его не назвал в этой ветке

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

потому что архитектурно сложный

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

Архитектурно systemd ближе к монолиту, чем к модульной системе.

И снова нет. Опять же, можешь почитать его исходники.

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

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

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

Разница в том, что zcat может сделать хоть винда, хоть андроид, хоть макось, хоть бздя, а журналцтл исключительно та машина, которая писала эти логи. А она у тебя по определению лежит если они тебе понадобились!

Такого быть не должно. Ты должен раздавать разные /etc централизованно с сервера, если нужно.

Для этого git и rsync есть. А суть уникальности сервера именно в его конфигах а не в том чтобы занимать физическую железку.

журналцтл исключительно та машина, которая писала эти логи

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