The summary says they round to the nearest 5 and then truncate, you seem to be rounding to the nearest 10 (which definitely makes more sense, so maybe the summary is wrong).
My understanding is that AMD is theroretically vulnerable to hard to mitigate spectre (version 2?), But the proof of concept didn't work on it and AMD says it's super improbable. Certainly that warrents mitigation though.
Other Spectre easy to fix is easy to fix (version 1?).
And AMD is immune to meltdown.
Please correct me where I'm wrong, there's a lot of FUD and also a lot of super "AMD is immune" nonsense.
As it is, there is no proof of concept for hard to fix spectre on AMD.
What I mean is how is the mitigation by programming different.
All software, even the OS, had to be patched, all cases found and fixed, mindfulness in future programming etc. Etc.
Eventually, over time, hardware and carefulness, and using different languages, and new features of the same languages, they're almost a thing of the past (relative to the time that a long URL could cause one).
Sure, hardware helps mitigate when an overflow happens now (64 bit address space with address randomization for example), but fundamentally it was a programming fix.
With spectre, the issue (again as I've understood, I can only read analysis, not the details) is that a process can read any of it's own memory, it seems credible that tools can be developed to try and find instances in code, language features can be developed to compile in a way that prevents it, etc. Etc.
Like with buffer overflows, I assume the programming side will address it faster than hardware can.
Obviously the exploit is different than a buffer overflow.
How much of Spectre can be mitigated by coding while mindful of it? At what cost?
I guess what I'm saying is leaving the vulnerability and trusting coders a valid choice (that's how buffer overflow was for a while if my understanding serves, then later additional instructions were added that made them less damaging?)
I guess prevent is a better word, but the checks that AMD does in hardware prevents meltdown. Does that check have overhead? If so how much? It follows that some of the speed difference is because of this overhead if there is overhead.
Clearly AMD had other problems with their design that made them slower for a very long time, but how much was because they were immune from meltdown?
I've found that in the US people prefer fake syrup. I personally find it unconsumable, I'd much rather just use butter and rub it in sausage/bacon grease, but most people prefer the thick stay on top gross stuff. That's my observation from hosting brunches anyway.
TMobile costs $75 ($5 extra, or $15 more than this) to get meaningful data overseas.
On the plus side, they don't throttle you down to 0.25mbps for hitting 15 GB.
Instead, at 50GB they throttle you down during heavy load times. I assume that you're always in that low priority heavy load state on project-fi though, since it's an mvno.
Project FI remains for relatively low use, or wifi heavy use, and that's OK, for that and travel it may be better than TMobile price wise, but in general it seems like a bad deal.
There are rare instances where I think it makes more sense than a flat rate domestic mvno or TMobile.
So the current (but soon to be fixed?) behavior is to put the phone in low power mode and disable the ability to turn it off after a certain amount of time, and you think that's best setup?
Example in an office where I may want full speed while not plugged in? Maybe when I'm in the cafeteria at lunch and want to fuck about playing games even if it will drain 50% of my battery in that half hour, it doesn't matter, it will be plugged in for the four hours afterwards.
An example may be I'm in an office with chargers, and I find the snow down irritating. I can keep it in high performance mode (also called performance I thought I'd have when I tried it in the store and purchased it, except maybe it feels less snappy as the newer apps want even more), but also, if I'm out all day, I can put it in low performance mode.
Why would your personal preference of battery over performance only apply to a degraded battery?
It's a feature I'd love to be able to turn on even on a brand new phone, and turn off on an old one, depending what I'm doing and my charger situation.
I only came up with around 25/day, and that was with a truck.
The 5k was for total maintaince, 5k/year would be insane, but breaks, tires, timing belt, water pump, oil, plugs and wires add up, and then there's always some miscellaneous.
Slashdot Mirror
If I had to bet, this store that's harder to get into without an ID won't be the one criminals focus on.
The price for these capabilities of dropping well faster than half every three years.
At best it's a three year speed up in bringing these capabilities.
That's pretty much the way every state works.
Revoking statehood isn't the same thing as granting Independence.
Pretty sure the Hawaiians don't want to be turned back into a colony.
The summary says they round to the nearest 5 and then truncate, you seem to be rounding to the nearest 10 (which definitely makes more sense, so maybe the summary is wrong).
I feel like SF is one of those cities (like NYC) where it is acceptable (though perhaps not preferable) to not clarify it's a neighborhood.
I live in the Eastern Seaboard and have no connection to SF, so I don't think I'm biased from locality (maybe I am WRT to NYC though).
Isn't everything from 127.51 to 137.4 represented as 13?
The nearest 5 would be either 130 or 135, then the truncation 13
Isn't everything not working a bug these days?
Or are some of them still features?
My understanding is that AMD is theroretically vulnerable to hard to mitigate spectre (version 2?), But the proof of concept didn't work on it and AMD says it's super improbable. Certainly that warrents mitigation though.
Other Spectre easy to fix is easy to fix (version 1?).
And AMD is immune to meltdown.
Please correct me where I'm wrong, there's a lot of FUD and also a lot of super "AMD is immune" nonsense.
As it is, there is no proof of concept for hard to fix spectre on AMD.
Ignore me, I missed your last paragraph, sorry.
I think what you're saying is that it's hard to detect because it's all proper from the code side?
What I mean is how is the mitigation by programming different.
All software, even the OS, had to be patched, all cases found and fixed, mindfulness in future programming etc. Etc.
Eventually, over time, hardware and carefulness, and using different languages, and new features of the same languages, they're almost a thing of the past (relative to the time that a long URL could cause one).
Sure, hardware helps mitigate when an overflow happens now (64 bit address space with address randomization for example), but fundamentally it was a programming fix.
With spectre, the issue (again as I've understood, I can only read analysis, not the details) is that a process can read any of it's own memory, it seems credible that tools can be developed to try and find instances in code, language features can be developed to compile in a way that prevents it, etc. Etc.
Like with buffer overflows, I assume the programming side will address it faster than hardware can.
Obviously the exploit is different than a buffer overflow.
How is this different than a buffer overflow? that it can be down in all languages?
Isn't the fixing of buffer overflows a similar situation?
I had to submit and start buying both types because people would complain about:
1) the maple flavor
2) the sweetness
3) that it soaked in
I agree also that most people don't realize they aren't usually using maple syrup, but also, once they realize, most seem to prefer the fake stuff.
Thank you for that great response.
How much of Spectre can be mitigated by coding while mindful of it? At what cost?
I guess what I'm saying is leaving the vulnerability and trusting coders a valid choice (that's how buffer overflow was for a while if my understanding serves, then later additional instructions were added that made them less damaging?)
I guess prevent is a better word, but the checks that AMD does in hardware prevents meltdown. Does that check have overhead? If so how much? It follows that some of the speed difference is because of this overhead if there is overhead.
Clearly AMD had other problems with their design that made them slower for a very long time, but how much was because they were immune from meltdown?
I've found that in the US people prefer fake syrup. I personally find it unconsumable, I'd much rather just use butter and rub it in sausage/bacon grease, but most people prefer the thick stay on top gross stuff. That's my observation from hosting brunches anyway.
Almost certainly planning them, and they will be faster than current chips (progress and all that).
Im curious how much of a speed Improvement they got for the design decisions that left them vulnerable to meltdown though.
It looks like a 5-10% cost to mitigate in software, probably less than in hardware.
AMDs chips mitigate meltdown in hardware, is that part of the performance gap?
TMobile costs $75 ($5 extra, or $15 more than this) to get meaningful data overseas.
On the plus side, they don't throttle you down to 0.25mbps for hitting 15 GB.
Instead, at 50GB they throttle you down during heavy load times. I assume that you're always in that low priority heavy load state on project-fi though, since it's an mvno.
Project FI remains for relatively low use, or wifi heavy use, and that's OK, for that and travel it may be better than TMobile price wise, but in general it seems like a bad deal.
There are rare instances where I think it makes more sense than a flat rate domestic mvno or TMobile.
So the current (but soon to be fixed?) behavior is to put the phone in low power mode and disable the ability to turn it off after a certain amount of time, and you think that's best setup?
Example in an office where I may want full speed while not plugged in? Maybe when I'm in the cafeteria at lunch and want to fuck about playing games even if it will drain 50% of my battery in that half hour, it doesn't matter, it will be plugged in for the four hours afterwards.
An example may be I'm in an office with chargers, and I find the snow down irritating. I can keep it in high performance mode (also called performance I thought I'd have when I tried it in the store and purchased it, except maybe it feels less snappy as the newer apps want even more), but also, if I'm out all day, I can put it in low performance mode.
Why would your personal preference of battery over performance only apply to a degraded battery?
Do companies usually pay taxes on money spent on R and D in the US?
My understanding is that money isn't taxed, only money held or paid out in dividends.
Even better, have a toggle.
It's a feature I'd love to be able to turn on even on a brand new phone, and turn off on an old one, depending what I'm doing and my charger situation.
The throttling 24/7 (not just during times of congestion) is pretty aggressive too.
I only came up with around 25/day, and that was with a truck.
The 5k was for total maintaince, 5k/year would be insane, but breaks, tires, timing belt, water pump, oil, plugs and wires add up, and then there's always some miscellaneous.
It looks like they released the patch to phones that weren't affected.
http://allaboutwindowsphone.co...