It's somewhat amusing how Itanium managed to completely miss the mark, and just how short its heyday was.
It's also somewhat amusing that I'm still today helping host a pair of HPE Itanium blades - and two two-node DEC Alpha servers - for OpenVMS development.
Do you have WebP support disabled in your browser?
(Wasn't aware my pict-rs was set to transcode to it, going to have to fix that)
If you build a linked list in C, and put the pointer to the next entry as the first element in your struct, then you only need a single variable (and two comparisons) to do sorted insertion into the list.
Why is it .jpg and not .jxl? That's the registered extension for JPEG-XL.
Flatpak uses OSTree - a git-like system for storing and transferring binary data (commonly referred to as 'blobs'), and that system works by addressing such blobs by hashes of their content, using Linux hardlinks (multiple inodes all referring to the same disk blocks) to refer to the same data everywhere it's used.
So basically, whenever Flatpak tells OSTree to download something, it will only ever store only copy of that same object (.so-file, binary, font, etc), regardless of how many times it's used by applications across the install.
Note that this only happens internally in the OSTree repo - i.e. /var/lib/flatpak or ~/.local/share/flatpak, so if you have multiple separate Flatpak installations on your system then they can't automagically de-duplicate data between each other.
It could be that running the game at full speed causes some lock contention that doesn't happen when slowed down by the log stream.
Or it could also be that under normal gameplay your system spins down the harddrive to save power due to a lack of accesses, which would cause slowdowns and choppiness when the game suddenly needs to load something - also something which would be helped by running the log in the background.
For testing the second point, I'd suggest running something like this in the background while playing; (i.e. generating some constant load)
while true; do
uptime > $HOME/workaround-test
sleep 1
done
My favourite advent calendar.
Got a private leaderboard with the other sysadmins from work - as well as a few people from our application/development team.
It makes sense to use the words that people are most used to, and bluescreen/BSOD has been the go-to lingua for describing a crash/error screen - even if not blue - since a while now.
The game will use whatever FoV value is listed in the configuration file, so you can go into your %localappdata% folder and edit the user settings file there.
Here's the Nitter link; https://nitter.net/neoncaelestis/status/1700580768458936469
I see some of these have already been mentioned, but they do deserve repeating;
I work as a Linux sysadmin for a university, we're paying for a full RedHat site license with all the goodies, and we certainly feel royally screwed over by this.
Not every single piece of software we run is a RedHat developed/sanctioned thing, and the removal of a guaranteed bug-compatible development platform for the people building those pieces of software - without jumping through hoops or limiting development efficiency - mean that we can no longer guarantee that core pieces of our infrastructure software will remain available for our RHEL installs. Not to mention course IT, where things are even worse in that regard. Lots of such software is already developed/tested/packaged on Alma/Rocky, and if they start diverging from being RHEL bug-compatible - which is very likely with this change - then we're going to either have to switch away from RHEL - and the paid support, or lose support from the pieces of software.
We're probably going to have to move a bunch more of our ~1.4k systems off of RHEL and onto things like SUSE, Debian, etc in the near future, just so that we're ready for when shit really hit the fan.
Ah, I had one of those wireless sticks from Netgear as well, probably a different model but still a royal pain to get it working.
Luckily ndiswrapper has become a thing of the past nowadays.