systemd v242

systemctl позволяет перезагрузку в определённую ОС (если загрузчик такое поддерживает)

И какие загрузчики такое поддерживают?

Который в Маках так умеет.

Маках

Прочитал как в «Макаках»

systemd-networkd уже можно использовать в качестве замены ЛММ-мерзкого network-manager?

если имеется в виду переменная next-boot в grubenv, то и груб сможет.

systemd-boot (очевидно) и форк GRUB2 в федоре.

опция –show-transaction

О, вот этого не хватало.

сгенерированные юниты .device (например посредством systemd-fstab-generator) теперь не цепляют соответствующий .mount в качестве автоматической зависимости (Wants=)

O_O а так было раньше? Сколько помню, всегда фигачил обратные зависимости руками, хмм.

Очевидно, маковый загрузчик не соответствует fd.o-шной спецификации, о которой здесь речь :)

Давно можно, но он немного не для этого задуман.

Ну и где теперь хейтеры системд?

Наперегонки ебилды рожают?

Иногда, например, изменение конфигурации (в основном мосты) окукливало вообще все интерфейсы, и сервер приходилось выключать/включать кнопкой (ошибок в конфигурации не было). NM в таком случае не стал бы ломать ВСЮ конфигурацию сети и обеспечил бы линк, если это в принципе возможно.

Я здесь. Сабж не нужен.

Почему, уже объясняли.

systemctl позволяет перезагрузку в определённую ОС (если загрузчик такое поддерживает)

лучше бы он позволял русский языка говорить

Почему, уже объясняли.

Получилось, как это обычно бывает у гуманитариев, довольно невнятно.

Отчего-то опущено вот это: «Добавлена возможность управления поведением systemd-logind через переменные окружения: $SYSTEMD_REBOOT_ TO_FIRMWARE_SETUP, $SYSTEMD_REBOOT_ TO_BOOT_LOADER_MENU и $SYSTEMD_REBOOT_ TO_BOOT_LOADER_ENTRY. При помощи данных переменных можно подключить свои обработчики процесса перезагрузки (/run/systemd/reboot-to-firmware-setup, /run/systemd/reboot-to-boot-loader-menu и /run/systemd/reboot-to-boot-loader-entry) или вообще отключить их (при выставлении значения в false);»

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

Systemd ненужен. Почему? Как говорится

systemd is the best example of Suck.

Т.е. мы имеем потенциальную дыру в безопасности

А вот и security experts подтянулись. Если у тебя есть root, то никакие дыры не требуются. Если нет... Ну, тебе понадобится сначала дыра для размещения этих файлов.

Полностью с тобой согласен. Когда уже закопают этого монстра, который ещё в 2017 расжирел до >1 миллиона строк кода?

https://www.phoronix.com/scan.php?px=systemd-2017-Git-Activity

до >1 миллиона строк кода?

Да, разжирел. Но меня смущает вот еще что:

systemd-boot

Как говорится

Should systemd's PID be changed from 1 to a negative, or imaginary, number? It now exists before the kernel itself, during a bootup.

Эта потеринговская фигня загружается раньше самого ядра...Вот увидите, будет так, как запланировал Red Hat.

Простейший пример (Arch linux): $ reboot Failed to set wall message, ignoring: The name org.freedesktop.PolicyKit1 was not provided by any .service files Failed to reboot system via logind: The name org.freedesktop.PolicyKit1 was not provided by any .service files [quote]Failed to talk to init daemon.[br][/quote]

Как должно быть (старый, добрый Slackware):

$ reboot reboot: must be superuser

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

Эта потеринговская фигня загружается раньше самого ядра...Вот увидите, будет так, как запланировал Red Hat.

Эта потеринговская фигня загружается раньше самого ядра...Вот увидите, будет так, как запланировал Red Hat.

Вы имеете в виду systemd-kerneld ?

systemctl позволяет перезагрузку

случайным образом. Это отлично. :-) Справедливости ради, это в 241. А тут как? :-)

И сам systemd, не systemctl.

systemd-kerneld

Конечно, так и будет. Хорошо, что есть Devuan. Давно им пользуюсь.

Отчего-то опущено вот это: «Добавлена возможность управления поведением systemd-logind через переменные окружения: ...

Наверное оттого, что имена переменных слишком короткие — не солидно как-то для такого серьёзного продукта.

и да, чудовище нужно уничтожать в зародыше.

Почему тогда X.Org до сих пор не уничтожен, если:

дело в лишней сложности, которую несёт идея

?

Двуличность любителей UNIX-like.

Когда уже закопают этого монстра, который ещё в 2017 расжирел до >1 миллиона строк кода?

А когда этого монстра с ~3М строк замшелого кода закопают?

https://www.openhub.net/p/x

Почему тогда X.Org до сих пор не уничтожен

Потому что ты не написал ему замену, очевидно.

Хорошо, что есть Devuan. Давно им пользуюсь.

