LINUX.ORG.RU

systemd 219

 


2

4

16 февраля был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, ведения журнала, управления сессиями пользователей и работы с контейнерами. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые вспомогательные задачи (т. н. plumbing layer) — от настройки подсистемы VT (systemd-vconsole-setup) и первичного конфигурирования системы (systemd-firstboot) до управления сетью (systemd-networkd) и профилирования загрузки (systemd-bootchart).

Большая часть изменений, вошедших в этот релиз, была направлена на расширение возможностей по работе с контейнерами. Эти изменения сконцентрированы в компонентах systemd-machined и systemd-nspawn и нескольких сопутствующих утилитах.

Примечание переводчика: в плане новых контейнерных фич релиз получился крайне сырой; по факту мало что работает. Такое ощущение, что они тупо сделали промежуточный тарболл, чтобы заиметь чуть побольше тестеров.

Изменения в ядре systemd:

  • При остановке mount-юнита, соответствующего директории, на которую примонтировано более одного устройства, теперь производится отмонтирование всех устройств на этой точке монтирования. [Раньше, надо полагать, отмонтировалось только последнее. Более того, примонтировать несколько устройств на одну директорию средствами mount-юнитов по-прежнему невозможно. — Прим. пер.]
  • device-юниты, соответствующие приводам оптических дисков, теперь считаются активными только при наличии диска в приводе.
  • Все mount-юниты теперь автоматически получают зависимость BindsTo= от «своих» device-юнитов. Вкупе с предыдущим изменением это обеспечивает автоматическое [небезопасное, но так хотя бы /etc/mtab не захламляется — Прим. пер.] отмонтирование дисков и других носителей при их извлечении.
  • Введена концепция «неподдерживаемых» типов юнитов. Так, например, при попытке активировать busname-юнит на системе без kdbus он будет помечен как сбойный с комментарием «unsupported».

    Список типов юнитов, не поддерживаемых на некоторых конфигурациях:

    • .busname — на системах без kdbus;
    • .swap — в контейнерах; на системах с CONFIG_SWAP=n;
    • .automount — в контейнерах; на системах с CONFIG_AUTOFS4_FS=n;
    • .device — в контейнерах.
  • Суммарное потребление памяти всеми процессами юнита (атрибут memory.usage_in_bytes соответствующей контрольной группы) теперь экспортируется как свойство MemoryCurrent объекта юнита на шине и отображается в выводе команды systemctl status. Например:
    $ systemctl status systemd-journald
    ● systemd-journald.service - Journal Service
    [...]
     Main PID: 210 (systemd-journal)
       Status: "Processing requests..."
       Memory: 90.4M
    [...]
    
    $ busctl introspect org.freedesktop.systemd1 /org/freedesktop/systemd1/unit/systemd_2djournald_2eservice org.freedesktop.systemd1.Service
    NAME                                TYPE      SIGNATURE      RESULT/VALUE                             FLAGS
    [...]
    .MemoryAccounting                   property  b              true                                     -
    .MemoryCurrent                      property  t              94887936                                 -
    [...]
    

    [Стоит отметить, что это свойство отражает суммарный RSS и объём файлового кэша процессов в контрольной группе. Также, разумеется, это возможно только при задействовании контроллера memcg, т. е. CONFIG_MEMCG=y в конфигурации ядра и DefaultMemoryAccounting=true в /etc/systemd/system.conf. — Прим. пер.]

  • Генераторы юнитов теперь можно маскировать (по аналогии с самими юнитами), размещая в /{etc,run}/systemd/system-generators/ пустые файлы (или симлинки на /dev/null).
  • Для юнитов, присоединённых к терминалу (StandardInput=tty, StandardOutput=tty), будет автоматически устанавливаться переменная окружения TERM=vt220 (вместо vt102, как было ранее). Это должно исправить ошибки в приложениях, использующих нетривиальные возможности терминала (например, клавиши PgUp/PgDn).
  • Добавлен механизм, позволяющий процессам «сохранять» в PID 1 открытые файловые дескрипторы (например, на время собственного перезапуска). Эта возможность уже задействована в systemd-journald для того, чтобы избежать потери сообщений при перезапуске.

    Таким образом, все три «ключевых» компонента systemd (systemd, logind, journald) теперь способны перезапускаться с сохранением состояния.

    Технически этот механизм реализован через расширение API sd_notify(3) (функция sd_pid_notify_with_fds()). Для прикрепления файловых дескрипторов к сообщению используется концепция fd passing, а само сообщение должно содержать строку FDSTORE=1.

    Количество файловых дескрипторов, которое процессы юнита могут единовременно «сохранить» таким образом, ограничивается значением директивы FileDescriptorStoreMax= в секции [Service] unit-файлов (по умолчанию 0, т. е. нисколько).

  • Нажатие Ctrl-Alt-Del более семи раз в течение двух секунд теперь вызывает аварийный перезапуск системы, эквивалентный результату выполнения systemctl reboot -f (т. е. при этом все процессы завершаются, а файловые системы демонтируются или переводятся в режим «только для чтения»). Этот механизм стоит рассматривать как более «щадящую» альтернативу Alt-SysRq-B.
  • В файле /etc/crypttab (за его обработку отвечает systemd-cryptsetup-generator) добавлена поддержка параметра header= (как в Debian). Этот параметр позволяет указать расположение LUKS-заголовка, если он хранится на отдельном устройстве.
  • При копировании куда-либо каких-либо файлов (например, в контексте действия C в systemd-tmpfiles) компоненты systemd теперь сначала пытаются создавать reflink (на тех ФС, которые это поддерживают, в частности, btrfs и ocfs2). При отсутствии поддержки выполняется обычное копирование.

