В OpenRC добавлены пользовательские сервисы

Это у тебя ядро какое-то специальное.

Это Alpine, дистрибутив с openrc :)

А всё-таки, dhcp-то тут причём?

При том, что udhcpc шлет запросы через af_packet.

При том, что udhcpc шлет запросы через af_packet.

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

В нашем эксперименте был только udhcpc, и то справиться не смогли. Это мы еще не дошли до podman и cgroups. Аргумент-то был «это проще», а в итоге дошли до чтения сорцов udhcpc и сборки ядра.

… был только udhcpc, и то справиться не смогли…

Дык, справились же.

… Это мы еще не дошли до podman и cgroups.

Возможно, достаточно будет unshare. «это проще» :). От задачи, конечно, зависит.

Дык, справились же.

Дык нет же. Автор не смог написать последовательность шагов и конфиги mdev или что он там собирался использовать.

Возможно, достаточно будет unshare. «это проще» :). От задачи, конечно, зависит.

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

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

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

Так неудобно было. Был sysv init который всех достал, был openrc, upstart и systemd. Выбирали наименее всратое решение на замену bsd init, выбрали systemd. Сражаться с ним не надо, геморроя с ним нет, все у всех работает. Я про нерабочий systemd слышу только в пузярых типа LOR, где находятся сражающиеся с ним клоуны. Зачем они с ним сражаются это вопрос к клоунам.

все удобно было, кинул скрипт и забыл

все удобно было, кинул скрипт и забыл

Да нет, не было. Но я не вижу смысла это обсуждать. Все что мы вынесли из треда:

• Когда кто-то орет «systemd не нужон я сейчас на busybox все сделаю», он просто не знает, о чем говорит.

• У OpenRC наконец-то появился разработчик, если ему не надоест, возможно openrc догонит dinit.

• Зачем все это нужно, если есть systemd, никто не смог внятно объяснить.

OpenRC – система инициализации для Linux-систем, которая поставляется вместо systemd

Она поставлялась «вместо systemd» когда systemd ещё в планах не было.

Ещё в Artix. Хороший дистр, кстати, годный.

… Все что мы вынесли из треда:

Всё что вынесли Вы, несите обратно. Вам не пригодится.

… никто не смог внятно объяснить…

зачем нужен systemd.

ну что значит не было? я 25 лет на линухе, ты мне давай расскажи как оно там трудно раньше было.

зачем нужен systemd

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

Сказал как любой дед из гаражей.

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

systemd сделал лучше все. Инициализация лучше (параллельный старт, таргеты, таймеры), split dns лучше (без дрочевания c dnsmasq), логирование лучше (вижу все логи сервиса, а не только куски), супервизия лучше (а не ad-hoc костыли). Короче сплошные плюсы. Ты сейчас начнешь кричать «этого не должно быть в ините11!», а я скажу — должно. И индустрия со мной согласна.

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

Кто его ненавидит? Ты? Почему это важно?

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

Его не надо внедрять, он уже десять лет дефолт.

проблема 1. Супервизор пользовательской сессии в сустемд стартует независимо от композитора (sway в моем случае). Значит, чтобы запускать в нем зависящие от sway пользовательские сервисы, нужно устраивать ручной пердолинг с кастомными таргетами, пробросом переменных окружения и т.п. В случае с s6 все это лишнее - я просто запускаю супервизор напрямую из конфига sway, и все само пробрасывается без дополнительных усилий.

проблема 2, логи. Я привык их изучать в виме. Журналд конечно может их экспортировать, но зачем, когда есть s6-log, который сохраняет все сразу в текстовые файлы? Плюс для фильтрации логов с помощью журналд нужно изучать его опции - дополнительная когнитивная нагрузка.

проблема 3, дыбас. Это дополнительный демон для задачи, для которой в принципе не нужны дополнительные демоны. Плюс для анализа его сообщений опять же нужны дополнительные инструменты. Пёттеринг с друзьями недавно начали что-то подозревать и наоверинжинирили varlink на основе жсон, но когда его повсеместно внедрят, науке неизвестно. Плюс в дыбасе есть собственный механизм сокет-активации, в который опять надо вручную пробрасывать переменные среды.

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

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