Какой смысл пользоваться Devuan, если там имеются иксы? То бишь кал и комбайн похлеще того, который устроили в systemd.

Вот когда разработчики Devuan осилят нормальный KISS, а не этот стыд и позор мира UNIX, вот тогда и можно будет пользоваться этим дистрибутивом. А пока, извините, когда у вас в качестве display server используется какая-то блоатварь, то тут хоть systemd, хоть sysvinit – всё это фиолетово.

Какой смысл пользоваться Devuan, если там имеются иксы? То бишь кал и комбайн похлеще того, который устроили в systemd.

От падения иксов ничего серьёзного не падает и система не ломается.

Какой смысл пользоваться Devuan, если там имеются иксы? То бишь кал и комбайн похлеще того, который устроили в systemd.

Какой смысл ловить преступников, если их меньше не становится?

Какой смысл мыться, если завтра снова грязный?

Какой смысл есть, если потом идти в туалет?

И другие насущные вопросы от интеллектуалов ЛОРа в тредах о systemd.

Should systemd's PID be changed from 1 to a negative, or imaginary, number? It now exists before the kernel itself, during a bootup.

Есть такая пословица — не стыдно не знать, стыдно не учиться. Вообще говоря, неизучение тех или иных специализированных вещей (в частности, systemd-boot(7)) для неспециалиста не постыдно. Стыдно быть ламером — ничего не зная по существу вопроса, позволять себе высказывания космической глупости.

NB: я тоже не в восторге от UEFI. Вот только к его изобретению и внедрению Поттеринг имеет такое же отношение, как ты или я.

NB: я тоже не в восторге от UEFI. Вот только к его изобретению и внедрению Поттеринг имеет такое же отношение, как ты или я.

Какое отношение к сабжу имеет UEFI?

UEFI -> Grub -> Linux - всю жизнь так работало, пока кого-то не заел NIH-синдром.

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

Когда уже туда добавят функции ядра?

под шумок «переписали» половину операционной системы

Это плохо. Надо бы переписать всю, кроме ядра. Да и ядро не мешало бы, в некоторых местах.

Какое отношение к сабжу имеет UEFI?

Посмотри, ответом на что был мой коммент и перечти man 7 systemd-boot — увидишь.

Это плохо. Надо бы переписать всю, кроме ядра. Да и ядро не мешало бы, в некоторых местах.

Согласен. Наконец-то перестанут путать продукцию Red Hat и системы GNU/Linux, и вы там окуклитесь в своём уютном RH-мирке.

когда у вас в качестве display server используется какая-то блоатварь

Позвольте вас спросить, а что нужно использовать, в качестве display server?

/me взял попкорн

А если его ребренднуть обратно в gummiboot, то проблема исчезнет?

Посмотри, ответом на что был мой коммент и перечти man 7 systemd-boot — увидишь.

Прочитал, но не понял, что именно я должен увидеть. Что бы ни происходило до старта системы инициализации (или «системного менеджера»), это должно покрываться отдельными спецификациями, и соответственно, нет никакого смысла делать это частью того же самого проекта.

Поэтому приставка systemd- и провоцирует стёб.

И udev пожалуйста обратно.

А если его ребренднуть обратно в gummiboot, то проблема исчезнет?

Боюсь, твой вопрос не по адрсу — я не воспринимаю sd-boot как проблему.

systemd-networkd уже можно использовать в качестве замены ЛММ-мерзкого network-manager?

Зависит от преимущественно используемого типа подключения. Для проводного можно, для беспроводного лучше iwd, для всяких adsl лучше NM.

мы имеем потенциальную дыру в безопасности

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

Опять эти наркоманы воскресили ненужнод? L2TP то вообще прям нуждался в их дури. А как мы жили без монтирования разделов до сих пор не представляю. busctl наконец заработал частично. А уж как всем необходимо по времени менять часовые пояса, что все страдали без этого. А благодаря их особой старательности кому-то из числа наркоманов теперь публичные сервера имен придется настраивать. Это надо еще суметь сделать все ненужное в выпуске для и без того никому не нужной программы.

Что бы ни происходило до старта системы инициализации (или «системного менеджера»), это должно покрываться отдельными спецификациями

Оно и покрывается.

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

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

Поэтому приставка systemd- и провоцирует стёб.

s,стёб,FUD,

Ненужное ненужно ненужному ненужну ненужно

дело в лишней сложности, которую несёт идея системд

Если для тебя даже systemd сложен (несмотря на великолепную документацию, простейший формат конфигов и концептуальную простоту), то IT это определённо не твоё. Попробуй чем-нибудь по проще заняться? Дворников, я слышал, не хватает например.

А что - и пользу людям принесёшь, и голубям лекцию про вред systemd и плоскую землю прочитаешь. Птицы наверняка оценят.

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

Ок, ждём пока в systemd завезут графическую систему и браузер.