matja

Encode every 0 as 10 - then decode every 10 back to 0. Or more efficiently, the first 0 as 10, then decode the the first 10 as 0.

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.

I feel like IPv6 is overengineered

In what metrics? IPv6 is more simple to implement than IPv4. In Linux 7.1.1 IPv4 is 84kLOC, IPv6 is 59kLOC.

I can think of a few reasons:

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).

Apt comic: https://www.workchronicles.com/p/comic-prevention-vs-cure

well that is fortunate

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".

[1] https://en.wikipedia.org/wiki/Anthropic_principle#Dimensions...

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.

I play games but I suppose I don't download a 100GB game frequently enough for it to matter to myself.

True, but that is transport (TLS). I was asking about the underlying data.

Please can you enlighten the ignorant that are also gamers? :)

Is that 80-100GB of unique data multiple times per day? Is it encrypted with a different key every time? Sounds very interesting.

One side-effect, is that the separate .mmproj file (Multi-Modal Projection encoder) is no longer needed, when using the model with llama.cpp etc.

+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.

I loved hearing this comment in my mind :)

I was also thinking along the same lines. Interesting, but I'm not sure in which aspect it is an achievement, considering the loop isn't a regex.

Meanwhile, 1K ZX Chess takes fewer bytes of memory than the first four paragraphs from the post.

Even with O_DIRECT and aligned blocks, I still don't understand how the storage engine can return a "successful commit" to the client without a sync at some point, because a sync (IIRC) is the only way to guarantee an ATA/NVMe FUA command is sent, and the device write cache/buffer is committed.

The eigenvalue distribution looks somewhat similar to Benford's Law - isn't that expected for a human-curated corpus?

SUB has higher latency than XOR on some Intel CPUs:

latency (L) and throughput (T) measurements from the InstLatx64 project (https://github.com/InstLatx64/InstLatx64) :

  | GenuineIntel | ArrowLake_08_LC | SUB r64, r64 | L: 0.26ns=  1.00c  | T:   0.03ns=   0.135c |
  | GenuineIntel | ArrowLake_08_LC | XOR r64, r64 | L: 0.03ns=  0.13c  | T:   0.03ns=   0.133c |
  | GenuineIntel | GoldmontPlus    | SUB r64, r64 | L: 0.67ns=  1.0 c  | T:   0.22ns=   0.33 c |
  | GenuineIntel | GoldmontPlus    | XOR r64, r64 | L: 0.22ns=  0.3 c  | T:   0.22ns=   0.33 c |
  | GenuineIntel | Denverton       | SUB r64, r64 | L: 0.50ns=  1.0 c  | T:   0.17ns=   0.33 c |
  | GenuineIntel | Denverton       | XOR r64, r64 | L: 0.17ns=  0.3 c  | T:   0.17ns=   0.33 c |

Alpha: r31, f31

This is a bit like saying stop using Ubuntu, use Debian instead.

Not really, because Ubuntu has always acknowledged Debian and explicitly documented the dependency:

Debian is the rock on which Ubuntu is built.

Ubuntu builds on the Debian architecture and infrastructure and collaborates widely with Debian developers, but there are important differences. Ubuntu has a distinctive user interface, a separate developer community (though many developers participate in both projects) and a different release process.

Source: https://ubuntu.com/community/docs/governance/debian

Ollama never has for llama.cpp. That's all that's being asked for, a credit.

If you think files are easier than a database, check out https://danluu.com/file-consistency/

What if the "slug" was a prefix for the API key revocation URL, so the API key was actually a valid URL that revoked itself if fetched/clicked? :)

I suppose there could be two checksums, or two hashes: the public spec that can be used by API key scanners on the client side to detect leaks, and an internal hash with a secret nonce that is used to validate that the API key is potentially valid before needing to look it up in the database.

That lets clients detect leaks, but malicious clients cant generate lots of valid-looking keys to spam your API endpoint and generate database load for just looking up API keys.