systemd 255

Из man systemd-bsod

systemd-bsod.service is used to display a blue screen which contains a message relating to a boot failure, including a QR code which can be scanned to get helpful information about the failure.

В смысле «у вас было >10 лет переписать всю эту скриптоту, осталось пара месяцев».

а планируется ли завезти в systemd-networkd детектирование состояния линка (как в ifplugd)?

вообще, systemd в основном бесит именно такими мелочами. Из другого примера – это отдельные окружения для каждого сервиса. Я как-то долго вдуплить не мог, почему php-fpm возвращал ошибку при попытке проверить на записываемость симлинка в /usr/share (да-да, в арче именно так пакуют веб-приложения), хотя права на запись того, куда этот симлинк указывал, у процесса были.

Ну так я для кого статью написал?

У вас в статье написано вот это:

дочерний процесс не может (согласно стандарту POSIX.1) вызывать
не async-signal-safe функции до вызова exec

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

Т.е. до этой новой версии весь systemd работал на UB.

Я не уверен, что системд вызывал форк из мультитридового процесса.

Уровень скилла программистов systemd зашкаливает.

Пруфы будут?

А в чем юзкейз отдельного /usr?

Во времена дорогих маленьких SSD было актуально сунуть основную систему (/bin, /sbin, /boot) на SSD, а /usr со всяким жирным софтом на вертушку.

Правильный вопрос: нахрена /usr вообще существует до сих пор?

Потому что это Unix System Resources.

Ты дома вещи беспорядочно по квартире не разбрасываешь же?

А что надо вместо?

\Windows\System32

Вот эти все каталоги, которые в /usr - просто перенести в корень.

Потому что это Unix System Resources

Это не аргумент. Юникс вообще рипнулся.

Класс, обожаю срач. В хомяке срача мало, давайте еще в корне насрем.

Че ты ж тогда с SUS-совместимой системы мне отвечаешь, а не с какой нибудь kolibri.

FHS это и есть срач. Дублирование каталогов bin, lib и прочих - тоже срач. При том что смысла в этом абсолютно никакого.

Какое дублирование. Куда. Где.

Потому что мне нравится Линукс, а на Юникс мне плевать.

/bin и /usr/bin

/lib и /usr/lib

Впрочем, первые уже давно стали симлинками на вторые. Хотя надо бы наоборот, перенести вторые в первые и удалить /usr нахрен как недоразумение.

Мне нравится Ауди, а на автомобили мне плевать.

Фракталл - легенда.

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

Или опять будут только чувственные ощущения?)))

Ага, можно еще твои вещи на лестничную клетку вынести. Квартиры - это недоразумение.

Неверная аналогия. Автомобили - это ОС как таковые.

Я так понимаю, рациональных аргументов в пользу /usr у тебя нет.

А у тебя они есть? =)

Это же твоё предложение, ты и аргументируй.

Бритва Оккама

В usr как минимум есть share, для которого в FHS нет альтернативного места от корня. Это бы сломало совместимость с огромным количеством софта, Так что сделали максимально безболезненно.

Вот ею недоразумения вроде /bin в корне Поттеринг и вырезал.

Осталась только ссылка для совместимости.

Правильно, нефиг каталогам /bin и /lib делать в корне, нужно перенести их в /windows, ой то есть /usr.

Правильно, нефиг каталогам /bin и /lib делать в корне

Ого, как ты догадался?

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

Зачем?

Затем, что это системный менеджер, а не тупо инит.

Не надо?

Во времена дорогих маленьких hdd не получалось упихать всю систему на один диск, поэтому в /usr положили софт, не требующийся при загрузке, home и прочее ненужное.

в явном виде вы не сказали

Любая программа, вызывающая fork становится мультипоточной

Пруфы будут?

doing work after fork and before exec is against glibc’s supported case for several APIs we call

we call

Однако systemd начало выходить за рамки просто системы инициализации и стало «брать» на себя гораздо больше.

Да, потому что это системный менеджер. В чем проблема-то?

Unix System Resources

Прошу прощения, что влезаю в разговор, но у меня есть сопутствующий вопрос. А куда положено складывать программы и настройки для них, которые предназначены для всех пользователей? (я просто всегда наивно думал что такие вещи как раз в /usr и стоит сваливать)

да их прямо тут пишут:

Теперь монтирование отдельного раздела /usr/ поддерживается только на этапе initramfs.

sapienti sat

А проблема-то в чем? Зачем тебе /usr на отдельном разделе в 2023 году? Это была фича сомнительной нужности даже в конце нулевых, не говоря уже про современность.

Какие это проблемы вызывает у тебя, кроме невозможности иметь /usr на отдельном разделе?

sapienti sat

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

Любая программа, вызывающая fork становится мультипоточной

Чего?

doing work after fork and before exec is against glibc’s supported case for several APIs we call we call

glibc-supported case. В глибсе багов может быть сколько угодно. Это ни коим образом не доказывает ваш тезис о низкой компетенции системдшных кодеров. А о том, что глибс наркоманы пишут, и без вас известно.

mumpster

Я так понимаю, что клоунский смайл - это твой лучший аргумент? Кто бы мог подумать. Можешь еще и под этим каментом свою «роспись» оставить.

Дожили. Уровень технической дискуссии май эсс.

Программы — в /usr, настройки — в /etc

Теперь монтирование отдельного раздела /usr/ поддерживается только на этапе initramfs

И что тебя смущает? Если тебе кровь из носу как нужно сделать /usr отдельным разделом – добавляешь хук в конфиг используемого тобой генератора initramfs и не сношаешь окружающим мозги. Но я категорически не понимаю, нахрена это нужно

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

Теперь монтирование отдельного раздела /usr/ поддерживается только на этапе initramfs

И что тебя смущает? Если тебе кровь из носу как нужно сделать /usr отдельным разделом – добавляешь хук в конфиг используемого тобой генератора initramfs и не сношаешь окружающим мозги. Но я категорически не понимаю, нахрена это нужно

Что, без initramfs теперь уже никак? Прогресс, однако.

Что, без initramfs теперь уже никак? Прогресс, однако

Зашифрованный рут или рут, монтируемый по nfs, без initramfs тоже никак. Предлагаю совершить тебе ритуальный суицид. Как несовершенен мир, в самом-то деле

Не говоря уже о том, что ты до сих пор не объяснил, нахрена нужен /usr на отдельном разделе

Нет системного реестра. Системный менеджер есть - реестра нет.

Его кривляния еще хоть как-то можно было бы понять, если бы он смог объяснить, зачем нужна суходрочка с отдельным /usr в 2023 году и почему эту проблему нужно решать средствами инита, а не initramfs. Но без технических аргументов это выглядит как мантра. /usr на отдельном разделе должен быть, потому что так сказал Великий Авторитет

Вот эти все каталоги, которые в /usr - просто перенести в корень.

Можно, все равно дистры линукса похожи на помойку. Но для более целостной системы вполне разумно держать отдельный /usr с пользовательским окружением. Даже можно было бы несколько разных usr иметь параллельно.

Тебе зачем без initrd грузится? Чтобы что? Чтобы не запускать fsck на корне? Только не говори, что можно запускать его на ридонли, потому что на самом деле нельзя.

Да нету никакого авторитета, им просто хочется, как в старые добрые.

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