Devuan Excalibur 6

Но даже несмотря на это систем-дэ вызывал бы меньше отторжения, если бы оставался системой инициализации и мониторинга, а не стал брать на себя всё больше функций.

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

Мои претензии не в том что он облегчил задачу дебага в датацентрах, а в том что он усложнил все прочие задачи для всех прочих.

Мои претензии не в том что он облегчил задачу дебага в датацентрах, а в том что он усложнил все прочие задачи для всех прочих.

Он усложнил задачу для очень небольшого количества людей. Подавляющему большинству зашло.

В чём профит?

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

Ф курсе

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

А сначала прочесть не такое уж короткое руководство.

Ой-вей, учиться заставляют.

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

У тебя не возникали - возникали у других. У меня, например, возникали. Systemd решает проблемы продакшна, а не админов локалхоста, потому что они по определению с таким не сталкиваются. Но решение для продакшна подходит и локалхостам, как мы видим на примере всех дистрибутивов, перешедших на systemd.

если бы оставался системой инициализации и мониторинга

То не решил бы всех проблем. Я уже говорил, повторю еще раз: за последние 30 лет оси стали сложнее, и решаемые задачи тоже. Появилась потребность в интегрированном решении для динамического реагирования на события. Раньше всё, что сейчас делает systemd, делалось с болью и плясками. Сейчас делается одной опцией, стандартно на всех дистрибутивах. Стало однозначно лучше.

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

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

Никто тебя не останавливает.

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

Кроме более важных дел?

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

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

Кроме более важных дел?

Они у всех есть. Поэтому поддерживать альтернативный инит без разумных аргументов «зачем» никто не будет. Пока таких аргументов нет.

Странно, но в первые 5 лет существования этой штуки 70% предпочитали видень нормальный текстовый лог.

И это, кстати, тоже плохо, потому что конфигурация императивная.

Юниты systemd можно распарсить INI-парсером и отредактировать автоматикой. Скрипт с функцией так не исправишь, в лучшем случае - отредактируешь седом с неизвестными последствиями. Потому что проблема останова.

А еще юниты systemd можно оверрайдить: основной юнит лежит в /usr/lib, и ты хочешь локально заменить один параметр. Делаешь override-файл, в котором меняешь нужную опцию, и этот результирующий юнит будет наследовать сначала базовую конфигурацию, потом твой override из /etc. Это супер-необходимая фича для прода, и совершенно неочевидная для мамкиных админов локалхоста.

Для скриптов это недостижимый уровень гипкости при деплое. Максимум возможного там - засорсить /etc/default/фигнянейм, и то - если автор скрипта додумался так сделать. А в systemd всё это делается средствами самого systemd, единообразно, и работает всегда.

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

У Девуана - есть. И у Гугла есть.

Юниты systemd можно распарсить INI-парсером и отредактировать автоматикой. Скрипт с функцией так не исправишь, в лучшем случае - отредактируешь седом с неизвестными последствиями. Потому что проблема останова.

Все эти переменные описаны в мане, разницы с systemd здесь нет.

А теперь наоборот. Очнись уже, клоун, 2025 год на дворе.

У меня был опыт эксплуатации систем на базе Devuan. Я пришел на проект и там это уже было. Помню, что вместо systemd units, overrides и параметризированных units приходилось костыли прикручивать.

Опыт так скажем печальный.

Но сейчас я думаю задонатил бы этим ребятам. Уж очень безалтернативным становится systemd.

У Девуана - есть. И у Гугла есть.

Ну и вот они героически страдают. Занимаются поддержкой софта (который не тестирует никакие другие иниты) и багфиксом.

Ты меня не понял. Обрати еще раз внимание, о чем я пишу при проблеме останова.

Ты меня не понял. Обрати еще раз внимание, о чем я пишу при проблеме останова.

Я понимаю, я к тому что наличие функции тут тоже не обязательно. openrc умеет command=/usr/bin/foo и тогда разницы с systemd буквально нет.

Гугл - точно не страдает. Он просто выполняет скрипт запуска системы и собственно всё. Нет никакой необходимости что то менять в нём лет 10-15.

Гугл - точно не страдает. Он просто выполняет скрипт запуска системы и собственно всё. Нет никакой необходимости что то менять в нём лет 10-15.

Держи нас в курсе.

Ага, пора переписать весь этот хлам из 2015 на электрон и реакт! Думаю тебе такая идея зайдёт - ведь чем сложнее выполняется простейшее действие тем лучше.

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

Systemd решает проблемы продакшна

