А что ещё простому человеку нужно?

Свобода самоиспражнения, а тут повод.

ЗАВИСИМОСТИ. некоторые от них серчают и кушать не могут

создателям твоего дистрибутива приходится тратить на него силы. Вроде всё.

Сам systemd? Лично меня — ничем. А вот то, что оно хочет пожрать и заменить вообще всё собой, особенно там, где это уже работает, вызывает подозрения.

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

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

В бинарных логах смотрел, может там конфиги?

То есть против systemd лоровци выступают лишь потому, что скучно?

не потому, что скучно, а потому что говно

тогда «скучное говно»

Да в чем же?

Оно такое говно?

Сейчас отвтят «в архитектуре», но по существу никто ничего опять не скажет.

stevejobs

тогда «скучное говно», тянущее тонну зависимостей и из-за которого перепиливается структура ФС.

fixed

меньше слушай лоровских троллей, systemd это подарок богов. Увы, автор сегодня ушёл в компанию apple а значит скоро сырцы закроют и программу будут продавать за денюжку в appstore :(. Зато маководам повезло, скоро их ось будет грузиться ещё быстрее.

Увы, автор сегодня ушёл в компанию apple

На календарь глянь.

Это был толстый троллинг.

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

=> В случае частичного повреждения системы сложнее понять, в чем проблема

Это был эльфинг :)

cvs-255

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

А зачем понимать?! Да здравствует windows-way. «Пришло время переустанавливать линупс. Линупс сам не переустановится.»

Я пробовал - грузиться

Куда пробовал?

Ты фотку поттеринга видел? Он же злобный безбородый гремлин. Такие ничего хорошего никогда не сделают.

Сейчас отвтят «в архитектуре»

All-in-one black box.

вроде у него вообще всё лежит /usr/lib/systemd и /etc/systemd - по крайней мере в генте

Забаньте уже этого школьника. Пусть у него вместо ЛОРа tsya.ru открывается.

Ну можно было просто допилить initNG.

Какие, блин, зависимости?
В гентушном ебилде обязательных всего шесть: http://www.gentoo-portage.com/sys-apps/systemd/Dep#ptabs
Все шесть и так есть в любой полноценной системе.
Что он пытается собой заменить? Журнал? Никто не мешает использовать syslog c systemd. Consolekit? Разработчики consolekit так и не осилили его основные функции - отслеживание залогиненных пользователей, распределение периферийных устройств между их рабочими местами и работу в связке с policykit для обеспечения их изоляции: http://wiki.gentoo.org/wiki/Multiseat#Bypassing_policykit А когда появился systemd-loginctl, они просто радостно забили на свое поделие.
Просто привыкшие к inittab консерваторы не смогли прочесть несколько коротких манов, понять концепцию target'ов и instantiated services и теперь брызжут слюной при каждом упоминании Поттеринга.

Чего стоит как минимум зависимость от dbus, который в существующих системах лежит в /usr.

Какие изменения?
В /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.

Есть три варианта:
-зависимость от D-Bus ради возможности предварительно создавать адреса сервисов на шине и стартовать их одновременно/стартовать сервисы, когда что-то запрашивает их через D-Bus - т. е. для ускорения запуска и рационализации использования ресурсов;
-отказ от приемуществ, которое дает интеграция с D-Bus;
-выкинуть D-Bus, сломать все и начать делать другой IPC который, возможно, устроит всех.
Угадай, какой из этих вариантов оптимален для абсолютного большинства аудитории.

Есть три варианта

Можно ещё запилить D-Bus в ядро. Кроме шуток, такие разговоры ходили года два назад.

Можно ещё запилить systemd в ядро.

fxd

Потому что, его сделал Поттеринг

Есть ещё один вариант - самый оптимальный: выкинуть systemd, journald, поттеринга и обрести счастье.

Как обычно, попытка привести технические аргументы натыкается на возражения типа «это предлагает/делает/поддерживает Поттеринг НЕНАВИСТЬ НЕНУЖНО ВЫКИНУТЬ ЗАКОПАТЬ ОБРАТНО СКИНУТЬСЯ НА КИЛЛЕРА»

