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 ()

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

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

alex_the_v ★★★ ()

Посмотрел на ставший уже привычным срач,почитал о том,каксистемд плохо документирован и у меня вопрос,как долго ждать момента,когда Поттеринг забыв почему он написал так,а не иначе внесёт несколько изменении которые сделают дальнейшее изменение кода не возможным?

Не пора ли,коль уж он так всё продавил административным ресурсом,
действительно уходить на дистры,где этого системд нет?
(Возможно начав разработку своей системы инициализации?)

Донатов с меня кот наплакал,но теперь Debian,
при всём моём восхищении оным их точно не получит.

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

Ещё одно дитя Windows

Это определяется настройками WM, хотя похоже systemd-шники уже добились полного переноса идей Windows95 на линукс.

anonymous ()

Простыню не осилил, но считаю нужным сказать, что сабж не нужен

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

Подтверждаю ненужность данной подделки.

Пусть закапывают

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

я именно это и хотел сказать - где стабильный api? где документированный формат хранения и гарантии его неизменности? новость то читали? «Директория /var/lib/containers, предназначенная для хранения файловых систем контейнеров и образов ВМ, переименована в /var/lib/machines ради единообразия терминологии.»

стабильно да?

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

Поддержка старой оставлена в целях совместимости. Забыл написать.

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

Этот пост написан на 21-ой федоре.
В релизе же - стабильный systemd.
Директория /var/lib/containers, предназначенная для хранения файловых систем контейнеров и образов ВМ, переименована в /var/lib/machines
где стабильный api?

В 21-ой федоре перенесли образа в /var/lib/machines? Или переехали на systemd 219? Или anonymous не понял о чём речь и принялся газифицировать лужи?

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

Индексировать затем, что никогда нельзя придумать наперёд, что захочется сделать пользователю. Оверхед на индексирование (он невелик) не мешает, потому что 1) сообщения всё равно генерируются медленнее (почти всегда), 2) есть буфер, 3) периоды «всплеска» интенсивности появления новых сообщений в нормальных условиях невелики.

Убеждаться в том, что журнал не скомпрометирован, нужно по очевидным причинам. С точки зрения формата файла — по постановке задачи.

Что касается вопросов про текст: в текстовый файл, безусловно, тоже можно всё это впихнуть, но тогда он станет практически нечитаемым (будет слишком много метаданных). Поэтому это не несёт реальной выгоды, а оверхед создаёт. К тому же, нет никакой проблемы извлечь из бинарного файла текстовые данные даже при отсутствии специализированного парсера формата.

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

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

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

Зачем вводить собственный механизм контроля целостности и отключать существующий?

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

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

Системд журнал так-же можно прочитать даже если он частично поврежден. Банальной командой strings, которая есть во всех линуксах.

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

И так огульно большую часть мейнтенеров дебиана ты назвал фанатами Поттеринга.
А теперь серьезно. Основная движуха началась с того, что гном привязался к системд. Почему привязался? Да потому-что не нашлось никого кто бы мог подхватить ConsoleKit. Два года ждали, кстати. Кооперация? Где?

Поясню почему systemd может привести к смерти linux. Хотя большая часть кода создаётся корпорациями, меньшая часть создаётся энтузиастами.

В прошлом релизе ядра - таки энтузиасты лидируют.

Энтузиасты делают новые замечательные вещи для linux потому что под Linux это делать легко.

Системд, к примеру, резко упрощает разработку и создание новых демонов. Позволяет их привязывать фактически к любым событиям. Создает удобную платформу, функционалом которой реально приятно пользоваться. Что мы и видем в виде гнома, который юзает системд, в виде кед, у которых нормальная залочка экрана работает только с системд.

И если у такого разработчика есть выбор под что писать, то он предпочтёт то в работе чего разобраться проще.

Таки тут системд на коне. Намного проще разобраться, чем в зоопарке lsb-init, start-stop-daemon, openrc. Один юнит, и покрыл сразу дебиан, убунту, федору, центось. Что примерно 100% серверных установок линукса и 95% десктопных.

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

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

В генте никто не навязывает - хочешь ставь, не хочешь - не ставь. А в негенте - хочешь не хочешь - всеравно ставь. И никто ничего не навязывает. Парадокс, ага? Миллиарды мух не могут ошибаться.

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

Оверхед на индексирование (он невелик)

Спасибо вы сделали мой день.

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

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

Вы определитесь, для начала, для кого предназначено это ненужно - для админов локалхоста, или для профессиональных сисадминов. По вашему же утверждению админ локалхоста говорит «кококо нинужно», админам с прямыми руками, по многочисленным отзывам, - тоже ненужно. Так для кого?

Не мечите бисер[\quote]

