Having P = 0.05 has led to "P-Hacking". One example was the "chocolate" trial that had a small group eating different diets and tracked a whole slew of things, looking for a correlation in any of them. It happened to be that in the small group eating 1.5oz of chocolate and otherwise dieting lost slightly more weight than the group just dieting. Due to not having a specific goal in mind, and small sample size, they were bound to determine some sort of "positive correlation" somewhere, and there you go. If it hadn't been weight loss, it would have been heart rate or something else.
"some of these attacks" = the various speculative execution attacks, not the exact attacks in the article, numbnuts. My point was that this is a much further reaching issue than just some handful that have been found in Intel chips. This problem of leaking data via various speed enhancements type of attacks will probably be more widespread than we currently realize, and saying "don't buy intel, buy AMD because it's safe" is a naive and dangerous mindset to be in for this. We should be taking steps to mitigate this entire class of attack.
I read this part, in the linked original Spectre disclosure, did you?
Google Project Zero (GPZ) Variant 1 (Bounds Check Bypass or Spectre) is applicable to AMD processors. GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors. GPZ Variant 3 (Rogue Data Cache Load or Meltdown) is not applicable to AMD processors.
So, at least two variants of Spectre/Meltdown had to be mitigated on AMD platforms. My point still stands, it's not just an Intel thing, and switching to another processor isn't going to protect you from all variations of future attacks, just against a handful of intel specific ones that we know about right now. These are flaws inherent to our current processor designs and will probably take a few generations of processors to make secure.
Reminder: AMD has been vulnerable to some of these attacks, and it's entirely possible that a variant of this attack would work against AMD. It's inherent flaws in our processor designs and security models for "jailed" applications.
There's probably AMD/ARM-specific attacks that haven't been discovered or disclosed.
Funny that, I dont see anywhere in the first amendment where it applies to companies restricting free speech, just the government. Maybe you can argue that we should accept that we do have a de facto common communication system and we should consider restricting when and where large companies can censor. But, as it stands, we do not have free speech protections from Facebook on Facebook.
There's a big difference between habitual harassers being run off platforms (by those platforms) because they broke their TOS and the government making it so that you cannot travel.
Are you saying that companies have no free speech? I cannot choose who uses my platform or not? Or does that only apply when bakers refuse to make cakes for gay couples?
Fair points, but, if they're going to have "advertiser friendly comments" being enforced by video creators, we're going to have to have some sort of moderation system in place that can handle the massive amount of comments that some videos get.
Was actually talking about the current "adpocalypse" and its causes, and wondered if youtube wouldn't be eventually working towards disabling comments. In fact, I'd go a step further and start phasing out comments in general. While they increase "engagement", they're so incredibly useless that I definitely wouldn't miss them. Leave chats for livestreams, though, as that actually provides instantaneous feedback that can be valuable.
I think in at least some cases, it actually is clear-cut malice.
If you understand how herd immunity works, but also worry about potential side effects of a vaccine (ie. if you don't buy into most of the anti-vaxx nonsense, but still don't like elective medical procedures), you might opt to not get vaccinations, weighing the risks to the herd by having one less vaccination against the risk imposed by the vaccine. It's essentially a form of the tragedy of the commons. Increase the risk to everyone to slightly lower the risk to your own child.
The problem is that herd immunity works, and if too many do this, then it all breaks down and they're putting their kid at higher risks.
I imagine that, if distilled down to a usable script, it could make for an interesting "faux-writing" hobby where you write a few ideas, let it finish it, edit it a bit and have it continue from there. Could make for some interesting works of fiction.
And, yes, I realize that you can certainly write code that creates malformed strings. The point is that the standard C library itself would have memory safety built into its own handling of strings.
I feel like there's a fundamental misunderstanding of what ptr+len means.
It means that all of the c api's functions would be based around this idea. So, for example, "get_s()" would return a structure containing the length of the string and a pointer to the first character. It means that "str_concat()" would take in two of these structures and return a new one, etc. (or, some idiomatic c equivalent of these things).
Exactly how do you think that a "malformed string" would get in that lies about its length? It's not like we'd be relying on the input to tell us the length, the function calls would create the char* and tell us how long it is.
I can think of no valid reason why you'd ever want to have a string as large as 16 exabytes and think it's ever a good idea to have to walk the entire thing to figure out its length.
Slashdot Mirror
Having P = 0.05 has led to "P-Hacking". One example was the "chocolate" trial that had a small group eating different diets and tracked a whole slew of things, looking for a correlation in any of them. It happened to be that in the small group eating 1.5oz of chocolate and otherwise dieting lost slightly more weight than the group just dieting. Due to not having a specific goal in mind, and small sample size, they were bound to determine some sort of "positive correlation" somewhere, and there you go. If it hadn't been weight loss, it would have been heart rate or something else.
https://io9.gizmodo.com/i-fool...
Exactly how would that be muddying the waters? It's fair to point out that issues affecting your system affect your direct competitors, too.
"some of these attacks" = the various speculative execution attacks, not the exact attacks in the article, numbnuts. My point was that this is a much further reaching issue than just some handful that have been found in Intel chips. This problem of leaking data via various speed enhancements type of attacks will probably be more widespread than we currently realize, and saying "don't buy intel, buy AMD because it's safe" is a naive and dangerous mindset to be in for this. We should be taking steps to mitigate this entire class of attack.
I read this part, in the linked original Spectre disclosure, did you?
Google Project Zero (GPZ) Variant 1 (Bounds Check Bypass or Spectre) is applicable to AMD processors.
GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.
GPZ Variant 3 (Rogue Data Cache Load or Meltdown) is not applicable to AMD processors.
So, at least two variants of Spectre/Meltdown had to be mitigated on AMD platforms. My point still stands, it's not just an Intel thing, and switching to another processor isn't going to protect you from all variations of future attacks, just against a handful of intel specific ones that we know about right now. These are flaws inherent to our current processor designs and will probably take a few generations of processors to make secure.
https://www.amd.com/en/corpora...
AMD has had some speculative execution attacks that are viable against them, and there's probably undiscovered/undisclosed ones.
The correct answer is: don't run untrusted code, even from websites. Come up with better (slower) execution environments that enforce timings.
Reminder: AMD has been vulnerable to some of these attacks, and it's entirely possible that a variant of this attack would work against AMD. It's inherent flaws in our processor designs and security models for "jailed" applications.
There's probably AMD/ARM-specific attacks that haven't been discovered or disclosed.
Funny that, I dont see anywhere in the first amendment where it applies to companies restricting free speech, just the government. Maybe you can argue that we should accept that we do have a de facto common communication system and we should consider restricting when and where large companies can censor. But, as it stands, we do not have free speech protections from Facebook on Facebook.
Being an asshole isn't a protected class.
There's a big difference between habitual harassers being run off platforms (by those platforms) because they broke their TOS and the government making it so that you cannot travel.
Are you saying that companies have no free speech? I cannot choose who uses my platform or not? Or does that only apply when bakers refuse to make cakes for gay couples?
There's a huge difference between organizations enforcing their own rules and the government running a system to disenfranchise people.
No. Just no. Nothing of the sort has been proposed.
Fair points, but, if they're going to have "advertiser friendly comments" being enforced by video creators, we're going to have to have some sort of moderation system in place that can handle the massive amount of comments that some videos get.
Was actually talking about the current "adpocalypse" and its causes, and wondered if youtube wouldn't be eventually working towards disabling comments. In fact, I'd go a step further and start phasing out comments in general. While they increase "engagement", they're so incredibly useless that I definitely wouldn't miss them. Leave chats for livestreams, though, as that actually provides instantaneous feedback that can be valuable.
Sounds like a hi-tech version of the classic potato gun, just more expensive and arguably more dangerous.
"high-frequency gravitational wave generator"
So, basically, no. Sounds like a crank.
I think in at least some cases, it actually is clear-cut malice.
If you understand how herd immunity works, but also worry about potential side effects of a vaccine (ie. if you don't buy into most of the anti-vaxx nonsense, but still don't like elective medical procedures), you might opt to not get vaccinations, weighing the risks to the herd by having one less vaccination against the risk imposed by the vaccine. It's essentially a form of the tragedy of the commons. Increase the risk to everyone to slightly lower the risk to your own child.
The problem is that herd immunity works, and if too many do this, then it all breaks down and they're putting their kid at higher risks.
Fair point. Though, a surrealist tone in a work could make things interesting, too.
https://imgur.com/YpLzccg
This is the stuff of nightmares.
I imagine that, if distilled down to a usable script, it could make for an interesting "faux-writing" hobby where you write a few ideas, let it finish it, edit it a bit and have it continue from there. Could make for some interesting works of fiction.
And, yes, I realize that you can certainly write code that creates malformed strings. The point is that the standard C library itself would have memory safety built into its own handling of strings.
I feel like there's a fundamental misunderstanding of what ptr+len means.
It means that all of the c api's functions would be based around this idea. So, for example, "get_s()" would return a structure containing the length of the string and a pointer to the first character. It means that "str_concat()" would take in two of these structures and return a new one, etc. (or, some idiomatic c equivalent of these things).
Exactly how do you think that a "malformed string" would get in that lies about its length? It's not like we'd be relying on the input to tell us the length, the function calls would create the char* and tell us how long it is.
Edit: Even if you can evaluate 4 billion characters per second, you're looking at 146 years to calculate the length of that string.
I can think of no valid reason why you'd ever want to have a string as large as 16 exabytes and think it's ever a good idea to have to walk the entire thing to figure out its length.
16 exabytes, actually.