And then those people get banned for a year when the same ai tools that created a hallucination also think that hallucination is real. I don't see a problem here.
I don't know why someone with a cousin named Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso is that much of a better hire than someone named Jón Bergþóruson, 王小明, Sukarno (with no surname), גִּדְעוֹן בֶּן־גּוּרְיוֹן , or Karl-Theodor Maria Nikolaus Johann Jacob Philipp Wilhelm Franz Joseph Sylvester Freiherr von und zu Guttenberg. None of whom would classically qualify as diversity hires.
Hiring someone in the off chance that their ethnicity gives them some unique critical unknown unknown that will pop up half a decade down the line resides in the same mental space as a programmer writing `if (5 == i)` in case a future programmer accidentally deletes an =. It's just speculative defensiveness whose efficacy is simply not well established by actual research. And, in my view, just works to confound actual signals that, evidently, gitlab and other employers feel get unfairly overshadowed when emphasizing explicitly pro-diversity hiring policies.
There could also be some degree of "(5) bandwagon effect" players, who pump money into an outcome specifically to get people talking about its possibility, thereby increasing its probability of coming into fruition.
> but at some point a state based cyber attack that just wipes wikipedia off the net is deeply damaging to our modern society’s ability to agree on common facts
Haven't we hit that point already with bad faith (and potentially government-run) coordinated editing and voting campaigns, as both Wales and Sanger have been pointing out for a while now?
I'm not sure what you mean by this. Wikipedia is not a democracy.
> as both Wales and Sanger have been pointing out
{{fv}}. Neither of those essays make this point. The closest either gets is Sanger's first thesis, which misunderstands the "support / oppose" mechanism. Ironically, his ninth thesis says to introduce voting, which would create the "voting campaign" vulnerability!
These are both really bad takes, which I struggle to believe are made in good faith, and I'm glad Wikipedians are mostly ignoring them. (I have not read the third link you provided, because Substack.)
That's a relatively recent process: there have only been 3 such elections ever. They have measures in place to try to curb abuse of the process, and it cannot really be used to introduce bias (since an administrator exhibiting bias would leave a public trail of evidence attesting to that bias). That said, thanks for letting me know about it.
I feel like the section on primality testing with Fermat's test should at least make a shout out to Carmichael numbers and that for some inputs the probability you get a false positive result is 1.
This is so tangentially related to the P vs NP problem that the title is basically pure clickbait. Remove every sentence relating to polynomial anything and the information content of the write-up doesn't change at all.
What's a concrete threat model here? If you're sending data to an ssh server, you already need to trust that it's handling your input responsibly. What's the scenario where it's fine that the client doesn't know if the server is using pastebin for backing up session dumps, but it's problematic that the server tells the client that it's not accepting a certain timing obfuscation technique?
The behavior exists to prevent a 3rd party from inferring keystrokes from active terminal sessions, which is surprisingly easy, particularly with knowledge about the user's typing speed, keyboard type, etc. The old CIA TEMPEST stuff used to make good guesses at keystrokes from the timing of AC power circuit draws for typewriters and real terminals. Someone with a laser and a nearby window can measure the vibrations in the glass from the sound of a keyboard. The problem is real and has been an OPSEC sort of consideration for a long time.
The client and server themselves obviously know the contents of the communications anyway, but the client option (and default behavior) expects this protection against someone that can capture network traffic in between. If there was some server side option they'd probably also want to include some sort of warning message that the option was requested but not honored, etc.
To clarify the point in the other reply -- imagine it sent one packet per keystroke. Now anyone sitting on the network gets a rough measurement of the delay between your keystrokes. If you are entering a password for something (perhaps not the initial auth) it can guess how many characters it is and turns out there are some systemic patterns in how that relates to the keys pressed -- eg letters typed with the same finger have longer delays between them. Given the redundancy in most text and especially structured input that's a serious security threat.
Capping margins at a percentage also directly breeds inefficiencies. If you could spend $10M to fix a problem that costs you $4M/yr, you're effectively paying $10M now to lose $400k in annual profit potential.