Оп том и речь. Решает несколько проблем ограниченного круга людей, но стремиться занять весь «сектор».

Раньше всё, что сейчас делает systemd, делалось с болью и плясками.

Н-да? /// поддержка компиляции eBPF программ с помощью bpf-gcc; – это вот жизненно необходимо в мониторе процессов?!

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

Старые инструменты решали современные задачи неэффектиивно. Новые решают.

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

Скрипт с функцией так не исправишь

Это явная ложь.

Это супер-необходимая фича для прода, и совершенно неочевидная для мамкиных админов локалхоста.

Эта проблема была решена передачей переменных. Интересно, слышал ли ты о такой возможности?

А в systemd всё это делается

Удвоением объёма дерева юнитов, которое должен держать в голове сопровождающий? Чо, гениально... И совсем ничего не засрали в /etc/... и ещё /run, и ещё хз где потому что я ведь нихрена на знаю а значит 6 возможных положений свалки юнитов это лишь вершина айсберга.

Оп том и речь. Решает несколько проблем ограниченного круга людей, но стремиться занять весь «сектор».

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

это вот жизненно необходимо в мониторе процессов?!

Ты совершаешь типичную ошибку всех systemd-хейтеров: это не инит и не монитор процессов, это системный менеджер: прослойка, управляющая распределением всех ресурсов системы и реагированием на события, происходящие в ней. В рамках этого подхода всё прекрасно.

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

Я, в отличие от тебя, тонну софта для критических применений написал и целый дистр на сотни тысяч клиентов поддерживаю.

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

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

Ложь.

Поэтому достаточно сделать удобные инструмент для продакшна - и проблемы локалхостов эффективно решатся сами собой.

Ложь.

это системный менеджер: прослойка, управляющая распределением всех ресурсов системы и реагированием на события, происходящие в ней. В рамках этого подхода всё прекрасно.

Забивание гвоздей микроскопом. Некоторые люди считают такой подход в корне неправильным.

Это явная ложь.

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

Эта проблема была решена передачей переменных. Интересно, слышал ли ты о такой возможности?

Я об этом буквально выше написал, клоун. С оговоркой: если автор скрипта предусмотрел.

Удвоением объёма дерева юнитов

Нет никакого удвоения. Есть общее дерево юнитов, предоставляемое дистрибутиивом. Есть частные конфигурации в /etc/systemd, нужные только в случае кастомизации юнита. Количество ничем не отличается от прописывания /etc/default.

И совсем ничего не засрали в /etc/… и ещё /run, и ещё хз где потому что я ведь нихрена на знаю

Вот именно, что ты нихрена не знаешь. Системные конфигурации лежат в /usr. Частные специализации лежат в /etc. Всё.

Ложь.

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

Ложь.

Нет. То же самое.

Забивание гвоздей микроскопом.

И снова нет, клоун. Три из трех - фейл. Попробуй лучше.

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

Хорошая аналогия. Несмотря на наличие мотокультиваторов до сих пор во всех магазинах садового инструмента продаются палки-копалки (тяпки, грабли, лопаты, …). И никто не призывает всем запретить пользоваться чем-либо кроме мотокультиваторов.

Так и здесь. Где-то нужен systemd. Где-то кибернетис с докером, а где-то и daemontools полностью достаточно.

Очень хочу увидень наконец то, спустя 15 лет допиливания, хоть что то похожее на эффективность.

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

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

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

У тебя просто whishful thinking. Ты выстроил какой-то манямирок в своей голове, и теперь отчаянно ищешь ему любые подтверждения, выдумывая голословные утверждения и декларируя их здесь. Раз за разом они оказываются ложными, и ты их тут же забрасываешь, начиная выдумывать всё новые небылицы, лишь бы не смотреть на себя критически.

Забивание гвоздей микроскопом. Некоторые люди считают такой подход в корне неправильным.

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

Несмотря на наличие мотокультиваторов до сих пор во всех магазинах садового инструмента продаются палки-копалки (тяпки, грабли, лопаты, …).

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

На большом поле тебе уже понадобится какой-нибудь условный джон дир (кубернетес).

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

В баше - легко - просто передай вместо неправильного куска правильный или вызови отдельным скриптом. В 99% случаев это будет одна строка бинанрник-опции.

прочитай уже про проблему останова

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

Есть общее дерево юнитов, предоставляемое дистрибутиивом

А как же 2/3, генерируемых на лету в виртуальные ФС при загрузке?

Всё.

