171–180 of 298 posts
Earlier quoted context omitted.
If your allegation is true, that would seem to be very illegal.
I've heard you can schedule big sales all the time and then regularly cancel them unless something goes wrong. Apparently there is no rule against insider canceling.
Earlier quoted context omitted.
If your allegation is true, that would seem to be very illegal.
I've heard you can schedule big sales all the time and then regularly cancel them unless something goes wrong. Apparently there is no rule against insider canceling.
https://corpgov.law.harvard.edu/2013/02/05/rule-10b5-1-plans...
Earlier quoted context omitted.
I was assuming contention but I guess I wasn't clear, sorry. I updated the post. But saying this "only" occurs when there is contention is very misleading since it makes it seem like the scenario of lock contention is a negligible concern. It's not.
Thread-suspending contended mutexes are already extremely slow. If you have a heavily-contended mutex you already have a major performance bug. If this is the kick in the pants you need to go fix it that's arguably a good thing ;) Note that mutex contention does not itself mean immediately falling back to futex - commonly you'll spinloop first and hope that resolves your contention (fast), then fall back to futex (sl…
I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. It certainly isn't consistent with my experience, but if every problem you've solved could have been parallelized infinitely without increasing lock contention, more power to you.
All Intel CPU's are affected, mitigation syscall overhead increased by 50%, and none of AMD CPU's affected? I would say this could be an indicator to short INTC and long AMD...
If the hit is as bad as they say (30% performance), cloud providers will be almost forced to upgrade when the new hardware comes out that fixes it. Are they really ready to adopt AMD? Go long on INTC?
Earlier quoted context omitted.
> IMHO it's not such a big deal for the typical single-user personal computer IDK. If this means that some JavaScript from a website can read my kernel's memory, then it seems like a big deal.
All the more reason to keep JS off by default... ...but the blog post above shows that you need to execute instructions that (try to) access kernel addresses, and have a handler in place to catch the inevitable exception. That doesn't seem like code a JS JIT could generate. You might be thinking of that JS RowHammer demonstration, but that was using regular memory accesses and not with the specific kernel addresses t…
Earlier quoted context omitted.
Tao/Intent/Elate (which I think is defunct nowadays) would also qualify, and I'd argue .NET on Windows with the GAC would, too (although there'll be a legitimate argument about whether that's "simple and closely models the processor").
Tao is long defunct, yes (went under a decade ago). It turns out that people don't really want a runtime-portable OS/apps (IIRC the biggest takeup it got was as a Java runtime for mobile, because the competition at that time was all interpreted). There was no security model in VP, though -- single flat address space and bytecode could turn any integer into a pointer and dereference it (loads just got translated into…
Earlier quoted context omitted.
Sorry that train has left the station. JS is now a part of the web. The advice to keep JS off by default is a lot like saying "turn off your Wi-Fi by default" and "don't use a computer." People that do it occasionally experience an exaggerated sense of smugness when a particularly nasty bug is discovered, but then they go back to leading a much more difficult online life than the rest of the world.
there's a subset of the web that still remains a hypertext document database (the 'web 1.0' if you will) instead of becoming an application delivery platform (web 2.0, i hear it's almost out of beta). going JS-less on wikipedia is possible and not at all a bad experience.
I'm not sure what the advantages of this argument are anymore. JS is now so ubiquitous I can only imagine how a drive-by JS exploit can truly mess you up in obscure ways despite the fact you browse the web with IE4.
Earlier quoted context omitted.
Thread-suspending contended mutexes are already extremely slow. If you have a heavily-contended mutex you already have a major performance bug. If this is the kick in the pants you need to go fix it that's arguably a good thing ;) Note that mutex contention does not itself mean immediately falling back to futex - commonly you'll spinloop first and hope that resolves your contention (fast), then fall back to futex (sl…
> If you have a heavily-contended mutex you already have a major performance bug. I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. It certainly isn't consistent with my experience, but if every problem you've solved could have been parallelized infinitely without increasing lock contention, more power to you.
Earlier quoted context omitted.
>OK, but that's (a) 100% speculation 95% speculation. The last 5% comes from exercising basic pattern recognition. I remind you that we're probably talking about interference from the organization that arranged this: https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa... The existence of that program was pure speculation, until it turned out to be totally real. >(b) fails Hanlon's razor. This is completely i…
I think they have an incompetent management department that decided that no open sourcing ME is a good idea. Marketing is may also be incompetent at picking up the pieces after the bugs were discovered. > 95% speculation. The last 5% comes from exercising basic pattern recognition. No, it's all speculation because pattern recognition is not evidence, as applied here. Like, is it possible that I am an NSA agent trying…