1

Всего через пять дней с момента выпуска значительного релиза 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

2

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

SimplyMepis ->OpenSUSE->Mandriva->OpenSUSE

3

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

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

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

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

4

basileus пишет:

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

у меня для вас плохие новости: если в программе нет багов, то это Must Die.

Т.ч. пусть Леннарт пилит, я за.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

5

Vascom пишет:

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

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

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

6

drBatty пишет:

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

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

7

dyasny пишет:

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

размером с RAM.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

8

drBatty пишет:

размером с RAM.

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

9

dyasny пишет:

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

проще, но не быстрее. Если у вас память скажем 4096Мб, то с таким файлом БД займёт как минимум 8192Мб, и не влезет в память. Т.ч. это не решение.

dyasny пишет:

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

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

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

10

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

11

dyasny пишет:

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

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

dyasny пишет:

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

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

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

12

Vascom пишет:

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

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

SimplyMepis ->OpenSUSE->Mandriva->OpenSUSE

13

basileus пишет:

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

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

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

14

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

15

basileus пишет:

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

там все "релизы" пока ещё беты. Точнее преальфы. Релизы пойдут когда его в RHEL запилят.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

16

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

17

Vascom пишет:

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

естественно. Но очевидно, что сабж ещё не готов для продакшена.

за пруфом далеко ходить не надо: Ошибка входа в систему.

никто даже не попытался помочь.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

18

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

19

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

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

20

drBatty пишет:

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

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

drBatty пишет:

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

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