LINUX.ORG.RU

Релиз systemd 230

 


4

8

Представлен выпуск системного менеджера systemd 230. Из новшеств можно отметить включение по умолчанию DNSSEС и режима чистки процессов пользователя после завершения сеанса, поддержку унифицированной иерархии cgroup, возможность настройки прокси ARP для сетевого интерфейса, новые типы юнитов generated и transient, новую команду systemctl revert и возможность создания виртуальных прямых сетевых ссылок между контейнерами.

Основные изменения:

  • В DNS-резолвере systemd-resolved по умолчанию включен DNSSEC. DNSSEC доступен в режиме allow-downgrade (автоматический откат на режим без DNSSEC) и может быть отключен через настройку DNSSEC в resolved.conf или на этапе сборки при указании опции configure --with-default-dnssec=no. Дистрибутивам пока не рекомендуется включать DNSSEC по умолчанию, пока не будут выявлены все возможные несовместимости режима DNSSEC с DNS-серверами.
  • В systemd-resolve добавлена возможность резолвинга DNS-записей DANE (DNS-based Authentication of Named Entities) при указании опции --tlsa и OPENPGPKEY при указании опции --openpgp, а также создания дампа raw-данных записей DNS при указании опции --raw=дамп.
  • В systemd-logind по умолчанию обеспечено принудительное завершение процессов, запущенных в составе пользовательского сеанса, после выхода пользователя из системы. Управлять принудительным завершением можно через опцию KillUserProcesses в logind.conf, которая теперь выставлена в значение yes по умолчанию, что требует отдельных настроек, если необходимо сохранить работу длительно выполняемых пользовательских процессов (для работы screen и tmux требуется специальная настройка сервисов, например, включение т.н. lingering через loginctl). Для восстановления старого поведения на этапе сборки можно указать опцию --without-kill-user-processes.
  • В systemd-logind добавлены новые настройки SessionsMax и InhibitorsMax, которые по умолчанию установлены в значение 8192.
  • В systemd-logind добавлена поддержка обновления конфигурации по сигналу SIGHUP.
  • Добавлена поддержка унифицированной иерархии cgroup (в ядре с 4.5), для задействования которой в systemd при загрузке требуется указать опцию командной строки ядра systemd.unified_cgroup_hierarchy=1. Для унифицированной иерархии также добавлен контроллер cgroup io, который дополнил контроллеры memory и pids.
  • Поддержка протокола LLDP (Link Layer Discovery Protocol) расширена возможностями использования пассивного (только приём) и активного (отправка) режимов. Пассивный режим включен по умолчанию в systemd-networkd, а активный режим включен по умолчанию в изолированных контейнерах с адресацией внутренней сети. Для просмотра статистики можно использовать команду networkctl lldp.
  • Добавлена возможность настройки уникальных идентификаторов IAID и DUID, отправляемых в запросах DHCP. Идентификаторы могут быть определены как для всей системы, так и для отдельных файлов .network при помощи опций DUIDType, DUIDRawData и IAID.
  • В systemd-networkd добавлена возможность настройки прокси ARP для отдельных сетевых интерфейсов, используя опцию ProxyArp в файлах .network. Кроме того, в файлы .netdev добавлены опции MulticastQuerier и MulticastSnooping, позволяющие включить режим отправки запросов и прослушивания IGMP-трафика.
  • В файлах .network представлена новая опция PreferredLifetime, позволяющая определить время жизни IP-адреса.
  • В DHCP-сервере, встроенном в systemd-networkd, активирована по умолчанию опция EmitRouter, включающая поле DHCP Option 3 (Router).
  • Тестовая утилита systemd-activate переименована в systemd-socket-activate и перемещена в /usr/bin.
  • В systemd-journald задействован отдельный поток для сброса прокэшированных данных на диск при закрытии файлов с журналом, что решило проблемы с задержками записи в лог на медленных дисках.
  • В journalctl добавлен новый метод вывода -o short-unix, при котором к записями в логе добавляется префикс с эпохальным (UNIX) временем (число секунд с 1970 года). Также добавлена опция --no-hostname для исключения столбца с именем хоста.
  • Устройства фреймбуфера, сканеры и 3D-принтеры теперь подключаются в режиме uaccess и доступны для вошедших в систему пользователей.
  • В опции DeviceAllow теперь можно указывать спецификаторы (начинаются с символа %).
  • В systemctl show добавлена опция --value, позволяющая вывести только содержимое заданного свойства юнита без указания его имени.
  • Для автоматически сгенерированных и созданных в процессе работы через обращения к API файлов добавлены новые типы юнитов generated и transient.
  • Добавлена новая команда systemctl revert для отката к предоставляемой поставщиком версии файла юнита в случае внесения в файл юнита локальных изменений.
  • В machinectl clean добавлена возможность автоматического удаления всех или только скрытых образов контейнеров.
  • В systemd-tmpfiles добавлен новый тип записи «e», позволяющий организовать очистку директорий, если они уже существуют.
  • В systemd-nspawn добавлена поддержка автоматического исправления UID/GID и ACL для всех файлов и директорий в контейнере для их соответствия диапазону UID/GID, выбранному при запуске контейнера.
  • В systemd-nspawn добавлена новая опция --network-zone для создания виртуальных прямых линков между контейнерами.
  • Для socket-юнитов добавлены опции TriggerLimitIntervalSec и TriggerLimitBurst для настройки лимитов на возможное число активаций в заданный промежуток времени.
  • Компонент systemd-bootchart вынесен в отдельный репозиторий.
  • Из состава удалён systemd-bus-proxyd, так как kdbus вряд ли будет принят в ядро в своём текущем виде.
  • Удалены библиотеки libsystemd-daemon.so, libsystemd-journal.so, libsystemd-id128.so и libsystemd-login.so, которые ранее были объявлены устаревшими.
  • Удалена опция Capabilities, вместо которой следует использовать AmbientCapabilities и CapabilityBoundingSet.

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

