I can't judge the veracity of the history of hash functions, but the moment it starts talking about cryptography it goes completely off the rails: it seems to indicate that finite field exponentiation o'r high degree polynomials are used in cryptographic hash functions; they are emphatically not. It presents password hashing as just applying a suggest function to the password; in practice a KDF is used, which is a completely different design space (for a start, KDFs have a tweak parameter, usually called a salt in this context). Finally, there's a haven't reference to quantum computers breaking hash functions and needing post-quantum algorithms as a result. This does brush with reality in that Grover's algorithm does theoretically eat half the first preimage resistance security level of your hash function, but even SHA256 will require 2^128 iterations on a quantum computer, which will likely never be feasible. Worse, it doesn't help at all in attacks against second perimeter resistance or collision resistance.
Considering that everything I have personal knowledge of here is obviously bunk, best ignore the rest of it too
Author here.
In the article I explicitly mention that the second part (about high degree polynomial and descrete exponentation) is based on Diffie-Hellman's 1976 paper and presents their one-way function constructions, not MD5 or SHA family (my goal is to cover the history of hashing from the beginning, so I haven't done a research on modern systems yet).
As for the quantum computing stuff, I should have stated more clearly that I'm referring only to quantum computer allowing to calculate descrete logarithms rather fast, and provided a source such as https://math.mit.edu/~shor/elecpubs.html containing a link to the paper Algorithms for quantum computation: Discrete logarithms and factoring by Peter Shor. (I'm planning on covering post-quantum cryptography after I'm done with modern algorithms)
It's been a long time since I've touched any of this, so the details have slipped my mind. However, the general idea was that there were two different exit calls in DOS: terminate and terminate and stay resident. The difference between the two is that the stay resident option wouldn't release the memory used by your application. Further, the interrupt table, which told the processor how to handle each interrupt, was in RAM and therefore writable.
So, what TSRs would do is overwrite one or more interrupts to point to a routine that would check if the system call in question was one it wanted to handle (eg, to add a hotkey it would grab the keyboard handler and check for a special set of keys before passing control back to the normal handler). Once that was fine, it would call the TSR system call and control would be passed back to the OS with the hook still in place
Grammatically, this would not change X. "...GIVING X" would just return X. Since it's part of the same statement, it seems it should ignore the "ADD 5 TO X" part.
Now, if you'd like to place the result into X, I suggest "ADD 5 TO X" would suffice as the entire statement.
> So I think the following is IMO by far the biggest problem, no matter one's personal opinion:
>
> "Rakoff entered a permanent worldwide injunction covering ten Anna’s Archive domains: annas-archive.org, .li, .se, .in, .pm, .gl, .ch, .pk, .gd, and .vg."
Legally speaking, the Southern District of New York can say whatever it likes, and Libera, Sweden, India, St-Pierre-et-Miquelon, Greenland, Switzerland, Pakistan, Grenada, and the British Virgin Islands are free to ignore what the US says. They all have national sovereignty over their respective ccTLDs, and of them, most are not going to simply accept the US telling them what to do considering recent geopolitical missteps.
NixOS using https://github.com/thequux/nix-zone-firewall/ worked well for me for many years. I only stopped using it because my poor embedded Linux machine started having issues and it made more sense to go with a Mikrotik than to buy a new device to run as a soft router.
Hi! I'm one of the founders of dotMeow, and it's been a long road to get to the point that we're willing to stake our reputations on a crowdfunding campaign. From applying to the applicant support program (we believe we were one of the first, if not the first organization accepted) to working out financial plans and overall strategy to achieve NIS2 compliance on a shoestring budget, it's been a year and a half of effort to reach where we are now.
It's quite late here in Belgium, so I'm about to go to sleep, but in the morning, I'll happily answer any questions people have about the project.
The sad thing is, this is one of the rhetorical flourishes that gets drilled into you in debate and comms education. ChatGPT picked it up because it's extremely common.
A few people have called us on this, but it's simply not true. The copy was all written by hand; the only machine assistance here is XCompose (you, too, can type an em-dash!).
It turns out that when everybody involved is some level of techie and you're targeting a sort of "corporate bland" tone so that you look professional and trustworthy by modeling your communications on other successful kickstarters, it comes out looking similar to what other marketing copy looks like, which is precisely what all of the LLMs were trained on.
Considering that everything I have personal knowledge of here is obviously bunk, best ignore the rest of it too
reply