dave_universetf

The readme has strong LLM smells. Was the code written by an LLM as well?

What is your experience with cryptographic engineering, in particular avoiding common implementation pitfalls that bite first-time implementers of cryptographic primitives?

Are the primitives tested against Wycheproof vectors, and proofed against the common implementation mistakes they document?

It's vibe coded, so not surprising that it replicates the patterns of existing systems.

+1, the information content is nice, but the AI telltales and writing patterns were annoyingly distracting.

This is probably just a difference in how your brain and the author's work. A variety of home organizers have told me that people mean different things when they say they want an organized space. Some people want everything precisely labeled and sorted into narrow categories, and hidden away in drawers or closets. Others want everything visible and coarser categories. Each system looks and feels very distressing to brains of the other types.

It's especially a problem for people with ADHD, because the "very sorted and hidden" mode of organizing is heavily socialized as the _only_ way to be organized, but it's also the exact opposite of how (some) ADHD brains want to operate. OTOH the very exposed and "emergent" organization that works for an ADHD brain probably is mild torture to an OCD brain :)

For myself, the sorting system in this post looks pretty ideal. All the stuff is right there where I can see it and scan for what I'm after, it explicitly allows for emergent organization where classification happens incrementally over time, and the dots thing has near zero activation energy but still gives me long-term information I can use. It's much better than an electronic or "clean" inventory system precisely because I'll never be able to consistently keep using those, whereas slapping a dot on a box, even on bad brain days I can manage that!

Strictly speaking: no. The "forward pass" terminology does not imply that there exists a "reverse pass" that does the same kind of computation. Rather, it's describing two different kinds of computation, and the direction they occur in.

The forward pass is propagating from inputs to outputs, computing the thing the model was trained for. The reverse/backwards pass is propagating from outputs back to inputs, but it's calculating the gradients of parameters for training (rougly: how much changing each parameter in isolation affects the output, and whether it makes the output closer to the desired training output). The result of the "reverse pass" isn't a set of inputs, but a set of annotations on the model's parameters that guide their adjustment.

The computations of the forward pass are not trivially reversible (e.g. they include additions, which destroys information about the operand values). As a sibling thread points out, you can still probabilistically explore what inputs _could_ produce a given output, and get some information back that way, but it's a lossy process.

And of course, you could train a "reverse" model, one that predicts the prefix of a sequence given a suffix (trivially: it's the same suffix prediction problem, but you train it on reversed sequences). But that would be a separate model trained from scratch on that task, and in that model the prefix prediction would be its forward pass.

Both, with caveats. The attention computation is fundamentally quadratic: for every token in the sequence, you're doing a computation that has to compute over every other token in the sequence. So it's O(N) per token, O(N^2) for the whole sequence.

The big mitigation for this is that in causal transformers (i.e. all the chatbot type applications, where each token is only allowed to see tokens before it), you're running inference repeatedly on the same prefix in order to grow it by one token at a time. So if you cache the computations for tokens 0..N-1, on each inference pass you only have to compute O(N) for the newly added token at the end of the sequence.

That's why caching (and caching charges) appear so prominently everywhere in the pricing of inference.

In practice, caching is most beneficial at inference time, because you typically have relatively long conversations that start with the same cacheable prefix (the system prompt). At training time the same optimization can apply, but you're typically not pushing the same prefixes through the model repeatedly so you end up paying the quadratic cost more often.

The quadratic cost of attention is the fundamental compute bottleneck for transformer architectures, which is why there's research like this trying to find shortcuts in computing attention, as well as research into completely new primitives to replace attention (e.g. SSM, which is O(N) on a cold cache and O(1) on a warm cache).

I don't know about all hyperscalers, but I have knowledge of one of them that has a large enough fleet of atomic frequency standards to warrant dedicated engineering. Several dozen frequency standards at least, possibly low hundreds. Definitely not one per machine, but also not just one per datacenter.

As you say, the goal is to keep the system clocks on the server fleet tightly aligned, to enable things like TrueTime. But also to have sufficient redundancy and long enough holdover in the absence of GNSS (usually due to hardware or firmware failure on the GNSS receivers) that the likelihood of violating the SLA on global time uncertainty is vanishingly small.

The "global" part is what pushes towards having higher end frequency standards, they want to be able to freewheel for O(days) while maintaining low global uncertainty. Drifting a little from external timescales in that scenario is fine, as long as all their machines drift together as an ensemble.

The deployment I know of was originally rubidium frequency standards disciplined by GNSS, but later that got upgraded to cesium standards to increase accuracy and holdover performance. Likely using an "industrial grade" cesium standard that's fairly readily available, very good but not in the same league as the stuff NIST operates.

Does the orange light specifically mean no RF link at all? Or does it include anything that prevents the modem from getting an IP address and route configuration? If the latter, BGP could still be at fault if it took out access to the control planes on the ground. But again all just guessing, from the outside all I see is the BGP routes are still being announced, and everyone seems to be seeing 100% packet loss and zero traffic.

BGP is the canonical way to take your entire global network offline within seconds. Glancing at BGP looking glasses, Starlink's prefixes seem to still be announced, but there could still be an accidental blackhole or routing loop within their AS, or something broken in one of their transit providers.

No idea if that's what's going on, but routing protocols are one of a few effectively global control planes that can go wrong very quickly like this.

They are/were scanning random public projects and creating unsolicited bugs in those projects to chide them about profanity in their source code. The linked thread is just a bunch of the victims of that spam having some fun with the format.

In the case of this attack, somewhere between 40s and 30min of physical access, depending on how the card was set up. In the case of a hotel, the spicy card to clone would be the cleaning staff's, which conveniently also admits a reasonable explanation for the card going temporarily missing (e.g. abandon it one corridor over, oops must have dropped it while doing the rounds).

Depending on the specifics of a deployment, I'm guessing you could also use the card secrets to mint new cards that authenticate correctly to facility readers, but contain different information? But I don't know nearly enough about how these cards get used to know how much flexibility you get there.

Indeed. Alas (or fortunately depending which colour team you work on), fully broken Mifare Classic is still all over the place, and likewise the "hardened" variant broken in this paper :(

Possibly so. It just means that based on the report's findings, even if you'd decided to play it safe and buy exclusively from NXP directly (the creators of this ecosystem and owners of the MIFARE trademark), it looks like you could still end up with backdoored hardware.

The paper reports that the same backdoor seems to be present in some NXP and Infineon SKUs as well, including some manufactured in Europe.