★★★★

Проверено: Falcon-peregrinus ()
Последнее исправление: Klymedy (всего исправлений: 5)
Ответ на: комментарий от intelfx

IPC в ядре это микроядро, IPC на уровне приложений это экзоядро. Если Поттеринг хочет сделать микроядро, то пусть делает. При чем тут текущее ядро linux?

anonymous
()

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

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

Да нет, дорогой, в ините я сразу вижу - что где и почему

И в системд тоже, ты просто неосилятор

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

которые за час значительно превышают лично твой месячный доход

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

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

А статья из вики воида не отвечает на твой вопрос?

нет. патчи инфиналити заточены под определенную версию fontconfig и freetype, а в репах война уже более новые. потому при установке получается не патчинг, а хатчинг. это не удобно.

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

IPC в ядре Linux уже есть, и не одно (сокеты, общая память, очереди сообщений). Микроядром оно от этого не становится.

intelfx ★★★★★
()

Стоит у меня ubuntu 16.04 на ноуте - ssd, i5-2410m, 8GB RAM и watt os R9 на celeron m 1.6 GHz 2 GB RAM (да, да, ноут 2004-го года), HDD 80GB. R9 собран на пакетной базе ubuntu, версии 12.04, если не ошибаюсь.

Удивительно, но грузится второй до состояния «рабочий стол + значки + указатель мыши» быстрее, чем первый. Он и до старта рабочего стола грузится быстрее. Никаких особых проблем от отсутствия systemd я не заметил - звук есть, wi-fi работает, ядро довольно свежее, флешки подключаются.

Ну вот нафига оно?

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

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

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

OMG, то есть это нормально что это надо вот переносить? то есть это хорошо теперь что надо заниматся совместимостью с одним другим и еще чем то там.

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

Кстати, я не видел чем этот systemd лучше, эфимерное - скорость загрузки (мне плевать на 2-3 секунды быстрее), новое - старое выполняло свои задачи без проблем, удобное - бинарные логи ниразу не удобны,

Ты про бинарные логи тут упоминаешь уже в *-цатый раз. Ты сам смотрел в каком формате логи хранятся? Не обратил внимания, что если их less-ом открыть, то human-readable лог там тоже есть и бинарная там только метадата? Или ты опять, прочитал где-то и теперь пересказываешь всем?

sysvinit работал, да, он просто работал, жил там себе, и не надо было думать что на bsd как то сильно иначе - плюс минус тоже самое, и screen везде работает.

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

Кстати, я не видел чем этот systemd лучше, эфимерное - скорость загрузки (мне плевать на 2-3 секунды быстрее)

