9.2 норм собирает

Предлагаю тщательнее тестировать 😏

Так куда еще тщательнее. Ты где был когда тестировали? Зарепортил, надеюсь?

Так куда еще тщательнее. Ты где был когда тестировали? Зарепортил, надеюсь?

Нет. Я так и не понял, где и что в софте сломалось

Помню проблемы были на первом этапе но их быстро отловили. Хотя если вспомнить недавний баг с firefox, то там тоже GCC упоминался. Но как иначе протестировать и самое главное кто будет всё это фиксить? Сидеть на старом всегда можно на CentOS.

А вот ченж немного спорный https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_transaction

To mark a services as "restart on upgrade" the unit file should contain an option to mark it so. This can be either in the main .service file, or e.g. in a drop-in file in /usr/lib/systemd/system/<service>.service.d/needs-restart.conf. The exact name of the option should be something like X-restart-on-upgrade=true|false. I'll take the proposal for discussion in systemd upstream, since this is something that could be used across distributions, and then the "X-" prefix could be dropped and/or the name changed.

Я не сильно уверен, что мейнтейнер nginx установит этот параметр в true.

Ну, тут да, я согласен.

Я не сильно уверен, что мейнтейнер nginx установит этот параметр в true.

Ну а какие у него варианты есть?

Ну а какие у него варианты есть?

Отключить автоперезагрузку сервиса при обновлением, и включить. Надеюсь, будет первый вариант.

Отключить автоперезагрузку сервиса при обновлением, и включить. Надеюсь, будет первый вариант.

Но зачем? Сейчас, кстати, почти все сервисы перезапускаются во время обновления

Но зачем? Сейчас, кстати, почти все сервисы перезапускаются во время обновления

На самом деле, вся разница до этого изменения и после только в том, в какой момент это всё происходит. И как это контролируется (ну или как сейчас, не контролируется).

Но зачем? Сейчас, кстати, почти все сервисы перезапускаются во время обновления

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

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

Видимо я тебя неправильно понял, ты за или против изменения?

Видимо я тебя неправильно понял, ты за или против изменения?

Ну, на самом деле, против.

Но тут смотря с какой стороны смотреть.

Ну, на самом деле, против.

Почему?

Почему?

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

Каковы ваши мысли и чувства в связи с пропозалом? https://fedoraproject.org/wiki/Changes/EnableEarlyoom

Отключу сразу же себе его.

@Artem4 в чем плюсы дефолтного поведения для тебя?

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

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

Разве дефолтный киллер не будет делать то же самое?

Не будет. Рад что теперь это хоть протестят массово и засыпят багами и жалобами того кто это придумал. А не только 5 секунд проверят в VM.

Если ты опасаешься за приоритеты убийства, то порядок убийства у юзерспейсного и ядерного одинаков - если VM самая жирная, то также будет убита и ядерным киллером.

У меня опасения вызывают не возможные баги в самом earlyoom (он достаточно неплохо протестирован, широко известен, последний релиз был более полугода назад), а изменившееся поведение: 1. ядерная настройка в cgroup2 memory.oom.group, применяемая для убийства всей группы, не будет работать: завершится один процесс вместо группы. 2. Вероятно, не сработают настройки KillMode= и OOMPolicy=, применяемые в юнитах.

https://fedoraproject.org/wiki/Changes/PythonStaticSpeedup таким образом удалось ускорить до 30%

Еще 30% speed-up https://towardsdatascience.com/making-python-programs-blazingly-fast-c1cd79bd1b32

Это новое или всё те же 30?

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

кроме того, интересно, работает ли, действительно, расставление приоритетов

Какое расставление? Где? приоритеты как в ядерном, но можно менять сопоставлением имени процесса с регуляркой.

Каковы ваши мысли и чувства в связи с пропозалом? https://fedoraproject.org/wiki/Changes/EnableEarlyoom

Эта штука не нужна ИМХО.

Это уже вопросы к производителю твоей материнки.

У меня опасения вызывают не возможные баги в самом earlyoom (он достаточно неплохо протестирован, широко известен, последний релиз был более полугода назад), а изменившееся поведение: 1. ядерная настройка в cgroup2 memory.oom.group, применяемая для убийства всей группы, не будет работать: завершится один процесс вместо группы. 2. Вероятно, не сработают настройки KillMode= и OOMPolicy=, применяемые в юнитах.

Не забудь об этом написать в список рассылки

Сложный алгоритм есть только в далеких планах реализовать в ядре, но серьезно этим никто не занимается до сих пор. А это всё хаки.

А это нормально, что chromium-libs-media-freeworld давнгрейдит chromium?

А это нормально, что chromium-libs-media-freeworld давнгрейдит chromium?

Юзай chromium-freeworld, и тогда не придётся задавать этот вопрос. 🙂

А это нормально, что chromium-libs-media-freeworld давнгрейдит chromium?

они вечно отстают

