InitWare — форк systemd для Linux, BSD и MacOS

Да. Только нормальную, а не зонд от Лени.

Ты тоолдфаг и рукодельниц, но сустемдимдик реально в работе кпрощает жизнь. Дерьмо в нем не в идее, а в реализации.

Бзди очень круты и потому тут много молодых и горячих. Про скрипты в ядре тут ещё не написали?

Плохого в сустемд лишь не портабельность как одна из основ.

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

А я разве что-то говорил против systemd? Я отношусь к нему нейтрально. Поюзал его около трёх лет перед тем как свалить с линуксов.

Дерьмо в нем не в идее, а в реализации.

Дерьмо не столько в реализации, сколько в дебильности разработчиков (NOTABUG, WONTFIX вместо решения проблем).

много молодых и горячих

Много попыток. Но чаще всего молодёжь сливается раньше чем успевает пощупать. ☺

Что там у этих неумёх и wannabe-linux freebsd не знаю, правда.

У неумёх из openbsd абсолютно то же самое что я написал, потому что init система унаследована от неумёх из фряхи, причем как и всё что они унаследовали, в оригинале она ещё как-то развивалась, а у них нет. А переписать они не просто не могут в силу некомпетентности, но и не хотят, потому что цели быть полезной системой у них нет.

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

Спасибо. Интересный пост. Теперь понятно откуда ноги растут.

Она работает на Linux и всех современных BSD, включая macOS.

Эпл дает возможность заменить launchd? Или это хитрый костыль?

Костыль. «InitWare may run either as an init system or as an auxiliary service management system under another init system.»

systemd — это попытка (удачная или нет — судите сами) реализовать подобие launchd(8).

На чем основано это утверждение? Просто чтобы было понятно, юниты launchd пишутся на xml..

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.example.hello</string>

    <key>ProgramArguments</key>
    <array>
        <string>hello</string>
        <string>world</string>
    </array>

    <key>KeepAlive</key>
    <true/>
</dict>
</plist>

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html

С таким же успехом можно любую систему инициализации объявить ПОПЫТКОЙ РЕАЛИЗОВАТЬ LAUNCHD.

юниты launchd пишутся на xml

Как и у SVC. Я в курсе. Вот только это никак не меняет их суть — системные менеджеры (а не просто иниты).

всего чуть-чуть назад по треду. быстрее пролистать, чем писать такой длинный коммент. InitWare — форк systemd для Linux, BSD и MacOS (комментарий)

SVC - это service (а не system) management. золотая середина, имхо.

