Разработчики Arch Linux начали обсуждение возможности перехода от SysV к systemd в ближайшем будущем

А что, в Арче был классический SystemV Init?

Да, но со скриптами в стиле BSD.

Аллан МакРей (Allan McRae) здесь обьясняет почему арч еще торт.

Ъ: «Я сам не пробовал systemd и не знаю, хорош он, или плох, но я считаю, что мы должны на него перейти потому что он новый».
Волшебно.

Вы точно обратили внимание на слово «классический»?

Ну, мало ли, что вы под этим словом подразумевали. В контексте новости его значение ближе к «старый добрый».

У меня в аче уже systemd, всё как работало так и работает. По скорости загрузки на глаз монопенисуально.

+1

Увы, ничего из этого не осталось. Теперь вся надежда только на Plan B & Inferno.

//fixed

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

И снова плюсану. :)

О да, план он таааак забииииираааааееет

она одна, описана в arch way, и systemd ей противоречит не больше чем initscripts

И еще: поскольку арч не позиционируется для серверов, то и справедливые претензии к systemd по части серверного применения для него не актуальны. А вот в рамках RH — другое дело. Но это уже личные проблемы RH и её пользователей.

Ссылку уже привели, так что добавлю от себя всего одну фразу «любое ПО, которое архитектурно является комбайном, нарушает принцип KISS»

Интеграция udev, ..., интеграция journald, интеграция crond

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

интеграция cgroup

Конечно, процессы веселей ручками по cgroups распихивать.

интеграция ...consolekit?

Он сдох. Вместо него теперь будет systemd-logind.

И вот накрылся systemctl

С чего вдруг?

> Интеграция udev, ..., интеграция journald, интеграция crond

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

Вот и практически готовый ответ на вопрос «Почему все так ненавидят Леннарта?»

Вместо того, чтобы описать API и сделать Reference Implementation каждого из свих модулей он все прибивает гвоздями в один архив/сборник программ.

А люди не любят, когда им что-то навязывают.

Ну вот и кто он после этого?

А тем временем в соседнем треде maxcom пишет...

Толсто.

> А тем временем в соседнем треде maxcom пишет...

Толсто.

Зато жизненно.

/me рад, что не перешёл на арч

Наверное тем, что грузится слишком быстро по сравнению с system V, и рядовой анонимус с лора не успевает прочитать все логи загрузки, которые мелькают на экране :)

Спасибо. Интересно. Когда будет время, обязательно посмотрю.

Вот как знал, когда снёс его со своей пандоры неделю назад.

Асинхронной загрузки сервисов нет, зависимостей нужных для неё тоже. Есть конечно всякие извращения на Bash для проверки что уже загрузилось, а что нет - но разве это зависимости, нужные из коробки? System V init писался в дремучую эпоху слабых процессоров, когда процессоры были недешёвым удовольствием, и на один ПК приходилось по одному процессору. Из-за этого реализация асинхронной загрузки тогда казалась не очень перспективной идеей.

Асинхронной загрузки сервисов нет, зависимостей нужных для неё тоже.

Ещё раз повторяю, идите читать вики. Арчевские initscripts прекрасно умеют грузить сервисы в фоне, и без всяких зависимостей.

А я одобряю.

Есть конечно всякие извращения на Bash

Это ты щас стандартизированные LSB-заголовки так назвал? Ok.

процессоры

Ололо. Systemd быстрее исключительно за счёт откладывания запуска всего, что только можно. Когда он работал «честно», то по сравнению с другими реализациями параллельной загрузки (я про sysvinit в Debian и upstart в Ubuntu) был ничуть не быстрее.

Арчевские initscripts прекрасно умеют грузить сервисы в фоне, и без всяких зависимостей.

Ну ты же понимаешь, что это может быть чревато, а потому требует вдумчивого управления, зачастую со страховочными подпорками в виде sleep (лично видел такую рекомендацию в этой вашей вики).