Изменения в утилитах и вспомогательных компонентах:

  • Команды loginctl user-status, loginctl session-status и machinectl status теперь также выводят (подобно systemctl status) последние несколько строчек из лога, ассоциированных с данным пользователем, сессией или контейнером соответственно. При этом в последнем случапе имеется в виду не внутренний лог самого контейнера, а лог того юнита, в котором он запущен (т. е., например, вывод systemd-nspawn).
  • Все подкоманды loginctl, которые принимают в качестве аргумента идентификатор сессии или имя пользователя (например, две вышеупомянутые), теперь могут быть вызваны без аргумента. В этом случае они применяются к той сессии, в которой (к тому пользователю, от имени которого) запущены.
  • В systemd-run добавлен параметр командной строки -t (--pty), позволяющий перенаправить ввод/вывод запускаемого процесса в текущую консоль (при этом он всё равно запускается как дочерний процесс systemd). Стоит отметить, что это также поддерживается при запуске процесса в другом контейнере.

    Например, команда systemd-run -t /bin/bash запустит рутовую оболочку в обход PAM и регистрации сессии.

  • В systemd-tmpfiles добавлено действие v — создание btrfs subvolume по указанному пути. В случае невозможности (если используется другая ФС) создаётся обычная директория (эквивалентно действию d).
  • В systemd-tmpfiles добавлено действие a — назначение файлу заданных ACL.
  • В комплект поставки включён скрипт для xinitrc.d, который сообщает systemd --user текущие значения переменных $DISPLAY и $XAUTHORITY. Это позволит «из коробки» запускать с помощью systemd --user графические приложения, взаимодействующие с X-сервером.

    [При этом никаких дополнительных зависимостей не проставляется, поэтому при завершении работы X-сервера все эти приложения не будут корректно прибиты и упадут вслед за сервером. Но лучше так, чем никак. Ждём, пока кто-нибудь придумает, как вписать иксы или вейланд в эту концепцию. — Прим. пер.]

  • В спецификацию формата файла /etc/os-release добавлено новое поле PRIVACY_POLICY_URL=, позволяющее создателям дистрибутива указать ссылку на его Privacy Policy.

