systemd или openrc? (отрезано от "Давно не работала с gentoo")

[megabaks]

я убедился что ты неосилятор, потому твои циферки меня не возбуждают на публичное изнасилование системы.

[fragment]

я убедился что ты неосилятор

Не, ну тут просто массовые пения мантр какие-то: у одного "нинужно... нинужно...", у второго "неосилятор... неосилятор..."
Спрашиваешь подробности - опять мантры по кругу.

[megabaks]

подробности тебе предоставили.
ты же их не видишь в упор.
Фракталушка, умней уже.

[fragment]

подробности тебе предоставили.

Подробности чего? Что твоя система на OpenRC грузилась быстрее моей на OpenRC? И на основании этого ты делаешь вывод что я чего-то там не осилил?

Ты реально такой невменоз или просто в Эдика поиграть решил?

[eddy]

Да уж. Вся тема — позорище фракталушки...
Цирк одного клоуна!

А вот что на моем рабочем компьютере:

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

ps -O lstart 1 `pidof xdm`
  PID                  STARTED S TTY          TIME COMMAND
    1 Wed Dec 25 13:05:45 2013 S ?        00:00:13 init [5]
 1434 Wed Dec 25 13:08:47 2013 S ?        00:00:00 /usr/bin/xdm -nodaemon

[yars]

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

ps -O lstart 1 `pidof slim`
  PID                  STARTED S TTY          TIME COMMAND
    1 Mon Jan 27 12:36:03 2014 S ?        00:00:00 init [4]
  589 Mon Jan 27 12:36:32 2014 S ?        00:00:01 /usr/bin/slim

[fragment]

Вы к чему тут выкладываете эти листинги? Что с чем сравниваете вообще? абалдеть

[yars]

Как к чему - у кого сколько времени система грузится до входа в графику ~29 секунд для моего железа - более чем нормально.

[fragment]

yars, а что за железо у вас?

[eddy]

Вы к чему тут выкладываете эти листинги? Что с чем сравниваете вообще? абалдеть

С тем, что не у всех только игрушки на компьютере. У кого-то еще и сервисы разные запускаются.
Вечерком могу то же самое для бука своего привести. Самому интересно, сколько секунд от init до startx проходит.

[fragment]

С тем, что не у всех только игрушки на компьютере. У кого-то еще и сервисы разные запускаются.

А зачем ты напихал в загрузку тонну игрушек?

[yars]

а что за железо у вас?

Процессор - Intel Pentium 4 2.4 GHz
Память - DDR 512 Mb
Материнская плата - Gigabyte GA-81PE1000
Видеокарта - NVIDIA GeForce FX5200
HDD - 160 Gb SATA Seagate ST3160827AS.

[Rootlexx]

Например "They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc." я считаю ложью в каждом слове.

Первые три достаточно субъективны, но их высказал очень уважаемый в сообществе и опытный человек, который сам является разработчиком и поддерживает несколько пакетов. Вот его объяснение, почему по его мнению необходимо выбрать systemd как систему инициализации по умолчанию в Debian (естественно, большинство аргументов не эксклюзивны для последнего).
В принципе, понятно, что специализированный декларативный синтаксис с ясным предназначением каждой директивы больше соответствует задаче, чем фактически полноценный язык программирования общего назначения. Разумеется, многие вещи, доступные в systemd, в принципе можно реализовать и на shell, но если, скажем, выставление лимитов через ulimit тривиально, то помещение сервиса в собственную cgroup, файловый или сетевой namespace... - уже потребует серьёзной модификации скрипта и написание значительного куска кода. Именно поэтому многие возможности ядра Linux сегодня практически не используются, а systemd наконец делает их доступными.
Далее, модификация скрипта несёт проблемы при обновлении, ибо придётся вручную переносить свои модификации из старого скрипта в новый. С декларативным синтаксисом это намного легче, а учитывая возможность легко переопределять любую директиву, не трогая дистрибутивный файл .service - вообще тривиально. systemd даже предоставляет специальную утилиту systemd-delta, упрощающую контроль этих изменений.
Кроме того, у скриптов фактически нет состояния. Скажем, было бы полезно узнать код выхода упавшего сервиса. systemd не просто запускает процесс и "забывает" о нём, но и следит за его выполнением и статусом. Например:

root

# systemctl status netcfg.service netcfg.service - Netcfg multi-profile daemon Loaded: loaded (/usr/lib/systemd/system/netcfg.service; enabled) Active: failed (Result: exit-code) since Пт 2013-02-08 13:15:42 MSK; 1h 21min ago Main PID: 166 (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/netcfg.service фев 08 13:15:43 darkstar netcfg-daemon[166]: No recorded netcfg state to restore #

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

То, что для изучения systemd потребуется много читать - правда. Думаю, это одна из главных причин лютой ненависти к нему .
Однако для написания надёжных init-скриптов требуется очень хорошее знание shell и её особенностей, что не всегда верно даже для опытных разработчиков.
Кроме того, на shell приходится писать много сопутствующего кода, чтобы скрипт корректно работал в граничных случаях, о части которых написано по второй моей ссылке:

For those who don't agree, please try the exercise of writing systemd and
upstart configuration files for some typical daemon package and look at
the number of lines of code in both and the behavior in edge cases (daemon
already running, daemon running but with no PID file because something
else deleted it, daemon part of a dependency chain that shouldn't fire
until the daemon is actually listening to the network, correct exit status
for various failure conditions, stopping the daemon when there is a user
process with the same name as the daemon also running, and the other cases
Policy says one must handle). Now compare the length of time it took you
to make an init script correctly handle all those cases versus how long it
took to write the upstart or systemd configuration. (Note that I have
found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while
working on Debian, so even if you start from that file, which is only
applicable to a relatively narrow range of circumstances, you can still
fail edge cases.)

Удобство и логичность тоже нужны

от любого нововведения есть плюсы и минусы. В любом случае, нововведения по крайне мере неудобны. Кроме того, нововведения не логичны, ибо логика -- понятие субъективное. И systemd очевидно нелогичен по логике init scripts.

Логичность, разумеется, является субъективным показателем. Потому я и написал:

многие вещи в нём на мой взгляд достаточно логичны

Например, тут выше жаловались, что, мол, systemd включает в себя функциональность cron - но ведь последний выполняет по сути ту же функцию, что и init, только не при загрузке, а по расписанию. systemd реализовал достаточно функциональную систему запуска и контроля процессов, которые могут запускаться: по требованию, по зависимости других процессов, по обращению к сокету, по обращению к соответствующему сервису dbus - мне представляется вполне логичным расширить этот список и временными триггерами запуска. И всё это настраивается в единой манере, для всего этого доступны все полезные функции, всё это централизованно контролируется и управляется.
А cron, at, syslog и остальные традиционные сервисы у вас никто не отнимает.

Уже сейчас Gnome тащит за собой systemd, а дальше от него вообще будет не избавится. ПО без него просто не будет работать.

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

[Rootlexx]

Фишка systemd в том, что DM показывается юзеру до того, как запустятся остальные сервисы.

Это фишка всех систем инициализации, использующих параллельный запуск сервисов. В том числе и стандартной в Debian .

[Bizdelnick]

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

...и централизованно ломается.
Не юниксвейно как-то всё в одну программу пихать, не кажется? Если бы systemd был просто системой инициализации (одной из), в этом не было бы ничего особо плохого. Но он вбирает в себя функционал кучи сервисов, а то и просто поглощает их, как udev. И я вижу только одно объяснение этому: Red Hat пытается сделать все дистрибутивы без исключения зависимыми от своих разработок и вернуть себе положение монополиста и апстрима всея линукса. При всём моём уважении к Red Hat мне эти поползновения не нравятся.

[Rootlexx]

...и централизованно ломается.
Не юниксвейно как-то всё в одну программу пихать, не кажется?

А ломается ли ?
Что же касается UNIX-way, то во-первых, для меня соответствие каким-то обобщающим принципам не является некой священной коровой, которой нельзя пожертвовать даже при технической целесообразности, а во-вторых, по мне UNIX-way скорее описывает прикладные пользовательские программы, которые имеет смысл комбинировать между собой, а не системные. Кроме того, systemd - это не одна программа:

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

/bin/journalctl
/bin/loginctl
/bin/systemctl
/bin/systemd
/bin/systemd-ask-password
/bin/systemd-inhibit
/bin/systemd-machine-id-setup
/bin/systemd-notify
/bin/systemd-tmpfiles
/bin/systemd-tty-ask-password-agent
/lib/systemd/systemd
/lib/systemd/systemd-ac-power
/lib/systemd/systemd-activate
/lib/systemd/systemd-binfmt
/lib/systemd/systemd-bootchart
/lib/systemd/systemd-cgroups-agent
/lib/systemd/systemd-cryptsetup
/lib/systemd/systemd-fsck
/lib/systemd/systemd-hostnamed
/lib/systemd/systemd-initctl
/lib/systemd/systemd-journald
/lib/systemd/systemd-localed
/lib/systemd/systemd-logind
/lib/systemd/systemd-logind-launch
/lib/systemd/systemd-modules-load
/lib/systemd/systemd-multi-seat-x
/lib/systemd/systemd-quotacheck
/lib/systemd/systemd-random-seed
/lib/systemd/systemd-readahead
/lib/systemd/systemd-remount-fs
/lib/systemd/systemd-reply-password
/lib/systemd/systemd-shutdown
/lib/systemd/systemd-shutdownd
/lib/systemd/systemd-sleep
/lib/systemd/systemd-sysctl
/lib/systemd/systemd-timedated
/lib/systemd/systemd-timestamp
/lib/systemd/systemd-update-utmp
/lib/systemd/systemd-user-sessions
/usr/bin/hostnamectl
/usr/bin/localectl
/usr/bin/systemd-analyze
/usr/bin/systemd-cat
/usr/bin/systemd-cgls
/usr/bin/systemd-cgtop
/usr/bin/systemd-delta
/usr/bin/systemd-detect-virt
/usr/bin/systemd-nspawn
/usr/bin/systemd-stdio-bridge
/usr/bin/timedatectl

