Ну вот-с, приплыли

аааа, Апокалипсис близко :)

Нажимай 'Y'.

Да я уже и PKGBUILD глянул, просто перенесли udev в этот пакет, но как выглядит-то :)

Слабак.

Вот вам и KISS. Хотя не удивлюсь, если вдруг окажется, что сабж отныне соответствует этой идеологии :D

Дык, про слияние кодовой базы давно писали. Главное, что мейнтейнеры догадались всё это в отдельный пакет выделить.

Вот вам и KISS.

Сам systemd оно не тянет, всё хорошо.

До этого были отдельно systemd-tools и udev, сейчас наоборот консолидировали.

Сам systemd оно не тянет

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

всё хорошо

Ага, повторяй чаще эту фразу, оптимизм полезен для здоровья :)

Следующее обновление: установить systemd (Y/y)? _

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

Думаю, пока дебиан и ко сопротивляются этой гадости, разрабы не будут привязывать к ней udev намертво. В крайнем случае будут дебиановские патчи или форк, которые те же мейнтейнеры арча могут спокойно использовать.

дебиан и ко сопротивляются

Разве? Сопротивляется, AFAIR, только Марк.

А в чем противоречие KISS?

Разве?

А разве нет? Systemd в Debian не будет до тех пор, пока он не будет работать под FreeBSD. Вероятно, это означает никогда.

не будет по умолчанию до тех пор,

fix

Разве? Сопротивляется, AFAIR, только Марк.

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

Это печально.

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

Да, но я думаю, все поняли мою фразу правильно. В репозиториях есть несколько разных систем инициализации, но все они, включая systemd, могут использоваться либо минимально из коробки, либо полноценно после большого количества ручной работы, как правило с нарушением целостности базовой системы (dist-upgrade вернёт sysvinit на место). Поэтому для большинства пользователей этих систем в Debian как бы и нет :)

Bloatware.

Может, расскажешь, какая ещё современная система инициализации не является, как ты говоришь, «bloatware»? А то они все умеют почти всё то же самое, чт и systemd.

Может, расскажешь, какая ещё современная система инициализации не является, как ты говоришь, «bloatware»?

SysV Init, Runit, daemontools, BSD Init, Minit.

А то они все умеют почти всё то же самое, чт и systemd.

Ведут бинарные логи, завязаны на D-Bus, претендуют на функции udev? А мужики-то и не знали…

А мне идея systemd вполне устраивает. Мне давно подобной штуки не хватало.

Ключевое слово: «современная».

А по каким критериям они не являются современными? По пунктам, пожалуйста :)

Сам он и меня не пугает. А вот то, что он всё хочет вобрать в себя и ещё какие-то бинарные логи ввести, как-то не очень.

(Y/y)?

Лучше так:

(Yes/okay)?

не написаны поццерингом, очевидно же ) Потому и не современные

Управлять приоритетами они не умеют, планированием не занимаются, разруливать процесс загрузки тоже не могут. Даже распараллеливания нет.

Управлять приоритетами они не умеют

Это ты так коряво обозначил cgroups? Ну во-первых, нужность этого ещё не доказана. Во-вторых, init не обязан этим заниматься.

планированием не занимаются

Каким планированием? Снова маркетинг? Нет, cron и at не нужно интегрировать куда-то там, они и сами работают нормально.

разруливать процесс загрузки тоже не могут

WTF? Я на техническом ресурсе или это форум домохозяек?

Даже распараллеливания нет.

Серьёзно?

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

Если что, под приоритетами подразумевалась, внезапно, приоритетность запуска одного процесса над другим, под планированием, ясное дело, cgroups, а под управлением процессом загрузки, очевидно, управление процессом загрузки(systemd может без участия пользователя по определённому условию прибивать процессы или перезапускать их необходимое количество раз, но откуда бы тебе это знать, на ЛОРе же не было).

Ну во-первых, нужность этого ещё не доказана.

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

Серьёзно?

Ну и сколько из перечисленных систем умеют параллельную загрузку из коробки? Одна-две?

приоритетность запуска одного процесса над другим

Хватит говорить языком домохозяек. Nice или что?

systemd может без участия пользователя по определённому условию прибивать процессы или перезапускать их необходимое количество раз, но откуда бы тебе это знать, на ЛОРе же не было

Ох ты ж блин… Деточка, это называется service sepervision, и есть практически везде, кроме SysV Init (в сильно покалеченном виде) и BSD Init.

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

Действительно, зачем жить без изменяющих сознание веществ? Продолжай их принимать, результат доставляет.

Ну и сколько из перечисленных систем умеют параллельную загрузку из коробки?