Изменения в udev:

  • Часть API libudev, относящаяся к работе с hwdb (декларативной базой данных оборудования), вынесена в отдельную библиотеку sd-hwdb (заголовочный файл sd-hwdb.h), отделённую от libudev.

    Также добавлена вспомогательная утилита systemd-hwdb, позволяющая взаимодействовать с этой базой данных (пересобирать и производить тестовые запросы).

  • Эта самая hwdb теперь включает в себя информацию о «разрешающей способности» колёс прокрутки мышей (что-то вроде «повороту на какой угол соответствует одно событие») и различные сведения о тачпадах.

    [Напомню, что в версии 218 в hwdb начали собирать информацию о разрешающей способности самих оптических сенсоров мышей. Это делается для того, чтобы настройки ускорения курсора и скорости прокрутки работали одинаково на любом оборудовании. Разумеется, необходима поддержка этих свойств со стороны того, кто будет обрабатывать события с устройств ввода; насколько мне известно, это пилят в libinput. — Прим. пер.]

  • Физические размеры сенсорных экранов теперь отражены в атрибутах соответствующих им устройств ввода.

Изменения в journald:

  • systemd-journald теперь устанавливает btrfs-специфичный флаг FS_NOCOW на файлах журнала. Это должно повысить производительность на btrfs, поскольку типичная последовательность обращений к этим файлам [то, как journald работает с этими файлами] достаточно плохо ложится на механизм Copy-on-Write.

    Побочный эффект состоит в том, что также отключается btrfs-специфичный механизм проверки целостности файлов. Однако, это не является проблемой, поскольку формат файла журнала предусматривает собственный механизм контрольных сумм.

    Ещё одно изменение состоит в том, что systemd-journald теперь более корректно обрабатывает события переполнения диска (а именно — сигнал SIGBUS для файлов, отображённых в память) в тех случаях, когда использование fallocate(2) по тем или иным причинам не гарантирует выделения места. [Видимо, имеются в виду Copy-on-Write-ФС, отличные от btrfs. — Прим. пер.]

  • При удалении текущего файла журнала (того, в который сейчас ведётся запись) systemd-journald теперь это замечает и немедленно начинает запись в новый файл.

В networkd добавлена поддержка:

  • FDB-таблиц для соединений типа «мост» (секция [BridgeFDB] network-файлов);
  • сбора LLDP-оповещений (отображаются в выводе утилиты networkctl);
  • нескольких новых типов виртуальных сетевых устройств, а именно ipvlan, gretap, ip6gre, ip6gretap и ip6tnl (директива Kind= секции [NetDev] netdev-файлов);
  • автонастройки link-local IPv6-адресов (директива LinkLocalAddressing= секции [Network] network-файлов);
  • настройки перенаправления и маскарадинга IPv4/IPv6 отдельно для каждого интерфейса (директивы IPForward=, IPMasquerade= секции [Network] network-файлов);
  • явного задания scope (global, link, host) для создаваемых маршрутов (директива Scope= секции [Route] network-файлов);
  • явного задания нижних 64 бит IPv6-адреса при задействовании SLAAC (директива IPv6Token= секции [Network] network-файлов);
  • перечислений и wildcard'ов в директивах секции [Match] всех файлов конфигурации.

    [например, можно указать список MAC-адресов, к которым нужно применить link-файл, или же что-то вроде Name=en* — Прим. пер.]

Другие изменения в networkd:

  • Утилита systemd-networkd-wait-online теперь позволяет указывать подмножество интерфейсов, настройки которых требуется дождаться, и таймаут этого ожидания.
  • systemd-networkd теперь автоматически завершается, когда ему нечего делать (это случается, когда все присутствующие интерфейсы либо не требуют настройки, либо конфигурируются статически). При появлении в системе новых интерфейсов networkd запускается заново, для чего используется вариант механизма сокет-активации.

