I worked on that Node.js issue. If you can share a repro, I'd love to take a look: https://github.com/nodejs/node/issues/new?assignees=&labels=...
HN user
kvakil
https://kvakil.me/
wow, this is impressive.
I wrote a similar x86-16 assembler in < 512 B of x86-16 assembly, and this seems much more difficult <https://github.com/kvakil/0asm/>. I did find a lot of similar tricks were helpful: using gadgets and hashes. Once trick I don't see in sectorc which shaved quite a bit off of 0asm was self-modifying code, which 0asm uses to "change" to the second-pass of the assembler. (I wrote some other techniques here: <https://kvakil.me/posts/asmkoan.html>.)
bootOS (<https://github.com/nanochess/bootOS>) and other tools by the author are also amazing works of assembly golf.
In addition, even if a normal number was used, it's far simpler to describe the data by just using a single number alone. For example, a binary encoding of the data (perhaps using a prefix-free code). Using a normal number and two "positions" is just more complicated.
Anecdote: for me the actor model has been the most understandable and useful concurrency primitive I've used. Pi-calculus, which was inspired by the actor model, is similarly elegant.
This assumes that pi is a normal number [0], a fact that is widely believed but has not been proven.
jsfuck is hardly obfuscation: remove the first 828 bytes (for "eval(") and the last 3 bytes (for ")()"), and then execute the remaining string, and that gives you the original source code.
Maksymilian Piskorowski found that if you happen to have a spare eight 9s, you can compute 𝑒 = (9/9 + 9^(-9^9))^(9^(9^9)), which is accurate to a little over 369 million decimal places.
Sure, because 9/9 = 1 and if you take x = 9^9^9, you get back (1 + x^(-1))^x, i.e. the first formula. It's cute, but I don't know if you could call it a "discovery".
Seems likely that the hard reset works on a lower level as it works even if the phone is hung.
Maybe take a look at gg [0]? It seems to solve the problem of slow compilation quite nicely.
From the article: "As an extra bonus, the generated proofs tend to be shorter than the ground truth proofs collected in CoqGym."
This feels a little misleading, the paper itself says that the phenomena "... suggests that theorems with longer proofs are much more challenging for the model." It'd be more interesting to see how the automated theorem proving length compares to the manual length for the same proofs (although I'd expect this to be biased downwards, for the same reason).
how does this compare to oss-fuzz [0]? is the main value proposition that its easier to set up?
Modern secure messaging systems are typically OTR and have deniability: after the session ends, anybody can forge messages to make it look like they came from you. Sure the messages can become public, but they're no more "proof" than someone saying "X said Y".
In French, there is a space before exclamation and question marks. Based on the author's name, I'd also guess that they are French.
I think that an age-based criterion would reflect that younger people (on average) have greater tech literacy. But I don't think Congresspeople reflect the general population, so I agree that using age is probably not the best idea.
It depends on how you define the modulo operator [0]--there are definitions where (-1)%5 == 4 and definitions where (-1)%5 == -1. Presumably the GP is referring to the former case.
[0] https://en.wikipedia.org/wiki/Modulo_operation#Remainder_cal...
I believe they're almost certainly referring to Clojure macros
and just like that, you've convinced me to install it. Different strokes for different folks, I suppose. :)
You might find this interesting: https://unhosted.org/
Of course the answer is N1 - 3 N2 + 3 N3, since that naturally completes the cubic interpolating polynomial.
Reminds me quite a bit of this, which also includes FOL: http://proofs.openlogicproject.org/
This looks like a nice variety of challenges! I've always found constructing ROP chains extremely satisfying, even more than regular exploit development.
As a plug, I wrote a blog post solving a similar exercise using a ROP chain: http://www.kvakil.me/posts/ropchain/ . It looks pretty similar to the pivot challenge here.
No, the reason you aren't supposed to use it to generate cryptographic keys is because it's public: so it effectively provides no (or nearly no) entropy. It's the same reason you shouldn't use the current time as a seed for a PRNG.
NIST Beacon is more intended for things like lottery drawings, where you want to prove that you're generating the random numbers in an unbiased manner.