Скорость - побочный эффект от того что systemd держит граф зависимостей сервисов друг от друга и стартует в правильном порядке, параллелизуя там, где возможно. Тебе не важно - кому-то важно.

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

Про «кривокод без проверок на null» - есть под рукой анализ? Там реально может возникать null или это такая же мантра как «нельзя пользоваться GOTO» ?

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

Стоит у меня ubuntu 16.04 на ноуте - ssd, i5-2410m, 8GB RAM и watt os R9 на celeron m 1.6 GHz 2 GB RAM (да, да, ноут 2004-го года), HDD 80GB. R9 собран на пакетной базе ubuntu, версии 12.04, если не ошибаюсь.

Удивительно, но грузится второй до состояния «рабочий стол + значки + указатель мыши» быстрее, чем первый.

Да пофиг на инит. Если у тебя система с SSD и i5-SNB грузится медленнее, чем с IDE HDD и целероном, то что-то в консерватории сильно не так. В данном случае, скорее всего, что-то не так с новой убунтой.

Никаких особых проблем от отсутствия systemd я не заметил - звук есть, wi-fi работает, ядро довольно свежее, флешки подключаются.
Ну вот нафига оно?

Мб затем, что в мире существуют не только ты, твоя система и твой юзкейс?

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

Удивительно, но грузится второй до состояния «рабочий стол + значки + указатель мыши» быстрее, чем первый. Он и до старта рабочего стола грузится быстрее.

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

Конечно же, убунта тормозит из-да systemd, а не из-за юнити, 100500 сервисов-индексаторов, веб-движка в линзах и изкоробочного вороха софта. Нет, именно из-за инита. А wattOS выигрывает не из-за openbox и того, что из неё калёным железом выжигали всё, что может тормозить загрузку и грузить проц, а благодаря upstart.

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

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

Есть задачи разной важности, под них выбираются разные железки.

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

Точнее, даже не так: он давным давно стабилен и делает то, что требуется.

Системд тоже, вроде как. В rhel/oel проблем не встречал. Остальное в проде от лукавого.

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

А я не говорю что одно. https://ru.wikipedia.org/wiki/Гибридное_ядро

Просто пару цитат:

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

Все взаимодействия внутри микроядра выполняются с помощью передачи сообщений. Механизм межпроцессного взаимодействия (Inter Process Communication, IPC) встраивается в систему, и различные серверы взаимодействуют между собой и обращаются к “службам” друг друга путем отправки сообщений через механизм IPC.

Kdbus — межпроцессный обмен сообщениями на уровне ядра

Одно из важных свойств экзоядерной архитектуры:

. традиционные абстракции, такие как VM и IPC, могут быть эффективно реализованы на уровне приложений, где они могут быть расширены, специализированы, или заменены;

Линус отказывается принимать в ядро код Kdbus и другие патчи Кея Сиверса, так как данный мэйнтейнер показал неспособность позаботиться об исправлении ошибок

Видимо в ядре linux не нужно делать еще больше IPC

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

Итак, смотрим на твои слова:

IPC в ядре это микроядро

Смотрим на первую картинку в твоей статье:

Monolithic Kernel Based Operating System
...
Kernel mode: IPC, file systems

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

Видимо в ядре linux не нужно делать еще больше IPC

Механизм kdbus много кто хочет из девелоперов, но код объективно - говно, поэтому в ядро его и не берут. И пока не напишут что-то нормальное - брать не будут. И это хорошо.

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

раньше я бы взял и просто не напрягаясь

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

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

код объективно - говно, поэтому в ядро его и не берут

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

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

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

Я помню что из федоры его выкинули именно из-за нестабильностей и большого количества багов.

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

из федоры его выкинули именно из-за нестабильностей и большого количества багов

Серьёзно?

https://lists.fedoraproject.org/pipermail/devel/2015-October/216235.html

The upstream developers asked me to remove the module from Fedora
while they rethink some of the approach they are taking with kdbus.

Тебе перевести?

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

Везёт. Когда-то не повезёт.

Это не технический аргумент, это можно ответить и на «в sysvinit всё работало».

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

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

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

Это не технический аргумент, это можно ответить и на «в sysvinit всё работало».

Это, зато, статистический аргумент, напрямую зависящий от объёма кода и количества излишней функциональности в ключевой подсистеме ОС.

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

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

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

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

Стоит у меня ubuntu 16.04 на ноуте - ssd, i5-2410m, 8GB RAM

