systemd создаёт лишний геморой => systemd на помойку

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

gentoo_root

1. Ничего не мешает положить одну либу в /lib.

лишний геморой при обновлении

gentoo_root

2. Ничего не мешает собрать systemd статически с libdbus.

лишний геморой при обновлении. Нужно каждый раз пересобирать systemd после обновления dbus (hint: исправление ошибок и уязвимостей)

gentoo_root

3. У нас половина софта в корне зависит от либ в /usr.

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

Чем так плох windows?

sphericalhorse

Чем же так плох windows для простого человека? Я пробовал - грузиться. Доволен. В подробности не вникал. А что ещё простому человеку нужно?

fixed

SunOS

используется лишь в Linux

ну да. а давно ли солярка оказалась от «мешаины» - не напомните?;)

толсто

gentoo_root

никто не заставляет

А зачем так рьяно переубедить тогда пытаетесь?!

Это systemd - толсто, а поттеринг толстый тролль.

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

O_o

Тем же, чем плохи все остальные лишние сущности.

Научи systemd работать с отдельным /usr без initramfs.

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

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

Чего стоит хотя бы service supervision.

А это что такое?

А это что такое?

Слежение за сервисами. Главная проблема SysV.

... В /etc/systemd/system и /usr/lib/systemd/system могут существовать директории вида <имя_уровня>.target.wants, внутри которых - симлинки на сервисы, которые должны быть запущены для достижения уровня. Если что-то связанное с изменением кинфигурации консолей - сервис консоли является инстанцируемым, т.е. его файл /usr/lib/systemd/system/getty@.service, а симлинки на него должны именоваться getty@<терминал>.service, например, getty@tty1.service - так определяется, на каком терминале он запустится. Дефолтный уровень - определяется симлинком default.target. Предполагается, что содержимое /etc/systemd/system может изменяться администратором и имеет приоритет перед дефолтным из /usr/lib/systemd/system.

Упаси Патрег!!! Слава богу есть дистрибутивы где этот усложнённый комбайнизм не пройдёт.

Не совсем понял. Это так называется его группировка процессов в cgroups?

Это когда инит не просто запускает демон, но и следит за его дальнейшей работой (например, перезапуская при падении или повисании). Ведь это есть в сабже? Если нет, то проку от него мало.

Мы поняли, ты любитель попередёргивать. Как уже написал твой чуть более адекватный товарищ: «или они тебе не нужны — не пользуйся»

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

Все просто и логично, почти как в гентушном Baselayout/OpenRC. Даже подобие инстанцируемых сервисов там тоже было - симлинки net.<имя_интерфейса> на сценарий net.lo для инициализации сетевых интерфейсов. Ну, еще в systemd вместо уровней выполнения используется чуть более абстрактная концепция «состояний» - система может находиться в нескольких состояниях одновременно, состояние может требовать не только запуска набора сервисов, но, к примеру, готовности каких-нибудь устройств.
В чем усложнённость? В чем комбайнизм?

А, понятно. Да, есть, конечно.

Все просто и логично

Просто и логично в crux, если ты видел их init-систему, slackware, возможно arch.

В чем усложнённость? В чем комбайнизм?

Много ненужных сущностей. Зачем они нужны простому человеку?

выкинуть systemd, journald, поттеринга и обрести счастье.

pulseaudio забыл

Он вроде как стал более менее сносно работать.

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

Еще напрягает непереносимость, но кто БСД виноват что они такие слоупоки, и не могут реализовать cgroups?

В остальном, ИМХО, отличный софт.

> который в существующих системах лежит в /usr.

Пример современного дистра, который грузится без /usr, в студию. ЛФС не предлагать.

загрузочные скрипты на С

WUT? Модули systemd не на С.

bash, vi и ld-linux можно засунуть в initrd, так что если система не загрузится, при загрузке монтировать initrd как корень и запускать bash, монтировать раздел диска в /mnt и править на нем конфиги.

Простому человеку не нужны ни сервисы, ни уровни выполнения, ни отдельный /usr. Ему нужна быстрая загрузка, и systemd позволяет ее получить.
В слаке вроде скрипты /etc/rc.d/rc.<уровень>. В текстовом файле может быть все что угодно, как просто и надежно реализовать включение/выключение запуска сервиса из GUI/при установке пакета? Или «простому человеку» все это не нужно?
В crux, насколько я вижу, вообще примитив, никаких уровней выполнения нет, просто переменная SERVICES в конфиге /etc/rc.conf, в которой через запятую перечислены скрипты, которые стартуются при включении системы и останавливаются в обратном порядке при выключении. Ты еще autoexec.bat из MS-DOS приведи в пример, лол. Идеальная система инициализации для «простого человека».

