Почему systemd? (comparison of init systems)

Обсуждение новостей, соответствующих тематике форума

Модератор: Модераторы разделов

Ответить
Аватара пользователя
deadhead
Сообщения: 1913
Статус: zzz..z

Почему systemd?

Сообщение deadhead »

Леннарт Поттеринг (Lennart Poettering), создатель системного менеджера systemd представил в своем блоге сравнительный анализ систем инициализации: sysvinit, upstart, systemd. Другие системы инициализации не затронуты в обзоре ввиду их "незначительной роли в общей картине" Сравнение производилось по трем "большим" группам: общие характеристики, предоставляемые настройки и группа "разное".
Автор делится мыслями по развитию системы, коротко затрагивает вопрос сложности перехода на systemd с других систем инициализации (особо подчеркивается случай встраиваемых систем). Также автор считает, что systemd является хорошей основой для стандартизации системы инициализации в различных GNU/Linux дистрибутивах.

Статья (англ.)

Update

Леннарт Поттеринг (Lennart Poettering) и Кей Сиверс (Kay Sievers) опубликовали описание того как они собираются расширить systemd переняв функционал от ConsloeKit.

Источник (англ.)
Описание (англ.)
[x] close
Спасибо сказали:
Аватара пользователя
romuil
Сообщения: 2095
Статус: Ромунцель
ОС: ALTLinux Sisyphus

Re: Почему systemd?

Сообщение romuil »

перешел на systemd - волос мягкий и шелковистый
Спасибо сказали:
Аватара пользователя
taaroa
Сообщения: 1319

Re: Почему systemd?

Сообщение taaroa »

спасибо за новость. хороший обзор возможностей.
:wq
Спасибо сказали:
Аватара пользователя
rssbot
Бот
Сообщения: 6002
ОС: gnu/linux

Re: Почему systemd?

Сообщение rssbot »