Удивительно, но грузится второй до состояния «рабочий стол + значки + указатель мыши» быстрее, чем первый. Он и до старта рабочего стола грузится быстрее.

Посмотреть что сколько времени занимает в systemd можно как здесь: Релиз systemd 230 (комментарий)

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

статистический аргумент, напрямую зависящий от объёма кода и количества излишней функциональности в ключевой подсистеме ОС.

Статистический аргумент - это количество падений в живых системах по вине инита.

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

Нет. Ещё раз повторяю вопрос: где конкретно Линус отказался принимать в ядро конкретный kdbus?

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

Статистический аргумент - это количество падений в живых системах по вине инита.

У меня вот 0 с sysvinit (за всё время знакомства с Linux и с кучей компьютеров) и 1 с systemd (за какой-то год с хвостиком, на единственном экземляре). А говорил я, что что-то вылезет, задолго до этого.

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

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

Вот, честно, - что меня никогда не волновало, - это фонтовые патчи. 8)

Иначе говоря, - этой темой не занимался, использовал всегда готовое, по необходимости; - если у тебя самого есть намётки и данные, - где патчи эти (свежее чем infinality) регулярно брать, и куда эти патчи потом применять (инфиналити затрагивает три пакета, а вайновские патчи?), - могу передать эти данные Хуану, или сам подготовлю автоматизатор для этого решения, - как будет удобнее. Рассказывай, - сделаем.

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

1 с systemd (за какой-то год с хвостиком, на единственном экземляре).

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

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

Это вышеописанный случай с удавом?

Нет, это вышеописанный случай с race с fsck при заргузке. Но удава тоже можно, раз они вместе теперь. Тогда два, хотя удав - это не мой случай. :-)

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

чета мы в оффтоп ушли ) я тупо пересобрал в xbps-src понизив версии пакетов. без патчей кривые шрифты на 96dpi (тяжело работать). Хуану привет - шикарный дистр.

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

Это вышеописанный случай с удавом?

Кстати, о нём. Ещё вспомнился случай с изменяющимися названиями интерфейсов. Да-да, этих, которые, якобы, стабильные enp0s25.

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

Тут вероятней в busybox инит запилят (если не уже).

Уже, причём давно.

border-radius
()

Как Линуз Торвальдс и другие разработчики ядра Linux относятся к разработчикам systemd...

На примере одного бага...

Сам баг (цитата из комментария разраба ядра):

Steven Rostedt 2014-04-02 14:58:30 UTC

Hmm, a user adds to the *kernel* command line «debug» and systemd starts spitting out so much crap that the system doesn't boot anymore? That sounds like a major regression to me. Note this is a kernel command line, not a systemd command line. Userspace tools should not be using the same kernel parameters that are defined by the kernel. That's just broken and wrong.

This bugzilla is the poster child of why people hate systemd and do not trust the developers that work on it.

Статейка на networkworld:

Kernel panic as Systemd dev pokes the bear: http://www.networkworld.com/article/2175826/software/linus-torvalds-suspends-...

Под другим углом, фороникс: https://www.phoronix.com/scan.php?page=news_item&px=mty1mza

Оригинал для цитаты об отказе принимать патчи от девелоперов systemd, пока разработчики systemd не научатся «сами убирать за собой мусор»: https://lkml.org/lkml/2014/4/2/420

Linus said: «I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project. Because I am *not* willing to take patches from people who don't clean up after their problems, and don't admit that it's their problem to fix.»

Как один из разработчиков systemd пытается закрыть issue, который он не считает проблемой, хотя об этом ему сообщают разработчики ядра:

https://bugs.freedesktop.org/show_bug.cgi?id=76935

Финал обсуждения от Линуза, оригинал: https://lkml.org/lkml/2014/4/2/580

Linus:

[System services parsing /proc/cmdline is fine but] does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.

It looks like Greg has stepped in as a baby-sitter for Kay, and things are going to be fixed. And I'd really like to avoid adding hacky code to the kernel because of Kay's continued bad behavior, so I hope this works. But it's really sad that things like this get elevated to this kind of situation, and I personally find it annoying that it's always the same f*cking primadonna involved.

Обсуждение у ТеоЦо: https://plus.google.com/ TheodoreTso/posts/K7ijdmxJ8PF

Linus:

