And égalité...
gbin
"one man's trash is another man's treasure" almost to the letter.
I have seen another contributing factor in CS: it is really hard for the management to keep a good senior to junior ratio ie. A lot of juniors are trying to enter the workforce today. It means that during covid and shortly after the companies definitely relaxed as much as they could the geographical constraints for senior remote roles, also being senior they trusted them to work remotely not needing too much direct supervision. And now it backfires when your company is in silicon valley and you ask your senior developer from the boonies Colorado to move to an industrial concrete jungle.
So so so so many ads in that page that I genuinely lost the article in the middle, that's a first.
UTF-8 is a variable encoding so none of the fixed sized type would work better for it.
The crashes are in the middle of browsers (both Firefox and chrome embedded in Spotify), if you try a simple mprime stress test (from the AUR mprime-bin) does it crash too?
One crash was in libxul and the other in libcef I doubt this is a specific lib
I use paru and the default is "paru" with no parameter for the upgrade. But I am on your team here: I have to Google every single time the -Q params for all the queries and I have been using arch for almost 2 decades now: "who owns this file?" "what are the deps of this package?" "Which packages are installed?" "Which packages I explicitly installed vs dependencies?" Not a single one of them is intuitive to query with the pacman command line for some reason.
This local shadow for the AUR is awesome, it reminds me of the overlays for Gentoo they are super useful.
For me: Gentoo is a meta distro, you are the distro maintainer then the power user of that specific distro you created for yourself which can definitely be fun. Arch is more like: let's give you one instance of a Gentoo distro when you are tired of being the distro maintainer.
Your overall process is perfect: first try to solve it from the UI, then the console, then the magic sysreq key.
The fact that your kernel was not responding to the sysreq key could mean a couple things: is it enabled on your install? (cat /proc/sys/kernel/sysrq to check)
Before trying to understand why the kernel locked up, are you sure everything is solid on the hardware side? ie. Did you overclock anything? If yes did you burn test the PC on some GPU demo?