I’ve switched to using an old device I had; it’s quite weak—at least by my standards. Its specifications are: 2 cores, 4 threads, and 16 GB of RAM.
It’s my primary device at the moment; it’s functional, but it’s slow most of the time. While it is usable, let’s be realistic—I need more speed.
Therefore, I am looking for solutions to reduce the burden on the processor. I am not particularly concerned about the RAM, as I believe it is sufficient; however, there is no harm in lightening the load on it as well.
Other questions on the same topic:
What is the best way to create a music cube with the lowest possible processing overhead?
I don’t think I need most of the tools inside the vault cube. Would using a Minimal templates reduce its resource consumption (and would it compromise security)?
If you think you have enough RAM for your particular needs, you could reduce swapping and logging, and disable unnecessary services. You could even try using a more lightweight file system (e.g. ext3 instead of ext4).
What is the best way to create a music cube with the lowest possible processing overhead?
You should probably explain what that means, e.g. what particular software will run in the cube, what are its requirements… and what is a “music cube” - it can be as simple as an mpv player or a whole audio editing suite.
I don’t think I need most of the tools inside the vault cube. Would using a Minimal templates reduce its resource consumption (and would it compromise security)?
Minimal templates can reduce resource usage and improve security (depending on threat model) but if you feel you are not experienced enough, stay away from them for a while.
BTW, I don’t think you can use 4 threads on 2 cores. Qubes disables SMT by default for security reasons, so it is likely 2 threads only (1 per core).
Best is ffmpeg (cli only) or MPV with various frontends. With ffmpeg/mpv you need the app + ffmpeg codec library, everything in base fedora repo.
With VLC you need more cpu because it’s not that lightweight and for many formats you need many codec libraries including ones from unofficial repos (which can sometimes clash with packages from base one - not synced update, courtesy of multiple separate maintainers).