в оригинале: не мечите бисер перед свиньями - cуть системд-разрабов и их отношения к ЦАУ. nuff said.

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

фанбои системд

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

не фанатеет от системд

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

от леннарта лично

Личность Леннарта Подтеринга не очень меня лично удовлетворяет — он напыщеный идиот, позер и избалованный ребёнок, но у него имеются хорошие идеи (это не касается pulseaudio и avahi).

не нужно отвечать на его вопросы

Если ответ на вопрос будет принят (а не «спросить, чтобы спросить»), то почему бы и нет, если человек действительно интересуется?

искать аргументы и анализировать

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

Поясню: хейтеры формулируют своё отношение приблизительно так:

Я не буду ставить $SOFTWARE, потому, что оно говно. И вы все говноеды.

Такие люди не воспринимают аргументы, они даже не хотят разобраться, аргументы их размыты (от незнания $SOFTWARE), и позиция сомнительна.

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

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

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

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

Не всем пофиг.

Если прогеру удобней хранить в двоичном - то пусть будет в двочном.

Пользователю не всегда удобно.

Мне не журнал нужен, а информация в нем. И тут у меня есть и экспорт в сислог, и в текстовый файл, и возможности быстрого фильтра записей без многоэтажных регекспов.

То есть без утилиты экспорта не прочитать? А ты подумал что её может не быть на другом компьютере?

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

Напомню что в случае systemd решение сделать так было продиктовано аргументом «Так круче!».

Почему привязался? Да потому-что не нашлось никого кто бы мог подхватить ConsoleKit. Два года ждали, кстати. Кооперация? Где?

Читаю http://forum.altlinux.org/index.php?topic=1744.0 и понимаю что ConsoleKit который

кушает 250 метров озу, иногда что-то совсем подвисает и одно ядро процессора загружено на 100%

Явно плохая вещь имеющая слишком большие запросы для своего функционала. То есть нинужно городят ради нинужно, а дальше рекурсия. Больше поделок Поттеринга богу говнокода!

Системд, к примеру, резко упрощает разработку и создание новых демонов. Позволяет их привязывать фактически к любым событиям.

Приведи примеры этих событий.

Таки тут системд на коне. Намного проще разобраться, чем в зоопарке lsb-init, start-stop-daemon, openrc. Один юнит, и покрыл сразу дебиан, убунту, федору, центось. Что примерно 100% серверных установок линукса и 95% десктопных.

Не все хотят что бы у них systemd был безальтернативным.

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

То есть без утилиты экспорта не прочитать? А ты подумал что её может не быть на другом компьютере?

На этом можно заканчивать диалог. Иди в школу. Даже для хейтера ты не достаточно умен.

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

Спасибо, записал

Nick: rezedent12
Комментарий: systemd хэйтер Малолетний долбоёб без логики [Изменить]
Полное имя: Гареев Станислав

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

Не все хотят что бы у них systemd был безальтернативным.

Много закоммитил/задонатилив дистр, который не собирается переходить на systemd? Ничего? Пошёл на йух со своим мнением.

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

Орфография - писец, синтаксис - туда же. Ты вообще не любишь читать, я вижу.

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

Вопрос как раз таки по существу. Тебе приходило в голову что где то может быть linux без systemd?

rezedent12 ☆☆☆ ()

Ждём своё ядро от Леннарта. С блекждеком и шлюхами (с). Будет GNU/Lennart.

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

Раз есть такой, то и пользуйся им молча, чего докопался до тех, кому systemd не мешает?

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

Я наивно полагал, что приведутся какие-нибудь c{a,u}t, которые действительно выполняют узкую задачу. Но никак не комбайны типа sed/awk, которые и вовсе сами по себе вполне самостоятельные ЯП. Особенно забавляет использование в сообществе awk где ни попадя, даже если можно обойтись (а это почти всегда так) cut.

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

ну мааааам, я уже большой мальчик, ну можно я оставлю анимешного чувака!

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

Кнопка закрытия окна в верхнем правом углу.

Не у всех :)

Лучше так: «я думаю, вашего уровня знаний, используемой ОС, хватит на закрытие окна».

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

Раз есть такой, то и пользуйся им молча, чего докопался до тех, кому systemd не мешает?

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

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

(Возможно начав разработку своей системы инициализации?)

Ну так давай, начинай разработку своей системы инициализации...а мы начнем тут срач....

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

Я такой злой стал, потому что systemd пропихнули в мой любимый debian и при том без альтернативы. И если ты не помнишь новости о том как это сделали, то напомню, это сделали при помощи интриг и бюрократической возни. А вовсе не демонстрацией технических преимуществ.

Купи уже себе велосипед, а?

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

Тебе приходило в голову что где то может быть linux без systemd?

