Моя Gentoo хочет systemd

Вопрос: что курили разработчики?

Уточнение к вопросу: разработчики конкретно чего?

upower поставь из тестовой ветки

eselect profile list

Там будет профиль KDE без systemd

То же самое, зачем-то захотелось ему поставить. Проблема, видимо, в udev. Кстати, интересно стало - пакет безальтернативен или его есть чем заменить?

Ставь upower-pm-utils. upower-0.99 требует systemd.

Проблема в том, что в ебилде upower убрали флаг systemd, и теперь systemd требуется всегда.

У меня не требует. И вообще такой проблемы не наблюдаю. 0.99.0, правда

Скажи спасибо разрабам upower, выпилившим поддержку pm-utils в пользу org.freedesktop.login1 (читай: logind. Да, оно занимается ещё и этим).

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-power/upower/upow...

Правильно сделали. pm-utils — костыль.

Вот уроды

Это systemd - костыль.

А смысл?

Правильно сделали. pm-utils — костыль.

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

Моя Gentoo хочет systemd (комментарий)

Спасибо! Теперь это г. больше не лезет в мою Gentoo. Но надолго ли?

Ок.

До ввода kdbus в эксплуатацию.

Потому что только в этой системе инициализации сподобились написать некостыльное решение. Как известно, на безрыбье любое земноводное становится рыбой (хотя я считаю, что systemd — вполне себе рыба, т. е. сделан достаточно качественно).

Чем systemd лучше openrc?

На openrc не смотрел, поэтому точно не скажу. А чем хуже?

/* troll mode: лучше тем, что за systemd в техническом комитете Debian отдали четыре голоса, а за openrc — ноль. */

Тем, что openrc умеет всё, что мне нужно. Зависимости, параллельный запуск, единообразная настройка сервисов без необходимости редактировать инитскрипты. То есть, есть каталог /etc/conf.d, где лежат конфиги сервисов. Можно поменять зависимости без необходимости править инитскрипт. При перезапуске сервиса перезапускаются все сервисы, зависящие от него. Куча разных настроек. И он просто работает. И при этом не пытается собой заменить полсистемы.

«openrc умеет всё, что мне нужно» — не аргумент к тому, что openrc хуже systemd. Тем более что всё описанное есть и в systemd.

Кстати, а где это systemd пытается заменить полсистемы? Или несчастный networkd сам прописывается в список запускаемых сервисов, а по ночам crontab автоматически конвертируется в timer-юниты?

Чем systemd лучше openrc?

Тем, что в systemd интегрирован udev, ConsoleKit, PolicyKit, syslog и многое другое… причем почти все элементарно отключается USE флагами ежели оно тебе нэнада.

А самое главное в systemd все это запускается таки параллельно в отличие от

https://en.wikipedia.org/wiki/OpenRC

- Parallel service startup (optional, in development)[3]

А чем хуже?

Тем, что не вносит ничего полезного (по крайней мере для десктопа), но вносит много неудобств.

Тем, что в systemd интегрирован udev, ConsoleKit, PolicyKit, syslog и многое другое… причем почти все элементарно отключается USE флагами ежели оно тебе нэнада.

Я спрашивал, не чем systemd хуже, а чем он лучше.

Кстати, а где это systemd пытается заменить полсистемы?

Моя Gentoo хочет systemd (комментарий)

новое решение работает только на одной единственной системе инициализации

В дебиане при обсуждении тоже некоторые ныли, что части системд от системы инициализации не отцепить. И что, месяца не прошло, как всё от системы инициализации отвязали и теперь non-init-systemd-stuff спокойно работает при любой из четырёх систем инициализации (sysvinit, upstart, systemd, openrc).

Я за бан

Тем, что openrc умеет всё, что мне нужно.

Ок. А теперь иди и убеди всех остальных разработчиков кедов, гнома и т.д. в том что openrc им гораздо нужнее и вкуснее чем вражеский systemd. До тех пор разговаривать с тобой не о чем.

Логин? Занимается отслеживанием событий с девайсов? Что это за наркомания?

Тем, что в systemd интегрирован udev, ConsoleKit, PolicyKit, syslog и многое другое

Иными словами все то же. Да, и я правильно понял, что теперь я не могу обновить отдельно ConsoleKit, мне придется весь комбайн обновлять?

А самое главное в systemd все это запускается таки параллельно в отличие от

Это да. Но что-то только это не вызывает эйфории. Иными словами недостатки пока перевешивают.

Полезное я прямо сейчас тебе назову: у меня smbd, sshd и cupsd запускаются автоматически и по необходимости, а не висят в памяти постоянно. И никаких xinetd не нужно. А ещё очень удобно смотреть логи за указанный период от указанного бинарника. А ещё logrotate настраивать не нужно, достаточно написать в конфиге, что под логи отведён один гигабайт места. Как раз в десктопе, где не нужна убер-гибкость cron, syslog, xinetd и так далее, это всё очень приятно.

А в чём неудобства, кроме того, что (о ужас) надо один раз читнуть манцов?

