[NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Сообщение **sash-kan** » 01.03.2012 10:44

altwazar писал(а): ↑
01.03.2012 08:07
Если этот побочный эффект - выигрыш в одну секунду

скорее микросекунда (напоминаю, что речь про невызов lsb-release)·

а по сравнению с sysvinit, боюсь, слишком часто наблюдается как раз большее время загрузки…
т.е., возвращаясь к systemd как таковому, выходит, что _единственная_ цель его существования достигается далеко не везде и далеко не всегда·
со своим частным случаем на suse Алексей нас уже ознакомил·
более общий случай — mandriva·
насколько мне известно, в типовой конфигурации mandriva 2011 инициализируется с помощью systemd дольше, чем с помощью sysvinit·
эту ситуацию напряжённо (осмелюсь даже добавить «судорожно») пытаются исправить в тестовой версии, сжигая на ходу мосты и делая невозможным инициализацию с помощью sysvinit·
тем самым на корню уничтожая совместимость с sysvinit, являющуюся ключевым (и, несомненно, положительный) моментом, которым пытался оправдаться «папа» systemd·

что могу сказать в качестве резюме?
попробуйте установить systemd, сравните, в какую сторону изменилось время инициализации конкретно _вашей_ конфигурации системы·
а потом уж делайте вывод — нужна ли вам лично или не нужна эта надстройка над sysvinit…

taaroa · Сообщение **taaroa** » 01.03.2012 11:23

sash-kan писал(а): ↑
01.03.2012 10:44
т.е., возвращаясь к systemd как таковому, выходит, что _единственная_ цель его существования достигается далеко не везде и далеко не всегда·

oops. у systemd есть цель? и она одна, единственная? кроме боли ниже поясницы (upstart изобрели не у нас, а в какой-то там убанте (или убунте)) и её устранения.

altwazar · Сообщение **altwazar** » 01.03.2012 11:29

sash-kan писал(а): ↑
01.03.2012 10:44
т.е., возвращаясь к systemd как таковому, выходит, что _единственная_ цель его существования достигается далеко не везде и далеко не всегда·

Я не разбирался с системд и не знаю _единственного_ назначения. Открыл http://fedoraproject.org/wiki/Systemd и не увидел там подобного заявления, да и скорость загрузки упоминается только вскользь.

Сообщение **alv** » 01.03.2012 14:03

taaroa писал(а): ↑
01.03.2012 11:23
(upstart изобрели не у нас, а в какой-то там убанте (или убунте))

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

SinClaus · Сообщение **SinClaus** » 01.03.2012 14:39

Мне нравится подход в Арче: systemd в принципе есть... но сервисы стартуют не из тривиального /etc/rc.d/init.d, а из файлика /etc/rc.conf

Сообщение **sash-kan** » 01.03.2012 14:40

altwazar писал(а): ↑
01.03.2012 11:29
Открыл http://fedoraproject.org/wiki/Systemd и не увидел там подобного заявления

первая же фраза, начало: systemd provides aggressive parallelization capabilities
с моей скромной точки зрения целью «агрессивной параллелизации» является либо «агрессивная параллелизация ради агрессивной параллелизации», либо «сокращение времени на инициализацию операционной системы»·
смею надеяться (невзирая на мнения явных злопыхателей), что вторая цель всё-таки несколько ближе к источнику вдохновения поттеринга…

Сообщение **serzh-z** » 01.03.2012 15:01

SinClaus писал(а): ↑
01.03.2012 14:39
но сервисы стартуют не из тривиального /etc/rc.d/init.d, а из файлика /etc/rc.conf

Из /etc/rc.sysinit или /etc/rc.single. Что ничуть не отличается от почти любого дистрибутива Linux. Что будет делать этот /etc/rc.sysinit (или systemd, или upstart, или my-dist-super-init) - запускать все (или выбранные) скрипты в /etc/init.d, /etc/rc.d или в /lib/system.d - уже не столь важно.

Сообщение **diesel** » 01.03.2012 15:06

alv писал(а): ↑
29.02.2012 02:44
serzh-z писал(а): ↑
29.02.2012 00:25
Активация сервисов занимает много времени

кажется, я даже цифирь приводил - время старта openSUSE с systemd и с sysV. Повторяю: в крнфигурации стартовых сервисов по умолчанию - 56 и 47 секунд соответственно.
Раз уж приблуда, специально разработанная для попадания в задницу ускорения старта системы, не способна даже на это - нужна ли ещё какая-то техническая аргументация?

внимание вопрос: openSuSE использует "чистый" systemd, или они просто sysV скрипты через systemd направляют? Если второе - то чему тут удивляться?

Сообщение **sash-kan** » 01.03.2012 15:18

diesel писал(а): ↑
01.03.2012 15:06
внимание вопрос: openSuSE использует "чистый" systemd, или они просто sysV скрипты через systemd направляют? Если второе - то чему тут удивляться?

понимаешь ли, systemd "перехватывает" управление скриптами·
обычно эти скрипты начинаются с вызова чего-нибудь вроде /bla/bla/functions·
вот туда он и «внедряется»·
это, конечно, только один путь внедрения — для поддержки прямого запуска sysvinit-скриптов·

другой (главный) путь — подмена /sbin/init-а·
вот тут он в первую очередь и «хозяйничает»·
и sysvinit-овые скрипты, кстати, тоже может запускать·
если не расписан (или именно так расписан) конф. файл соответствующего демона·

так что «чистого» или «грязного» systemd нет·
он или есть, или вообще отсутствует·

Basileus · Сообщение **Basileus** » 01.03.2012 15:18

alv писал(а): ↑
01.03.2012 14:03
....так что для самоутверждения приходится изобретать колёса в форме ромбододекаэдра.

ага, по шпалам ездить удобно....

Сообщение **sash-kan** » 01.03.2012 15:24

Basileus писал(а): ↑
01.03.2012 15:18
alv писал(а): ↑
01.03.2012 14:03
....так что для самоутверждения приходится изобретать колёса в форме ромбододекаэдра.

ага, по шпалам ездить удобно....

по «специально подготовленной трассе» (читай — выложенной шпалами)·
это самое «выкладываение шпалами» я в данный момент и наблюдаю в мандриве (иллюстрирующую ссылку уже приводил)·
не могу ничего сказать про другие дистрибутивы, а вот в мандриве по долгу службы ковыряться приходится…
что вижу (надеюсь, не через очень кривые очки), о том и пишу…

Сообщение **diesel** » 01.03.2012 15:35

alv писал(а): ↑
28.02.2012 23:02
diesel писал(а): ↑
28.02.2012 22:45
если видели, то не пользовались, и документацию врядли читали.

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

Вы потеряли прозрачность в чем?
Нельзя узнать какие команды выполняются во время старта сервиса? - можно
Нельзя изменить команды? - можно
Нельзя управлять тем что стартует? - можно
Нельзя управлять порядком загрузки? - теоретически, можно. Хотя для большинства сервисов(в Fedora, пардон, как там в SuSE - не представляю) заявление про "старт одновременно" - правдиво(проверка диска, или монтирование - все же не сервисы).
Нельзя добавлять собственные команды/сервисы? - можно. Более того, можно даже своими же старыми скриптами пользоваться, и более того пользоваться практически так же как и раньше.

Единственное что действительно убрали - это огород абстракций на баше, задача которого, с точки зрения пользователя была той же: вынести задаваемые пользователем параметры загрузки подальше, а старт самого сервиса как можно больше унифицировать.

arkhnchul привел пример, когда у него init скрипт откликался не только на стандартные start/stop/restart но и еще на какие-то кастомные команды. Не то чтобы совсем работать не будет, звать напрямую /etc/init,d/script something никто не запрещал, но возможны какие-то проблемы. У меня таких скриптов нет, у меня вообще кастомных сервисов, установленных не из репозитория на десктопе нет, да и на серверах которые я обустраивал - тоже нет, а от темного наследия в пределах своих серверов мы потихоньку избавляемся(да и для "наследия" никто init-скрипты никода не писал). Но если проблема таки возникнет - это проблема решаемая, возможно даже малой кровью.

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

Сообщение **diesel** » 01.03.2012 15:41

sash-kan писал(а): ↑
01.03.2012 15:18
diesel писал(а): ↑
01.03.2012 15:06
внимание вопрос: openSuSE использует "чистый" systemd, или они просто sysV скрипты через systemd направляют? Если второе - то чему тут удивляться?
понимаешь ли, systemd "перехватывает" управление скриптами·
обычно эти скрипты начинаются с вызова чего-нибудь вроде /bla/bla/functions·
вот туда он и «внедряется»·
это, конечно, только один путь внедрения — для поддержки прямого запуска sysvinit-скриптов·
....
так что «чистого» или «грязного» systemd нет·
он или есть, или вообще отсутствует·

повторю один из примеров:

Код: Выделить всё

[diesel@fedora /]$ cat  /lib/systemd/system/vsftpd.service
[Unit]
Description=Vsftpd ftp daemon
After=network.target

[Service]
Type=forking
ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf

[Install]
WantedBy=multi-user.target

никаких functions, никаких init.d - просто стартуем /usr/sbin/vsftpd.

Или, если у нас есть специальные утилиты которые управляют сервисом, как у pg или apache:

Код: Выделить всё

... skipped variables ...
ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA}
ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o "-p ${PGPORT}" -w -t 300
ExecStop=/usr/bin/pg_ctl stop -D ${PGDATA} -s -m fast
ExecReload=/usr/bin/pg_ctl reload -D ${PGDATA} -s
...