Приблизительно год назад Леннарт Поттеринг (Lennart Poettering), сотрудник компании Red Hat, создавший в свое время звуковой сервер PulseAudio, начал разработку новой системы инициализации и управления сервисами под названием systemd. На создание замены SysVinit, существующей уже несколько десятков лет со времён первых Unix систем, Леннарта сподвигли недостатки традиционной системы и её несоответствие реалиям нашего времени - появлению SSD-накопителей, обладающих практически нулевым временем поиска нужных данных и огромной скоростью, посему способных обеспечить параллельную загрузку информации. Другой проблемой SysVinit является её зависимость от множества достаточно тяжёлых и не очень быстрых приложений - bash, awk, sed и других, которые не отличаются скорой работы на встраиваемых системах. Учитывая, что Linux стал использоваться на серверах, где требуется повышенная отказоустойчивость, от SysVinit потребовалась возможность слежения и перезапуска сервисов в случае их краха, которую она не обеспечивала. Первым дистрибутивом, где systemd будет использоваться по умолчанию станет Fedora 15, готовящаяся к выпуску в конце мая этого года. Разработчики OpenSUSE собираются использовать systemd в следующем стабильном релизе 12.1. Arch, Debian, Gentoo включают поддержку systemd в экспериментальном режиме. Разработчики Mandriva также планируют использовать systemd. Следует учитывать, что при использовании ядра с собственной конфигурацией, systemd требует включения некоторых параметров ядра. Леннарт Поттеринг опубликовал развёрнутое сравнение systemd, upstart и SysVinit, которое не оставляет никаких сомнений в том, что systemd станет стандартом де-факто в мире Linux.
sysvinit Upstart systemd
Управление через D-Bus нет да да
Запуск без использования bash/shell скриптов нет нет да
Включены сервисы ранней стадии загрузки, написанные на языке C нет нет да
Возможность упреждающего чтения данных с диска нет нет[1] да
Активация сервисов на основе сокетов нет нет[1] да
Активация сервисов на основе сокетов: совместимость с inetd нет нет[2] да
Активация на основе шины (Bus-based Activation) нет нет[3] да
Активация на основе аппаратуры компьютера нет нет[4] да
Конфигурирование зависимостей устройств, используя правила udev нет нет да
Активация по событиям файловой системы (inotify) нет нет да
Активация по времени нет нет да
Управление точками монтирования нет нет[5] да
Управление запуском fsck нет нет[5] да
Управление квотами нет нет да
Управление автомонтированием нет нет да
Управление SWAP нет нет да
Сохранение снимков состояния системы (snapshotting) нет нет да
Поддержка XDG_RUNTIME_DIR нет нет да
Опциональная остановка процессов пользователя после его выхода из системы нет нет да
Интеграция с Linux Control Groups (cgroups) нет нет да
Генерация событий аудита для запускаемых сервисов нет нет да
Интеграция с SELinux нет нет да
Интеграция с PAM нет нет да
Управление шифрованными разделами и дисками (LUKS) нет нет да
Управление сертификатами SSL и паролями LUKS для Plymouth, консоли, wall, tty терминалов и GNOME агента нет нет да
Управление сетевым петлевым устройством (loopback) нет нет да
Управление binfmt_misc (поддержка неродных исполняемых файлов) нет нет да
Управление системной локалью нет нет да
Настройка параметров консоли и клавиатуры нет нет да
Инфраструктура для создания, удаления и чистки временных файлов нет нет да
Управление через /proc/sys sysctl нет нет да
Интеграция с plymouth (графическим запуском, используя KMS) нет нет да
Сохранение и восстановление random seed (состояния генератора энтропии) нет нет да
Поддержка статической загрузки модулей ядра нет нет да
Автоматическое управление консолью COM-порта нет нет да
Управление уникальным ID компьютера нет нет да
Управление динамическим именем хоста и метаданными компьютера нет нет да
Контролируемая остановка сервисов нет нет да
Поддержка раннего логгирования через /dev/log нет нет да
Включает минимальный демон логгирования на основе kmsg для встраиваемых систем нет нет да
Перезаупск сервисов в случае краха без потери соединения нет нет да
Безшовное обновление сервисов нет нет да
Графический интерфейс пользователя (опциальнально) нет нет да
Встроена поддержка профилирования и расширенных инструментов нет нет да
Поддержка сервисов типа "instantiated" нет да да
Интеграция с PolicyKit нет нет да
Есть встроенные утилиты для удалённого доступа и управления кластером нет нет да
Может показать все процессы, принадлежащие сервису нет нет да
Может идентифицировать процессы сервиса нет нет да
Автоматически создаёт cgroups для сервисов для равномерного распрделения времени CPU нет нет да
Аналогично для пользовательских процессов нет нет да
Совместимость с SysV да да да
Сервисы SysV контролируются как родные сервисы да нет да
Упралвение сервисами через /dev/initctl да нет да
Перезапуск сервисов с полной серализацией (serialization) состояния да нет да
Поддержка интерактивного (управлямеого) запуска системы нет[6] нет[6] да
Поддержка контейнеров (как расширенная замена chroot()) нет нет да
Загрузка, построенная на основе зависимостей нет[7] нет да
Отключение сервисов без редактирования файлов да нет да
Маскировка сервисов без редактирования файлов нет нет да
Надёжная остановка системы, используя только один процесс нет нет да
Встроенная поддержка перезапуска ядра на лету (kexec) нет нет да
Динамическая генерация сервисов нет нет да
Поддержка в других компонентах ОС да нет да
Файлы запуска сервисов, совместимые с различными дистрибутивами нет нет да
Отправка сигналов сервисам нет нет да
Надёжная остановка пользовательских сессий перед остановом системы нет нет да
Поддержка логгирования в utmp/wtmp да да да
Легкие для написания, расширения и обработки файлы управления сервисами, подходящие для манипулирования инструментами управления предприятием нет нет да

