Новая версия Systemd 210

Всего через пять дней с момента выпуска значительного релиза systemd 209 Леннарт Поттеринг (Lennart Poettering) представил корректирующее обновление системного менеджера systemd 210, в котором по горячим следам внесено 14 исправлений и улучшений. Новый выпуск уже добавлен в репозиторий Fedora Rawhide.

Наиболее заметные изменения:

• Уход от использования атрибута IFUNC в библиотеках для обеспечения совместимости (libsystemd-journal.so, libsystem-id128.so, libsystemd-login.so и libsystemd-daemon.so), что позволяет собрать библиотеки для архитектуры ARM с использованием инструментария, не поддерживающего IFUNC;
• Добавлена поддержка включения/отключения systemd-networkd через systemctl;
• Для unit-файлов добавлена поддержка атрибута "AppArmoreProfile=" для привязки к процессам профиля AppArmor;
• Для unit-файлов добавлена условная переменная "ConditionArchitecture=", позволяющая осуществить привязку к системной архитектуре.
• В systemd-networkd обеспечена поддержка проверки использования виртуализации, архитектуры, опций запуска ядра, имени хоста и идентификатора системы;
• В logind реализован более агрессивный переход в спящий режим при закрытии крышки ноутбука;
• Для systemd-networkd включен по умолчанию файл конфигурации .network для настройки DHCP для сетевых интерфейсов, созданных при помощи nspawn с опциями --network-veth или --network-bridge;
• Добавлена поддержка суффиксов M, K, G, T (кратные 1000) для определения пропускной способности. По умолчанию по-прежнему используются значения кратные 1024;
• В опции "DeviceAllow=" для unit-файлов теперь допускается помещением в белый список разом группы устройств, представленных в /proc/devices (например, указав "char-pts помещаем в белый список все псевдотерминалы);
• В sd-event добавлен новый источник событий - "post";

Источник: http://www.opennet.ru/opennews/art.shtml?num=39181

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

Это просто так кажется из-за единого номера версии.
Если бы нумерация была 20.9, вы бы и не обратили внимания. У всех бывает выход заплаток даже на следующий день.
Взять хотя бы недавний grep

Oops-релиз grep 2.17, с ускорением работы при использовании multbyte-кодировок в ряде случаев до десяти раз, как оказалось на самом деле замедлил их в двести раз. Ну бывает, чего уж там. Jim Meyering оперативно выпустил версию 2.18 с исправлением, выводящим grep на заявленные показатели по производительности.

И в kernel такое бывает. Ничего особенного.

Но вы же от этого не перестаёте доверять grep или ядру?

"basileus" написал:

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

"Vascom" написал:

Oops-релиз grep 2.17, с ускорением работы при использовании multbyte-кодировок в ряде случаев до десяти раз, как оказалось на самом деле замедлил их в двести раз.

"drBatty" написал:

большие файлы

большие это какие?

"dyasny" написал:

большие это какие?

"drBatty" написал:

размером с RAM.

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

"dyasny" написал:

я в свое время задолбался ковыряться в логах такого размера, и написал парсер который пихает их в БД, а там поиск и кореляции намного проще делать.

"dyasny" написал:

дамп RAM конечно анализировать таким образом не получится

кому он нужен? Речь как раз о дампах СУБД например. Типичная задача: имеем сервер с Over9000Mb, имеем клиент с 512Мб, и нужно на клиенте что-то найти в БД с сервера. Есть дамп, но он в Over9000Mb.

у меня другой случай - логи в DEBUG, 100 файлов по гигабайту каждый, с пары сотен хостов одновременно. Надо во первых иметь возможность вычислить поток событий, причем некоторые транзакции могут начаться на одном хосте, и быть продолжены на другом, или подзадача отгружена на другой, потому что он менее занят. Короче без очень быстрого поиска и такой-то матери не получалось, так что я держал ВМ с 32гб памяти только под эту базу - загрузил логи, сделал анализ, выкинул базу

"dyasny" написал:

Короче без очень быстрого поиска и такой-то матери не получалось

"dyasny" написал:

так что я держал ВМ с 32гб памяти только под эту базу

Vascom написал:

Это просто так кажется из-за единого номера версии.
Если бы нумерация была 20.9, вы бы и не обратили внимания. У всех бывает выход заплаток даже на следующий день.

Как бы сказать... "первичный" номер релиза в большинстве случаев является мажорным, т.е. 209-я версия уже должна быть по определению на каком-то уровне стабильности. А вот дальше как бы должны выходить релизы с точкой. Поэтому да, у меня диссонанс. Кстати на 20.9 я бы тоже обратил внимание. Видимо уже избалован версиями 20.9.ххх. Вот на такой релиз я бы внимания и не обратил. Но вообще здесь больше смущает именно краткость срока между 209-м и 210-м релизами.

"basileus" написал:

Но вообще здесь больше смущает именно краткость срока между 209-м и 210-м релизами.

Нет ничего странного.
210 релиз минорный к 209-му.
Когда захотели, тогда и выпустили.

Иногда даже kernel.org свои минорные релизы с одним пунктом исправлений выпускает чуть ли не через пару часов после предыдущего.

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

"basileus" написал:

Но вообще здесь больше смущает именно краткость срока между 209-м и 210-м релизами.

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

"Vascom" написал:

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

Не разводи очередной срач. И пиши ошибки в багзиллу.

Vascom, не развожу. Мне ||.

"drBatty" написал:

я думаю быстрее было-бы сделать на sed.

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

"drBatty" написал:

ну не у всех есть 32гб лишние, потому иногда и думать надо

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