если же там действительно или обертка к /etc/init.d, или к functions, хотя бы в 40% случаев .. то я согласен - нафиг не надо, и быстрее точно не будет

ЗЫ: про "перехватывает управление" не совсем понял. systemd - это init(тот который с pid == 1), он не должен перехватывать, он запускать должен.

Сообщение **t.t** » 01.03.2012 16:18

alv писал(а): ↑
28.02.2012 21:20
t.t писал(а): ↑
28.02.2012 18:59
Как это не продвигал?
Тихон, да не было такой агрессии никогда. Я вообще за 15 уже почти лет не помню такого агрессивного продвижения чего бы то ни было, сравнимоого с продвижением поделий Поттеринга.

По-моему, если разделить на коэффициент популярности линуксов в целом, выйдет где-то сравнимо.

alv писал(а): ↑
28.02.2012 21:20
А автомаунтом можно было спокойно не пользоваться даже в Мандрейке. Я вот ни разу не пользовался и даже смутно представляю, что это такое. И до сих пор прекрасно себя чувствую.

Так я и systemd ни разу не пользовался. Или в нынешних юзерофильных дистрибутивах насчёт него выбора не оставляют?

В Debian-то всё совершенно свободно в этом смысле:

Код: Выделить всё

$ apt-cache rdepends --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances systemd | tail -n +3 | egrep -v '(^ *|-)systemd(-|$)'
  lighttpd

