This isn't a *new* thing, though the scale of it may be, and the paper value of the virtual heists is going up. Stealing peoples' accounts in order to steal their in-game loot is about as old as MMOs.
18 posts • joined 11 Oct 2010
Malware spotted doing unspeakable, filthy things to infected Macs – injecting Bing results into Google searches
Re: Flash is still required
Try using Chrome or Safari but changing the user-agent so that it reports itself as being an iPad?
I've seen this work before on e.g. the BBC's website a couple years ago. They were doing UA sniffing to decide whether to try to show you the news video via a dirty dirty SWF or a nice cleanHTML5 video tag.
Re: If you want seamless updates...
When you dynamically link in a .so file, it's opened (read-only) and mmap()'d with the MAP_PRIVATE flag. This gives you a copy-on-write mapping. If you try to write to one of the pages in that mapping, the kernel will transparently stop you, make a copy of the page, then resume you with your own copy of the page. If a bunch of processes all link in the same .so file, they'll all share all of the pages in it that none of them try to write, and they'll each have their own private copy of each page that they do write.
In contemporary unixes, the pages from the text section ("text" in ELF land means "executable code") get marked as read-only by default, and the pages from the data section get marked as read-write by default. You can call mprotect() on the executable pages to make them writeable if you really want to (though this is considered a bad idea, and things like AppArmor or SELinux might stop you.)
For things like JITs that do runtime compiling of code, you're encouraged to do something like: call mmap(NULL, size, PROT_READ|PROT_WRITE, -1, 0) to get some pages that you can write but not execute, then write some code into them, then mprotect(addr, size, PROT_READ|PROT_EXEC) to mark them executable but no longer writable.
Having pages that are marked as writeable and executable simultaneously is allowed (unless you've got a super restrictive config set up with something like AppArmor or SELinux), but considered kind of a bad idea because it makes it easier to exploit things like buffer overrun vulnerabilities to get RCE.
It looks a bit nicer than before. The behaviour on narrow screens is noticeably improved. I'm not sure what but something has improved in the way the front page layout handles titles with uneven lengths, and this version seems to be much less prone to putting strange big gaps on the page when someone's editor indulges their very-long-headline habit.
It looks similar enough to the previous design to still feel familiar, which is a big plus in my book. Thumbs up! :)
One place that may be the origin of a lot of downloads is that you can use the MSSQL server docker image to do development against a copy of MSSQL on your workstation in order to test code that uses the DB cheaply and easily before pushing code to staging servers on Azure. (Just set it to "developer edition", which it defaults to, and DON'T DEPLOY TO PRODUCTION because the EULA expressly forbids doing that.)
At least, that's what I'm using it for. It's really nice because you can a) run it on a Mac via Docker-for-Mac, b) use Docker's functionality for snapshotting the entire SQL server state, for repeatedly testing destructive operations, since SQL Server doesn't currently support that very well AFAICT. The slowest part is waiting about 6 seconds for the SQL server daemon to load and become usable.
Re: Did someone not do their EMC/FCC/CE testing then?
> "can even cause the connected Macs to freeze, requiring a restart." (? what's freezing here: the screen, the Mac, both?)
At a guess, it could be something like: the monitor goes faulty and repeatedly attaches and detaches from the display output on the Mac's video card; the Mac has to change the window manager & video card state when a monitor is attached or detached; the rapid toggling tickles a bug in the video driver or window manager, leading it to freeze; and you don't normally experience that bug because it's not normal to be able to repeatedly plug and unplug a monitor that quickly without a hardware fault.
Or maybe when the monitor's bugged it does something amusing like sending totally bogus EDID information that tickles a bug somewhere. "I have a width of -3200 pixels and I want to be driven at 4MHz" or something equally silly.
Given the complete uselessness of faulty hardware, bugs which only occur when you have faulty hardware plugged in aren't top of the priority list to fix. It's pretty reasonable that a problem like that could be left lying around for years.
Tumblr host sites on lots of domains. If you own a domain name and have a Tumblr blog, you can configure both so Tumblr will serve your blog on that name. e.g. http://tumblr.snipe.net/ is one - the domain doesn't end in ".tumblr.com", it belongs to someone else. These probably are the ones being counted. It's very plausible that as many as 160k domains have been set up like this; Tumblr have lots and LOTS of users.
Tumblr also have a lot of subdomains, which must not have been counted. Tumblr serve every blog on its own subdomain. e.g. http://dooktrain.tumblr.com/ is a blog posting pictures of ferrets (and maybe other stuff, I didn't look). Tumblr have a LOT more than 160k registered blogs: as far as I can tell, well into the hundreds of millions. One estimate I saw put it at 300 million this July.