I have had the exact same scenario.
It may be that the desktop crashes or gets completely unresponsive, while the compilation gets all the priority.
The solution should be simple:
the kernel scheduler and the out-of-memory solution need to prioritize the system shell, compositor and main GUI components at all costs. (like nice -18
, just the kernel etc running at nice -19
).
There were even discussions about the used oomd
vs more aggressive tools like earlyoom
.
Like the commenter on Lemmy, on Windows this never happened. Programs would freeze but the desktop always stayed responsive, taks manager could always be opened and the process killed.
This requires a working GUI
I am on Kinoite and the KDE Plasma experience has improved drastically since Plasma 6. Not a single freeze, if the shell crashed it always appeared back in place.
But are these issues fixed?
How to test:
- Use your desktop environment
- run some low level program: gcc, rust or something else that eats your RAM and CPU time
- see if the desktop stays responsive
Some comments on Lemmy
- Linux is made for servers or multi-seated systems
- desktops are often not prioritized correctly, but handled like any other process
- the zen kernel suppodedly improves on that
- this may have other sacrifices
I havent had these scenarios in a while but would like to fix this essential problem.
I could even imagine a new goal: Make Fedora work in edge cases like under high load, with limited RAM etc.
This will vary between the desktops.
Problems
CPU scheduler
- normally processes are spawned with
nice 0
- child processes get the priority of their parent. This breaks the entire concept, as nearly everything is a child process of the desktop?