Сообщение **t.t** » 01.03.2012 16:36

serzh-z писал(а): ↑
01.03.2012 00:27
Bluetooth писал(а): ↑
01.03.2012 00:18
Нужны аргументы, чтобы внедрять новое.
Всего лишь один: прогрессу плевать на желания консерваторов.

А тождество "systemd == прогресс" принято за аксиому? Любопытный подход: чтобы доказать нужность чего-то нового, достаточно обозвать его прогрессом. (:

Сообщение **serzh-z** » 01.03.2012 16:57

t.t писал(а): ↑
01.03.2012 16:36
А тождество "systemd == прогресс" принято за аксиому?

Прогресс - это поиск новой архитектуры для менеджера сервисов.

Сообщение **alv** » 01.03.2012 18:23

sash-kan писал(а): ↑
01.03.2012 15:18
так что «чистого» или «грязного» systemd нет·
он или есть, или вообще отсутствует·

Насколько я успел понять - именно так.
Благо, в openSUSE есть (пока?) возможность вернуться к "чистому" sysV, чем я и не преминул воспользоваться.

Сообщение **sash-kan** » 01.03.2012 19:00

diesel писал(а): ↑
01.03.2012 15:41
если же там действительно или обертка к /etc/init.d, или к functions

нет, systemd не является обёрткой к /bla/bla/functions.
он заменяет этот файл·
точнее, дополняет его обращением к себе, любимому·

в теории, параллельный запуск демонов (_иногда_ параллельный, ибо, как ни крути, запуски демонов и прочие задачи, осуществляемые _любой_ системой инициализации, очень сильно взаимозависимы), помноженный на (во многих случаях) невыполнение скриптов из /etc/init.d, должен давать сокращение времени инициализации системы в большинстве ситуаций·
и, надо думать, товарищ поттеринг верит, что _очень_ существенное сокращение· и во _всех_ ситуациях·
ну а как на практике происходит — любой желающий может проверить·
именно на своей системе·
если, как в мандривовском кукере, sysvinit не поломали вообще, посчитав, что… чёрт, я честно не понимаю, _что_ такие люди считают·
может быть, Дима объяснит — он какие-то аргументы приводил в нашем с ним разговоре…

Сообщение **t.t** » 01.03.2012 19:19

serzh-z писал(а): ↑
01.03.2012 16:57
t.t писал(а): ↑
01.03.2012 16:36
А тождество "systemd == прогресс" принято за аксиому?
Прогресс - это поиск новой архитектуры для менеджера сервисов.

Поиск не есть прогресс. Прогрессом может быть некое новое решение -- пусть промежуточное и неидеальное, но в чём-то лучшее, чем было до него. Если не лучшее ни в чём, то это либо регресс, либо бессмысленное топтание на месте. В чём systemd лучше, чем sysvinit, мы, насколько я понял, пока не услышали; а следовательно и прогрессом его называть рановато.

Сообщение **diesel** » 01.03.2012 19:58

sash-kan писал(а): ↑
01.03.2012 19:00
diesel писал(а): ↑
01.03.2012 15:41
если же там действительно или обертка к /etc/init.d, или к functions
нет, systemd не является обёрткой к /bla/bla/functions.
он заменяет этот файл·
точнее, дополняет его обращением к себе, любимому·

можно как-то более подробно?
потому как
"systemd не является обёрткой к /bla/bla/functions" - я это понимаю как "systemd не дергает напрямую /bla/bla/functions, то есть если в /bla/bla/functions где-то прописан запуск, systemd явно это будет пускать через это", ок
"он заменяет этот файл" - читаю как "/bla/bla/functions теперь не нужны, их нет". да, это согласовывается с первым пунктом и здравым смыслом, в конце-концов systemd не является интерпретатором шелла.
"точнее, дополняет его обращением к себе, любимому" - разрыв шаблона.

taaroa · Сообщение **taaroa** » 01.03.2012 20:01

http://0pointer.de/blog/projects/why.html [1]

http://forums.opensuse.org/english/other-f...ot-upstart.html [2]

[1] сравнение sysv init, upstart и systemd.
[2] I am a bit biased because I listened to Lennart's talk recently. However aside from that, and the fact that I have not explored it in depth, I do notice that systemd subsumes the functions of (x)inetd as well, which upstart doesn't handle, as it only replaces rc. It also replaces a lot of code that the daemon itself has to do, such as forking. double forking, and uid changing. I regard these as improvements already. Some of the ideas in it will be familiar to those who have used OS/X's launchd.

Сообщение **diesel** » 01.03.2012 20:07

sash-kan писал(а): ↑
01.03.2012 19:00
в теории, параллельный запуск демонов (_иногда_ параллельный, ибо, как ни крути, запуски демонов и прочие задачи, осуществляемые _любой_ системой инициализации, очень сильно взаимозависимы), помноженный на (во многих случаях) невыполнение скриптов из /etc/init.d, должен давать сокращение времени инициализации системы в большинстве ситуаций·

проблема в том что systemd - это попытка сделать "всегда параллельный запуск всех демонов", но есть проблема, как раз со скриптами в /etc/init.d. То есть если у тебя десяток скриптов в init.d которые должны быть запущены, то у нас получается "иногда параллельный запуск", и соответственно абсолютно пофигу кто этот запуск производит: systemd или любой другой init daemon. Поэтому и был мой вопрос про openSuSE, если systemd просто дергает скрипты из /etc/init.d, то нет смысла сравнивать скорость загрузки(ее вообще нет смысла сравнивать, но черт с ним), потому как технически никакой разницы нет.

Сообщение **sash-kan** » 01.03.2012 22:14

diesel писал(а): ↑
01.03.2012 19:58
sash-kan писал(а): ↑
01.03.2012 19:00
diesel писал(а): ↑
01.03.2012 15:41
если же там действительно или обертка к /etc/init.d, или к functions
нет, systemd не является обёрткой к /bla/bla/functions.
он заменяет этот файл·
точнее, дополняет его обращением к себе, любимому·

можно как-то более подробно?
потому как
"systemd не является обёрткой к /bla/bla/functions" - я это понимаю как "systemd не дергает напрямую /bla/bla/functions, то есть если в /bla/bla/functions где-то прописан запуск, systemd явно это будет пускать через это", ок
"он заменяет этот файл" - читаю как "/bla/bla/functions теперь не нужны, их нет". да, это согласовывается с первым пунктом и здравым смыслом, в конце-концов systemd не является интерпретатором шелла.
"точнее, дополняет его обращением к себе, любимому" - разрыв шаблона.

когда ты вызываешь /etc/init.d/файл blabla, в начале "файла" вызывается скрипт /etc/init.d/functions, в котором после установки systemd появляется вызов systemctl, а управление назад не возвращается·
насчёт «_никогда_ не возвращается» не уверен — насколько понимаю, некоторые из скриптов всё-таки выполняются при таком вызове, — исходя из конфигурации самого systemd (например, если он просто не знает, что делать)·

Сообщение **sash-kan** » 01.03.2012 22:20

diesel писал(а): ↑
01.03.2012 20:07
если systemd просто дергает скрипты из /etc/init.d

нет, он не «просто дёргает»·
/sbin/init у него свой, и какие команды выполнять — он определяет из своей конфигурации·
кое-где прописан запуск не демона непосредственно, а скрипта из init.d:
$ grep -r 'init.d' /etc/systemd/ 2>/dev/null
/etc/systemd/system/multi-user.target.wants/alsa.service:ExecStart=/etc/init.d/alsa start
/etc/systemd/system/multi-user.target.wants/alsa.service:ExecStop=/etc/init.d/alsa stop
/etc/systemd/system/multi-user.target.wants/sound.service:ExecStart=/etc/init.d/sound start
/etc/systemd/system/multi-user.target.wants/sound.service:ExecStop=/etc/init.d/sound stop
$ grep -r 'init.d' /lib/systemd/ 2>/dev/null
/lib/systemd/fedora-autoswap:. /etc/init.d/functions
/lib/systemd/fedora-storage-init:. /etc/init.d/functions
Binary file /lib/systemd/systemd-update-utmp matches
/lib/systemd/fedora-autorelabel:. /etc/init.d/functions
Binary file /lib/systemd/systemd-initctl matches
Binary file /lib/systemd/systemd-fsck matches
Binary file /lib/systemd/systemd-hostnamed matches
/lib/systemd/fedora-readonly:. /etc/init.d/functions
Binary file /lib/systemd/systemd-cgroups-agent matches
/lib/systemd/system/basic.target.wants/mandriva-everytime.service:ExecStart=-/etc/init.d/mandrake_everytime
/lib/systemd/system/alsa.service:ExecStart=/etc/init.d/alsa start
/lib/systemd/system/alsa.service:ExecStop=/etc/init.d/alsa stop
/lib/systemd/system/mandriva-everytime.service:ExecStart=-/etc/init.d/mandrake_everytime
/lib/systemd/system/sound.service:ExecStart=/etc/init.d/sound start
/lib/systemd/system/sound.service:ExecStop=/etc/init.

Сообщение **t.t** » 02.03.2012 01:58

diesel писал(а): ↑
01.03.2012 20:07
проблема в том что systemd - это попытка сделать "всегда параллельный запуск всех демонов", но есть проблема, как раз со скриптами в /etc/init.d. То есть если у тебя десяток скриптов в init.d которые должны быть запущены, то у нас получается "иногда параллельный запуск", и соответственно абсолютно пофигу кто этот запуск производит: systemd или любой другой init daemon. Поэтому и был мой вопрос про openSuSE, если systemd просто дергает скрипты из /etc/init.d, то нет смысла сравнивать скорость загрузки(ее вообще нет смысла сравнивать, но черт с ним), потому как технически никакой разницы нет.

А если скрипты из init.d исключить из схемы напрочь, разве с ними вместе волшебным образом исчезнут и зависимости? А то я как-то не понимаю, откуда возьмётся этот пресловутый "всегда параллельный запуск".

minoru-kun · Сообщение **minoru-kun** » 02.03.2012 07:54

Dmitry Shurupov писал(а): ↑
16.02.2012 12:52
<p>Леннарт Поттеринг (Lennart Poettering), автор таких известных Open Source-проектов, как PulseAudio и systemd, объявил о решении прекратить в init-системе systemd поддержку Linux-дистрибутивов, не имеющих в своей файловой системе файла /etc/os-release.</p><p>/etc/os-release — это очередное нововведение от Поттеринга

Ну и ССЗБ.

Bluetooth · Сообщение **Bluetooth** » 02.03.2012 11:17

t.t писал(а): ↑
02.03.2012 01:58
А если скрипты из init.d исключить из схемы напрочь, разве с ними вместе волшебным образом исчезнут и зависимости? А то я как-то не понимаю, откуда возьмётся этот пресловутый "всегда параллельный запуск".

А у меня еще и другой вопрос: а разве на данный момент в debian squeeze не используется параллельный запуск демонов, на основе зависимостей?

Сообщение **diesel** » 02.03.2012 16:36

t.t писал(а): ↑
02.03.2012 01:58
diesel писал(а): ↑
01.03.2012 20:07
проблема в том что systemd - это попытка сделать "всегда параллельный запуск всех демонов", но есть проблема, как раз со скриптами в /etc/init.d. То есть если у тебя десяток скриптов в init.d которые должны быть запущены, то у нас получается "иногда параллельный запуск", и соответственно абсолютно пофигу кто этот запуск производит: systemd или любой другой init daemon. Поэтому и был мой вопрос про openSuSE, если systemd просто дергает скрипты из /etc/init.d, то нет смысла сравнивать скорость загрузки(ее вообще нет смысла сравнивать, но черт с ним), потому как технически никакой разницы нет.
А если скрипты из init.d исключить из схемы напрочь, разве с ними вместе волшебным образом исчезнут и зависимости? А то я как-то не понимаю, откуда возьмётся этот пресловутый "всегда параллельный запуск".

Если верить Поттерингу, зависимость сервиса А от сервиса Б, в основном, это необходимость сервиса А в "разговоре" с Б, разговор - это, в основном, все-таки сокеты. Сразу после старта А врядли будет сразу "говорить", ему просто надо куда-нить подключится, и даже если говорить будет... никто не обещает что он получит ответ сию секунду, может и подождать немного. Соответственно systemd берет на себя "открытие" сокетов, и "передачу" их соответствующим сервисам, когда они будут готовы их обслуживать, это не ново, (x)inetd или как их там, давно это уже делает. Что дает два эффекта: возможность запустить А и Б одновременно, поскольку формально зависимость удовлетворена, и с другой стороны возможность запуска сервиса on demand, о чем выше писал taaroa.

Если интересно, есть обзор от Поттеринга: http://www.youtube.com/watch?v=TyMLi8QF6sw

Bluetooth писал(а): ↑
02.03.2012 11:17
t.t писал(а): ↑
02.03.2012 01:58
А если скрипты из init.d исключить из схемы напрочь, разве с ними вместе волшебным образом исчезнут и зависимости? А то я как-то не понимаю, откуда возьмётся этот пресловутый "всегда параллельный запуск".
А у меня еще и другой вопрос: а разве на данный момент в debian squeeze не используется параллельный запуск демонов, на основе зависимостей?

тоже самое, если понимаешь язык вероятного противника: http://www.youtube.com/watch?v=TyMLi8QF6sw...tailpage#t=675s

Сообщение **diesel** » 02.03.2012 16:47

sash-kan писал(а): ↑
01.03.2012 22:20
diesel писал(а): ↑
01.03.2012 20:07
если systemd просто дергает скрипты из /etc/init.d
нет, он не «просто дёргает»·
/sbin/init у него свой, и какие команды выполнять — он определяет из своей конфигурации·
кое-где прописан запуск не демона непосредственно, а скрипта из init.d:
$ grep -r 'init.d' /etc/systemd/ 2>/dev/null
/etc/systemd/system/multi-user.target.wants/alsa.service:ExecStart=/etc/init.d/alsa start
....
$ grep -r 'init.d' /lib/systemd/ 2>/dev/null
/lib/systemd/fedora-autoswap:. /etc/init.d/functions
....

Понятно(Fedora 16):

[root@fedora /]# grep -Ir 'init.d' /lib/systemd/ 2>/dev/null
/lib/systemd/fedora-configure:. /etc/init.d/functions
/lib/systemd/fedora-storage-init:. /etc/init.d/functions
/lib/systemd/fedora-autorelabel:. /etc/init.d/functions
/lib/systemd/fedora-readonly:. /etc/init.d/functions

это не сервисы, ничего странного. Все же мы смотрим куда-то в разные системы.

Сообщение **t.t** » 03.03.2012 00:35

Вася, как бы то ни было, это всё ещё не ответ на вопрос "чем с systemd лучше, чем без него?"

Кстати, за примерами я как-то глубоковато в историю залез. Можно копнуть поближе: HAL. Уж его-то продвижение трудно не назвать агрессивным. И где он теперь? Благополучно помер, переродившись в DeviceKit, который теперь присоединяют к udev.

unixforum.org

[NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

Re: [NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release