correct, this is the same issue, this generally really only happens with a sustained all core workload that will consistently leave you cpu at 100%, since if it's not sustained, the kernel will allot some time to the programs, and the crash wont happen
while this is good on theory, when your CPU is being absolutely hammered, you need to re-adjust priorities to make a system responsive again, it's actually not a simple thing to do without a context aware scheduler. Even though EEVDF is pretty good, it still struggles some times
this is a wayland issue. Due to how wayland works, it cannot drop messages, this means if the messages stop being accepted (IE. the program becomes very slow and not very responsive) the application will wind up dying. EEVDF helped resolve a lot of these issues. but they arent gone yet.
a fairly easy replication cause is to start a large rust project compile since cargo will thread to oblivion if it gets the chance, then use the PC on wayland. Applications can frequently die, Firefox, MPV, Kate, gnome web, chromium, games, etc. it also doesn't matter what compositor you use right now as gnome, kde sway all share the issue
EEVDF really does help stop a lot of these crashing though
virtio-sound likely will eventually and ufs probably will too. the gpu driver is being worked on by a third party, but it's still using virgl so I doubt it will be very preformant
It's not as dramatic for me but it's still bad. I myself freed at least 20 Gb from my computer when I remove flat pack and all of its crap. and migrated my apps to aur myself.
EEVDF has been an insane improvement for the desktop, I can compile programs while listening to music and watching videos without any issues since the update, the responsiveness when my computer is maxed out is amazing, and the perf hasn't lessened any noticeable amount
quicksync really doesn't have good quality:compression buying a used nvidia gpu and using that would be far better. but really, any moderatly up to date cpu should get good x265 or svtav1 perf
Better quality:Compression ratio you can easily get better quality out of a gpu then a cpu depending on your settings, but it will rarely be better quality AND compression unless you have a quite slow CPU and cant run a sensible preset
Yes this is indeed what I said. but well calling gpu encoders "worse" isnt really fair, it's all trade offs, they for sure have worse efficiency as we both said, but their speed is significantly faster usually. I would say that doesn't make the encoder "worse" just different.
none, you aren't using gpu, just whatever cpu is the fastest. if you want gpu acceleration you have to specify it. and keep note gpu acceleration is less efficient then cpu so your files will be bigger. though at preset fast it might actually be pretty close
I wish I was that lucky, the final straw for me was the grub-customizer shenanigans, manjaro pushed an update that broke grub customizer boot entries, then when users were trying to figure it out, they removed grub customizer, and then they even went so far as to make grub conflict with grub-customizer which was really asinine. IIRC they even wound up locking the forum thread on it
this is possible in theory, libcamera can expose all of the bits that are needed, have fun actually finding hardware to support this though