Изменения, связанные с поддержкой контейнеров:

  • Директория /var/lib/containers, предназначенная для хранения файловых систем контейнеров и образов ВМ, переименована в /var/lib/machines ради единообразия терминологии.
  • Добавлен юнит machines.target, группирующий все автозапускаемые контейнеры в системе.
  • В утилите systemd-nspawn добавлены следующие параметры командной строки:
    • --template (только btrfs) — указание эталонного дерева ФС, которое будет скопировано в корневую директорию контейнера (--directory) в случае отсутствия последней;
    • --ephemeral (только btrfs) — запуск контейнера без внесения изменений в его корневую директорию посредством создания временного btrfs-снапшота этой директории (например, можно сделать systemd-nspawn --ephemeral --directory / и запустить в контейнере копию ОС хоста, не мешая самому хосту);
    • --image — запуск контейнера из образа диска с таблицей разделов MBR или GPT (при этом раздел должен быть один — или, в случае GPT, все разделы должны быть помечены согласно спецификации);
    • --machine, -M — запуск контейнера из дерева ФС или из образа c указанным именем в /var/lib/machines;
    • --network-veth, -n — создание для контейнера собственного veth-интерфейса (теперь для этих интерфейсов по умолчанию задействована вышеописанная директива IPMasquerade=yes, что даёт контейнеру доступ ко всем сконфигурированным на хосте сетям);
    • --port, -p — «проброс» указанного порта из контейнера в хост-систему (в сочетании с --network-veth это позволяет запускать в контейнерах серверные приложения так, как будто они запущены на хосте).
  • Прочие изменения в systemd-nspawn:
    • На директорию /tmp внутри контейнера теперь автоматически монтируется tmpfs
    • Реализована защита от повторных запусков одного и того же образа (read-write блокировка)
    • Почти вся иерархия контрольных групп (/sys/fs/cgroup) теперь отображается внутрь контейнеров (в режиме read-only, за исключением собственного поддерева контейнера)
  • В команде machinectl, предназначенной для взаимодействия с менеджером контейнеров systemd-machined, добавлены следующие подкоманды:
    • machinectl list-images, machinectl image-status — отображение информации об образах контейнеров в /var/lib/machines;
    • machinectl start — запуск контейнера с помощью systemd-nspawn -M (эквивалент systemctl start systemd-nspawn@<имя>);
    • machinectl clone (только btrfs), machinectl rename, machinectl read-only, machinectl remove — различные операции с образами в /var/lib/machines;
    • machinectl copy-from, machinectl copy-to — копирование файлов из контейнера на хост или в обратном направлении;
    • machinectl bind (только systemd-nspawn) — bind-монтирование директорий из хоста в контейнер;
    • machinectl pull-tar, machinectl pull-raw, machinectl pull-dkr (на данный момент только btrfs) — загрузка и распаковка в /var/lib/machines, соответственно, архивов ФС, образов дисков и образов Docker.
  • Последние три подкоманды, предназначенные для загрузки образов контейнеров из Интернета, обеспечивают реализованы посредством нового демона — systemd-importd. Он обеспечивает загрузку данных в фоновом режиме.

P. S.: Да будет срач.

>>> Объявление о релизе

★★★★★

Проверено: beastie ()

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

И чем же это «странное решение»? Ты хочешь формат файла без проверки целостности?

А зачем мне _формат_файла_с_проверкой_целостности_? Мне пофигу на формат файла (лишь бы можно было его прочитать тем, что под рукой, а не ставить кучу дополнительных приблуд), мне важно, чтобы _информация_была_целостной. У Поттеринга проблемы с дизайном, причем в корне. Вместо того, чтобы задавать вопросы _зачем_, этот идиот изобретает ответы на вопросы _как_, причем криво.

А что будет на системах с поддержкой целостности на аппаратном, фс, ОС уровнях? Ясен перец, что оверхед. Тогда зачем он это написал??? И так куда не посмотри. Видит хорошую вещь где-то (тут уже сказали где), и бежит ее реализовывать, причем даже ознакомиться с существующими решениями ему влом — он тупо свое лабает.

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

А что будет на системах с поддержкой целостности на аппаратном, фс, ОС уровнях?

а на системах без этого?

Ясен перец, что оверхед

ужас, катастрофа планетарного масштаба

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

Тут ответ прост — удобнее и надёжнее

Слава богу что не написали быстрее. И кстати в чем данная надежность выражается?

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

А при чём здесь «быстрее»? Хранить дополнительные поля, ясное дело, медленнее, чем не хранить их.

Надёжность выражается в том, что не требуется писать ad-hoc парсеры для извлечения информации из текста сообщения.

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

А при чём здесь «быстрее»?

удобнее, надёжнее, быстрее.

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

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

cawa ()

P. S.: Да будет срач.

Сказал монтер и яйца systemD натер..

