Собирать телегу 1.9 😊

А я и так им не пользуюсь 😀

Блин, надо мне что-то делать с частотой опечаток.

Попробуй вычитывать сообщения перед отправкой.. 😉

Блин, надо мне что-то делать с частотой опечаток.

@xvitaly глянь админку плз. Может их всех пачкой сразу тогда уже?

У меня без сноса даже работало.

Благодаря этому я понял, что экран не просто мой плох, он полное дерьмо. У меня один муар.

а как запустить без иксов? 3 куда писать?

Про это речь наверное https://russianfedora.github.io/FAQ/administration.html#configure-runlevel

Просто отключи graphical.target через systemd. Но это не точно.

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

пробовал во вторую консоль переключаться?

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

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

Ну вот и Леннарт появился в треде про earlyoom. tl;dr: > Hmm, are we sure this is something we want to have in the default install? Is the code really good enough for that? > Yes, l-m-m is great. If we can deploy l-m-m today already, why isn't it good enoug for earlyoom? > Anyway, still not convinced having this is a good idea. There's a lot of homework to be done first...

и это надо фиксить как можно быстрее

и это надо фиксить как можно быстрее

а earlyoom костыль? :-)

> Anyway, this all sounds very very fishy to me. Леннарт.

не, так и я могу написать :) по существу бы аргументов

Загони всех разработчиков ядра в ангар и прикажи им чтобы написали нормальный киллер и пока не напишут никто не выйдет. > For now, kernel developers have made it clear they do not care about user space responsiveness. At all. Their concern with kernel oom-killer is strictly with keeping the kernel functioning.

Не, ты уже не первый день флеймишь, зачем не знаю. По существую там уже написано 100500 всего, сходи и почитай уже.

> дохнет от любого жрущего чиха. > правильно делают > по существу Сходи почитай, не. ✅👌🏻

ну если у тебя это сейчас работает не так, то у тебя другой линукс какой-то

Может ты до сих пор не понял что текущее, предложенное решение может создать больше проблем чем решить. Давай ты почитаешь сначала хотя бы что Леня пишет, а потом послушаем уже мнение других экспертов Hmm, are we sure this is something we want to have in the default install? Is the code really good enough for that? Looking at the sources very superficially I see a couple of problems: 1. Waking up all the time in 100ms intervals? We generally try to avoid waking the CPU up all the time if nothing happens. Saving power and things. 2. New code using system() in the year 2020? Really? 3. Fixed size buffers and implicit, undetected, truncation of strings at various places (for example, when formatting the shell string to pass to system()). But more importantly: are we sure this actually operates the way we should? i.e. PSI is really what should be watched. It is not interesting who uses how much memory and triggering kills on that. What matters is to detect when the system becomes slow due to that, i.e. *latencies* introduced due to memory pressure and that's what PSI is about, and hence what should be used. But even if we'd ignore that in order fight latencies one should watch latencies: OOM killing per process is just not appropriate on a systemd system: all our system services (and a good chunk of our user services too) are sorted neatly into cgroups, and we really should kill them as a whole and not just individual processes inside them. systemd manages that today, and makes exceptions configurable via OOMPolicy=, and with your earlyoom stuff you break that. This looks like second guessing the kernel memory management folks at a place where one can only lose, and at the time breaking correct OOM reporting by the kernel via cgroups and stuff. Also: what precisely is this even supposed to do? Replace the algorithm for detecting *when* to go on a kill rampage? Or actually replace the algorithm selecting *what* to kill during a kill rampage? If it's the former (which the name of the project suggests, _early_oom)), then at the most basic the tool should let the kernel do the killing, i.e. "echo f > /proc/sysrq-trigger". That way the reporting via cgroups isn't fucked, and systemd can still do its thing, and the kernel can kill per cgroup rather than per process... Anyway, this all sounds very very fishy to me. Not thought to the end, and I am pretty sure this is something the kernel memory management folks should give a blessing to. Second guessing the kernel like that is just a bad idea if you ask me. I mean, yes, the OOM killer might not be that great currently, but this sounds like something to fix in kernel land, and if that doesn't work out for some reason because kernel devs can't agree, then do it as fallback in userspace, but with sound input from the kernel folks, and the blessing of at least some of the kernel folks. Lennart

Может ты до сих пор не понял что текущее, предложенное решение может создать больше проблем чем решить. Давай ты почитаешь сначала хотя бы что Леня пишет, а потом послушаем уже мнение других экспертов Hmm, are we sure this is something we want to have in the default install? Is the code really good enough for that? Looking at the sources very superficially I see a couple of problems: 1. Waking up all the time in 100ms intervals? We generally try to avoid waking the CPU up all the time if nothing happens. Saving power and things. 2. New code using system() in the year 2020? Really? 3. Fixed size buffers and implicit, undetected, truncation of strings at various places (for example, when formatting the shell string to pass to system()). But more importantly: are we sure this actually operates the way we should? i.e. PSI is really what should be watched. It is not interesting who uses how much memory and triggering kills on that. What matters is to detect when the system becomes slow due to that, i.e. *latencies* introduced due to memory pressure and that's what PSI is about, and hence what should be used. But even if we'd ignore that in order fight latencies one should watch latencies: OOM killing per process is just not appropriate on a systemd system: all our system services (and a good chunk of our user services too) are sorted neatly into cgroups, and we really should kill them as a whole and not just individual processes inside them. systemd manages that today, and makes exceptions configurable via OOMPolicy=, and with your earlyoom stuff you break that. This looks like second guessing the kernel memory management folks at a place where one can only lose, and at the time breaking correct OOM reporting by the kernel via cgroups and stuff. Also: what precisely is this even supposed to do? Replace the algorithm for detecting *when* to go on a kill rampage? Or actually replace the algorithm selecting *what* to kill during a kill rampage? If it's the former (which the name of the project suggests, _early_oom)), then at the most basic the tool should let the kernel do the killing, i.e. "echo f > /proc/sysrq-trigger". That way the reporting via cgroups isn't fucked, and systemd can still do its thing, and the kernel can kill per cgroup rather than per process... Anyway, this all sounds very very fishy to me. Not thought to the end, and I am pretty sure this is something the kernel memory management folks should give a blessing to. Second guessing the kernel like that is just a bad idea if you ask me. I mean, yes, the OOM killer might not be that great currently, but this sounds like something to fix in kernel land, and if that doesn't work out for some reason because kernel devs can't agree, then do it as fallback in userspace, but with sound input from the kernel folks, and the blessing of at least some of the kernel folks. Lennart

Что за?

Я так мельком почитал, а ентерпрайз варианта не убивать вообще процессы при нехватке озу для создания новых есть/возможен? Было бы здорово, если бы система пилинговала на почту/в другой сервис, что вот вот будет катастрофа

Так заббикс же

Насколько я понимаю, основные разработчики сидят на зарплате рх и будут делать то, что рх скажут Кто пойдёт гном ос пилить то? Те самые авторы сомнительных идей переписывания всего и вся на жаваскрипт? Если я не прав, поправьте, пожалуйста

Насколько я понимаю, основные разработчики сидят на зарплате рх и будут делать то, что рх скажут Кто пойдёт гном ос пилить то? Те самые авторы сомнительных идей переписывания всего и вся на жаваскрипт? Если я не прав, поправьте, пожалуйста

Забиккс мониторинг ведь, а как оом киллеры эти вообще остановить?

Уже в прошлом. Если интересно читни матрикс чат, там мы хоть немного перетерли это.

Выпилить. Зачем они тебе на сервере? Да и не будут они никогда включаться в поставку fedora server или rhel/centos

Ладно, спасибо