Полтора. ☺ Из них меньше половины можно прикрутить к фряхе. (%

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

SVC - это service (а не system) management. золотая середина, имхо.

Ну он там ещё гипервизор и немного системный менеджер (хоть и не лезет в каждую щель, как это делают launchd и systemd).

Полтора. ☺ Из них меньше половины можно прикрутить к фряхе. (%

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

Их нельзя прикрутить как PID 1 (можно, но это гребля с препятствиями), а гипервизор сервисом — это не очень по очевидным причинам.

Я бы давно себе прикрутил runit, он умеет всё что мне нужно и не лезет куда его не просят, и вполне может работать сервисом, но хочется гипервизор как PID 1, и при этом не хочется переписывать все скрипты сервисов. В общем, я тот ещё прокрастинатор. >_<

Ну он там ещё гипервизор

эт как? hypervisor - это в первую очередь понятие из виртуализации. в смысле рестарт сервисов? так это и есть service managment. что значит «немного системный»? маунты? да нет. никакой не system. service.

Их нельзя прикрутить как PID 1

и замечательно! ты не читал мой тред с intelfx? лучше с конца: root в ядре и обрушение системы через systemd (local)

но хочется гипервизор как PID 1

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

hypervisor - это в первую очередь понятие из виртуализации.

Не обязательно. Само понятие означает "контролёр всего", если совсем просто.

и замечательно!

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

В этом плане мне очень нравится runit — он простой как дубина и эффективный гипервизор, который больше ничего не делает, только (пере)запускает сервисы, которые ему скормили. Всё. И никаких проблем с повышением прав, дырах в безопасности (ну если только админ не сказочный долбоклюй и сам не кинул руткит в сервисы ☺).

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

Не обязательно. Само понятие означает «контролёр всего», если совсем просто.

спасибо, кеп, я понимаю) («в первую очередь») не понятно, что ты имеешь ввиду.

Нууу? Не обязательно контейнеров или виртуалок, не обязательно целой ОС, только всего того, на что он рассчитан. ^_~

вообще это слово используется теперь вот так https://en.wikipedia.org/wiki/Hypervisor

поэтому твое «всего прочего» мало понятно.

он простой как дубина и эффективный гипервизор

он supervisor. а гипервизор закреплено в виртализации.

Тьфу. ☺

Когда падает... А у systemd куча мест, где можно проковырять дыру

нет, сама идея отменить мини-инит и запихивать функционал в PID1 - это плохо. и CVE для runit это подтверждают. поэтому твои слова

Их нельзя прикрутить как PID 1

это как раз то, почему я говорю: оставь это Тео. SVC правильно сделан. и те service managment тулзы, что есть для линукса и бзд, - это гораздо лучше, чем то, что ты хочешь.

Ладно, убедил. Но распараллеливание загрузки точно нужно!

[пожал плечами] это десктопная фича

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

Пусть будет так. Но не вижу смысла откладывать монтирование отложенных несетевых маунтпоинтов, ожидая поднятие сети. Или откладывать переход в интерактивный режим (на который не только login(1) завязан) из-за ntp.

Вопрос «зачем?»

Спрашивать надо «почему?», а не «зачем?». И ответом на вопрос «почему?» будет то, что если раньше *BSD-системы оказывали огромное влияние на дистрибутивы Linux, то с увеличением популярности Linux и снижением популярности *BSD, всё начало работать в обратную сторону.

А ответ на вопрос «зачем?» – элементарный. Кто-то захотел себе что-то удобное и современное, вместо ковыряния в shell-лапше.

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

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

а во фре разве так? mountcritlocal, netif... другое дело, что присутствует еще с десяток скриптов для маунтов, чтобы отловить все моменты. интересно, как в SMF это решили.

переход в интерактивный режим (на который не только login(1) завязан) из-за ntp.

это спорный вопрос. ты опять думаешь с точки зрения root@localhost. а если это серверная многопользовательская система и мне нужно знать точное время, когда кто-то из пользователей залогинился? логично сначала привести ОС в порядок, а потом пускать юезров. поэтому я и сказал, что требования к серверным и десктопным системам отличаются и было глупо пытаться впихнуть все в systemd. и обрезанный системд из топика никак это не решает.

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

ты опять думаешь с точки зрения root@localhost.

Я думаю как админ без юзеров (совсем без юзеров, а не как на десктопе). ☺

И если уж пошла такая пьянка про кучу юзеров, то почему юзеры должны ждать 100500 счётного времени, если технически их можно пускать раньше?

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

Расход времени не более чем на две секунды ничего не даст, а если время совсем съехало, то надо было вовремя пинать тех у кого есть физический доступ к юниту для замены баты RTC, тут всё равно админ виноват, а не ОС.

логично сначала привести ОС в порядок, а потом пускать юезров

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

Я зря привёл в пример именно ntp, стоило написать про какой-нибудь… ну не знаю… qbittorrent, например.

Я думаю как админ без юзеров (совсем без юзеров, а не как на десктопе).

есть админ учетка, а есть админ работа. вторых без юзеров не бывает.

Расход времени не более чем на две секунды

нет, ntp - это как раз очень удачный пример. сбой может быть и на 10 лет. батарейка в биосе села. а что считать готовностью системы, решает админ (на основании требований, ес-но).

Не логично их не пускать когда всё необходимое уже готово... Я зря привёл в пример именно ntp

а если это логин с использованием kerberos в домене, то ntp is a must.

вторых без юзеров не бывает.

Юзеры тоже разные бывают. Если Kerberos, то юзеров фактически нет, есть тикеты. ^_~

ntp - это как раз очень удачный пример

Я хотел привести в пример такой сервис, без которого можно пускать юзеров.

сбой может быть и на 10 лет. батарейка в биосе села.

У плохого админа и железо разваливается. ☺

а что считать готовностью системы, решает админ (на основании требований, ес-но).

А вот тут ты абсолютно прав!

а если это логин с использованием kerberos в домене, то ntp is a must.

Вот именно поэтому пример с ntp был неудачным. ☺

батарейки иногда садятся.

батарейки иногда садятся.

Ну так за ними надо следить!

Я за всё время поздно обнаружил что батарейка села только один раз, и то было на десктопе, который тыщу лет простоял в подсобке. А на серверах IPMI репортит в том числе состояние CMOS Battery (хоть и называется это по-разному)… впрочем, не везде есть доступ к IPMI, но это уже совсем другая история.

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

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

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

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

Это я в курсе. Просто я не привык к частой ротации железа.