Marlboro ()
Ответ на: комментарий от cawa

unix предоставляет широкий набор инструментов для обработки текстовых данных.

которые - раз уж ты про них заикнулся - ни разу не unix-way :/

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

А зачем парсить собственные логи? Юзверь настолько туп, что прочитать не осилит, если что-то пойдёт не так?

CynicRus ()
Ответ на: комментарий от anonymous

которые - раз уж ты про них заикнулся - ни разу не unix-way :/

эм, чем вам не угодили sed, grep, awk, ...

cawa ()
Ответ на: комментарий от st4l1k

Не стоит додумывать за меня. Я сказал ровно то, что сказал.

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

ничто не мешает предоставлять готовые парсеры текста

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

работать с текстовыми данными удобнее, т.к. их формат буквально очевиден

И journald это, разумеется, допускает. journalctl | <что угодно> к вашим услугам.

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

А зачем парсить собственные логи?

Фильтрация. Прикажете читать все десять мегабайт? Нет, спасибо, я лучше отфильтрую. По времени, по имени процесса, по PID-у, ещё как-нибудь... И journald мне в этом поможет, потому что он заранее собирает все метаданные, которые только возможны.

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

Вопрос в том, что этот клоун лезет в чужой монастырь со своим уставом

В какой монастырь он лезет со своим уставом? Он работает в RH, пишет для них код, и если его работодатель этим кодом доволен то тебе то какое дело? Тебя никто не заставляет пользоваться systemd или дистрибутивом который перешёл на systemd. Так что он ни в какой монастырь не лезет, его монастырь - RH, а если тебе его монастырь не нравится можешь выбрать другой. Всё честно по-моему.

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

Вот и появился journald.

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

journalctl | <что угодно> к вашим услугам.

возвращает нас к исходному вопросу о целесообразности этой промежуточной прослойки в виде бинарного лога.

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

Соображения насчёт целесообразности я уже описал и повторяться не желаю.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)

Эх, все как обычно. Одни и те-же вопросы, одни и те-же ответы. Уже даже скучно, если честно.

Хейтеры, вы-бы хоть для разнообразия, нашли-бы пару вопросов, на которые я в прошлых тредах не отвечал.

В любом случае - не нравится системд - идите на диван. Или пилите uselessd. Впрочем, судя по отсутствию развития этих проектов - уровень профессионализма системд хейтера таков, что он ни мейнтенером быть не может, ни код писать не может, ни мозгами шевелить.

Не хотите / не можете делать альтернативу - ешьте то, что редхэт дает.

kir2yar ()
Ответ на: комментарий от alex_the_v

Хотя что тебе рассказывать, сейчас ты будешь возбухать что в федоре окаменелый софт хуже дебиана.

Этот пост написан на 21-ой федоре. А у федоры еще есть тестовые репозитории и альфы/беты со своими пользователями. Про арч-то согласен?

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

Обычное бухтение фанбоя в сторону хейтеров. Такой пост каждый из ваших уже по несколько раз написал. Не надоело?

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

Встречный вопрос: а что, после загрузки логгирование идти не должно?

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

Обычное бухтение фанбоя в сторону хейтеров. Такой пост каждый из ваших уже по несколько раз написал. Не надоело?

Дак и такой пост уже каждый из ваших по нескольку раз написал. )
Да надоело все, хочу пива и спать.

kir2yar ()
Ответ на: комментарий от anonymous

Кем? Только давай по существу. Кто навязал systemd в Debian? Arch? Fedora? Gentoo?

Конкретно в Debian, засланцы Поттеринга. Которых включили к число голосующих только для того что бы протолкнуть systemd.

rezedent12 ☆☆☆ ()
Ответ на: комментарий от rezedent12

Конкретно в Debian, засланцы Поттеринга. Которых включили к число голосующих только для того что бы протолкнуть systemd.

А еще он виноват в падении рубля и майдане.
Конспиролухи, блин.

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

А еще он виноват в падении рубля и майдане.

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

rezedent12 ☆☆☆ ()
Ответ на: комментарий от rezedent12

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

Если это свободное ПО настолько слабо, что для него опасны «глупые дети восхищающиеся его комбайнами на шасси инвалидных колясок» - нафиг такое ПО. Пусть дохнет.

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

