To expand on this, there are two settings you can put in user.js / prefs.js (desktop) or via about:config (mobile), documented on the Mozilla Wiki:

user_pref("media.autoplay.default", 5);
user_pref("media.autoplay.blocking_policy", 2);

Two bonus settings if you want to get rid of the “do you want to enable DRM?” pop-in bar when hitting one of those sites:

user_pref("media.gmp-widevinecdm.enabled", false);
user_pref("media.gmp-widevinecdm.visible", false);

hth

I would agree, and would bring awareness of ionice into the conversation for the readers - it can help control I/O priority to your block devices in the case of write-heavy workloads, possibly compiler artifacts etc.

The Linux kernel uses the CPU default scheduler, CFS, a mode that tries to be fair to all processes at the same time - both foreground and background - for high throughput. Abstractly think “they never know what you intend to do” so it’s sort of middle of the road as a default - every CPU cycle of every process gets a fair tick of work unless they’ve been intentionally nice’d or whatnot. People who need realtime work (classic use is for audio engineers who need near-zero latency in their hardware inputs like a MIDI sequencer, but also embedded hardware uses realtime a lot) reconfigure their system(s) to that to that need; for desktop-priority users there are ways to alter the CFS scheduler to help maintain desktop responsiveness.

Have a look to Github projects such as this one to learn how and what to tweak - not that you need to necessarily use this but it’s a good point to start understanding how the mojo works and what you can do even on your own with a few sysctl tweaks to get a better desktop experience while your rust code is compiling in the background. https://github.com/igo95862/cfs-zen-tweaks (in this project you’re looking at the set-cfs-zen-tweaks.sh file and what it’s tweaking in /proc so you can get hints on where you research goals should lead - most of these can be set with a sysctl)

There’s a lot to learn about this so I hope this gets you started down the right path on searches for more information to get the exact solution/recipe which works for you.

Refer to the cryptsetup-luksChangeKey man page --key-file options, you cannot change the password directly on a commandline; you either (a) type it interactively, (b) put it in a keyfile, or © accept input from STDIN with the standard use of - on the end (e.g. echo "mypass" | cryptsetup luksChangeKey /dev/sda - )