А тебе не приходило в голову, что для чтения файлов journal systemd не нужен? Даже для чтения файлов journal journalctl'ом, не говоря уже про strings, не нужны ни systemd, ни journald.

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

Где юниксвей да фряха?

О, уже и сюда юниксвей приплели :)

А ведь всего пару лет назад троллили говорили о «неправильной» лицензии, позволяющей «захапать весь труд на халяву, ничего не отдавая взамен» как и «высокомерной» верхушке (речь идет о фб-фоундатион, как впрочем и о Тео&Ко) — и мол по этому фирмы выбрали линукс и вкладывались в него, а фря сосет, рип и все такое!
Теперь это уже юниксвей виноват =)
Казалось бы, чем могут помешать принципы «не усложняй без надобности, не распыляйся — лучше делай что-то одно, но делай это хорошо! Озаботься взаимодейсвием с другим ПО! Используй по возможности универсальный/простой интерфейс (да, тогда это был текст, но принцип применим ко всему — никто ведь не изобретает свой TCP или свою собственную, кошерную кодировку)»? Это не означает, что нужно отключить то, во что многие просто едят (как впрочем и фанатизировать) — но откуда берется мнение, что «ничего не надо менять, ведь оно как-то, но работает!!!» тоже юниксвей? Это упорин-вей ;).
И вообще

Rule of Diversity: Distrust all claims for “one true way”

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

Где юниксвей да фряха?

