Альтернатив systemd тред

Да никаких камней - если твоему софту systemd не нужен то ты можешь его не использовать.

не хочется проигрывать в надёжности системы
arch
перезагружается 2-3 раза в полгода

Тут что-то лишнее, я никак не могу понять что...

Основная причина перезагрузки - загрузка с новым ядром. По мне система надёжна и достаточно чтобы такой и оставалась после перехода с systemd.

не хочется проигрывать в надёжности системы

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

Вперёд и с песней.

Из простого — runit. На Void как раз используется. Работает довольно шустро и без каких-либо видимых проблем. В качестве тупой запускалки процессов и демонов вполне сойдёт.

Использую sysvinit, ни одна скотина ещё не жаловалась, хотя из-за гнома и загадочного Debian установлен пакет systemd (используется systemd-logind), но не используется в качестве init. С systemd наигрался в своё время, не хочу его, хочу syslog и простые скрипты в /etc/init.d и не парится.

OpenRC. тред можно закрывать.

systemd — мэйнстрим. Это значит, что программы будут затачиваться под взаимодействие с системд.
Значит, если не хочется геморроя в будущем, это должно быть что-то системд-совместимое.

Мелкомягкие своего добились. Выросло поколение, которое ищет альтернативы systemd, а ведь на самом деле это systemd альтернатива нормальным инитам.

Из нормальных альтернатив есть SMF. С большой натяжкой - upstart, launchd. На линуксе из перечисленного только никому не нужный upstart.

runit

У меня везде (и дома, и на работе, и на VPS-ках) используется OpenRC

Одна из фич systemd - быстрый запуск системы

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

очевидная слака. особенно вот-вот 14.2 должны выпустить.

смотря что именно тебе надо, в manjaro или как там его есть вариант с openrc, если не хочется самому копаться. Есть s6, runit и т.п. Просто удостоверься что софту не нужно половина system и используй.

initscripts

На раче пробовал openrc, официальной поддержки нет, так что если нужна стабильность, и чтобы «всё работало», то лучше остаться на systemd.

В каком виде: с AUR или сторонний репозиторий arch-openrc?

Через сторонний репозиторий, он назывался «openrc-eudev».

Если нужен KISS - тащи инициализацию из слаки. Проще, надёжнее и быстрее не придумаешь.

ЗЫ: слухи о быстроте загрузки системы с systemd сильно преувеличены.

Хорошо, а в чём именно проявляется отсутствие официальной поддержки?

systemd — мэйнстрим. Это значит, что программы будут затачиваться под взаимодействие с системд.

Иди читни реймондцаESRца :) Быдлокодеры да, прибивают программы гвоздями к чему-то.

если не хочется геморроя в будущем

это должно быть что-то системд-совместимое.

Noep. «Этому» должно быть фиолетово, есть системд или нет :) Оно может им пользоваться если есть. Но от его отсутствия не должно впадать ни в панику, ни в корку.

Ну представь, что на генте с openrc у тебя будут установлены пакеты из профиля для systemd.

использую старые sysvinit в арче. проблем нет, брат жив.

 # >  systemd-analyze
Startup finished in 12.463s (firmware) + 12ms (loader) + 1.121s (kernel) + 2.418s (userspace) = 16.015s

В человекочитаемом виде:

 # >  /mnt/userdata/work/bin/startup
===== STARTUP =====

  firmware:   12.463s
  loader:     12ms
  kernel:     1.121s
  userspace:  2.418s
  total:      3.552s (16.015s)

Unit files. E:13; D:36.
  @912ms	+5ms	 - systemd-logind.service
  @879ms	+1ms	 - systemd-update-done.service
  @357ms	+59ms	 - ldconfig.service
  @101ms	+4ms	 - systemd-tmpfiles-setup-dev.service
  @97ms	+3ms	 - systemd-sysusers.service
  @91ms	+5ms	 - systemd-remount-fs.service
  @76ms	+13ms	 - systemd-fsck-root.service

===================

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

ЗЫ: слухи о быстроте загрузки системы с systemd сильно преувеличены.

А теперь прочитай мой пост выше.

Не надо чушь городить, ладно? Дело не в профиле, а в софте, который умеет только в logind и компанию. Это не проблема генты, а проблема кривых рук. Я жил на OpenRC, и не видел ничего из systemd в своей системе, теперь живу на systemd, и не вижу ничего от OpenRC.

Дюже прытко, у меня вот так:
$ systemd-analyze
Startup finished in 5.750s (kernel) + 1min 7.520s (userspace) = 1min 13.271s
Кеды вместо окружения рабочего стола, Debian 8 вместо операционной системы, SSD вместо диска с корнем.

Эээ. Какая проблема генты? Я говорил вообще говорил про то, что рач с опенрц из сторонних реп — как гента с опенрц, но в которой все пакеты собраны как если бы у тебя был сустемд (в генте такое, правда, невозможно, потому что из-за юзов systemd прилетит как зависимость, и с openrc то же самое, но в общем суть примерно понятна)

1min 13.271s
SSD

Каааааааааааааааааааааааааааааак?