[1] Реализация упреждающего чтения в Upstart доступна в виде отдельного пакета ureadahead и требует наложения патча на ядро
[2] Активация через сокеты в upstart является экспериментальной возможностью, а также не поддерживает сериализацию, поэтому вообще не подходит для этого.
[3] Активация через шину для upstart доступна пока только в виде патча, который в основную ветку разработки ещё не принят.
[4] реализация в upstart не является практичной.
[5] Данная возможность для upstart существует в виде отдельного пакета и работает только для монтирования во время загрузки, плохо поддерживая зависимости.
[6] Некоторые дистрибутивы реализуют эту возможность с помощью shell скриптов.
[7] Скрипты инициализации LSB поддерживают это, в случае если они используются.
Также systemd предлагает огромные возможности по установке параметров запускаемых сервисов:
  • параметры OOM;
  • рабочая директория;
  • root-директория (аналог chroot);
  • переменные среды;
  • переменные среды из внешнего файла;
  • ограничения по ресурсам;
  • umask;
  • user/group ID;
  • приоритет и класс ввода/вывода;
  • Настройки CPU (привязка к ядрам, приоритет, значение nice, сброс параметров для форка процессов);
  • и многое другое.



Источник: http://www.opennet.ru/opennews/art.shtml?num=30412


оригинал на opennet.ru
Спасибо сказали:
Аватара пользователя
Stauffenberg
Сообщения: 2042
Статус: ☮ PEACE ☮
ОС: открытая и свободная

Re: Почему systemd?

Сообщение Stauffenberg »

deadhead писал(а):
29.04.2011 19:09
Леннарт Поттеринг (Lennart Poettering), создатель системного менеджера systemd представил в своем блоге сравнительный анализ систем инициализации: sysvinit, upstart, systemd. Другие системы инициализации не затронуты в обзоре ввиду их "незначительной роли в общей картине" Сравнение производилось по трем "большим" группам: общие характеристики, предоставляемые настройки и группа "разное".
Автор делится мыслями по развитию системы, коротко затрагивает вопрос сложности перехода на systemd с других систем инициализации (особо подчеркивается случай встраиваемых систем). Также автор считает, что systemd является хорошей основой для стандартизации системы инициализации в различных GNU/Linux дистрибутивах.

Статья


Rindfleischfischteich mit Bier

LOL

Спасибо за линк, интересно почитать. Там, кстати, все статьи занимательные.
Labor omnia vincit

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
Спасибо сказали:
Аватара пользователя
/dev/random
Администратор
Сообщения: 5282
ОС: Gentoo

Re: Почему systemd?

Сообщение /dev/random »

Кошмар. Init, зависящий от dbus... Я очень надеюсь, что с этим bloatware мне столкнуться не придётся.
Спасибо сказали:
Аватара пользователя
taaroa
Сообщения: 1319

Re: Почему systemd?

Сообщение taaroa »

/dev/random писал(а):
29.04.2011 23:38
Я очень надеюсь, что с этим bloatware мне столкнуться не придётся.

оно уже здесь!!1
:wq
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu
Контактная информация:

Re: Почему systemd?

Сообщение serzh-z »

/dev/random писал(а):
29.04.2011 23:38
Я очень надеюсь, что с этим bloatware мне столкнуться не придётся.
Судя по всему, systemd всем дистрам пришёлся по нраву. Если у него будет поддержка со стороны разных дистростроителей, то почему бы ему и не стать мейнстримом.

Хотя, в Gentoo (stable) на это надеяться, думаю, не стоит). Благо, там и родная система инициализации хороша.

/dev/random писал(а):
29.04.2011 23:38
Кошмар. Init, зависящий от dbus...
Что плохого в универсальной шине сообщений? Это непривычно, но это всего лишь, как понимаю, интерфейс (или один из интерфейсов) к systemd
Спасибо сказали:
Аватара пользователя
aiming
Сообщения: 375
ОС: DEBIAN 6
Контактная информация:

Re: Почему systemd?

Сообщение aiming »

кустарно...что-то мне это напоминает.
никто не запомнит тебя за твои мысли.
Спасибо сказали:
Ответить