why would you call this a "pet peeve" it's obviously a matter of education not of people being assholes how tremendously pretentious.
-
why would you call this a "pet peeve" it's obviously a matter of education not of people being assholes how tremendously pretentious. i learned something but i'm terribly upset about it https://fosstodon.org/@djspiewak/113600799130927494
-
also "no point" is incredibly strong language. obviously the people who did this thought there was a point to doing it more slowly
-
note heavy use of jargon but no links or citations
-
pet peeve: when people didn't attend the same university as me
-
@[email protected] I like that the first response is "random jitter is an inherent property of the system" (which is almost certainly correct given the possibility of delays in network transmission; whether the magnitude of that stochastic element is large enough is another story)
and his response is "That jitter is a constant factor though" which... look. I'm not a network engineer. My understanding of physics tells me there is likely going to be a noise factor in transmissions times pulled from a Gaussian. If that's correct, then... that's not a 'constant factor'. "the jitter is a constant factor" ?? is meaningless?? -
@[email protected] Perhaps someone with a deeper understanding of network transmission physics and real world scenarios can chime in for me here.
Again, I would think that if anything, it would just be a matter of the stochastic element being insubstantial relative to what is necessary? -
@aud i think the duration of the request might be expected to be longer than the jitter induced by unreliable clocks and network transmission times
-
-
@[email protected] fair! I sort of assumed that was gonna be the case based on what he was saying, but effectively decrying a choice as pointless and then saying "that jitter is a constant factor" is... I mean, that's just not correct.
Unless he means it's a variable that is always present, but since he seems to be such a stickler for rules... -
@[email protected] lmao true. It's a power series based on 3 but that doesn't mean it's necessarily accurately reporting the times (it could say 3^n and just not be reporting the jitter) or the request duration could be within the 1 second range so it just gets rounded out or whatever.
-
@aud yeah i decided i'm not gonna interact but this guy was exactly as annoying on twitter where i have him blocked
-
-
@[email protected] lmao fosstodon gonna brosstodon
-
@aud they have a no shitposting policy
-
@[email protected] for sure. There's also theoretically jitter introduced by system load and other such factors but I would imagine that if this type of stuff is running on not-overloaded systems designed for network ops it's probably even less than transmission randomness.
but what, you don't trust the famously backdoored /dev/urandom?
What was the CPU entropy source that famously the NSA had backdoored?... -
@[email protected] really? Because 95% of their posts are shit.
-
@aud NSA backdoored the clipper chip and then DUAL_EC_DRBG thanks to RSA through project bullrun, i wasn't aware of cpu entropy?
-
-
@[email protected] It's not confirmed, but there were some theories. Apparently this was like, a decade ago though:
https://security.stackexchange.com/questions/42164/rdrand-from-dev-random
Basically, RDRAND from Intel was potentially compromised, or there was concern it might have been. I don't remember all the exact circumstances. I think urandom was the one you should use, or something. I can't remember. -
@[email protected] no no, I think you're right. /dev/urandom is awesome.
![Asta [AMP]](https://sharkey-data.sjc1.vultrobjects.com//f08b2285-6e62-4655-89e0-aecb33422b9c.png "Asta [AMP]"){kind=avatar}