Ладно, раскрою секрет:

$ systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1min 7.497s
└─multi-user.target @1min 7.497s
  └─ntp.service @17.403s +50.093s
    └─basic.target @17.177s
      └─paths.target @17.148s
        └─cups.path @17.148s
          └─sysinit.target @17.141s
            └─nfs-common.service @17.057s +83ms
              └─rpcbind.target @17.057s
                └─rpcbind.service @17.026s +30ms
                  └─network-online.target @17.026s
                    └─network.target @17.026s
                      └─ifup@eth1.service @17.025s
                        └─networking.service @1.736s +15.273s
                          └─bootcdflop.service @1.726s +8ms
                            └─local-fs.target @1.709s
                              └─run-rpc_pipefs.mount @17.135s
                                └─local-fs-pre.target @487ms
                                  └─systemd-remount-fs.service @469ms +17ms
                                    └─keyboard-setup.service @198ms +259ms
                                      └─systemd-udevd.service @192ms +4ms
                                        └─systemd-tmpfiles-setup-dev.service @160ms +31ms
                                          └─kmod-static-nodes.service @149ms +10ms
                                            └─system.slice @130ms
                                              └─-.slice @130ms

Оно что-то своё показывает. У меня systemd-analyze вообще больше двух минут пишет. Тоже на SSD. При этом до графического приглашения грузится 6 секунд ровно по секундомеру.

Не знаю, у меня всё правильно показывало (ну, правда, оно не учитывает врмя запуска приложений после логина пользователя в tty)

Upstart

Вообще, у меня 600-900 ms на нормальном запуске (я не считаю время firmware, так как это наглый 3.14-здёж, система грузится от силы секунды две от нажатия кнопки запуска до предложения ввода пароля), но у меня вместо загрузчика — UEFI, вместо диска — SSD, вместо дистра — Gentoo, вместо всего остального причёсанный софт, не прибитый ни к чему гвоздями. Да и большинство service-файлов подправлены, и таргеты тоже причёсаны, и всё лишнее отключено (но не замаскировано). Я не задавался целью быстро грузиться, так как комп ходит в ребут только при обновлении ядра, и то через раз, в остальное время он у меня даже не ходит в сон.

из-за юзов systemd прилетит как зависимость, и с openrc то же самое

Даже без юзов некоторый софт требует systemd, ибо завязан на. И гента немного прибита к OpenRC из-за gentoo-functions, но второе решается установкой отдельного пакета вместо всего openrc, а вот с первым немного беда.

To @all: Вообще, не понимаю бугурта по поводу инита, ни со стороны ярых противников systemd, ни со стороны его ярых поклонников. Это просто инструмент. Нравится концепция, осилил документацию — пользуйся, нет — пользуйся чем-то другим, благо альтернативы всегда имеются. Повод бугуртить за эти годы так и не раскрыт, а срачи на ЛОРе продолжаются.

1min 13.271s
SSD

Каааааааааааааааааааааааааааааак?

Как я и догадывался, его система ждёт доступности сети, а это 15-60 секунд обычно.

To @all: Вообще, не понимаю бугурта по поводу инита, ни со стороны ярых противников systemd, ни со стороны его ярых поклонников. Это просто инструмент. Нравится концепция, осилил документацию — пользуйся, нет — пользуйся чем-то другим, благо альтернативы всегда имеются. Повод бугуртить за эти годы так и не раскрыт, а срачи на ЛОРе продолжаются.

Лично я несколько недолюбливаю systemd по одной простой причине. Его добровольно-принудительно притащили в некоторые из используемых мной дистрибутивы, заменили то, что прекрасно работало и не дали ни одной новой полезной функции. Проще говоря, мне пришлось в силу профессии тратить время на изучение нового инструмента, который по сути мне не нужен, так как старый был не хуже и со всеми задачами справлялся отлично. Может быть когда-нибудь мне понадобится что-то из функционала systemd, но я считаю, что именно тогда и стоит осознанно его ставить и изучать. Поэтому дома на десктопах у меня gentoo, openrc и eudev. А вот на серверах debian и systemd.

Его добровольно-принудительно притащили в некоторые из используемых мной дистрибутивы, заменили то, что прекрасно работало

Причём работало годами и жрать не просило. Тут да, согласен, но это камень в огород не systemd, а манагерам дистра, так что аргумент засчитан лишь наполовину. (=

А вот на серверах ... и systemd.

Каскадёр ? :-) Ухожу, ухожу...

И что? А DHCP сервер, например, тупит. Или там mariadb/postgres c кластером синкаются минут 10. И сколько ты будешь ждать реальной готовности системы к работе? Эти говноциферки вообще ни о чём не говорят, с таким же успехом можно тупо запустить всё скопом, с & из единственного скрипта, вообще без всякой системы инициализации и получить промпт шелла раз в 5 быстрее чем вот это вот идиотское позорище. Толку-то от этого.

Это та же херня что и с виндой - раз-два и уже десктоп. А работать один хер невозможно ещё пару минут..