Ну ты же понимаешь, что это может быть чревато, а потому требует вдумчивого управления

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

Достаточно не бекграундить долго стартующие сервисы, от которых зависят другие.

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

### BEGIN INIT INFO
# Provides:          smartmontools
# Required-Start:    $syslog $remote_fs
# Required-Stop:     $syslog $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      1
# Short-Description: SMART monitoring daemon
### END INIT INFO

Время загрузки при этом всё равно зачастую меньше, чем с хвалёным systemd.

Эээ, когда я пробовал это поделие, XDM у меня появлялся где-то секунды через три-четыре после GRUB. Are you sure?

Ну вот я и говорю, что это надо предусматривать самому.

Тоже мне, бином Ньютона.

Разве это не KISS?

По вашей логике, KISS - это гуёвая программа с одной кнопкой «сделать зашибись». man KISS.

Эээ, когда я пробовал это поделие, XDM у меня появлялся где-то секунды через три-четыре после GRUB. Are you sure?

Definitely.

Тоже мне, бином Ньютона.

Пока сервисов 1.5-3 — никаких проблем :)

По вашей логике, KISS - это гуёвая программа с одной кнопкой «сделать зашибись». man KISS.

Какая программа, с какой кнопкой? Или в твоей версии (у арчеводов вообще ужасно разнообразное понимание принципов UNIX, чего стоят только рассуждения «rc.conf vs кучка-разных-файлов», тогда как это равнозначные сущности с точки зрения философии UNIX) KISS текстовые (пригодные для чтения и модификации человеком) метаданные, позволяющие автоматизировать то, что всё равно придётся делать руками, не нужны? Ok. ИЧСХ, только в Arch додумались до такого маразма, как параллельный запуск без учёта зависимостей — в *BSD так не упарываются.

Definitely.

Меньше 3 секунд на HDD? Сколько сервисов?

Пока сервисов 1.5-3 — никаких проблем :)

С полутора десятками у меня их тоже нет. Если у вас больше, то список в студию.

Меньше 3 секунд на HDD? Сколько сервисов?

Если все сервисы повырубать, то примерно секунды три до KDM и будет. Так - около семи. Я сужу больше по отзывам других.

Если у вас больше, то список в студию.

% --status-all
 [ + ]  acpid
 [ ? ]  alsa-utils
 [ - ]  anacron
 [ + ]  atd
 [ - ]  bootlogs
 [ ? ]  bootmisc.sh
 [ ? ]  checkfs.sh
 [ ? ]  checkroot-bootclean.sh
 [ - ]  checkroot.sh
 [ - ]  clamav-freshclam
 [ - ]  console-setup
 [ ? ]  cpufrequtils
 [ ? ]  cron
 [ ? ]  cryptdisks
 [ ? ]  cryptdisks-early
 [ + ]  dbus
 [ + ]  dictd
 [ + ]  fancontrol
 [ + ]  hddtemp
 [ ? ]  hdparm
 [ - ]  hostname.sh
 [ ? ]  hwclock.sh
 [ - ]  kbd
 [ - ]  keyboard-setup
 [ ? ]  killprocs
 [ ? ]  kmod
 [ - ]  lm-sensors
 [ ? ]  loadcpufreq
 [ - ]  lvm2
 [ - ]  masqmail
 [ + ]  mdadm
 [ ? ]  mdadm-raid
 [ - ]  motd
 [ ? ]  mountall-bootclean.sh
 [ ? ]  mountall.sh
 [ ? ]  mountdevsubfs.sh
 [ ? ]  mountkernfs.sh
 [ ? ]  mountnfs-bootclean.sh
 [ ? ]  mountnfs.sh
 [ - ]  mpd
 [ ? ]  mtab.sh
 [ ? ]  networking
 [ + ]  ntp
 [ ? ]  pppd-dns
 [ + ]  privoxy
 [ - ]  procps
 [ ? ]  qemu-kvm
 [ ? ]  rc.local
 [ - ]  rmnologin
 [ - ]  rsync
 [ + ]  rsyslog
 [ ? ]  sendsigs
 [ - ]  smartmontools
 [ + ]  ssh
 [ - ]  sudo
 [ + ]  udev
 [ ? ]  udev-mtab
 [ ? ]  umountfs
 [ ? ]  umountnfs.sh
 [ ? ]  umountroot
 [ - ]  urandom
 [ + ]  vnstat
 [ ? ]  webfs
 [ - ]  x11-common
 [ + ]  xdm