SysV Init (в современных дистрибутивах, да), Runit. Есть ещё OpenRC и Upstart. Это только те, про которые я знаю точно.

Леннарт, перелогиньтесь.

Хватит говорить языком домохозяек. Nice или что?

Ну как тебе ещё проще объяснить-то? В юнитах systemd это определяется параметрами requires,wants,bindto и before/after. В других системах есть в каком-то виде, но реализовано намного менее гибко.

Деточка, это называется service sepervision, и есть практически везде, кроме SysV Init (в сильно покалеченном виде) и BSD Init.

Что, уже и останавливать/перезапускать зависимые службы умеют(по таймауту или событию)? И OOMKiller вызывать/запускать третий сервис в случае ошибки тоже могут?

SysV Init (в современных дистрибутивах, да), Runit. Есть ещё OpenRC и Upstart. Это только те, про которые я знаю точно.

SysV Init и BSD Init по понятным причинам исключаем, Upstart не умеет cgroups, параллелизация в OpenRC не поддерживается. Сколько там «современных» систем инициализации осталось?

SysV Init и BSD Init по понятным причинам исключаем

Поподробнее, пожалуйста.

В юнитах systemd это определяется параметрами requires,wants,bindto и before/after.

Это называется «зависимости».

В других системах есть в каком-то виде, но реализовано намного менее гибко.

Да.

Что, уже и останавливать/перезапускать зависимые службы умеют(по таймауту или событию)?

Что такое «зависимые службы»? Хотелось бы любой реальный пример. События есть только в Upstart и Systemd, насколько мне известно. Про таймауты не знаю.

И OOMKiller вызывать/запускать третий сервис в случае ошибки тоже могут?

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

SysV Init и BSD Init по понятным причинам исключаем

Кому понятным?

Они не работают с D-Bus и их не рекламируют. А ещё они появились слишком давно, а это не модно.

:D

Да.

Ключевоя слово не «есть», а «менее гибко».

Что такое «зависимые службы»? Хотелось бы любой реальный пример.

ntp-client и <что-там-у-тебя-отвечает-за-управление-сетью>.

Кому понятным?

есть практически везде, кроме SysV Init (в сильно покалеченном виде) и BSD Init.

Тебе.

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

Можно, конечно, продолжать пользоваться рудиментами и плеваться на systemd из-за лично неприязни к автору/его высказываниями/политике, но тогда чем же ты лучше тех, кто не использует reiserfs потому что её автор - женоубийца?

Не согласен.

Ведут бинарные логи,

Согласен что нужен стандартизированный интерфейс для службы логирования.

завязаны на D-Bus

Свой велосипед лучше?

претендуют на функции udev

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

А вот то, что он всё хочет вобрать в себя

без возможности замены - это очень плохо^W^W не unixway

Еще один «ненавижу systemd» тред?

Классно!!! ;-)

Вроде, для умеющих читать, уже все кости перемыли.

Нужна новая система загрузки? - Не помешает.

Нужен перезапуск служб по событиям? - Не помешает.

Нужно разделение ресурсов по группам? - Да пусть будет.

...

Только вот нафига «самоваро-паровозо-вертолет» лепить?

завязаны на D-Bus

Свой велосипед лучше?

нет, дбас как зависимость должна быть опциональна (привет от embed`щиков). отсутсвие дбаса не должно влиять на core functionality инит системы

А разве нет? Systemd в Debian не будет до тех пор, пока он не будет работать под FreeBSD. Вероятно, это означает никогда.

systemd в Debian есть, можно хоть сейчас брать и пользовать. А будет ли он по умолчанию...

завязаны на D-Bus

Вы так говорите, как будто это что-то плохое.

должна быть опциональна

Почему? Я реально не в курсе, неужели у этого дебас такой огромный оверхед? Против дебаса я слышал пминус только то что он не рассчитан на сеть, но разве это нужно для системы инициализации? В эмбеддет можно использовать старые иниты. У людей есть опасения что дальше удев и системд будут неразрывно связаны но разве в эмбедде используют удев? Я считал что эмбеддет зарание известен перечень устройств и грузятся модули к ним не удевом.

Ну вот и пришло время ставить слаку.

Завязывание на D-Bus - да, плохое. Системе инициализации совершенно незачем быть завязанной на D-Bus.

Преумножение сущностей сверх необходимого.

(Hint: Дбас там прилетел потому, что самовар еще и вертолет! Оно службы по событиям разруливает.)

Преумножение сущностей сверх необходимого.

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

нет, дбас как зависимость должна быть опциональна (привет от embed`щиков).

В дистрибутивах для embed-щиков, да, должна. В десктопных дистрибутивах dbus уже почти стандарт де-факто для IPC, так почему бы его тогда не использовать в системе инициализации?