:(

https://lwn.net/SubscriberLink/808278/1722bede4004336d/

Каковы ваши мысли и чувства в связи с пропозалом? https://fedoraproject.org/wiki/Changes/EnableEarlyoom

Мне эта штука реально помогает, но по дефолту включать не стоит кмк

Fedora 31, KDE Пытаюсь настроить автоматический вход в систему. В настройках-учетная запись-управление пользователями ставлю галку "автоматический вход", выскакивает запрос пароля, ввожу, нажимаю "применить", выскакивает запрос пароля, ввожу, настройки применяются. Т.е. запрос пароля появляется дважды. Перезагружаюсь - запрос пароля. Потом оказалось, что если выйти из настроек и зайти снова, то можно обнаружить, что настройки входа не изменились. Куда копать?

Fedora 31, KDE Пытаюсь настроить автоматический вход в систему. В настройках-учетная запись-управление пользователями ставлю галку "автоматический вход", выскакивает запрос пароля, ввожу, нажимаю "применить", выскакивает запрос пароля, ввожу, настройки применяются. Т.е. запрос пароля появляется дважды. Перезагружаюсь - запрос пароля. Потом оказалось, что если выйти из настроек и зайти снова, то можно обнаружить, что настройки входа не изменились. Куда копать?

ручками etc/kde/kdm/kdmrc AutoLoginEnable и AutoLoginUser

ручками etc/kde/kdm/kdmrc AutoLoginEnable и AutoLoginUser

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

тогда в /etc/gdm/custom.conf [daemon] AutomaticLoginEnable=true AutomaticLogin="user"

:)))) Папки gdm тоже нет. Что-то мне 5.17.4 не нравятся очень.

Fedora 31, KDE Пытаюсь настроить автоматический вход в систему. В настройках-учетная запись-управление пользователями ставлю галку "автоматический вход", выскакивает запрос пароля, ввожу, нажимаю "применить", выскакивает запрос пароля, ввожу, настройки применяются. Т.е. запрос пароля появляется дважды. Перезагружаюсь - запрос пароля. Потом оказалось, что если выйти из настроек и зайти снова, то можно обнаружить, что настройки входа не изменились. Куда копать?

а ты когда настраивал пользователя то указал под каким заходить собираешься?

Да. Под обычным. С приданными правами админа. Не первый раз ставлю.

Да. Под обычным. С приданными правами админа. Не первый раз ставлю.

у тебя же 5(plasma)? /etc/sddm.conf [Autologin] User=user* Session=plasma.desktop

у тебя же 5(plasma)? /etc/sddm.conf [Autologin] User=user* Session=plasma.desktop

Да, 5. Кстати файл у меня пустой.

по умолчанию пустой насколько помню

по умолчанию пустой насколько помню

Ок. Перелогинюсь - отпишусь.

у тебя же 5(plasma)? /etc/sddm.conf [Autologin] User=user* Session=plasma.desktop

С этими настройками система не грузится. Зависает.

Ядро использует сложный алгоритм для нахождения oom_score. earlyoom использует простой алгоритм: выбирает процесс с наибольшим oom_score.

Сложный алгоритм есть только в далеких планах реализовать в ядре, но серьезно этим никто не занимается до сих пор. А это всё хаки.

Так говоришь, будто хаки - это что-то плохое.

Не забудь об этом написать в список рассылки

В issue по крайней мере написал, Крис уже отреагировал.

Он не агрессивен как тот ЛММ. Приоритет убийства как у ядерного киллера. Не убивает новую жертву, если не умерла старая. Все аккуратно.

Эта штука не нужна ИМХО.

Есть ли свежие аргументы?

Есть ли свежие аргументы?

Опять повторять то, что уже писали? Не, пасиб.

NAP это не запрещает, почему бы и не зайти

В NixOS чате? Он в основном обитает там.

Ещё раз убедился в том, что cmake 💩

На самом деле, там гораздо сложнее что-то испортить

А зачем ему это хардкодить?

Или просто напакостить хочет, как маленький?

Вы так тесно общаетесь в кепке, спросил бы ?)

вопрос помнится ещё пару лет назад bridge-utils были объявлены obsolete. не изменяет ли мне память? и если нет, то что он делает в 31 федоре?!

‼️ WINE остался без меинтенера https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/J5AXWQ2LND2SOGQBZ3AUIRICI4X2SLRC/

Здравствуйте

‼️ WINE остался без меинтенера https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/J5AXWQ2LND2SOGQBZ3AUIRICI4X2SLRC/

А это уже хуже.

Свято место пусто не бывает.

Надеюсь.

Там вроде Кевин написал что частично пофиксили инфру, но частично еще что-нужно сделать. Но starship уже например и пара других апдейтов уже прошли вот только что. @ignatenkobrain

Там вроде Кевин написал что частично пофиксили инфру, но частично еще что-нужно сделать. Но starship уже например и пара других апдейтов уже прошли вот только что. @ignatenkobrain

не прошло и года

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

Но у меня и в кодзи кое-какие застряли притом капитально. И вроде даже их пытались остановить, но оно все равно open 😃

‼️ WINE остался без меинтенера https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/J5AXWQ2LND2SOGQBZ3AUIRICI4X2SLRC/

Во, это шанс, засунь в репы proton ge, это тот же current wine staging + патчи протона, хуже не будет.

Во, это шанс, засунь в репы proton ge, это тот же current wine staging + патчи протона, хуже не будет.

1. Одному другому не мешает. 2. Я не вижу чтобы пакет был orphaned. Всё те же два меинтенера и совсем недавно обновляли его.

Но в рассылке я спросил уже что это значит.

Разве дефолтный киллер не будет делать то же самое?

> So yeah, enabling earlyoom by default means OOMPolicy is, in effect, preempted. Most of the time it should be earlyoom doing the killing.