Если это свободное ПО настолько слабо

Слабо сообщество которое перестало держаться за принципы Unix. Люди думают что смогут в любой момент соскочить, в крайнем случае на FreeBSD.

нафиг такое ПО. Пусть дохнет.

Ты за монополизм?

rezedent12 ☆☆☆ ()
Ответ на: комментарий от rezedent12

Слабо сообщество которое перестало держаться за принципы Unix. Люди думают что смогут в любой момент соскочить, в крайнем случае на FreeBSD.

Пусть оно держится за принципы юникса в юниксах. Не хочу, что-б линукс превратился в такое-же вялобулькающее болото, как freebsd да openbsd.

Ты за монополизм?

Я за естественный отбор.
Где юниксвей да фряха? А где редхет, убунта и андройд?

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

Пусть оно держится за принципы юникса в юниксах. Не хочу, что-б линукс превратился в такое-же вялобулькающее болото, как freebsd да openbsd.

Без обид, системы хорошие и даже кому-то подходят, но для массового пользователя - не лучший выбор. Да и для серверов уже отнюдь не всегда хороший выбор. Слишком узкая сфера применимости. И слишком неудобное обслуживание. Зато юникс-вей.

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

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

Ну давайте посмотрим, чего вы тут наприводили.

Берем первый документ и смотрим, сначала зачем это нужно было сделать, а потом уже как

The systemd journal stores log data in a binary format with several features:

Fully indexed by all fields

зачем индексировть, Леня объяснить в приведенном вами файле не смог, в приведенной вами переписке он практически просто сказал, «Что понятно, что индексирвать все нафиг не нужно, но это будет круто!». Возможно вы можете ответить на вопрос о необходимости индексации.

Вообще индексация нужна для поиска. Теперь вопрос. Зачем индексацией утяжелять такую критичную к времени реакции систему, как журналирование? Если же индексация проводится как отложенная, зачем пихать это в файл?

Если таки есть тому разумное требование, отвечаем на второй вопрос: можно ли текстовые данные в CSV формате индексировать?

Can store binary data, up to 2^64-1 in size

Нужны ли бинарные данные в журнале? Опять же фича без обоснования необходимости. Даже если нужна, отвечаем на еще один вопрос: можно ли в текстовом файле хранить бинарные данные?

Seekable

Можно ли сделать поиск в текстовом файле?

Primarily append-based, hence robust to corruption

Может ли в таком режиме работать текстовый файл?

Support for in-line compression

Поддерживает ли текстовые файлы сжатие? Можно ли сжатую строку записать в файл?

Support for in-line Forward Secure Sealing

Зачем нужно убеждаться в том, что журнал не скомпрометирован? Есть ли методы обеспечения контроля данных в тестовом журнале? Можно ли убедиться в достоверности/некомпрометируемости записанных текстовых данных?

В общем, вы привели документы, которые дают повод для задания новых вопросов, чем отвечают на текущие. Перечитайте все, что вы прислали и задайте для каждого пункта списка фич один вопрос «зачем?». Похоже Леня исходил из единственного ответа: «это будет круто».

dr_dobermann ()
Ответ на: комментарий от r3lgar

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

Почему все фанбои системд любого человека, который не фанатеет от системд или от леннарта лично, называют хейтером?

Наверная причина проста — навесив такой ярлык на оппонента, не нужно отвечать на его вопросы. Идеальная логика для ведения спора. Тогда же не нужно искать аргументы и анализировать.

dr_dobermann ()
Ответ на: комментарий от Alyssa

а на системах без этого?

приведите реальный пример систем «без этого?»

ужас, катастрофа планетарного масштаба

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

dr_dobermann ()
Последнее исправление: dr_dobermann (всего исправлений: 2)

Плодится дебильный сорняк.

anonymous ()

Нажатие Ctrl-Alt-Del более семи раз в течение двух секунд

Заяц барабанщик! Эти количественные характеристики настроить можно?

A-234 ★★★★★ ()
Ответ на: комментарий от dr_dobermann

