earlyoom VS linux

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.

There’s a one-sentence implied claim in here that raii is the reason for c++ rejection and rejection of c++ implies rejection of raii.

The author is clearly unaware of the recent cleanup attribute infrastructure submitted on the c side of the kernel: https://github.com/torvalds/linux/blob/master/include/linux/...

torvalds/linux//kernel/hung_task.c :

static void check_hung_task(struct task_struct *t, unsigned long timeout) https://github.com/torvalds/linux/blob/9f16d5e6f220661f73b36...

static void check_hung_uninterruptible_tasks(unsigned long timeout)

Read the source Luke: https://github.com/torvalds/linux/blob/master/drivers/tty/vt...

Linux Operating System

Curiously, I can't find this message in recent kernels, it was patched out in 2018: https://github.com/torvalds/linux/commit/9d7c249a1ef9bf0d569... . Is it being re-added by distros or something?

I'm reasonably confident that it is upstream: https://github.com/torvalds/linux/blob/master/drivers/androi... looks like the most obvious bit, though there are other pieces. (And now I'm curious why waydroid is maintaining their own dkms code separate from that; perhaps it's to better target a range of kernel versions?) I will agree that it's not generally actually built/used by distros.

I am pretty sure they just grep'd mail.ru, added a couple of other sus entries and pushed the commit. It's painfully obvious if you take a look at the file https://github.com/torvalds/linux/blob/master/MAINTAINERS, there are no mail.ru addresses left (it's a public email service akin to gmail). The next day someone woke up Linus and told him to answer the public and he came up with the usual FU. That's basically all.

I don't think clause 2b says that, do you perhaps mean clause 2a? In GPLv2 that says:

> a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

while in GPLv3 it says

> a) The work must carry prominent notices stating that you modified it, and giving a relevant date.

Note that git/svn are not always relevant. In particular, it is not uncommon to distribute release code with the .git directory stripped - this does not excuse you from the requirement.

Having said that, I had a quick glance at Linux, and picking a file at random it did have a copyright header, but certainly not one that included a record of every change. https://github.com/torvalds/linux/blob/master/init/calibrate...

So it doesn't look like this is peculiar to v2. But it does seem like people don't follow the letter of the requirement. I wonder if the FSF has ever clarified this.