systemd 256

И как много UNIX-like это поддерживают?

А как много unix-like актуальны?

Почти рандомный пример из серии «пальцем в небо»:

systemd-boot is a free and open-source boot manager created by obsoleting the gummiboot project and merging it into systemd in May 2015 (источник).

Вы уж там определитесь, трусы или крестик.

То, что не все компоненты systemd являются обязательными, я в курсе. Но они носят в своём названии слово systemd и, как видно по цитате выше, признаются его частями. Ну или иди в Википедию и объясняй им, что они написали ерунду. И даже если получится, вопрос, почему он именно systemd-boot, остаётся в силе. В начале было слово, как говорится.

То, что не все компоненты systemd являются обязательными, я в курсе. Но они носят в своём названии слово systemd и, как видно по цитате выше, признаются его частями. Ну или иди в Википедию и объясняй им, что они написали ерунду. И даже если получится, вопрос, почему он именно systemd-boot, остаётся в силе. В начале было слово, как говорится.

Компоненты openbsd тоже носят в себе ее название, но являются ее частями. Тебе это мешает пользоваться openssh?

Моновендорность - это не очень хорошо

Какая ещё моновендорность у открытого проекта который может форкнуть любой желающий и куда контрибьютят представители всех ключевых дистрибутивов GNU\Linux? Даже на ЛОР есть люди чьи патчи приняли в systemd.

когда-то ЛОР крутился на фряхе

Ты реально идиот именно в медицинском смысле? У тебя функциональная неграмотность? Как это соотносится с текстом на который ты отвечаешь? Что и кому это доказывает? Ты вообще понимаешь смысл текста который читаешь?

А почему ты спрашиваешь? Ты психиатр? Если да, тогда что ты делаешь на айтишном форуме?

Ну или иди в Википедию и объясняй им

Дожились - модеры к вики апеллируют. Какой зашкаливающий профессионализм, какие бездны экспертизы!

Видимо истинная причина хейтерства systemd в том что проект посмел выпустить документацию не в формате аниме-сериала.

Если да, тогда что ты делаешь на айтишном форуме?

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

когда-то ЛОР крутился на фряхе

… и был написан на php

На пёрле, вообще-то.

P.S. На щёт фряхи - меня чё-то берут большие сомнения. Вроде как со старта на красношапке было.

Где бы почитать историю ЛОРа? (комментарий)
LOR, jsp и веб-программирование (комментарий)

Видимо истинная причина хейтерства systemd в том что проект посмел выпустить документацию не в формате аниме-сериала

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

merging it into systemd

merging into systemd следует понимать как слияние репозитариев. От того, что systemd-boot теперь находится в том же git-репозитарии что и systemd, не следует, что systemd-boot являеется неотделимой частью systemd. В дебиане он вообще отдельным пакетом идет.

И впрямь, php. Склероз, однако.

Иниту и в принципе системному менеджеру не нужен быстрый прогресс. Оно уже перешло в фазу молотков и чайников: система запущена? запущена. Сбои обработаны, упавшие юниты переподняты? Отлично, большего не требуется. +/- 5с на запуске роли не играют, любое супер-мега-улучшение это всего лишь 0,1% на третьестепенной фоновой задаче и если там требуются какие либо, любые, изменения со стороны софта - это принесёт ненужные проблемы.

то что ламеры его не осиливают это ожидаемый побочный эффект.

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

Там не просто прочитать надо, там ещё и понять требуется, а для этого нужен работающий мозг.

Интересно, если в доке написано «опция Х= делает Х если выполнено условие У», то для прокачанного (веществами?) мозга это видимо означает что опция Х на самом деле задаётся через Z=, условие У устарело 2 версии назад и теперь нужно процерять условие W и дополнительно прописать V= для всех предшествующих юнитов дерева.

Нет, это сделает systemd.

А системд тоже сам напишет новый юнит чтобы новое действие легло в нужный момент?

Или может быть решение зависимостей и построение дерева паралельной загрузки не требуют времени при собственно загрузке?

Или может быть решение зависимостей и построение дерева паралельной загрузки не требуют времени при собственно загрузке?

Ты ведь в курсе, что топологическая сортировка дерева из 100-200 элементов займёт ну максимум 10 мс?

Вместе с чтением, парсингом и генерацией виртуальных юнитов?

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

Вместе с чтением, парсингом и генерацией виртуальных юнитов?

# time systemctl daemon-reload                                                                                                                                                                   
systemctl daemon-reload  0,01s user 0,01s system 3% cpu 0,422 total

Это синхронная операция, включающая в себя вообще всё. Приведённое время — у меня на ультрабуке восьмилетней давности.

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

Хуже ламера — только ламер самоуверенный (c)

у вас полагается затыкать рты

См. первую строчку моего профиля после списка железа.