+Paul Morgan I think what you (and others) seem to miss is that the systemd people made the «debug» option that we introduced not just do something - but do something useless that actively broke other peoples use of that option.

It doesn't matter who «owns» it, the fact is, they broke it.

Ok, fine. Bugs happen, and that's not what makes people upset.

What makes me (and others) upset is that when the bug is reported, with explanations and a suggestion for how to fix it, Kay just closed the bug-report, claiming it wasn't a bug.

Seriously? You want to debug kernel stuff, using the kernel command line command «debug» that makes the kernel more verbose, and now the systemd people say «sorry, we stole your thing and made it useless, and it's not a bug because you didn't call shot-gun».

Now, if this was an isolated incident, I personally would let it go. There are bad engineers out there, it's not worth worrying about. Ignore them and move on.

But this is not an isolated incident. This is how Kay has treated other bugs in the past. Literally months of stalling, closing bug-reports, and blaming other people and projects for problems that he caused, telling others how they should change their projects because he broke something, and obviously it can't be his fault.

And that is a problem.

И, наконец, завершение этого эпического бага заключением от Пёттеринга (следует читать как «будет так, - я сказал!, другого варианта у нас нет»):

Lennart Poettering 2014-05-24 08:38:07 UTC

systemd in git since a while will turn its debug output on if the kernel command line cotnains «debug», this will stay that way. However, it has been changed to not dump things to kmsg as soon as the journal is up. Up to that point we will still dump things to kmsg howerver, since there's no other nice place to put this.

Closing.

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

Неужели за 18 страниц бреда здесь появилась первая серьёзная предъява?

systemd in git since a while will turn its debug output on if the kernel command line cotnains «debug», this will stay that way. However, it has been changed to not dump things to kmsg as soon as the journal is up. Up to that point we will still dump things to kmsg howerver, since there's no other nice place to put this.

Вот здесь Лёня и ко реально протупили. kmsg - хрен бы с ним, но неужели нельзя реагировать не на debug, а на какой-нибудь sysdebug, например? Перехватывать внутренние флаги для ядра - это уже не очень. Штеудач, есть какие-то доводы на этот счёт или они за джва года уже починили этот косяк?

border-radius
()
Последнее исправление: border-radius (всего исправлений: 1)

Неужели за 18 страниц бреда здесь появилась первая серьёзная предъява?

Я сразу сказал - метать бисер я не намерен...

Но раз уж тут прозвучали слова «покажите мне, где Линуз отказался принимать патчи», причем после того, как человечку, задавшему этот вопрос, ссылка на слова Торвальдса была брошена трижды, - и он ее просто проигнорировал, крича - «это всё бред», я уже не выдержал, и решил наконец обрубить этот пупок лжи.

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

Я читал этот тред, и крутил пальцем у виска, периодически делая facepalm. Дальше за ыныеуьв я не слежу. Мне лично достаточно было один раз наступить на его грабли, чтобы больше никогда не использовать этот «продукт», о чем я и писал выше.

Хотите огребать - огребайте. Я - не хочу. У меня есть всё, чтобы жить без этой поделки. И мне лично она не нужна.

Более того - я понял мотивы использующих эту поделку, о чем также написал выше, и не испытываю больше острой неприязни к поддерживающим это направление. Как можно обижать детей, отнимая у них любимую игрушку? Ответ - нельзя. Пусть играют до поры. Но лгать? Это уже через край, этого даже детям не прощают.

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

watt os

как оно вообще? свое основное предназначение оправдывает?

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

А чё в тред припёрся-то, дядя?

Хотел удостоверится, что апологеты systemd ведут себя в соответствие с моделью «10 заповедей национал-социалиста».

Хотел понять - почему продолжают упорно кушать кактус и доказывать всем, почему это вкусно.

Хотел понять молодняк.

Понял.

Легче стало? Да.

Я понимаю теперь мотивы локалхостеров, отстаивающих идеи этой системы. Понимаю даже этого мнимого админа из эстонского городишки с населением в 55++ тысяч человеков, якобы админящего 300-сколько-то-там серверов. - Ынеыеуьв даёт им уверенность, что с минимумом знаний им не придётся изучать всю остальную систему, и в ней они смогут сделать какую-то работу, не особо напрягая себе мозг. Дёшево и быстро. А баги можно всегда списать на производителя софта или дистрибутива. Логично, да. В начале 2000-х как раз по этим причинам некоторые компании выбирали windows2000server - проще заплатить за сервер, купить дешевого админа, отсертифицировать его, и купить с годик техподдержки для какого-нибудь iis/mssql, а за все баги, не связанные с самописным софтом этой компании, - ответственность несет microsoft. Тут - примерно та же схема, только утрированнее и проще.

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

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

