LINUX.ORG.RU

Февральские тезисы о планах развития systemd

 ,


2

4

На прошедшей конференции FOSDEM Леннарт Поттеринг огласил некоторые перспективы развития systemd:

  • Интеграция в systemd загрузчика gummiboot, поддерживающего технологию UEFI Secure Boot.
  • machined — менеджер регистрации виртуальных машин, спроектированный под впечатлением от Solaris Zones.
  • В подсистеме nspawn и смежных с ней ожидается больше возможностей для управления контейнерами, например, journald сможет собирать логи не только с хоста, но и с контейнеров.
  • Уже в следующей версии ожидается улучшенная поддержка Btrfs (подразделы и снапшоты Btrfs планируется использовать для изоляции отдельных приложений).
  • Поддержка HiDPI и Юникода в consoled.
  • Сервис-ориентированный фаерволл: можно будет задавать правила в привязке не к номерам портов, а к именам процессов.
  • Отпадёт нужда указывать путь к юниту для systemctl-cat; systemctl-edit позволит редактировать юниты и после сохранения изменений автоматически перезапускать соответствующие сервисы.
  • nss-getmyhostname — функция для получения имени хоста на stateless-системах.
  • Утилита ping gateway позволит автоматически определить все доступные сетевые интерфейсы и проверить их статус командой ping.
  • Развитие networkd и собственной библиотеки для работы с DHCP (совместимой с dhcpv4 и dhcpv6).
  • Комбинирование nspawn и networkd позволит легко конфигурировать сеть для контейнеров.
  • Создание средств для широкого системного аудита, интегрированных в journald. Например, станет возможным логировать все системные вызовы к файлу /etc/passwd.
  • Движение в сторону stateless-систем, у которых только /usr доступен на чтение и запись, а /etc и /var будут автоматически заполняться systemd.
  • journald-remoting — удалённая работа логгера через HTTP. Поддержка в journald моделей pull и push: при pull выполняется запрос HTTP GET для получения потока JSON, а при push данные передаются в другой экземпляр journald при помощи HTTP POST.
  • Возможность определения для сервисов минимальных пространств имён и sandbox-изоляции: доступ к некоторым разделам и каталогам только на чтение, сокрытие устройств в /dev, приватный /tmp для каждого сервиса, и др.
  • timesyncd в качестве замены ntpd.
  • Автоматическое определение разделов GPT, не нуждающееся в указании их в fstab.
  • Поддержка перезапуска демонов без потери их состояния (посредством сохранения оного на диск).

>>> Подробности



Проверено: Shaman007 ()
Ответ на: комментарий от intelfx

Как минимум на 50% - да. Правильно раскладывать один архив исходников на несколько бинарных, больший гимор, нежели при соотношении архив-пакет. Проще делегировать поддержку пакетов. Плюс, есть гарантия, что удаление из системы timesyncd/чего-то другого, с учётом того, что оно было включено при конфигурации, а как следствие другим компонентам тоже становится об этом известно и они могут завязаться на это, не поломает чего-то? Где гарантия отсутствия сильной связанности? Да и вообще, я нигде ещё не видел внятного ответа: зачем в ОДИН проект тянуть всё, что только можно, да ещё и дистрибутировать в одном пакете? В чём сакральный смысл?

h4tr3d ★★★★★ ()
Ответ на: комментарий от intelfx

Не стало. Открой страшную тайну.

А подумать? Ты только что ответил что вся эта каша взаимопересвязана, соответственно пихать ее в разные пакеты смысла нет никакого. Все-равно придется установить их все чтобы система взлетела.
Ну и логично, что народ не понимает какого хрена система инициализации втащила в себя это все и так завязана по компонентам друг на друга. Я вот модульности тут не усматриваю. Убери любой из них и поведение станет непредсказуемым.

Q-Master ()
Ответ на: комментарий от Q-Master

Нет. Ты не понял. Я перечислил 11 зависимостей (и забыл ещё семь), причём они неплохо так кластеризованы, плюс 11 зависимостей *ctl от *d. Это означает, что все остальные бинарники, шестьдесят штук, ни от чего не зависят, а эти можно разбить на группы вида «основной демон + две-три вспомогательные программы», и каждая такая группа будет зависеть максимум от ещё одной. Поэтому

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

Нет.

Ну как бы всё, больше нечего говорить. Если хейтерство затмило глаза — тогда жаль.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ну в том что ты перечислил зависимости циклические, что кагбэ не отменяет несколько пакетов, но в целом делает их наличие бессмысленным. Зависимости будут их их не отменит рассовывание по пакетам. Хорошо что можно разгруппировать по отдельным пакетам 60 бинарников которые «ни от чего не зависят», но тогда не очень понятно зачем они надо в одном и том-же репозитории? Помойка-же получается.

Q-Master ()
Ответ на: комментарий от Q-Master

зависимости циклические

Где? Нет там циклических зависимостей.

тогда не очень понятно зачем они надо в одном и том-же репозитории?

Потому что у всех этих программ много общего утилитарного кода, которому пришлось бы в противном случае иметь свой публичный API.

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

Пока не понял они «независимые» или «много общего утилитарного кода».
В случае общего утилитарного кода такие вещи надо в библиотеки выносить и использовать публичный апи, а не компилировать в каждый бинарник свою копию.
Кстати, а почему systemd-cat внезапно делает exec, а не cat?

Q-Master ()
Ответ на: комментарий от Q-Master

Пока не понял они «независимые» или «много общего утилитарного кода»

Здесь нет взаимоисключения. На примере: ls и grep становятся менее независимыми оттого, что оба используют утилитарные функции из общей внутренней библиотеки libcoreutils?

В случае общего утилитарного кода такие вещи надо в библиотеки выносить и использовать публичный апи, а не компилировать в каждый бинарник свою копию.

Обоснуй. Я не согласен с тем, что в этом есть какая-либо польза, компенсирующая усложнение разработки за счёт необходимости поддержания ещё одного API.

Кстати, а почему systemd-cat внезапно делает exec, а не cat?

А почему нет?

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Здесь нет взаимоисключения. На примере: ls и grep становятся менее независимыми оттого, что оба используют утилитарные функции из общей внутренней библиотеки libcoreutils?

Согласен, но:

Обоснуй. Я не согласен с тем, что в этом есть какая-либо польза, компенсирующая усложнение разработки за счёт необходимости поддержания ещё одного API.

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

Q-Master ()
Ответ на: комментарий от Q-Master

<...> идет в разрез с вышевысказанным

Где?

У coreutils есть собственная внутрипроектная статическая библиотека libcoreutils с различными утилитарными функциями.

У systemd есть собственная внутрипроектная статическая библиотека libsystemd-internal с различными утилитарными функциями.

Если такие вещи не понятны и не очевидны

Ни те, ни другие не занимаются выделением этих библиотек в public API, потому что это сверхбольшой геморрой. Когда такая либа внутрипроектная, при рефакторинге достаточно пройтись sed'ом по всему коду. Когда она представляет собой публичный интерфейс — хрен ты что отрефакторишь.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Когда такая либа внутрипроектная, при рефакторинге достаточно пройтись sed'ом по всему коду. Когда она представляет собой публичный интерфейс — хрен ты что отрефакторишь.

Очень посмеялся. Непонятно как живут другие проекты и рефакторят все... Прям ну вообще не понятно. Тот-же kdevelop с его плагинами...

Q-Master ()
Ответ на: комментарий от Q-Master

Смейся дальше.

Существует разница между фреймворком и набором вспомогательных однострочников. Делать из последних публичный API и стабилизировать его — геморрой ради ничего.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.