на фоне существования не менее гибких альтернатив

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

ламерами осваиваются и делают практически всё то же самое

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

следовало избавиться ещё

И по этой же причине твоё мнение об архитектуре интересует разработчиков systemd и создателей дистров не больше чем мнение свиньи о яблоках интересует создателя сидра.

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

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

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

Специалиста в чём то можно узнать по 2-м признакам: во первых он не станет рассуждать про то что все вокруг ламмеры и нихрена не понимают, особенно в контексте «я прав, вы нет». А во вторых - потратит всё то же самое время не на словестный понос а на пару-тройку конкретных примеров почему runit/upstart принципиально хуже системд ну хотябы чтобы не напрягаться, потому что они сами по себе выскользнут из его памяти.

А ещё есть третье соображение из области здравого смысла и житейской мудрости: грамотно спроектированная система должна быть простой в использовании. Задача вмешательства в запуск ОС/программы/службы это что, кунг-фу для избранных? Нет, **ять!!! Это должен делать эникейщик после двухчасового чтения мануала! Причём с возможностью не просто вкл/выкл, но ещё и поправить на ходу если что то пошло не так.

Это конечно хорошая идея, но за время пути граф успел подрасти. Начиная с какого то момента сложность вопроса «что я должен прописать в юните чтобы он выполнился после монтирования ФС но до запуска ХХХ?» должна превысить возможности человека, сидящего перед консолью с systemctl и nano. И лично для меня - давно и значительно превысила.

В этом случае самый тупой и архаичный костыль init'а, реализующий линейную последовательность действий на основе последовательности чтения файлов в папке может эффективней решить задачу.

Это конечно хорошая идея, но за время пути граф успел подрасти. Начиная с какого то момента сложность вопроса «что я должен прописать в юните чтобы он выполнился после монтирования ФС но до запуска ХХХ?» должна превысить возможности человека, сидящего перед консолью с systemctl и nano.

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

В этом случае самый тупой и архаичный костыль init’а, реализующий линейную последовательность действий на основе последовательности чтения файлов в папке может эффективней решить задачу

В случае, если ты не осилил документацию?

на пару-тройку конкретных примеров

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

Это должен делать эникейщик после двухчасового чтения мануала

Всё так. Тот факт что ты до сих пор этого не осилил показывает лишь то, что ты тупее эникейщика.

И лично для меня - давно и значительно превысила.

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

стабильной параллельности

в openrc есть stacked runlevels, и они отлично работают

зависимости старта сервиса от точки монтирования

не нужно при наличии inotifywait

если не встроенного, то хотя бы интегрированного журнала

а, я понял. Ты фанат кучи магических настроек в юнитах, вместо какого-нибудь элементарного | s6-log в строке запуска. Это не считая того, что в openrc есть rc_logger.

пользовательских юнитов

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

• передать в сустемд все нужные переменные среды
• создать специальный таргет
• прописать в пользовательские юниты зависимость от этого таргета
• прописать запуск этого таргета в конфиге WM

очевидно что подобная архитектура - ненужная переусложненная хрень, и намного проще оставить в ней только последний пункт, запуская пользовательский супервизор (например s6-svscan) напрямую из конфига WM.

встроенной супервизии

есть supervise-daemon.

Резюме: кажется ты слабо понимаешь, о чем говоришь.

в openrc есть stacked runlevels, и они отлично работают

Причем тут это?

не нужно при наличии inotifywait

Каким образом это связанные вещи, объясни пожалуйста? Я бы ещё понял, если бы ты сказал «при наличи mountpoint», но это все костылищи.

а, я понял. Ты фанат кучи магических настроек в юнитах, вместо какого-нибудь элементарного | s6-log в строке запуска.

В s6-log нет НИЧЕГО элементарного. s6 это вообще наименее userfriendly замена иниту. Самое смешное, что это даже автор признает и клянчит деньги на фронтенд.

Это не считая того, что в openrc есть rc_logger.

Который либо не установлен, либо установлен в «logger» и шлет все в один syslog где тебе надо руками все разгребать :)

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

Написать юнит в десять строк. Вот, смотри:

[Unit]
Description=Syncthing - Open Source Continuous File Synchronization
Documentation=man:syncthing(1)

[Service]
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure

[Install]
WantedBy=default.target

ТАДАМ. Вы великолепны.

сложность написания юнитов? Ведь речь изначально шла именно о сложности обхода графа зависимостей.

Так я и говорю о сложности графа! В юните всё предельно примитивно, нужно вписать правильные точки графа в поля «до» и «после». А как их определить чтобы именно тогда, когда надо и не вывалиться с ошибкой? В линейной последовательности всё крайне просто: вот между тим и этим, а если не угадал - увидишь сразу и поправишь за минуту. А в сложном графе можно и кольцевую зависимость словить, тогда решения не будет в принципе.

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

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

