LINUX.ORG.RU

systemd 218

 ,


3

5

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

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

Список изменений:

  • Все компоненты systemd, обладающие конфигурационными файлами в /etc/systemd, теперь умеют считывать настройки из соответствующих *.d-директорий в /usr/lib, /run и /etc.

    Например, /etc/systemd/system.conf можно дополнять из /{usr/lib,run,etc}/systemd/system.conf.d/*.conf.

  • Добавлена команда systemctl edit, которая позволяет редактировать unit-файлы (используется редактор, указанный в переменной окружения $EDITOR).

    Возможные режимы работы таковы:

    • (по умолчанию): «режим дополнения», т. е. редактирование нового drop-in'а (создаётся и открывается /etc/systemd/system/$unit.d/override.conf)
    • --full: «режим исправления», т. е. редактирование всего юнит-файла (он предварительно копируется в /etc/systemd/system, если необходимо)
    • --runtime: «режим временных изменений», т. е. вместо /etc используется /run и все внесённые изменения живут только до перезагрузки
  • Команда systemctl is-enabled теперь выводит «indirect» вместо «static» (при этом код возврата равен 0) в тех случаях, когда секция [Install] юнита содержит только директивы Also=, т. е. когда сам юнит не может быть включен, но «включает» другие юниты.
  • Команда systemctl status ЮНИТ теперь выводит также и «предлагаемое» состояние юнита согласно preset'ам. Это показывает, должен ли юнит быть включен согласно дистроспецифичному дефолту.

    Пример:

    $ grep -R remote-fs.target /usr/lib/systemd/system-preset
    /usr/lib/systemd/system-preset/90-systemd.preset:enable remote-fs.target
    
    $ systemctl status remote-fs.target
    ● remote-fs.target - Remote File Systems
       Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; disabled; vendor preset: enabled)
    

  • Команда systemd-run теперь поддерживает отложенный запуск команд в стиле at(1) (параметры командной строки --on-calendar и аналогичные). Это реализовано с помощью создания временного timer-юнита наряду с основным service-юнитом (поддержка создания timer-юнитов как раз была добавлена в API systemd).
  • В команде busctl, предназначенной для работы с шиной D-Bus, добавлены следующие подкоманды и параметры командной строки:
    • busctl capture (захват всех данных, проходящих через шину, в формате libpcap)
    • busctl tree (отображение дерева объектов для конкретного сервиса или для всех сервисов на шине)
    • busctl introspect (отображение подробной информации о конкретном объекте на шине)
    • busctl call, busctl get-property и busctl set-property (предназначение очевидно из названий)
    • busctl --augment-creds= (включение или отключение сбора вспомогательных данных о процессах на шине из /proc)

      Последняя опция по умолчанию включена, но в некоторых случаях это может привести к race conditions, поэтому и была добавлена возможность её отключения.

  • В команде journalctl добавлены параметры командной строки --vacuum-size= и --vacuum-time=, позволяющие принудительно удалить старые файлы журнала. Как легко понять из названий параметров, критерием очистки может быть или суммарный размер файлов журнала, или давность сообщений в конкретном файле.
  • В команде systemd-nspawn добавлены параметры командной строки --link-journal=try-guest и --link-journal=try-host, которые работают аналогично значениям guest и host (а именно — включают объединение журналов хоста и контейнера), но не возвращают ошибку, если на хосте ведение постоянного журнала отключено.

    Параметр командной строки -j теперь является синонимом для --link-journal=try-guest.

  • Команда systemd-inhibit при отображении списка активных ингибиторов теперь поддерживает фильтрацию по типу (block или delay).
  • Для каждой директивы вида ConditionXYZ= в секции [Unit] unit-файлов добавлена аналогичная директива AssertXYZ= в той же секции.

    Отличие между ними состоит в том, что невыполнение Condition-директив приводит к пропуску (игнорированию) юнита, а невыполнение Assert-директив переводит юнит в состояние «failed».

  • В секциях [Scope] и [Service] unit-файлов добавлена директива Delegate=, разрешающая процессам юнита самостоятельно управлять своим поддеревом контрольных групп.
  • В секции [Service] unit-файлов добавлена директива SmackProcessLabel=, позволяющая установить для всех процессов юнита указанную метку SMACK64.
  • Директива ConditionSecurity= unit-файлов теперь может принимать значение audit, что будет приводить к проверке доступности audit-подсистемы ядра.
  • systemd-coredump теперь собирает и кладёт в журнал вместе с core-дампом некоторое количество метаданных об упавшем процессе, а именно:
    • контрольные группы, к которым принадлежал процесс (/proc/$PID/cgroup)
    • список переменных окружения и их значения (/proc/$PID/environ)
    • карту адресного пространства процесса (/proc/$PID/maps)
    • рабочую директорию (/proc/$PID/cwd)
    • корневую директорию (/proc/$PID/root)
    • состояние процесса (/proc/$PID/status)
    • список открытых файловых дескрипторов (/proc/$PID/fd)
  • journald теперь умеет собирать сообщения audit-подсистемы ядра (с обработкой сопутствующих метаданных) и записывать их в общий лог. В частности, это означает, что journalctl становится альтернативой традиционному audit-клиенту ausearch.
  • systemd-networkd теперь поддерживает:
    • конфигурирование VXLAN-устройств (секция [VXLAN] netdev-файлов)
    • указание «стоимости» портов bridge-устройств (директива Cost= в секции [Bridge] network-файлов)
    • настройку правил IP source routing (директива Source= в секции [Route] network-файлов)
    • выбор сетевого интерфейса по его исходному имени (до переименования; директива OriginalName= в секции [Match] link-файлов)
    • изменение MAC-адреса и MTU интерфейса из network-файлов (директивы MACAddress= и MTUBytes= в секции [Link] network-файлов)
  • В systemd-networkd начата работа по реализации протокола PPPoE.
  • NSS-модуль nss-myhostname теперь ресолвит имя «gateway» в IP-адрес шлюза по умолчанию. Если таковых несколько — они сортируются по значению метрики.

    Отмечу, что это изменение не нарушает работу конфигураций, в которых имя «gateway» уже как-либо используется, поскольку модуль nss-myhostname обычно идёт последним в списке NSS-модулей.

  • macvlan-устройства, создаваемые systemd-nspawn внутри контейнеров, теперь имеют стабильные MAC-адреса (в том смысле, что они не будут изменяться каждый раз).
  • systemd-cryptsetup-generator теперь поддерживает указание key-файлов и назначение имён для отдельных устройств из командной строки ядра (luks.key=<UUID>=<имя файла> и luks.name=<UUID>=<назначаемое имя устройства>).
  • В systemd-tmpfiles добавлено действие t — назначение файлу произвольных расширенных атрибутов (xattrs).
  • systemd-localed теперь опционально зависит от libxkbcommon. Эта библиотека будет использоваться для проверки корректности устанавливаемых настроек раскладки клавиатуры X11 (напр., с помощью localectl set-x11-keymap).
  • В systemd-hostnamed список текстовых описаний типов системы (chassis type) был пополнен значением «embedded».
  • systemd-rfkill теперь ассоциирует запоминаемое состояние rfkill'а не с его именем (rfkill0, rfkill1, ...), а с комбинацией его типа (wlan, bluetooth, ...) и свойства ID_PATH.

    Это связано с тем, что имя rfkill'а не обязано сохраняться между перезагрузками или переподключениями устройства. Более того, в последнем случае оно никогда не остаётся прежним.

  • База данных аппаратного обеспечения (hwdb) udev'а теперь содержит базу данных разрешений оптических сенсоров мышей. Она будет использоваться в libinput для автоматической коррекции ускорения курсора.

    Ситуация более подробно описана в этом сообщении.

  • systemd теперь умеет корректно обрабатывать ситуации, в которых система одновременно
    • не имеет файла /etc/machine-id
    • запускается с корневой ФС в режиме «только чтение»

    Для обработки этих случаев была добавлена вспомогательная утилита systemd-machine-id-commit, которая запускается сразу после перемонтирования корневой ФС в режим «чтение и запись» и атомарно перемещает временный файл machine-id из tmpfs в /etc/machine-id.

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

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 7)
Ответ на: комментарий от Ivan_qrt

А без goto, пришлось бы 4 раза занулять пароль до вызова process_root_password(), даже если забить на освобождение остального.

Чушь, учите С. Но я могу показать код который делает все тоже саме без единого goto, если сдаетесь.

если пароль был введён как параметр

Он и есть параметр, то что вы код не читаете не значит что это не так.

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

Использование глобальных переменных вообще плохая практика. И не стоит этим злоупотреблять

Не спорю.

Значит пусть спросит еще раз пароль! Ты еще скажи на стенке записать пароль, что бы все видели.

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

Выделил память в функции, значит освободи,

Ты хоть код то почитай, а потом уже коментируй.

Он и не должен там зануляться.

Мой постскриптум ты проигнорировал, или просто не понял?

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

Чушь, учите С. Но я могу показать код который делает все тоже саме без единого goto, если сдаетесь.

Давай, если не сложно. Желательно, с коментариями, чем он лучше.

Он и есть параметр

Имелся ввиду аргумент командной строки.

то что вы код не читаете не значит что это не так.

То что ты предложил сделать (очищать arg_root_password только в process_root_password()) - это уязвимость.

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

Не спорю.

Ну наверное, так же ты не будешь спорить с тезисами:

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

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

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

Ты случайно не из тех, кто выключает логин для рута, но прописывает в sudo свой повседневный акк с параметром NOPASSWD?

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

А вот если программа загнется на каком нибудь free до clear_string(arg_root_password) то пароль утек

Интересно для общего понимания, а как такое вообще можно вызвать?

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

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

У каждого дистрибутива своя область применения. Если в каком-либо бинарном дистрибутиве что-то собрано не в том виде, в котором тебе нужно — либо меняй дистрибутив, либо собирай сам.

Мда... С тобой всё ясенно и песенно.

alex-w ★★★★★
()
Ответ на: комментарий от ioway

Ну наверное, так же ты не будешь спорить с тезисами

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

пароль запрашивать в параметрах вообще фу-фу-фу

Его не запрашивают в параметрах. Есть возможность его передачи параметром. Допускаю, что иногда она востребована.

Что сказать-то хотел? Или просто тезисов накидать решил?

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

тезисы не предлагают альтернативы.

Тезисы предлагают обсуждение

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

Сильно не закапывался, но там по-ходу эха нет, так что ничего не выведется. И да лучше 10 раз перезапросить.

Что сказать-то хотел? Или просто тезисов накидать решил?

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

ioway
()
Ответ на: комментарий от alex-w

Твоё ЧСВ, наверное, видно за километр. Поделишься вселенской мудростью?

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

Тезисы предлагают обсуждение

Обсуждение чего? Тезисы бессмысленны.

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

Что конкретно в коде тебе не нравится, и как по-твоему надо делать правильно. С примерами и подробными пояснениями.

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

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

Ниразу, иначе либо вызываете free либо делаете метод совмещающий clear_string(arg_root_password) и free.

Здесь точно никакой разницы. Или мы начинаем обвинять автора данного кода в том, что «а вот если бы он забыл free...»?

А вот если программа загнется на каком нибудь free до clear_string(arg_root_password) то пароль утек

С тем же успехом программа может загнуться на чём угодно — от ввода данных с клавиатуры или записи в shadow до SIGBUS посреди кода без сисколлов вообще.

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

Что конкретно в коде тебе не нравится, и как по-твоему надо делать правильно. С примерами и подробными пояснениями.

Ух ты, рефакторинг провести? Тестами обвязать?

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

Мне вот одно интересно, у всех фанбоев systemd, замашки мелкой шпаны?

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

Это всё понятно — привет, kdbus.

intelfx ★★★★★
() автор топика

systemd теперь умеет корректно обрабатывать ситуации, в которых система
запускается с корневой ФС в режиме «только чтение»

Нужно больше фич и меньше тестирования :)

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

Ух ты, рефакторинг провести? Тестами обвязать?

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

Мне вот одно интересно, у всех фанбоев systemd, замашки мелкой шпаны?

Если ты кукаретик, то не стесняйся. Имеешь право, здесь пол лора таких.

Но без вменяемой аргументации диалога не получится.

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

Я там условие написал. A -> B, !A || B.

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

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

библиотек сугубо направленные (т. е. udev -> libsystemd, systemd -> libsystemd).

Только если libsystemd обратно совместим. А насколько я в курсе, Лёня такого не обещал про внутренние интерфейсы.

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

http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI

В общем-то, udev из systemd тянет за собой только
libsystemd-daemon и libsystemd-login. Это можно бы и
перетерпеть.

Я так понимаю, это было на будущее предупреждение. На ближайшее будущее. Но пока это не осуществилось, и по тому, зависимостей у удев _пока_ не так много?

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

Раз: libsystemd — не внутренний интерфейс.

Два: как связано направление зависимости и версионирование? Если обновлять — так всё сразу, нет? Или я таки не распарсил то, что говорит AS?

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

Раз: libsystemd — не внутренний интерфейс.

Тогда ок.

Или я таки не распарсил

Может я неправильно понял, но по-моему его волнует невозможность заморозки версии udev и обновления systemd. Или же заморозки любого другого отдельно взятого компонента systemd с обновлением всего остального. Формально он прав, это снижает гибкость, но кому это надо непонятно.

Для этого понадобится дублировать библиотеки(те, что без обратной совместимости), что не всегда возможно, и не всеми пакетниками поддерживается. А если dbus-интерфейс поломают, то вообще непонятно, что делать.

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

Два: как связано направление зависимости и версионирование?

От libsystemd зависит как udev, так и systemd. Обновление этой библиотеки ведёт к необходимости обновления как udev, так и systemd одновременно. А вызывается обновление библиотеки как попыткой обновления udev, так и systemd. В итоге - замкнутый круг. То есть, получаем однозначную зависимость версии udev от версии systemd через их общую библиотеку.

В итоге приходим к мысли, что нам надо городить огород с раздельной сборкой systemd и udev. Спрашивается: ну и зачем udev втянули в общее дерево, если мантейнеру пакета надо это всё делить ?

Вcё же попробуй сам пообновлять их раздельно в любом бинарном дистрибутиве. В какие-то моменты, при совпадении soname, это, видимо, удастся, но это будет частный случай.

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

но по-моему его волнует невозможность заморозки версии udev и обновления systemd.

Именно. Только наоборот - больше волнует init, от работоспособности которого зависит всё, и который не должен обновляться по желанию левой пятки (udevd, logind и т.п.).

но кому это надо непонятно.

Тому, кто не хочет пилить через весь город из-за невозможности перезагрузки сервера с обновлённым init.

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

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

А может ты по-старинке учиться пойдешь?

Но без вменяемой аргументации диалога не получится.

С тобой? Ты себе переоцениваешь

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

Тому, кто не хочет пилить через весь город из-за невозможности перезагрузки сервера с обновлённым init.

Но при этом хочет пилить через весь город из-за невозможности работы сетевой карты после перезагрузки с обновлённым udev? Для этого есть дистры, которые не меняют мажорные версии пакетов. (debian, centos и т.п.).

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

из-за невозможности работы сетевой карты после перезагрузки с обновлённым udev ?

Это, кстати, тоже недавно привнесённая проблема, появившаяся после втягивания udev в systemd. Но она решаемая пока.

которые не меняют мажорные версии пакетов. (debian, centos и т.п.).

Рано или поздно их тоже случается обновлять. И чем большее количество критичных компонент остаётся неизменным, тем лучше. sysvinit практически не меняется много лет, а такой комбайн, как systemd, обречён всегда обновляться.

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

Это, кстати, тоже недавно привнесённая проблема

Если ты про persistent names, то это проблема только на rolling-дистрах. В дистрах с релизными циклами просто так такие изменения не попадают.

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

Рано или поздно их тоже случается обновлять.

Я правильно понимаю, что ты собрался обновлять debian/centos между релизами, оставив системд старой версии, но обновив udev, а потом удивляться, почему система не загрузилась?

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

Я правильно понимаю, что ты собрался обновлять

Нет, ты понимаешь неправильно. Я просто не хочу менять системный init просто потому, что Поттеринг посчитал, что он наделал достаточно нового кода в systemd-java или systemd-libreoffice. И если этих двух компонент всё ещё нет, то это просто его недоработка, очевидно.

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

Ну так не меняй.

А как, если из тарбола systemd образуется десяток пакетов, которые с ним связаны, и на которые пытаются завязать пол ОС ? И которые не должны, по идее, касаться инита.

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

А как, если из тарбола systemd образуется десяток пакетов, которые с ним связаны

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

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

Если не всё работает, то пиши багрепорты, обновляй systemd и не выпендривайся.

Дебилушка. Иди учись. AS тебе уже третий раз пишет что все собрано из одной версии исходников. Ты хоть почитай что такое разбиение исполнимых файлов, как оно работает и чем закончится твое «не обновляй».

Ты поза-позавчера свою первую программу написал, а позавчера наконец-то ее собрал, но гонору как у системного архитектора.

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

Нет, ты точно читать не умеешь.

AS писал «От libsystemd зависит как udev, так и systemd. Обновление этой библиотеки ведёт к необходимости обновления как udev, так и systemd одновременно. »

Уверен? При общем количестве багрепортов сервак с системд _вынужден_ обновляться, пока не пришлось выгребать останки данных с посыпавшейся FS которая по мнению бракоделов вроде тебя «слишком долго проверяется и надо рестартануться». С другой стороны параметры меняются от фонаря без плана, без гарантий. Документация не соответствует действительности, о чем потному 100500 раз заявляли на что это тело выдавало «а мы еще менять будем». И это нихрена не приемлемо для эксплуатации, что до вас «одминов файлопомоек» и пытаются донести.

Ей богу, лучшеб бухали и курили.

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

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

Вот поэтому ты и не умеешь читать. Научись и умерь ЧСВ.

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

Значит пусть спросит еще раз пароль! Ты еще скажи на стенке записать пароль, что бы все видели.

Лолшто?!

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

Что, впрочем, не делает systemd не говном.

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

Чушь, учите С. Но я могу показать код который делает все тоже саме без единого goto, если сдаетесь.

И содержит в 4 раза больше уровней вложенности? :D

Deleted
()

В systemd-networkd начата работа по реализации протокола PPPoE

Оно хочет заменить собой Network Manager?

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

Ну хоть кто-то пытается вытянуть Linux из болота.

В чём состоит болото?

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

Какое-такое было болото, из которого systemd помогает вытащить Linux?

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

Если только в long-term. На данный момент конфигурирование полностью статическое; шинного интерфейса у этой штуки попросту нет.

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

Это не описка ? Именно сетевой стек ?

Вот и я про то.

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

Минимальный «cетевой менеджер/конфигуратор» (нет, всё-таки не стек), не имеющий внешних зависимостей. Аналог connman, только «всё в одном», потому что так надёжнее.

http://lists.freedesktop.org/archives/systemd-devel/2013-November/014253.html

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

Это не нарушает мое утверждение - тех, кто «славит» systemd тут можно по пальцам пересчитать.

Ну это не нарушает. Какая разница, оно все равно ложное.

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

системд

Использую системд на Убунту (я просто юзер, ни капли не прогер) отлично работает. 15.04 тестовая ни одного рапорта по системд, количество процессов значительно снизилось и надеюсь еще снизится, что делает систему на Юнити очень комфортно отзывчивой.

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

как связано направление зависимости и версионирование?

А ты подумай нахер вообще версионирование нужно, глупыш.

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

Не сложно, могли бы и сами догадаться. Как один из вариантов:

r = (process_locale() >= 0 &&
     process_timezone() >= 0 &&
     process_hostname() >= 0 &&
     process_machine_id() >= 0 &&
     process_root_password() >= 0) ? EXIT_SUCCESS : EXIT_FAILURE;
Почитайте про разницу между && и &, программировать станет проще. Я уже более десяти лет ниразу goto не использовал, просто не представляю себе ситуации когда этот оператор нужен. Еще неплохо Дейкстру почитать, он доказал ненужность этого оператора. Но в данном коде очистка выполняется в одном и тоже порядке в любом случае, поэтому никакой необходимости в грядке if нет. Я еще понимаю если бы они в разные места скакали.

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