I meant, obviously in the sense that Windows and macOS both apparently already do this and that it’s a desirable property to have, not that it’s technically easy.
Lots of bad answers here. Obviously the kernel should schedule the UI to be responsive even under high load. That’s doable; just prioritise running those over batch jobs. That’s a perfectly valid demand to have on your system.
This is one of the cases where Linux shows its history as a large shared unix system and its focus as a server OS; if the desktop is just a program like any other, who’s to say it should have more priority than Rust?
I’ve also run into this problem. I never found a solution for this, but I think one of those fancy new schedulers might work, or at least is worth a shot. I’d appreciate hearing about it if it does work for you!
Hopefully in a while there are separate desktop-oriented schedulers for the desktop distros (and ideally also better OOM handlers), but that seems to be a few years away maybe.
In the short term you may have some success in adjusting the priority of Rust with nice, an incomprehensibly named tool to adjust the priority of your processes. High numbers = low priority (the task is “nicer” to the system). You run it like this: nice -n5 cargo build
.
Chimera Linux (not to be confused with ChimeraOS, a variant of SteamOS). It introduces itself like this:
It’s worth mentioning that it’s a Linux without GNU (though not for the sake of being that). In general I think projects like this one has a value from a ecosystem diversity perspective too, which also has become immediately apparent when Chimera Linux wasn’t hit by the two last security issues I learned about (the recent SSH regression and the xz debacle).
I’m particularly impressed with their relatively lean setup, but I haven’t had opportunity to use it yet. It’s a bit too immature for my desktop use and I’m already happy with the server I have so it makes no sense to switch.