HN user
Interesting, I haven't tested this myself but intuitively I think that a 4 byte OOB write is plenty for a data-only attack like [PageJack](https://i.blackhat.com/BH-US-24/Presentations/US24-Qian-Page...), so I don't think hardening against the KASLR leaks discussed in OP would necessarily save you from this attack.
Worth noting that this is a bound on arbitrary search, but there exist some problems with structure (e.g. integer factorization) for which quantum algorithms are exponentially faster than known classical algorithms (a problem believed to be in NP and BQP but not P).
Repost of https://news.ycombinator.com/item?id=47088212 due to the page changing its title
nethack.alt.org is conspicuously absent...
Also worth noting that the verifier is under active development not only to verify more legitimate programs, but also to reject programs with exploits and side channels (and there are runtime defenses too, like dead code elimination and ALU sanitation).
I worked a tiny bit on this experiment so I'm a bit biased, but it really is quite an impressive demonstration. I don't know if the methodology has changed since I was on the project, but in the past there was a whole process of sneakernet-ing the data from the game across an air gap and onto the ISS.
The discussion of Richard Caley was warming, reminded me of Izchak Miller a little bit.
For a blend between Lisp and a more traditional POSIX shell, I enjoy Emacs' [eshell](https://www.masteringemacs.org/article/complete-guide-master...).
That's an excellent question, I thought the exact same thing when I wrote this article. From what I can tell [child](https://github.com/NetHack/NetHack/blob/ed600d9f0f3c37677418...) properly spawns a child process with the real uid/gid instead of the effective uid/gid. And to your point, there are actually a decent number of [CVEs](https://www.nethack.org/security/) due to NetHack being set[ug]id.