OAuth is designed so that an end-user never needs to see an API key (OAuth refresh/access token) or even know what one is. When it is implemented to the spec, that happens well.
I think that most of the "just give me an API key" comments are from a <1% of end-users (developers) that know what an API key is, and are facing a broken OAuth implementation.
Amazon Route 53 is $0.40 per million DNS queries - which would terrify me if I used it, considering a typical 10Gbit server connection hosted at a unscrupulous ASN with no egress IP filtering is capable of sending a million DNS requests per second from random spoofed IP addresses.
There wasn't any such features for x86 when the patch was created, other than AES-NI.
Many hardware platforms that have TPM, have it connected via a low-bandwidth LPC bus which would have nowhere near enough bandwidth for demand decryption/encryption of memory pages.
Hardware vendors can apparently turn these security features off as they wish, even if the hardware supports and was shipped with it :)
There was a patch called Tresor that did this, but I don't think it was updated for a long time.
You have to store the encryption key in CPU registers and ensure it's not saved to RAM during task switching or power suspend operations. Tresor used x86-specific debug registers for it, but you could potentially use unused SIMD registers if you masked-off the CPUID bits for them and disabled them for access by user-space.
But securing against attacks from a hostile hypervisor or a server provider needs more than just memory encryption, because they can intercept any part of the boot process and control the hardware/firmware that can lie to your kernel.
To counter that you'd need something like AMD SEV(ES/SNP) with measured boot and remote attestation to switch the only thing you trust to the CPU manufacturer (best you can do IMO).
I think that was one of the arguments of the Anthropic principle [1], that there doesn't appear to be any reason why there are 3 spatial dimensions and 1 time dimension, or why the fundamental constants are what they are - but if they weren't then there wouldn't be anyone to exist to say "well that is fortunate".
You're right that the ECC validation is very robust, but that only validates one small part - that the drive is reading what it has previously written, not that the data was correct when it came in to the drive, correctly handled by the firmware, or even written in the correct place (LBA) on the drive.
There's been times when some features of entire models of drives have been disabled in the Linux kernel because of buggy firmware that silently writes bad data (with correct ECC), so reading it back is successful from both the drive's and the OS's block driver views.
I was hit by this myself with the queued TRIM command firmware bug that affected all Samsung EVO 840 SSDs (Linux kernel commit 9a9324d3969678d44b330e1230ad2c8ae67acf81 if you want to look into the history) - the drive didn't report any errors, but ZFS kept reporting corruption, and kept on fixing it in the background.
Because I would have expected for game development that it would be rare for majority of the large assets (art, textures, 3d meshes, video, sound, music) to change multiple times per day, so - to me - sounds like would perfectly suit a differential/incremental sync protocol, rather than treating everything as a large packed blob. At least that was the case for the game development I did.
+1 this. Example: Using Mistral TTS voice cloning appears to be not possible via the "providers" pass-through object in the OpenRouter API because some parameters are always forwarded which conflict with the provider's parameters.
The latest Raspberry Pi 5 has one 32-bit channel (2x 16-bit subchannels) of LPDDR4X-4267 SDRAM giving 17.1GB/s of bandwidth, 52x less than this GPU. Never mind lacking the CUDA and Tensor cores, so the FP16 performance is 102x less (307 GFLOPS vs 31.4 TFLOPS). So for £200, there's absolutely no comparison for this specific use-case.
The AMD MI250X GPUs are also interesting - 128GB of HBM2E at 3TB/s, sometimes you see them second-hand for under $1k, the catch obviously is that it needs an OAM socket. Never seen an easy way to hook them up to a regular mainboard.
> canonicality matters — for signatures, content-addressing, or any kind of “two implementations must agree on the bytes” property
If you don't do this properly, you end up with things like:
- SAML XSW attack due to XML signature wrapping
- ASN.1 BER/DER signature forgery
- Bitcoin transaction malleability attacks
The problem is AVX-512 was disabled in later Intel Alder Lake CPUs, and later generation Intel desktop CPUs, so very few Intel desktop CPUs have AVX-512 now. Ironic that AMD has better support/performance for an ISA extension that Intel invented.