проблема 6, сложность. У меня издавна автоматически монтируется сетевая шара, которую окучивает mpd, который запускается в пользовательской сессии. Если насильно отмонтировать эту шару до завершения mpd, то он впадет в состояние овоща с зомби-процессами и подвешиванием процесса выключения. В сустемд есть автомаунтер x-systemd.automount, который долго допускал именно это. Потом его вроде починили, но как отлаживать и исправлять такие баги самостоятельно - я понятия не имею (см. проблему 4). Сейчас у меня заведует монтированием autofs - самый обычный отдельный сервис, настроить правильный порядок запуска и завершения которого - стандартная задача.

…список далеко не полный.

Супервизор пользовательской сессии в сустемд стартует независимо от композитора (sway в моем случае)

Просто запускаешь sway как часть сессии и все. kwin так и работает.

проблема 2, логи. Я привык их изучать в виме.

Ну камон:

$ journalctl -u NetworkManager | vim -

Серьезно? :)))

Предвосхищая вопрос:

:%!journalctl -u NetworkManager

проблема 3, дыбас. Это дополнительный демон для задачи

Это тревожность.

На этом сайте регулярно появляются темы «не могу сделать то и это, помогите запилить юнит».

На этом сайте человек только что не смог вывод команды в stdin VIM отправить.

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

Типичное поведение рациональных людей. Теперь у этого кода есть люди, готовые его чинить. От пердоликов даже альтернативы logind не смогли дождаться, чего уж говорить о поддержке альтеративной libc.

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

Так укажи шару в зависимостях у MPD :)

journalctl -u NetworkManager | vim -

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

В общем нет, не все так просто.

А что если файлы gz? А что если они ротейтились и теперь нужно искать по дате? Если бы ты сказал что «мне эстетически нравится s6 больше systemd», это было бы понятно. Но ты начинаешь защищать вкусовщину «проблемами». Но ведь нет никаких проблем, просто тебе другое нравится. Что самое смешное, мне тоже больше импонирует стиль того же runit, но очень глупо утверждать что

:%!journalctl -u NetworkManager --since='1 hour ago'

как-то менее удобно, чем пердолево zgrep’ом.

А что если файлы gz? А что если они ротейтились и теперь нужно искать по дате?

никакого gz там гарантированно не будет, потому что, как я уже написал, я использую s6-log и полностью контролирую то как происходит ротация (то есть без gzip, да). Место на диске - не проблема, потому что для каждого нужного сервиса четко определен максимальный объем логов. Формат даты я тоже контролирую, и найти нужную в наборе текстовых файлов в папке - уж как-нибудь смогу.

И нет, это не вкусовщина а использование стандартных приемов и способов работы в linux в противоположность бесконечному раскуриванию кучи ad-hoc (то есть больше нигде не применимых) опций, манов и сервисов. Я предпочитаю занимать память рабочими задачами, а не вот этим всем.

Ну ты же раскурил документацию к s6? А там полная срань. Почему им можно делать кучу программ, в которых баз манов не разобраться, а ман к journalctl это преступление против человечества?

Давай напомню, для контекста, сколько бинарников в s6:

# apk info -L s6 | grep '^usr/bin' | wc -l
60

Это БЕЗ execline и s6-ipcserver.

наоверинжинирили

Почему? Это как раз очень годная срань. Это хорошая замена лютому стеку из http/gorpc, с наличием схемы и интероперабильностью между разными языками. Буквально как деды делали, plaintext через сокет, только теперь руками не надо парсеры писать.

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

да не дефолт он еще

Лолшто? RHEL, Debian, Arch, Ubuntu, Oracle, SUSE, Nix. Все мейнстримные дистрибутивы это systemd уже больше десяти лет. Вылезай из криокамеры. Девок, которые родились после выпуска rhel7 с systemd, через пять лет можно будет легально трахать.

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

Это уже какой-то торг с реальностью. Либо systemd есть, либо его нет. Он есть. Он дефолт.