Just nuke them. It has a lot of advantages:

- You can get rid of old nuclear warheads that don't operate to spec anymore. As long as they still have enough power to vaporize a group of people sitting right next to them they're fine.
- It should be fairly painless, given that the prisoners' brains quickly transition to a gaseous state.
- It's inherently flashy so everyone looking for bloody retribution can see it being served from one state over.
- It's inherently suitable for group executions, which makes it very efficient in dealing with America's large number of criminals.
- It makes you consider whether you really want that prisoner dead. If you're not willing to nuke some part of your state you probably don't want the person's death that much.

Plus, it doesn't make you look much sillier than complaining about how nobody wants to sell you equipment for killing your own citizens.

I wonder if Valve will expand the Steam Cloud in response. Steam already warns you on game launch if your savegames don't match what's in the cloud so broken savegames can be recovered as long as you don't sync. The flaw in that is that syncing happens whenever you exit the game so you'd have to force-kill Steam if you notice that everything is corrupt. (Perhaps this only applies if your game actually saved something but some games are very save-happy.)

If Valve adds a simple versioning system, even if it just offers the current version and the one before that, crypto-ransomware will become completely useless against Steam titles.

A faster, leaner and generally less quirky alternative to Chromium-based browsers, especially on mobile. Lots of work on the standards front. Plus MDN is one of the best web development knowledgebases I know. Also Thunderbird, the only platform-independent mail client used by more then a handful of people. Oh, and they came up with asm.js, which allows massive performance gains for generated JS code.

Honestly, I have no idea what the article is talking about:

- The "waning market share" doesn't seem to wane all that much, going by international market share numbers (although I'm in Germany where Firefox is still the undisputed top dog so that may color my perception).

- The only thing close to "questions over tooling for their platform" I am aware of is that they're implementing Gecko's successor in Rust, their own programming language.

- While FirefoxOS has pretty much zero presence today it's still easy to run Firefox on Android (and I recommend it because the bundled browser is usually an antique, plus mobile Blink/WebKit ain't all that hot anyway).

- I have no idea what "Gecko-flavored JavaScript" is supposed to be and how it's supposed to deliver "standard tools" that other browser vendors somehow have.

Even if Mozilla sucked at what they're doing (cf. Microsoft, although they're at least trying these days) they'd create competition and thus drive the other players forward.

(No, I don't work for Mozilla. I'm just a web dev.)

Is there a good SPC library somewhere? I'm thinking about something like the High Voltage SID Collection, which aims to contain just about every single bit of CBM-II/C64/C128 music ever and seems to be doing well in that regard. SIDtunes are compact enough (and sufficiently conveniently packaged) that one can easily download the entire HVSC and listen to tracks from games/artsts one didn't know yet. Anything similar for SPCs?

I'm not sure. On the one hand they have convenience and possible a price advantage. On the other hand the drivers probably don't have the kind of insurance regular taxi drivers have so you might end up SOL if they get into a severe accident while transporting you. To be honest, I'd probably stick with a regular taxi driver.

Look at it like this: You are a municipality. You have local taxi companies and they're all regulated and pay for their special licenses and whatnot. The system works. You get some money and you can be certain that taxi drivers are competent and relatively trustworthy. This also goes for taxi drivers from other municipalities because those are also regulated and licensed.

Now Uber show up and declare themselves to be exempt from taxi laws because they don't employ taxi drivers, they just make money by "soliciting" "ridesharing", which is somehow different except it seems to work exactly the same*. And they're not willing to enforce that their drivers have valid licenses because they think they're not subject to the law.

Now you have lots of taxi drivers in all but name driving around without a license and you probably can't even get Uber to disclose their identities so you can fine them because, again, Uber thinks there's no legal basis for this.

I think it's fairly easy to see why Uber isn't very popular with municipalities.


* Technically it's a form of outsourcing but to my knowledge they don't require the drivers to be their own proper taxi businesses so Uber is still blatantly ignoring the law by contracting with people they know don't qualify under existing regulations.

(Note: This is all due to my understanding of the situation. I did not extensively research the GTX 970 and might be entirely wrong.)

The problem is that GPUs usually have a uniform memory layout. If your GPU advertises 4 GiB of RAM then all 4 GiB of it behave in pretty much the same way. Accessing one part of the memory does not significatly affect accesses to other parts. Thus it's unnecessary to take special care in how to structure your memory handling; you just use whatever's there.

The 970, as I understand it, has a non-uniform memory layout where the segment between 0x00000000 and 0xDFFFFFFF cannot be accessed at the same time as the segment between 0xE0000000 and 0xFFFFFFFF. Try to access one segment and all accesses to the other segment will stall until this one access has been handled.

This could be used without appreciable performance impacts if the software accessing the memory is aware of it and specially structures its memory management so that accesses to the upper segment are sparse and happen in bulk (ie. it switches between blocks of lower segment accesses and blocks of higher segment accesses). That's the kind of optimization you see in game console programming and actually smells kind of like how PS3 games had to structure their memory handling around the Cell's peculiarities. If I remember correctly, this made the PS3 somewhat unpopular to develop for.

Of course, no one in their right mind is going to add special Geforce GTX 970-specific logic to their game (potentially having to restructure half the engine for it) just to make best use of the hardware. Even making a codepath that detects the 970 and avoids the upper 0.5 GiB of VRAM entirely is unlikely. Thus, in situations where more than 3.5 GiB of VRAM are needed, the 970 will exhibit stuttering because of stalled memory accesses and there's not much anyone can do about it - except Nvidia, who could release a driver that reports the 970 as having 3.5 GiB of RAM.


