Most regular players didn't encounter these bugs though, as often they're edge cases that don't occur during regular gameplay. A lot of them were found by people intentionally looking for them.
I'd argue that games today are bugger than games in the past, just due to how complex they are now. Sure, they're a different class of bug (and arbitrary code execution via buffer overflows isn't really a thing any more thanks to ASLR and the NX bit), but I don't think there's fewer bugs at all.
In some cases, the RAM actually is in use by the site. That's especially the case on sites with heavy client-side logic. In that case, it's not Chrome's (or Firefox's) fault, it's the website's fault. If you hover over the tab, it should show memory usage in the popover.
Chrome has a "Memory Saver" feature where it'll unload tabs that are offscreen/hidden which helps quite a bit. Not sure if Firefox has something similar.
Unused RAM is wasted RAM. Apps like Chrome use available RAM if it's available, but they should be releasing it for other apps to use when there's high memory pressure.
It's the same with disk caching. If you have a lot of free RAM, the OS will use all of it for caching files.
Games were impressive in this way too. Computers and consoles didn't have much CPU power or memory, so they had to squeeze every little bit.
This was still happening even with 5th gen consoles. Crash Bandicoot couldn't fit in the Playstation's memory so they ended up overwriting system memory and memory allocated to features of Sony's standard library they weren't using.
These days, game development is more "boring" in that aspect. Systems are powerful and frameworks like Unreal Engine handle all the core stuff. That's not necessarily a bad thing though - it lets the game developers focus on the game itself.
Crowdsec is much more efficient than fail2ban. Fail2ban is a lot of old single-threaded Python code with inefficient log parsing/tailing routines. Crowdsec is a more modern Go codebase.
If you're looking at old-school solutions, there's also DenyHosts.
you immediately tie the permanent accessibility of your local files to you retaining access to a cloud account?
The Microsoft account holds a backup of the recovery key, which you need to use to restore access in if you do something like significantly change the hardware or move the drive to a different system (which are effectively the same thing).
You don't need it for day-to-day use of the system, and you can also just get the recovery key and print it out or write it down somewhere, which is usually how it's handled on systems that don't use a Microsoft account.
Say, Veracrypt is churning away in the background. Why would one leave Bitlocker activated?
That's a good point.
You have different opinions on TPM and the prevalence of evil maids than me, fair
I work at a big tech company so have to be vigilant even with my personal systems :)
Some of the things mentioned in the OP don't actually happen in real life, though. Bitlocker is only automatically activated if you use a Microsoft account to log in, and why wouldn't you know the account credentials if it's what you use to log in?
doesn't rely on TPM and secureboot silliness
TPM is optional (but recommended) for Bitlocker. Practically every computer released in the past 10 years has TPM support.
Secure boot is needed to ensure that the boot is secure and thus it's okay to load the encryption key. Without it, a rootkit could be injected that steals the encryption key.
You generally want to use TPM and secure boot on Linux too, not just on Windows. You need secure boot to prevent an "evil maid attack"
You do have to have an unencrypted /boot, but the rest of the system can be encrypted. This uses a separate authorized_keys file embedded within the initramfs.
Whenever I rented an N64 game, the manual was in the box, and the store would check to ensure the manual was there when you return the game. That was in Australia though, so maybe it was different in your country?
I wonder why they didn't go with something more supported, like a Realtek chip. They're not the best (I'd prefer Intel or Aquantia), but they're cheap and widely supported. The Framework's Ethernet expansion card uses a RTL8156 which is supported practically everywhere.
Most regular players didn't encounter these bugs though, as often they're edge cases that don't occur during regular gameplay. A lot of them were found by people intentionally looking for them.
I'd argue that games today are bugger than games in the past, just due to how complex they are now. Sure, they're a different class of bug (and arbitrary code execution via buffer overflows isn't really a thing any more thanks to ASLR and the NX bit), but I don't think there's fewer bugs at all.