And an extra article giving more background and lead up https://www.politico.eu/article/ukraine-general-runs-out-of-road-kyiv-washington/

tl;dr question: How do I get the Handbrake Flatpak to operate at a high niceless level in its own cgroup by default? I'm using Fedora Linux.

So if I understand things correctly, niceness in Linux affects how willing the process scheduler is to preempt a process. However, with cgroups, niceness only affects this scheduling relative to other processes within a cgroup. This means a process running with a high niceness in its own cgroup has the same priority as other processes in equivalent cgroups, and it will not in fact be preempted in a way one would expect.

So why does this matter to me at all? I have a copy of Handbrake installed from Flatpak. And sometimes I want to encode a video in the background while still having a decently responsive desktop experience so I can do other things, and basically let Handbrake occupy the cpu cycles I'm not using. Handbrake and the video encoding process should be at the bottom priority of everything to the maximum extent possible.

But it does not appear to be enough to just go into htop and set the handbrake process's niceness level to 19 and then start an encode, because of the cgroup business I mentioned above.

Furthermore, in my opinion Handbrake should always be the lowest priority process without my having to intervene. I would like to be able to launch it without having to set its niceness. Does anybody have suggestions on this? Is my understanding of the overall picture even correct?

PipeWire 0.3.77 (2023-08-04)

This is a quick bugfix release that is API and ABI compatible with previous 0.3.x releases.

Highlights

• Fix a bug in ALSA source where the available number of samples was miscaluclated and resulted in xruns in some cases.
• A new L permission was added to make it possible to force a link between nodes even when the nodes can't see each other.
• The VBAN module now supports midi send and receive as well.
• Many cleanups and small fixes.

After approximately 10 months in a release candidacy phase, OpenMW 0.48 has finally been released. A list of changes can be found in the link.

The OpenMW team is proud to announce the release of version 0.48.0 of our open-source engine!

So what does another fruitful year of diligent work bring us this time? The two biggest improvements in this new version of OpenMW are the long-awaited post-processing shader framework and an early version of a brand-new Lua scripting API! Both of these features greatly expand what the engine can deliver in terms of visual fidelity and game logic. As usual, we've also solved numerous problems major and minor, particularly pertaining to the newly overhauled magic system and character animations.

A full list of changes can be found in the link to Gitlab.

What is OpenMW?

"OpenMW is a free, open source, and modern engine which re-implements and extends the 2002 Gamebryo engine for the open-world role-playing game The Elder Scrolls III: Morrowind."

It is an excellent way to play Morrowind on modern systems, and on alternative systems other than MS Windows. It requires the a copy of the original game data from Morrowind, as OpenMW does not include assets or any other game data - it is simply a recreation of the game engine. OpenMW can be found on Flathub for Linux users here. https://flathub.org/apps/org.openmw.OpenMW