Если все сервисы повырубать, то примерно секунды три до KDM и будет.

А я ничего не отключал :) Но да, там сомнительные пути ускорения, сильно напоминающие некую проприетарную ОС, лидирующую на десктопах. Я считаю, что лучше знать о проблемах при запуске сервиса при загрузке, чем потом, когда он будет запущен «по событию».

Я сужу больше по отзывам других.

Не стоит.

А, да, на той конфигурации в списке были ещё apache2, postfix, virtualbox. hddtemp и smartmotools тоже заводятся небыстро, если дисков несколько.

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

Так большинство дискуссий на ЛОРе (и не только) идут по схеме: сторонники и противники НЕЧТЫ приводят подтверждение своих точек зрения какой-то дикий бред, имеющий мало общего с реальностью. А на их фоне изредка раздаются грамотные аргументы за и против, которые тонут в общем потоке :)

Из всего этого списка «демонами» в моём понимании является меньше четверти. Монтировщики FS, udev, и так далее, у меня, думаете, не стартуют? Я имел в виду всякие демоны вроде syslog, iptables, dbus и так далее.

Сейчас склонировал одну из своих систем в виртуалку и запилил туда systemd. На глаз, и правда, раза в полтора-два быстрее грузиться стала (от загрузчика до старта иксов, конечно же), так что тут был неправ.

демоны
iptables

Да, мутноватая тут классификация :)

Да, мутноватая тут классификация :)

Не то слово. Лично я имел в виду пункты в строке «DAEMONS» в rc.conf.

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

На всякий случай напомню, что диск виртуальной машины часто находится в кэше хоста.

Естественно, я сравнивал одну и ту же виртуалку с «init=/bin/systemd» и без.

Уговорили, сейчас буду на служебном буке переходить на системд

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

Ну, почти ничего не сломалось, на первый взгляд. Разве что русский в консоли пропал. Скорость примерно та же, вывод в консоль при загрузке существенно иной - ОК появляются не справа, а слева.

Русский починил. Пока полёт нормальный. Чем оно лучше - непонятно. Из того, что хуже - неудобно конфигурить, по сравнению с rc.conf и /etc/rc.d/...

А ты так говоришь, как будто не имеет.

А ты так говоришь, как будто не имеет.

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

Назови хоть одно устройство, где скорость загрузки важна.

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

По сравнению с слакой, очень понравилась структура системы тем, что она еще проще (2 ранлевела, не считая ребута и халта). Слакбилды писать нетрудно, а пкгбилды для крукса - вообще элементарно. Дистрибутив выпиливает документацию, и предпочитает держать одну локаль (если не согласен - можно изменить). Практически нет утилит конфигурирования. Хочешь сеть? Создай /etc/rc.d/net, и в нём пропиши ifconfig'ом. В вики показано как. В общем, если знаешь чего хочешь - дистр будет максимально простым и вспомогательным средством. Который, даже по сравнению с слакой - еще проще.

P.S. конфигурировать ядро самому придётся) И ядро, штатными средствами не обновляется. Хочешь новое - kernel.org. Короче, меня дистр поразил лаконичностью и _удивительной_ простотой.

ПК?

No.

Yes же.

No.

пропадали из {core,opt,config} репозиториев?

Не проблема самому написать, или нагуглить pkgbild.