Кстати есть где-нибудь нормально написанной инфы про systemd (желательно тезисно). Для чего он нужен и какие преимущества он дает?

Кстати есть где-нибудь нормально написанной инфы про systemd (желательно тезисно). Для чего он нужен и какие преимущества он дает?

Написано просто дофига. Надо немного погуглить.

Вообще, критиковать SysV стали почти сразу (насколько я помню, первым, кто указал на вопиющие недостатки, был DJ Bernstein, который написал дедушку systemd еще хез когда), но в линуксе и без того проблем было навалом, и никто исправлять проблемы не стал. Запускается, и ладно! Однако, проблемы так и остались, и непонятно, почему народ тут так неровно дышит, когда видит древний init.

В макоси, кстати, доказав высокий уровень специалистов там работающих, сразу-же внедрили свою приблуду для запуска сервисов, вместо имеющейся наколеночной поделки, которую можно было своровать из BSD. Я про launchd, на который убунту даже переходить хотела. И, кстати, это типично для коммерческих юниксов, где также используются свои выделенные компоненты (smf, например). Насколько я понимаю, примитивный init + мешанина скриптов, написаных на shell, используется лишь в Linux и в совсем уже устаревших операционных системах семейства BSD.

На сайте у него все написано. Rethinking PID 1 - кратко, тезисно про концепцию и приемущества.
Systemd for Developers #1, #2 - подробнее про эту самую сокет-активацию.
Вкратце: если в OpenRC/Upstart сервисы 1 и 2 зависят от сервиса 3, то сначала будет запущен сервис 3, а потом одновременно 1 и 2. В systemd же, если сервисы взаимодействуют через сокет ил D-Bus (99.9% случаев), будет создан сокет/идентификатор на шине сервиса 3, как будто он уже запустился, после чего одновременно будут запущены все три сервиса: http://0pointer.de/public/parallelization.png - в основном за счет этого он такой быстрый.
Ну, и еще ряд приятных вещей вроде привязки запуска/останова сервисов к событиям, в частности, входящим соединениям (эдакое обобщение inetd), подключению/отключению устройств, отображения лога при выводе информации о состоянии сервиса, cgroups (можно надежно убить все порожденные сервисом процессы при его остановке, как бы они не форкались, можно нагрузку балансировать), мультисита и т. п.
Для dbus-активации ему нужен (внезапно) D-Bus, для обработки событий устройств - udev, для вывода лога - своя подсистема журналирования. От этого у консерваторов СИЛЬНЕЙШИЙ БАТТХЕРТ и НЕНАВИСТЬ К ПОТТЕРИНГУ. Прямо как у ПГМнутых в 18 веке, когда Петр заставил всех бриться, покончил с церковным бардаком и запилил Святейший Синод.

Я про launchd, на который убунту даже переходить хотела.

Собственно, идея сокет-активации в systemd позаимствована оттуда. В некотором роде, systemd - адаптация launchd к реалиям Linux (другое userspace IPC, другой менеджер устройств).

Научи systemd работать с отдельным /usr без initramfs. Когда сделаешь, приходи, сможем аргументированно пообщаться.

initramfs давно используется во всех нормальных дистрибутивах. Самоделки не рассматриваем.

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

А что, у нас уже /usr/bin/vim и /lib/ld-linux.so.2 должны быть скриптами?

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

Ничуть не сложнее, чем с любым другим инитом.

Я ваш initramfs в гробу видал. Вместе с поццерингом и сотоварищами. Там же новый udev, systemd, journald и иже с ними.

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

Работает из коробки. Или нужно устроить публичное чтение вслух configure --help?

Да что ты, а как он подцепит dbus, который на отдельном /usr?!

dbus, который на отдельном /usr

ССЗБ.

Кстати, даже весь D-Bus не надо класть в корень — достаточно одной маленькой либы.

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

Или ты мне ради нафиг не нужной поделки предлагаешь пересобрать dbus?!

Без dbus либ оно не запуститься совсем. А либы эти лежат на /usr. Так что ничего оно (systemd) не умеет, зато создаёт кучу лишнего гемороя.

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

Без dbus либ оно не запуститься совсем.

Чем так плох systemd? (комментарий)

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

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

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

Так что ничего оно (systemd) не умеет

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