$ curl https://intelfx.name/files/remarks.txt | grep -e «hater» -e «negat» -e «идиот» -e «тролль» -e «клоун»|wc -l 249

$ curl https://intelfx.name/files/remarks.txt |wc -l 388

То есть - из 388 человечков, которые участвовали в прошлых спорах про systemd, 249 активно выразили своё недовольство ситуацией с systemd. Это говорит о том, что потенциально мыслящих среди общего числа systemd-спорщиков, которых отметил один из ярых апологетов systemd - примерно в полтора раза больше, чем апологетов+нейтралов+хохмачей. откинем _примерно_ 10% дельты на фактор ошибки в оценке этих пользователей апологетом systemd, ведущим этот самый список - получаем не такой уж плохой расклад - 1.3:1, есть куда стремиться. Для этого сообщества далеко не всё потеряно - здесь можно найти достаточно разумных людей. Исключая фанатиков systemd-пути, конечно же.

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

Haters gonna hate

Здесь - пример всего одного критического бага, который, ко всему, препятствует загрузке системы

4.2. Баг с kmsg не препятствует загрузке системы, он просто какое-то время разбавляет ядерные сообщения системдэшными, и мне это поведение кажется странным, но я же не кричу «азазанинужна», а пытаюсь выяснить нынешний статус этого вопроса.

У меня есть всё, чтобы жить без этой поделки. И мне лично она не нужна.

Ну так почему ты ещё здесь?

border-radius
()
Ответ на: комментарий от zink

Механизм kdbus много кто хочет из девелоперов, но код объективно - говно,

те многие кто хотят пишут говнокод?

Deleted
()
Ответ на: Haters gonna hate от border-radius

Баг с kmsg не препятствует загрузке системы

...Когда же вы все уже начнёте наконец читать написанное и думать над тем, что прочитали...

Выше процитировал - для кого?

Релиз systemd 230 (комментарий)

...«systemd starts spitting out so much crap that the system doesn't boot anymore»...

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

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

Вот тебе ещё json, потренируйся парсить своими ретроградскими методами.

...«systemd starts spitting out so much crap that the system doesn't boot anymore»...

Не верю. Вот не верю и всё. Даже если такое два года назад было, не верю, что до сих пор так. Вот щас чисто из принципа перезагружусь и проверю.

Upd: проверил. Косяк на месте (до запуска journald systemd вываливает простыню в kmsg), но: 1) система, хоть и медленнее, но грузится; 2) ядро при запуске вываливает простыню несоизмеримо больше, чем systemd.

Вывод - косяк на данный момент имеет место, но несущественен.

border-radius
()
Последнее исправление: border-radius (всего исправлений: 1)

У меня вот на дефолтной Ubuntu 16.04 так:

Startup finished in 4.556s (kernel) + 3min 26.427s (userspace) = 3min 30.983s 
Многовааато

datafile4
()
Ответ на: комментарий от border-radius

Не верю. Вот не верю и всё.

Вот о том я и говорил - это вопрос религии, а не технической стороны.

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

Ладно, не верь дальше. По секрету скажу - после этого эпического бага в ядро был внедрен воркэраунд, согласованный с обеими сторонами, этот воркэраунд добавлял рейт лимит на сообщения kmsg

Вот тебе ещё json, потренируйся парсить своими ретроградскими методами.

Зачем? Для json у меня есть другие методы, использующие простейшие парсеры, - только зачем мне еще один набор данных? 8)

Я уже всё выяснил, а ты продолжаешь мне показывать павлиний хвост, как будто мне интересно - что под ним. 8) Зачем?

Я же доступно объяснил - что мне было нужно от этого треда. Я получил нужное, дальнейшее развитие событий меня уже не особо интересует. Хочешь продолжать спор - и зачем? 8)

Тебе так важно, чтобы последнее слово осталось за тобой?

Да пожалуйста, отвечай дальше, делай публично выводы, - я умолкаю. Посмеюсь молча... 8)

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