О, и где же тогла лежит какой нибудь sys-devices-platform-soc-fef00700.hdmi-sound-card1-controlC1.device или просто тупо home.mount?

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

Становится. Обычный юзер обычного десктопа не может совершить простейшее действие «хочу чтобы вот это стартовало между вот этим и вот этим (или просто где нибудь псле вот этого)». Вместо этого он должен вычитать десятки мануалов, распутать дерево на 200-400 юнитов и провести дебагинг.

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

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

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

YMMV. Для локалхоста бывает по-всякому. Я часто даже в systemd просто делаю себе rc.local, в который вписываю всё необходимое. Потому что писать юнит на каждый скрипт просто влом.

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

P.S. Я не один такой: https://troubleshooters.com/linux/diy/daemtools_on_sysd.htm

В баше - легко - просто передай вместо неправильного куска правильный или вызови отдельным скриптом. В 99% случаев это будет одна строка бинанрник-опции.

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

О да, для программистов машины Тьюринга это действителньо проблема…

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

А как же 2/3, генерируемых на лету в виртуальные ФС при загрузке?

Это обычные динамические сущности, существование которых зависит от хоста. Раз, два. И они не имеют никакого отношения к обсуждаемому вопросу, мы обсуждали локальную модификацию сервисов, вся она лежит в /etc.

Обычный юзер обычного десктопа не может совершить простейшее действие «хочу чтобы вот это стартовало между вот этим и вот этим (или просто где нибудь псле вот этого)».

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

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

В твоем случае, выучить баш и написать портянку. Ини-файл на 5 строчек будет короче.

Обычный юзер обычного десктопа не может совершить простейшее действие «хочу чтобы вот это стартовало между вот этим и вот этим (или просто где нибудь псле вот этого)»

В инит это намного сложнее, если них уже соседние префиксы S (или вообще одинаковые).

# ls /etc/rc3.d/
K01apache-htcacheclean  S01cups                         S01rsync
K01gdm3                 S01cups-browsed                 S01samba-ad-dc
K01speech-dispatcher    S01dbus                         S01saned
S01anacron              S01exim4                        S01smbd
S01apache2              S01named                        S01ssh
S01binfmt-support       S01nmbd                         S01sudo
S01bluetooth            S01plymouth                     S01tpm2-abrmd
S01console-setup.sh     S01pulseaudio-enable-autospawn  S01unattended-upgrades
S01cron                 S01rng-tools-debian             S01winbind

Как заставить что-то запуститься перед exim но после dbus?

Вместо этого он должен вычитать десятки мануалов

Один. По формату файла unit. Мануал по bash на порядок длиннее.

Идеальный ример кстати как не надо забивать гвозди!

А люди используют. Тоже ничего не понимают без Вашего чуткого руководства?

P.S. Я не один такой: https://troubleshooters.com/linux/diy/daemtools_on_sysd.htm

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

I’m writing this on 7/4/2015.

Ага. Смотрим на сам daemontools:

b40600d 7 years ago

Умерло за ненадобностью, потому что есть systemd.

Как заставить что-то запуститься перед exim но после dbus?

S01dbus
S01dbus_a
S01dbus_b
S01dbus_c
S01exim4

могу ошибаться, поправьте?

Да, верно. А удобно-то как, м-м-м! Красота! Явно же лучше, чем Before/After, не так ли?

Красота!

красота, сам аж прослезился! а кто спорит-то?! каков вопрос :о)))
разговор, я так понимаю все бОлее про лакалхост, а лично для меня - такое ушной изврат вполне себе даже очень рабочий вариант (без напрягов)

А когда у тебя обычный средний российский огород (локалхост), то стоит купить мотоблок и не убивать себе спину.

Как имеющий в семье 2 участка и 1 мотоблок (высокого класса кстати) - скажу что ты опять не прав. Чёрт, как человек, смонтировавший десятка 2 фундаментов, подземных трубопроводов и распланировавший десяток участков скажу, что землеройная техника вообще не должна выходить на работу если под рукой нет 2 лопат и крайне желательно человека чтобы их держать.

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

могу ошибаться, поправьте?

Вот-вот. Очень «очевидное» и «стабильное» решение. Назовите свою службу на нужную букву. А потом запоминаешь, что iptables настраивал в dbus_a, а мониторинг в dbus_b.

Вообще, конкуренты SysV (все эти Upstart и прочие) и появились именно из-за того, что людям надоело вручную расставлять префиксы после S.

Зато там нечему пойти не так. А вот в Before/After можно и цикл словить...