с таким же успехом можно тупо запустить всё скопом, с & из единственного скрипта

Про зависимости не в курсе, да?

А работать один хер невозможно ещё пару минут.

Что за калькулятор вместо компа?

Про зависимости не в курсе, да?

Их важность тоже сильно преувеличена. Если демоны не цепляются к конкретным интерфесам и ИП, например, а слушают на 0.0.0.0 - то им по барабану, поднялся ли какой-нибудь eth8 при запуске или ещё нет. Лишь бы хотя бы один lo был - всё будет работать как задумано. Поднимутся остальные интерфейсы - пойдёт и через них трафик. В общем, средний сервак поднимется при любом порядке запуска демонов и поднятия железок.

Фактически единственное что имеет смысл сделать в первую очередь - смонтировать /proc и /sys и поднять lo. Это, в общем-то единственная реально существующая зависимость в линуксе, существование которой совершенно не требует какой-то специальной фигни.

Что до всяких dbus и прочего говнища которое не может в произвольной последовательности запускаться - так это проблемы дизайна этого говнища. Писали бы нормально, как принято писать приличный софт - никакой необходимости в зависимостях вообще не было бы.

Что за калькулятор вместо компа?

4-хксеоновые монстры с четвертью терабайта памяти, на которых крутится кластер БД. Хоть обдрочись на системде, а пока включённая нода не сольёт те гигабайты данных которые были пропущены при простое - никакой системде ничем не поможет вообще.

Так что есть системде, нет системде - никакой разницы вообще на самом деле нету. Скорость загрузки системы до состояния up and running настолько мало зависит от системы инициализации, что этим мизерным различием можно запросто пренебречь.

Эти говноциферки вообще ни о чём не говорят

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

с таким же успехом можно тупо запустить всё скопом, с & из единственного скрипта

Ты действительно такой, или прикидываешься? systemd строит дерево зависимостей. OpenRC в этом плане немного халатен, но всё же вполне справляется со своей задачей.

Это та же херня что и с виндой - раз-два и уже десктоп. А работать один хер невозможно ещё пару минут..

С предложенным тобой способом — да.

Как раз говорят, и достаточно точно.

Ну и где там тайминг запуска хотя бы MariaDB c базёнкой хотя бы в десяток гигов, например?

Вообще, на сервере эти циферки довольно важны, так как даунтайм должен быть минимален

Ну так продемонстрируй, насколько твой системде ускорит запуск вышеупомянутой MariaDB. Пока оно не поднялось - сервер в дауне. Хоть там 100500 системде установлено.

Ты действительно такой, или прикидываешься? systemd строит дерево зависимостей.

Расскажи мне на конкретных примерах с распространёнными демонами от апача до какого-нибудь ntpd нахера там вообще эти зависимости нужны. А то что-то зависимостей хотят почему-то только всякие идиотские поделки десктопные.

С предложенным тобой способом — да.

Оно ничем не отличается от того, что пытается делаеть системде. Форкнуть в бэкграунд тормозные процессы - много ума не надо. Зависимости - тупая отмазка, большинство нормального серверного софта их не требует.

Расскажи мне на конкретных примерах с распространёнными демонами от апача до какого-нибудь ntpd нахера там вообще эти зависимости нужны.

Нафига тебе ntpd без сети? Вначале нужно поднять сеть. Как поднять сеть, если ФС с конфигами ещё не примонтирована? Примонтировать сеть. И так далее. Тебе не нужно беспокоиться обо всех этих деталях, ты включаешь ntpd в автозапуск, остальное за тебя делает софтина. Проще, чем вендовое Далее → Далее → Далее → Готово.

Оно ничем не отличается от того, что пытается делаеть системде.

И всё же я начинаю подозревать, что тебя часто били по голове. Помимо зависимостей оно ещё и ждать готовности умеет, а не тупо запускалка софта. А твои скрипты запустят всё скопом, половина отвалится из-за неготовности второй половины, а потом сиди в ssh (если сеть поднимется вообще), и разруливай.

Нафига тебе ntpd без сети?

А ntpd насрать, есть ли сеть при запуске или нет. Появится сеть - он достучится до серверов, нет сети - будет ждать.

Кроме того, ntpd, если ты не в курсе, прекрасно может использовать в качестве источника точного времени локальный GPS, радио или там локальные атомные часы. man ntp.conf и всё такоэ.

Вначале нужно поднять сеть. Как поднять сеть, если ФС с конфигами ещё не примонтирована? Примонтировать сеть.

А чтобы примонтировать сеть надо поднять сеть :) И как раз вот тут системде начинает вытворять такоэ! :) Не, лучше бы Поттеринг не рождался вовсе. :)

И так далее. Тебе не нужно беспокоиться обо всех этих деталях, ты включаешь ntpd в автозапуск, остальное за тебя делает софтина.

Ага. И при отмирании одного интерфейса системде берёт и прибивает ntpd. Зависимости такие зависимости.

А твои скрипты запустят всё скопом, половина отвалится из-за неготовности второй половины

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

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

dhcpd. Реальный пример? Или будешь утверждать, что сфероконина?