У инита тоже. И может даже длинная, сложная и правильна, но там есть ключевые 2-3 абзаца которые необходимы и достаточны в 99,99% случаев.

В случае, если ты не осилил документацию?

Ок, аналогия. На Матизе масляный картер свободно доступен снизу. В принципе можно почитать документацию, но и так понятно что если течёт - открути эти болты и поменяй прокладку/помаж герметиком. На Ниссан Х-трэйл масляный картер доступен после снятия всей передней подвески и то ли обоих радиаторов, то ли кондиционера. Всё это великолепно описано в целой главе мануала, качественного перевода на русский просто не существует, как и не существует адаптации для стандартного набора инструментов вместо нисанновских сервисных наборов съёмников. Результат: стоимость обслуживания Х-трэйла раз в 10-50 раз выше, время простоя больше, ремонт в гаражных и домашних условиях почти невозможен, а вероятность ремонта и дополнительных повреждений в сервисном центре примерно равна. Или обобщая: у Матиза 12 года совершенно логично не течёт масло, а у Х-трэйла 12 года - течёт, и это проще признать нормой чем исправить.

Написать юнит в десять строк

идиот

идиот

Ты как-то уж очень быстро порвался. Никаких таргетов создавать, к слову, не надо, они уже есть :DDD

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

В s6-log нет НИЧЕГО элементарного

еще и тупой получается, иди маны покури

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

Я не знаю, ты написал очень много страшных буков. Я показал, что они не имеют к реальности отношения, ведь все что мне потребовалось чтобы сделать user unit – написать вот эти строки. И все работает. Значит, ты балабол?

еще и тупой получается, иди маны покури

Зачем? У меня systemd, там все работает из коробки и никакого пердолева с шизофренией skarnet.

Напомню как выглядит конфиг s6-log:

s6-log n30 E500 - +fatal: 2 - +^STAT =/var/log/foobard/status f s10000000 S15000000 T !"gzip -nq9" /var/log/foobard

ExecStart=/usr/bin/syncthing

Кстати, вот почему системд считает, что для запуска демона достаточно одной команды а типичный инит-скрипт имеет размер в 10Кб, там отдельно определён сценарий запуска, сценарий остановки и сценарий рестарта? А ещё там происходит куча операций над всякими путями и переменными, наверное они зачем то нужны, хотя системд ничерта о них не знает (а если знает, то где это всё в юните?). Нигде в сис-в не сказано что инит-скрипт должен быть таким жирным, а не просто

#!/bin/sh
/usr/bin/syncthing serve --no-browser --no-restart --logflags=0

Кстати, вот почему системд считает, что для запуска демона достаточно одной команды а типичный инит-скрипт имеет размер в 10Кб, там отдельно определён сценарий запуска, сценарий остановки и сценарий рестарта?

Да нет, в openrc это тоже три переменные. Просто openrc пользовательские юниты тоже через жопу умеет, как и все остальное.

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

Но системд не может определить отдельный сценарий завершения и отдельный для рестарта!

ExecStart и ExecStop и ExecReload.

systemd-run получил алиас run0 который работает как аналог sudo с контролем привелегий с помощью PolKit;

У pkexec нашли фатальный недостаток.

поддержка старых скриптов System V объявлена устаревшей, её планируется убрать в одном из следующих релизов;

Офигели, они так кучу софта поломают.

Мне кажется или вы с Lrrr один и тот же человек?

Офигели, они так кучу софта поломают.

Назови три.

Или вот ещё одна странная архитектурная химера: он принципиально работает только с полными путями. А что если системе нужно по-быстрмоу глобально переключать версии каких нибудь питонов или джав просто перееопределяя PATH?

А тридцать не хочешь?

https://imgur.com/6Eu95pZ.png

Или вот ещё одна

Ты хотел сказать «первая», потому что остальные – твое непрочтение мана.

странная архитектурная химера: он принципиально работает только с полными путями. А что если системе нужно по-быстрмоу глобально переключать версии каких нибудь питонов или джав просто перееопределяя PATH?

Так делают все сервисные менеджеры, оло. И systemd, и openrc, и даже rc в OpenBSD, который по сути тупо обвязка на pkill.

Это команды а не сценарии. Ну типа там примонтировать, скопировать, разархивировать, запустить 3 бинарника, подождать, один прибить, второму послать команду по ssh.

Что это за дистрибутив?

Это команды а не сценарии. Ну типа там примонтировать, скопировать, разархивировать, запустить 3 бинарника, подождать, один прибить, второму послать команду по ssh.

Засунь это в скрипт.

Что это за дистрибутив?

Linux Mint (считай убунту), некоторые приложения туда скриптов докидывают.

Так делают все сервисные менеджеры

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