И я вижу только одно объяснение этому: Red Hat пытается сделать все дистрибутивы без исключения зависимыми от своих разработок и вернуть себе положение монополиста и апстрима всея линукса. При всём моём уважении к Red Hat мне эти поползновения не нравятся.

Red Hat разрабатывает GNOME, Red Hat разрабатывает coreutils, Red Hat разрабатывает glibc, Red Hat разрабатывает ядро - а волнует всех только systemd.

[yars]

GNOME, Red Hat разрабатывает coreutils, Red Hat разрабатывает glibc, Red Hat разрабатывает ядро

Их вклад в это все большой, да. Но разрабатывает все это не Red Hat.

[fragment]

GNOME, Red Hat разрабатывает coreutils, Red Hat разрабатывает glibc, Red Hat разрабатывает ядро

Их вклад в это все большой, да. Но разрабатывает все это не Red Hat.

С systemd та же фигня.

[Bizdelnick]

Red Hat разрабатывает GNOME, Red Hat разрабатывает ядро, Red Hat разрабатывает glibc, Red Hat разрабатывает coreutils - а волнует всех только systemd.

Правильно, потому что только systemd разрабатывается изначально и исключительно Red Hat. Да, насчёт glibc ты вроде погорячился: они тянут в пакетах кучу патчей к нему, потому что влияния на апстрим у них нет (по крайней мере ещё пару лет назад так было). А про их существенный вклад в coreutils вообще впервые слышу. С GNOME же всё просто - им можно не пользоваться (а с выходом 3 версии - даже нужно).

[yars]

С systemd та же фигня.

Где работает Поттеринг?

[Rootlexx]

GNOME, Red Hat разрабатывает coreutils, Red Hat разрабатывает glibc, Red Hat разрабатывает ядро

Их вклад в это все большой, да. Но разрабатывает все это не Red Hat.

...точно так же как systemd разрабатывает не только Red Hat. Скажем, два сопровождающих systemd в Debian имеют commit access.
Не говоря уже о том, что это свободное ПО, и если вдруг что-то пойдёт не так, всегда можно сделать форк.

[Rootlexx]

Правильно, потому что только systemd разрабатывается изначально и исключительно Red Hat.

Судя по данным, у systemd было 158 contributors за последние 12 месяцев, 488 за всё время. Там же есть список - можете сами проверить, сколько из них работают в Red Hat.

[Bizdelnick]

Правильно, потому что только systemd разрабатывается изначально и исключительно Red Hat.

Судя по данным, у systemd было 158 contributors за последние 12 месяцев, 488 за всё время. Там же есть список - можете сами проверить, сколько из них работают в Red Hat.

Мне, естественно, лень этим заниматься. Мне достаточно знать, что командуют разработкой Леннарт и Ко, и основные модификации делаются ими. Кто ещё сколько строчек коммитил - не суть важно.

[fragment]

С systemd та же фигня.

Где работает Поттеринг?

На Поттеринге свет клином не сошёлся.

Мне, естественно, лень этим заниматься. Мне достаточно знать...

Железобетонная позиция

[Rootlexx]

Мне достаточно знать, что командуют разработкой Леннарт и Ко,

С аргументами ad hominem не поспоришь. Поэтому не буду даже пытаться.

[Bizdelnick]

Ну почему же, попытаться-то можно. Если есть время выснять, где работают полтораста человек.

[eddy]

Как и обещал, вот с ноутбука:

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

ps -O lstart 1 `pidof X`
  PID                  STARTED S TTY          TIME COMMAND
    1 Mon Jan 27 15:40:08 2014 S ?        00:00:00 init [5]
 2723 Mon Jan 27 15:40:26 2014 S tty7     00:03:26 /usr/bin/X -nolisten tcp :0 -auth /tmp/serverauth.uCtGIAlnJ2

18 секунд на полный старт системы. И все сервисы уже запущены

[fragment]

eddy, небось, с каким-нибудь убогим недоразумением вместо рабочего DE?

[Женя Подсыпальников]

Как и обещал, вот с ноутбука:

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

ps -O lstart 1 `pidof X`
  PID                  STARTED S TTY          TIME COMMAND
    1 Mon Jan 27 15:40:08 2014 S ?        00:00:00 init [5]
 2723 Mon Jan 27 15:40:26 2014 S tty7     00:03:26 /usr/bin/X -nolisten tcp :0 -auth /tmp/serverauth.uCtGIAlnJ2

18 секунд на полный старт системы. И все сервисы уже запущены

Зашибатый результат. А сеть - на загрузке ли потом ?

[eddy]

eddy, небось, с каким-нибудь убогим недоразумением вместо рабочего DE?

Нет, с IceWM. Говна не держим!

А сеть - на загрузке ли потом ?

Я же сказал - это полная готовность. Так долго из-за вайфая (соединение секунд 10 устанавливается). Когда была проводная, гораздо шустрей стартовал бук.
А у Фрактала за это время только логин-менеджер появится. Потом еще минуту будут четверокеды грузиться. Зато за это время (возможно) успеет подняться сеть...