А что будет на системах с поддержкой целостности на аппаратном, фс, ОС уровнях? Ясен перец, что оверхед.

Ты нибаись - не будет оверхеда.

anonymous ()
Ответ на: комментарий от kir2yar

Пусть оно держится за принципы юникса в юниксах. Не хочу, что-б линукс превратился в такое-же вялобулькающее болото, как freebsd да openbsd.

Будет хуже, если linux станет ещё одной виндой. И Unix не болото.

Кстати о Unix-way, ответь мне на вопрос. Зачем нужен двоичный формат файлов журнала? Если журналы слишком большие, то почему бы не сжимать их архиватором? Зачем вводить собственный механизм контроля целостности и отключать существующий? Использование текстового формата журналов позволяет прочитать их человеку, даже в том случае если они будут частично повреждены.

Я за естественный отбор.

Мало ты про него знаешь. Да и КПД у естественного отбора низкий. Кооперация лучше конкуренции. Человечество тем и занимается что минимизирует естественный отбор заменяя его разумным совершенствованием. Впрочем если фанаты Поттеринга навязывают сообществу то от чего Linux умрёт, его развитие уже нельзя назвать разумным совершенствованием и действительно происходит естественный отбор. Только за естественный отбор придётся заплатить большими жертвами.

Где юниксвей да фряха? А где редхет, убунта и андройд?

Сформулируй подробнее.

Поясню почему systemd может привести к смерти linux. Хотя большая часть кода создаётся корпорациями, меньшая часть создаётся энтузиастами. Корпорации в первую очередь заинтересованы в поддержке их технологий и они используют имеющийся для этого инструментарий и «инфраструктуру». Однако новые прорывные технологии которые определяют методы взаимодействия компонентов системы и являются её основой, создают энтузиасты - художники кода. Качественно переделывают код когда старый превращается нагромождение костылей тоже они. Тут тоже действует правило 95% и 5%. Большая часть разработчиков лишь добавляет новые функции притом зачастую запутывая код в общем. Школьник изучивший C++ часто даже не изучает какой нибудь plugin API, а просто делает патч для основного модуля программы.

Энтузиасты делают новые замечательные вещи для linux потому что под Linux это делать легко. А легко это делать, потому что не так уж и трудно понять функциональность каждой части системы, ибо она простая. Но когда разработчик видит огромный комбайн который делает слишком много, ему нужно гораздо больше времени что бы понять как именно он работает. Кроме того «комбайны» часто работают не очевидно. И если у такого разработчика есть выбор под что писать, то он предпочтёт то в работе чего разобраться проще. А потеряв «художников кода», linux в лучшем случае начнёт опухать, многие ошибки перестанут исправлять и вместо них будут городить новые комбайны обёртки даже не пытаясь разобраться в причинах.

rezedent12 ☆☆☆ ()
Ответ на: комментарий от arcanis

Аватарку сначала смени, потом уже пытайся мне что-то сказать.

ee1337a ()
Ответ на: комментарий от mandala

Тестовые репы и альфы/беты для того и сделаны, чтобы тестить последние версии софта. В релизе же - стабильный systemd.

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

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

При таком акутном воспалении фичеризма, я очень сомневаюсь, что и те полтора поттеринга ещё помнят и понимают что-к-чему. А ты тут целую статью восжелал. ;)

Наверное я оптимист :)

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

А, наоборот… а зачем так часто нажимать? %)

Это был юмор. Видимо не самый удачный :)

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

«В релизе же - стабильный systemd.» критерии стабильности.

ну хотя бы отсутствие критичных багов ? задокументированный и замороженный api ? задокументированные и замороженные форматы хранения (ага журналд)?

anonymous ()

Вот чего в systemd пока нет и что нужно для полного счастья: стандартного API для конфигурирования приложений типа вот этого: http://wiki.openwrt.org/doc/techref/uci Ну или типа виндового реестра. Или http://en.wikipedia.org/wiki/Dconf. Конечно, не стОит воспроизводить угрёбищный бинарный формат реестра и прочие идиотизмы, но стандартизированный API для доступа к любым конфигурационным параметрам всех приложений есть благо.

asaw ★★★★★ ()

как жить дальше?)

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

carter ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.