Я спрашивал, не чем systemd хуже, а чем он лучше.

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

А где здесь, собственно, «заменить»? Перечислены факты интеграции.

Иными словами все то же. Да, и я правильно понял, что теперь я не могу обновить отдельно ConsoleKit, мне придется весь комбайн обновлять?

if [[ "весь комбайн" eq systemd ]]; then
echo "Да"
else
echo "Нет"
fi

Это да. Но что-то только это не вызывает эйфории. Иными словами недостатки пока перевешивают.

Это твои личные проблемы а на поверку любая из них {openrc/systemd/upstart} (и да в gentoo есть и upstart ! при желании…) работает без проблем а баги как раз вылазят именно из-за того что отдельные пациенты упороты четко на идее „openrc и больше ничего кроме него“

новое решение работает только на одной единственной системе инициализации

а что теперь будет с ubuntu? Там же еще не systemd?

я просто поставил laptop-mode-tools и глобально выключил флаг upower. Кедам он больше не потребовался. (Надеюсь я не отстрелил себе ногу?)

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

Если ты про использование systemd API, то это даже хорошо, т. к. API у них вполне приятные (можно реимплементить). Единственное — хотелось бы, чтобы не было ситуации с 14 стандартами (см. xkcd).

Если бы некостыльный logind был бы универсальным решением, не зависящим от systemd и всего, что в него напихано, то таких возмущений бы не было.

Текущая реализация зависит от systemd, т. к. там есть, чему зависеть. Как известно, функционал из ниоткуда не берётся...

У меня upower-0.99, и никакого systemd нет. Может, потому что у меня стоит eudev вместо куска systemd?

Это твои личные проблемы

Давай ты не будешь говорить какие у меня проблемы, я не буду говорить куда тебе пройти, ок?

и да в gentoo есть и upstart ! при желании

Спасибо, КО.

отдельные пациенты упороты четко на идее „systemd и больше ничего кроме него“

fixed
Нормальные люди взвешиваю все «за» и «против» и принимают для себя решения. А не жрут что дают, а потом на вопрос «а почему так?» начинают лихорадочно гуглить «а правда, а чем лучше?» или оправдываться глупыми отмазками.

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

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

Я, собственно, пару месяцев назад спросил об этом самого Леннарта. Писал, правда, про journald, но это не так важно. Ответ пришел примерно такой: мы не будем обеспечивать поддержку выпила journald, потому что он является монолитной частью systemd, и что бы это сделать, пришлось бы переписывать половину кода. Напомню, что journald - система ведения логов. Отличный показатель качества кода! Не сомневаюсь, что и с logind у них похожая ситуация.

Потому что «меньшей». Управление питанием в logind должно взаимодействовать с сессиями пользователей, а те — с механизмом cgroups.

journald как раз имеет полное право быть неотключаемым. Это не система ведения логов, это система сбора логов. Так или иначе, частью функционала systemd является сбор сообщений от всех запущенных демонов. Я думаю, если бы этот функционал был реализован прямо в PID1, это не понравилось бы людям ещё сильнее, и правильно (потому что повышается риск падения PID 1). Следовательно, этот код вынесен в отдельный процесс, но логически функционал по сбору логов всё равно является частью systemd.

А что с логами делать — сохранять своими средствами, отдавать syslog'у или вообще игнорировать — вполне себе настраивается.

[I] sys-fs/udev
     Available versions:  208-r1^t 212-r1^t (~)213^t **9999^t {acl doc +firmware-loader gudev introspection +kmod selinux static-libs ABI_MIPS="n32 n64 o32" ABI_X86="32 64 x32"}
     Installed versions:  213^t(12:02:24 AM 05/31/2014)(acl firmware-loader gudev kmod -doc -introspection -selinux -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_X86="32 64 -x32")
     Homepage:            http://www.freedesktop.org/wiki/Software/systemd
     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

раньше тоже всё ок было. кроме sys-fs/udev-210, там всё сломали. и если забыть про неработоспособность с /usr на отдельном разделе(кому это может понадобиться?).

В systemd хороший код и совершенно приемлемая команда разработчиков. Дело в том, что некоторые вещи гораздо проще сделать неотключаемыми, но всё равно PID 1 там достаточно маленький.

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

Яйца, одна корзина, все дела.

Когда у тебя протухло одно яйцо (sysvinit ->openrc), ты можешь его выкинуть и заменить на другое. Когда у тебя протухла курица (леннарт), несущая яйца, интегрированные друг в друга, становится сложней.

Нужно не API, а метод интеллектуального анализа конфигурации системы, чтобы софт мог адаптироваться под разные системы. Для этого со стороны системы нужно API на интроспекцию, а для со стороны софта - анализаторы. Но нет, быдлокодеры нафигачат апи и прибьют к нему все гвоздями. А когда систему нужно будет запустить на квадракоптере, все рухнет нафиг с out of memory. В качестве лечения предлагаю пожизненный эцих с гвоздями.

Плохо что теперь производители софта и железа будут ориентироваться на systemd.

Плохо для кого?