bash, vi и ld-linux можно засунуть в initrd, так что если система не загрузится, при загрузке монтировать initrd как корень и запускать bash, монтировать раздел диска в /mnt и править на нем конфиги.

Это как-то должно конфликтовать с systemd?

Простому человеку не нужны ни ..., ни ..., ни .... Ему нужна быстрая загрузка

Ох лол. Быстрая загрузка да. xD

как просто и надежно реализовать включение/выключение запуска сервиса из GUI/при установке пакета?

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

Или «простому человеку» все это не нужно?

видишь, ты и сам всё знаешь.

В crux, насколько я вижу, вообще примитив, никаких уровней выполнения нет

Плохо смотрел. Там три уровня исполнения (всего лишь). Классно.

Ты еще autoexec.bat из MS-DOS приведи в пример

Ты ныряешь либо в примитивизм либо в комбайнизм)) Дуалист, трудно жить наверное!? :D

Какой там C, там текстовый формат systemd.unit. Вот ман по нему:
http://www.freedesktop.org/software/systemd/man/systemd.unit.html
Параметры, специфичные для описания сервисов:
http://www.freedesktop.org/software/systemd/man/systemd.service.html

Там три уровня

четыре, пардон муа :)

как просто и надежно реализовать включение/выключение запуска сервиса из GUI/при установке пакета?

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

Вглядись:

при установке пакета

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

Gentoo

Ему нужна быстрая загрузка

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

как просто и надежно реализовать включение/выключение запуска сервиса из GUI/при установке пакета?

pre/postinst скрипты?!

К.О.?
Речь о том, как надежно реализовать в pre/postinst скриптах внесение изменений в скрипт, в котором в принципе может быть намешано что угодно.

shatsky

внесение изменений в скрипт

этим занимаются мейнтейнеры и вообще не понятно причём здесь система инициализации.

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

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

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

и запускать/выключать сервисы?)) И он еще должен знать какой сервис за что отвечает. И он не будет жмакать OK-OK-OK-NEXT а пойдёт гуглить и читать маны.

Спасибо КО. Но это даже не аргумент)

Помню в zenwalk была простая графическая система включения/выключения сервисов. Задолго до появления systemd, и, при этом, суть работы init-системы так проста, что самому на коленке можно накалякать какую хочешь КНОПКУ-GUI-комбайн.

shatsky

еречислением в текстовом файле или созданием/удалением симлинков.

самое интересное, что systemd тут тоже не при чём. И то, и другое было до него.

у systemd бинарные файлы вместо скриптов

Инфа 146%ая?

http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdJustRunStuff

Простому человеку не нужны ни сервисы, ни уровни выполнения, ни отдельный /usr. Ему нужна быстрая загрузка, и systemd позволяет ее получить.

Так защитил, что лучше б обругал ))

При чем тут простой пользователь и система инициализации?

systemd как раз очень интересен тем, кому нужна гибкая настройка загрузки.

Система целей вместо 5 фиксированных уровней и бардака в rc.d/ позволяет гораздо четче описать какие условия нужны для запуска каждого конкретного сервиса. При чем всё это записывается в простых стандартизированных конфигурационных скриптах, в отличие от init.d/*, которые легко и создавать, и анализировать.

Для нормального сисадмина, который всё-таки прочитал в оригинале, чем плох отдельный /usr, systemd - это удобный, эффективный и очень качественно документированный инструмент.

Недавно нужно было быстро внести изменения в /etc/inittab, так в системе оказалась systemd. Так и не нашёл, где теперь находится всё, что было в /etc/inittab.

куда катится лор...

$ cat /etc/inittab
# inittab is no longer used when using systemd.
#
# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.
#
# Ctrl-Alt-Delete is handled by /etc/systemd/system/ctrl-alt-del.target
#
# systemd uses 'targets' instead of runlevels. By default, there are two main targets:
#
# multi-user.target: analogous to runlevel 3
# graphical.target: analogous to runlevel 5
#
# To set a default target, run:
#
# ln -s /lib/systemd/system/<target name>.target /etc/systemd/system/default.target
#

https://www.google.com/search?btnG=1&pws=0&q=systemd inittab

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

Да, потому то у systemd бинарные файлы вместо скриптов.

Вот всё-таки мне интересно, что вы понимаете под скриптами в данном случае и какие именно бинарные файлы systemd нужно править? Пример такой задачи?

бардака в rc.d/

Вот не надо.

гораздо четче описать какие условия нужны для запуска каждого конкретного сервиса

LSB headers чем-то хуже?

alpha

куда катится лор...

Мне эта простыня ничего не дала.
Скитания по /etc/systemd - тоже.