(I find it interesting how a Google search for "VRAM" ended up having several articles about the 970's slowness on the first page. I have never searched for the 970 before; my 660 from 2012 still has more power than I need.)

That one probably wasn't Apple's fault. Apple issued a recall for certain MBPs because Nvidia managed to screw up the packaging of the Geforce 8600M GT so badly that the thermal stress of running caused the chip to slowly break itself apart.

Not that Apple is free of sin. I had an iBook with a power jack that liked to desolder itself and my current MBP has an Nvidia GPU and Yosemite, which is an explosive combination due to Yosemite's Nvidia GPU driver being unstable when switching between the Intel GPU and the Nvidia one. Apple does screw up. But not every problem is their fault - and, in fact, their speed in issuing a recall is usually directly proportional to how much it isn't. The hand grenades Sony sold them instead of regular battery packs were recalled pretty quickly, if I recall correctly.

My next Mac will still be a Lenovo but that's mainly because I find the Retina MBPs higly unappealing. While Apple has terrible customer support, my Macs do have a tendency to outlive AppleCare. In fact, the only one that really died was the one with the 8600M GT. That one died once during the AppleCare period and once shortly after it ended - it turned out that the replacement GPUs were also faulty.

(As for speed, my experiences differ but I have to deal with UAC a lot and UAC is easily the slowest privilege escalation method on any major operating system. I'd take (g)ksudo over it any day.)

Remember, these are the people who shipped a version of Android with a custom kernel extension that created a second, world-accessible instance of /dev/mem because they couldn't get the camera driver to work without it.

As has been pointed out, they've misdeployed this to the wrong market but still - it's Samsung. Their hardware is nice but they're not terribly strong on the software side.

I just tried that and imagine my surprise when my MBP spontaneously downgraded itself to Mountain Lion!

Okay, actually it just booted into the old Mountain Lion volume on the first HDD because the Mac keeps the preferred boot volume in NVRAM. So when clearing your NVRAM keep in mind that the Mac will boot into whatever system volume it finds first unless you tell it otherwise.

I'd ask "Do 'normal' people still carry tablets?" as the tablet-on-the-go fad seems to have cooled off quite a bit. I see a lot of people with smartphones and a sizable number of people with laptops but pretty much nobody with a tablet. Tablets are commonly found in homes but they definitely don't seem to be popular for mobile computing.

This might be because tablets suck for the two things I commonly see people do with their laptops on the train: Watching movies (big stationary screen, easy to view with more than one person) and working (big screen, physical keyboard and sometimes software that has no smartphone equivalent).

No, with the big M in there it's a megameter wave. I'm not sure whether 300 Hz is a good frequency for a new broadband standard, although penetration would be excellent. Antennas might be a bit big, though.

If you want to lock down the login the easiest way (besides using a nonstandard admin user with a good password) is to rename wp_login.php and write a little plugin that changes the login URL to point to the new file. There's actually a hook for that. That way all brute force attacks will get 404'd by Apache without the WordPress core getting involved, which saves a ton of resources. In case someone mounts a distributed brute force attack on you this might mean the difference between somewhat elevated traffic and the server going down. (Yes, that happened to us already. Renaming wp_login.php took us from base load of 6 with spikes of 120(!) to a base load of 1 with spikes of 3. Login limiters and fail2ban weren't nearly as effective against distributed attacks.)

XML-RPC should mainly be disabled because of pingbacks; not too long ago these could be exploited to make your site participate in a DOS attack. XML-RPC itself not a significant security risk these days. You can go for a more nuanced approach by only disabling the functions used for pingbacks (there's a hook for that too) but if you don't need XML-RPC it might be easier to just rename or delete the entire file.

Trackbacks should be disabled because of trackback spam. Yes, you can install plugins that help you deal with it but - seriously - pretty much no Wordpress-as-a-CMS user cares about trackbacks (or pingbacks, for that matter) in the first place. Disabling them means fewer hassles.


Again, these days the biggest security risk are badly-written plugins. We once had an infected WordPress where it turned out that the attacker never compromised any user account. They didn't need to because a plugin allowed them to execute PHP code on the server. They just injected their attack code directly into WordPress and could do whatever they wanted, such as displaying dodgy pharma ads without even touching the database. That's the kind of danger unreviewed plugins pose.

WordPress can be quite capable when managed correctly. Just don't make the mistake of assuming that you can just install a plugin and get new functionality without any risk. Badly-written plugins are common and they can screw you just as much as an insecure admin account can.

Not so fast, my friend. While I agree that the WordPress core has come a long way and is reasonably secure once hardened (such as by removing the XML-RPC and trackback files, two of the biggest attack vectors) I decidedly disagree on plugins being even remotely secure.

Some WordPress plugins are well-written and secure. Most WordPress plugins are messy and were written by people who haven't even heard of code injections. If you want your WordPress to be secure, don't use plugins. Ever. At least not without a full code review by someone who knows how to write secure code in PHP.

Seriously. Most WordPress CVEs these days are for plugins and after having seen the code of a few dozen plugins I can see why. Do not trust a WordPress plugin you have not verified yourself.

WordPress itself is actually reasonably secure these days provided you rename wp-login.php and delete the files for XML-RPC and trackbacks (comments too if they're not needed). The plugins, however, aren't. Most WordPress plugins are written by people who know a bit of PHP and need an itch scratched, not by people who know what MVC is or how to prevent code injection. The former just makes maintenance a hassle but the latter is what gets your network pwned.

You can use (a hardened) WordPress without much issue except for poor performance when compared to plain websites. If you intend to extend it in any way, however, you really should do a full code review of every plugin you use every time it is installed or updated. That means either your customers get their WordPress without plugins and further support or you rack up the billable hours doing code reviews for them.

The company I work at is actually migrating away from WordPress because our customers demand non-core functionality and keeping the plugins reasonably secure is simply too expensive.