I'm perplexed to the claim that addition is cheaper than XOR, especially since addition is built upon XOR, am I missing anything? Is it javascript specific?
I work on the machine code level, so the only characteristic I'm interested in is how many ticks it takes to compute the result, not how many transistors it requires or anything like that. All modern CPUs take 1 tick to compute both XOR, addition, and many other simple arithmetic operations, so even though addition is technically more complicated in CPU designs, it never surfaces in software. In the context of this post, I preferred addition instead of XOR to reduce cancel-out and propagate entropy between bits.
The wording was a bit unclear. The previous paragraph mentions wanting something cheaper than "those pesky XORs and multiplications". The multiplication is the expensive part; the (very cheap) XORs are just mildly annoying because you have to think about what they're doing.
At least on x86, multiple additions and multiplications can be done with a single `lea` instruction so it's preferable to XOR. Though I have no idea about other architectures, compiler implementations, any interpreters...
That only helps with multiplications by statically known word sizes (4x, 8x, etc.) and not arbitrary x·y. It can help with many smaller constant multipliers if the complete is clever, but it has to be known at compile time.
padding with zeroes to a fixed length and prepending the original length would suffice, but you’d have to have a fixed length of double infinity to account for both the length information and the hash information, and the hash is less efficient than the original information.
What a great case of "you're holding it wrong!" I need to add individual configuration to every host I ever want to connect to before connecting to avoid exposing all public keys on my device? What if I mistype and contact a server not my own by accident?
I have over a dozen ssh keys (one for each service and duplicates for each yubikey) and other than the 1 time I setup .ssh/config it just works.
I have the setting to only send that specific host’s identity configured or else I DoS myself with this many keys trying to sign into a computer sitting next to me on my desk through ssh.
Like I can’t imagine complaining about adding 5 lines to a config file whenever you set up a new service to ssh onto. And you can effectively copy and paste 90% of those 5 short lines, just needing to edit the hostname and key file locations.
The server matches your purposed public key with one in the authorized keys file. If you don't want to expose your raw public key to the server, you'll need to generate and send the hashed key format into the authorized keys file, which at that point is the same as just generating a new purpose built key, no? Am I missing something?
If the rename changes the entire behavior (see busybox comment) it makes sense. But defining multiple arguments? Now the author had to use -- in the file name where using space would do (and the OS splits it for you)
And good luck trying to run the same programs with different arguments. You'll have to take turns renaming the file, or create hardlinks just for ephemeral arguments.
It can be useful but there's time and place to do it.
The beauty is that often used parameters don't live (and die) in .bash_history. They live on the file system. Sure, the same can be achieved by wrapping in a script, but that needs both a name and content and they better stay in sync on changes or else....
> And good luck trying to run the same programs with different arguments
I don't read the idea as trying to replace arguments as in remove, "don't ever use arguments anymore", but as a DSL for _allowing_ to pull supported arguments into the filename. Basically an args list preprocessor. That would only take away your freedom of including triple-dashes in your file name without there being consequences.
You could just fix whatever is wrong with your bash history and/or learn to use the history properly. Bash also supports programmable completion so you could also use that than come up with some weird hack.
I remember there's a PCI device that's meant to be snooping and manipulating RAM directly by using DMA. Pretty much one computer runs the game and one computer runs the cheat. I think kernel anti cheats are just raising the bar while pretty much being too intrusive
First of all, I don't want to run anyone's code without proper explanation, so help me understand this.
Let's start with the verifier. The 3rd party verifier receives a bundle, not knowing what the content is, not having access to the tool used to measure, and just run a single command based on the bundle which presumably contains expected results and actual measurements, both of which can easily be tampered. What good does that solve?
Right question. Bundle alone proves nothing — you're correct.
Two things make it non-trivial to fake:
The pipeline is public. You can read scripts/steward_audit.py
before running anything. It's not a black box.
For materials claims — the expected value isn't in the bundle.
Young's modulus for aluminium is ~70 GPa. Not my number.
Physics. The verifier checks against that, not against
something I provided.
ML and pipelines — provenance only, no physical grounding.
Said so in known_faults.yaml :: SCOPE_001.
Claude + Cursor wrote the structure. I fixed hundreds of
errors — wrong tests, broken pipelines, docs that didn't
match the code. That's literally why the verification
layer exists. AI gets it wrong constantly.
This comment — also Claude, on my direction. That's the
point. Tool, not author.
I'm perplexed to the claim that addition is cheaper than XOR, especially since addition is built upon XOR, am I missing anything? Is it javascript specific?
reply