earlyoom VS picom

EarlyOOM [1] could help with that quite a lot. Not to sure about using it on chromebooks, but linux got quite a bit more usable because of it.

[1] https://github.com/rfjakob/earlyoom

> The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong. It might become slower as pages are flushed to disk but it shouldn't be terrible unless you are really constrained and thrashing. If the Kernel still can't allocate memory, you should expect the OOMKiller to start removing processes. It should not just 'lock up'. Something is wrong.

I don't why but locking up is my usual experience for Desktop Linux for many years and distros, and I remember seeing at least one article explaining why. The only real solution is calling the OOMKiller early either with a daemon or SysRq.

> It should not take minutes. Should happen really quickly once thresholds are reached and allocations are attempted. What is probably happening is that the system has not run out of memory just yet but it is very close and is busy thrashing the swap. If this is happening frequently you may need to adjust your settings (vm.overcommit, vm.admin_reserve_kbytes, etc). Or even deploy something like EarlyOOM (https://github.com/rfjakob/earlyoom). Or you might just need more RAM, honestly.

Yeah. Exactly. But as the thread says, why aren't those things set up automatically?

It's not that simple: some defaults may differ, and some features may arrive at different times (if ever). For example, earlyoom has been enabled on Workstation since F32, but the KDE Plasma spin got it one release later.

Most answers will answer your question, but you can do better and avoid the freezes in the first place. IME almost every time the system froze up and didn't come back in a few seconds it was out of memory. The obvious solution is to add memory, but you can use Early OOM to kill hungry processes if you're running out of memory instead.

It sounds like you're running out of memory though, so if your OS's OOM killer isn't working as well as it should, you can try earlyoom as an alternative.

Picom has an awesome feature [0] that, for the sake of all our eyes, should come by default on every device with a screen. It can continuously adjust the brightness of individual windows by averaging all the pixels in that window. It's great for defending against "flashbangs" (when a new tab burns your eyes with a blank white screen).

0: https://github.com/yshui/picom/blob/ae73f45ad9e313091cdf720d...

Picom is a lightweight standalone compositor created for the X Window System. It is a fork of Compton (which is a fork of xcompmgr-dana, which is also a fork of xcompmgr) and it is suitable for use with window managers like Openbox that do not provide compositing effects on their own. If you want to learn more about its history, then you should visit this page or, if you are interested in knowing a bit more about it, you can check its page on the Arch wiki.

(https://github.com/yshui/picom/blob/next/picom.sample.conf)

Also I took a census and zero founding members of NWA are "straight outta Picom". That's right, you heard it here first: Not even MC Ren is running Picom.

Update: after reporting in picom GitHub repo this is temporarily solved by using --no-frame-pacing. Looks like a recent commit causes this. You can view the discussion here: https://github.com/yshui/picom/issues/1072

NEED HELP TESTING (write your issues here): https://github.com/yshui/picom/issues/1052

Compositor : picom

It looks like this was identified and the repo corrected in Jan (https://github.com/yshui/picom/issues/808) but the NixOS package has not been updated since Nov.