Где онтопик и где венда (для начала — на десктопе. Хотя фанаты форточки утверждают, что и на серверах МС подбирается к 30-ти процентам — но тут, как говорится, кто статистику заказывает, тот и д'Артаньян). Т.е. венда-вей еще правильней? :)

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

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

anonymous ()

системд хейтерства коммент

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

Так же есть ряд нетехнических проблем:

  • Лёня страдает nih-синдромом и с каждым релизом придумывает новую проблему и мегафреймворк для её решения: то QR-коды с http-сервером, вот теперь контейнеры
  • Так же Лёня склонен к Д'Артаньянству и пренебрежительно относится к критике своей работы, зачастую достаточно разумной
  • Ну и наконец, действительно ли Линукс-сообщество хочет сосредоточить все ключевые подсистемы в руках одного вендора?
anonymous ()

Что-то я ослеп или в этой теме до сих пор не отметился тейлганнер?

anonymous ()

Почему на самом деле не нужен systemd

Господа, я вам вот что скажу: Unix-way и философия — это слова, хоть и правильные, но не вполне понятные, во всяком случае понятные не всем. Я вам скажу иначе. Я вот намедни попробовал поднять Gentoo на Raspberry Pi. А там — ОНО.

И что? А и всё. Я в течение получаса не смог понять, как сделать так, чтобы сеть работала, как Я хочу, а не как ОНО хочет. Я. Не. Смог. Настроить. Сеть. В. Линуксе. Я, блин, который с линуксом работает с 1994 года, который в конце девяностых провайдеры строил, не смог настроить сеть. Всего-то навсего не смог (а) открутить dhcp от основной карты и (б) сделать так, чтобы второй эзер поднимался при загрузке сам собой, а не руками.

Ну то есть как, я, наверное, если бы очень сильно упёрся, то смог бы. Английским владею, доки вроде есть. Но я никогда ещё не тратил больше 15 минут на настройку сети, и если я в течение получаса не смог понять, что этой хреновине надо, и найти нужные конфигурационные файлы (NB: я умею юзать grep, не волнуйтесь), то проблема не во мне, а в дистрибутиве.

Вот уже так и слышу улюлюканье и крики «ага, ниасилил, ниасилил». Понимаете, я уже всё, что надо, давным давно доказал и себе, и публике. Мне, чёрт подери, сороковник, у меня две учёные степени, мне пофигу это ваше «ниасилил». Я могу себе позволить заявить, что я НЕ ХОТЕЛ это осиливать, потому что у меня есть существенно лучшие идеи, как потратить время.

Почему-то бытует мнение, что, типа, если человек не хочет что-то там изучать, то это он такой ленивый тупой урод, а нормальные люди давно всё изучили. Так вот, жизнь, чёрт подери, коротка, она гораздо короче, чем хотелось бы. Сколько бы мне потребовалось времени, чтобы понять, как обращаться с systemd? День? Два? Неделя? Примерно представляя масштабы катастрофы, я скорее склонен думать, что да, неделя. Но даже если всего пара часов — это ведь пара часов из моей оставшейся жизни, которой уже и так не хватит на всё то, что мне хотелось бы сделать.

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

Иное дело systemd. Он что, какие-то проблемы решает? Так у меня этих проблем НЕТУ, понимаете?! Ну не нужно мне решать какие-то там проблемы, связанные с неправильной последовательностью запуска сервисов, потому что у меня нет таких сервисов, которые друг от друга зависят, и они мне не нужны, если такие появятся, я им замену подберу, ибо вообще любые зависимости — вселенское зло. И другие проблемы, о решении которых гордо заявляют фанаты этого монстра — их тоже нету. Ну вот нету, понимаете? Не существует в природе. Этот ваш монстр — это ответ на вопрос, которого я не задавал. Вот я сказал less /var/log/messages, и впервые за те 20 с лишним лет, что я работаю с *nix'ами, я в ответ на это получил no such file or directory. В свежеустановленной FreeBSD когда-то не оказалось less, помнится, но /var/log/messages был на месте. Мог я посмотреть в инете, как мне смотреть логи, порождённые этим бастардом? Ну конечно, мог, но это потребовало бы времени. А что я для себя при этом получу? Что такого МНЕ дадут бинарные логи от systemd, чего не давали традиционные текстовые? Профит, мать вашу, где?! Во что и во имя чего мне в это унылое дерьмо инвестировать своё время?

А между тем, вот есть некоторые вполне реальные дела, которые я знал как сделать с помощью старого SysVinit, тупо редактированием /etc/inittab. Раньше знал, а теперь вот со всеми этим апстартами и прочими systemd — получается, что не знаю. Эй, вы куда дели мои возможности? И, кстати, это не только с инитом так. Вон раньше было LILO, я с ним умел обращаться. Теперь везде этот дебильный Grub, с которым уметь обращаться, по-моему, невозможно, там какая-то альтернативная логика. Он мне хоть одну проблему решил? Нет, не решил, только создал. Ну кто вас, чёрт подери, просил, а?

Между тем, наблюдаю, как вокруг люди тратят время на изучение systemd. И постоянно один и тот же диалог: он тебе что, нужен? Да в принципе не очень, но я привык к <distro_name>, а они перешли на systemd. И вообще, весь мир на него перешёл, видимо, так надо. Нельзя же от жизни отставать.

Сколько этих людей? Десятки тысяч? Сотни тысяч? Сколько тех, кто тратит драгоценные часы своей жизни на «освоение» тупого высера этих безответственных сволочей из Redhat, высера, который ничего не даст в жизни большинству изучающих его, только отнимет время на его изучение? А давайте помножим их количество на среднее потраченное время. Сколько мы, простите, получим человеческих жизней? Господа сторонники systemd, я обвиняю вас в серийных убийствах.

Надо просто понимать, что монстры подобного рода — это не простой софт. Обычно чью-то программу мы изучаем ради вполне определённых профитов, которые даст её использование, а если оно нам ничего не даст — то не изучаем. Иное дело systemd. Вот просыпаешься утром, бац — а твой любимый дистрибутив перешел на systemd. И либо уходить на другой, либо изучать. Никакой перспективы профита, просто так получилось: кто-то где-то принял решение, что надо бы нам в духе времени и идя с оным временем в ногу, перейти на модный нынче systemd. Один урод принял решение, а тысячи ни в чём не повинных людей ВЫНУЖДЕНЫ тратить время.

Вердикт? Расстрелять. Я абсолютно серьёзен. Я, в принципе, против смертной казни, но не тогда, когда речь идёт о серийных убийцах.

Croco ★★ ()
Ответ на: Почему на самом деле не нужен systemd от Croco

Вот уже так и слышу улюлюканье и крики «ага, ниасилил, ниасилил».

Не надо слушать идиотов, а в остальном согласен. Linux это не игрушка и не конструктор для развлечения школьников, а инструмент для решения ряда задач.

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

Вот официальный стабилити промис, вот более детальный расклад, вот дока на формат журнальных файлов. /var/lib/containers является частью функциональности, которая все еще в разработке, еще не стабилизирована и поэтому не подпадает под стабилити промис и неизвестно относится ли к API вообще.

Уж всяко постабильней, чем большинство решений.

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

Сразу скажу,что я не только не умею программировать,но даже и администрировать систему.
ИМХО systemd разрушает этот мир

Прям-таки квинтэссенция тупого, малограмотного хейтера - хоть сейчас в палату мер и весов :)

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

Пора снимать постапокалиптик. Массовку наберём из комментов на ЛОРе и опеннете.

Не поверят: таким уродам даже после ядерной войны неоткуда взяться :)

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

Вах! Что за эльфа у тебя на аватарке, откуда?

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

Чё-та у тя линкор на аватарке неч0ткий какой-то - ты бухой что-ли?

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

Срань господня, что за инопланетный ужас у тебя на аватаре?!

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

Возьми лучше systemd-stable

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

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