I don't think the comparison holds up well, because in the case of XP users had control of the upgrade while in the case of phones it's usually the handset maker and to a lesser extent the carrier in charge. Adoption of Lollipop is mainly a function of how many handset models ship with it installed and how quickly people are upgrading to newer models of phones. Most of the flagship models are shipping with some flavor of 4.2 or 4.4 on them, and enough people seem to have bought those models in the last year that it'll probably be summer at the earliest before we see the next cycle of upgrades start in earnest. The only way we'll see Lollipop uptake pick up faster than that is if Google manages to convince the handset makers to roll 5.0 out to phones like the Galaxy S4. It'd also help if carriers stopped insisting on different "models" where the difference is strictly in branding and the actual phone hardware is identical.

Harder and "tech savvy"? Hardly. If you're running a router based on DD-WRT (which is basically any home WiFi router these days), it already includes PPTP and OpenVPN servers. Doesn't take much on Windows to create a little script that'll do a one-click push of the necessary files to configure and enable the server and set up the firewall to allow VPN traffic to go to the WAN side as well as the LAN. Worst case is you go to your local geek and have them flash stock DD-WRT onto the router to replace the factory-modified installation (which I'd recommend anyway, the stock images are more stable and less prone to wonkiness).

Apparently the media companies haven't heard of this new-fangled device called a "router". It comes with this exotic, difficult-to-use feature called a "firewall". And it insures that regardless of what DNS servers the application may try to use, it will use my DNS server while on my network. Problem solved.

As for VPNs, it's difficult to block router-based VPN tunnels since there's no trace on the device that a VPN's in use. All it takes is a suitable server to connect to, and I've got a selection available that aren't part of any VPN service since I set them up myself. Setting it up the first time's a bit tricky, but duplicating that first setup and changing a few address numbers to match the new system's pretty simple.

The media companies need to just grow up and accept that the world's moved on with or without them, and that their problems stem not from any overwhelming desire of consumers to pirate content but from their own adamant refusal to accept consumers' money for that content.

It's already assumed on desktops and laptops: saying it has a 500GB hard drive means it has a 500GB hard drive, not 500GB of free space after Windows and all the other software is installed. Saying it has 8GB of RAM means 8GB of RAM, not 8GB of memory free after device drivers and services and Windows and run-on-startup programs have loaded. So why on a phone or tablet should 16GB of storage not mean 16GB of storage, why is it supposed to mean 16GB free after the operating system and software is installed? It may be simply that phones and tablets have so much less storage compared to desktops, so people are more sensitive to how much is used by the pre-loaded software. The solution to that, though, is simply to either buy a model with enough storage or one with an SD card slot so you can add storage.

If Twitter is being paid to promote a brand through my appearing to follow it, they're having me act as a spokesman aren't they? If so, where's my fee? I think 10% of the gross that Twitter receives is fair.

1. Ingress/egress filtering near the edges. Backbone providers obviously can't feasibly do this, but edge networks like consumer ISPs have a solid knowledge of what netblocks are downstream of each subscriber port and what netblocks should be originating traffic on their networks. Traffic coming up from each subscriber should be blocked if it doesn't have a source address in a block owned by that subscriber, outgoing traffic through the upstream ports should be blocked if it doesn't have a source address of a netblock that belongs on or downstream of the network, and incoming traffic through the upstream ports should be blocked if it doesn't have a destination address that belongs on or downstream of the network.
2. Disconnection of infected systems. If a subscriber system is confirmed to be originating malicious traffic due to a malware infection, shut off the subscriber's connection until they contact the ISP and clean up the infection. Time and time again it's demonstrated that the people getting repeatedly infected won't do anything as long as their connection appears to still work, and that the only thing that gets their attention is connectivity going out. Get their attention and make it clear to them that letting this continue is just not acceptable.
3. Extend this as far into the Internet as is feasible. Even if you have so much interchange traffic that you can't filter all ports, you may also have some ports where there's a manageable number of known netblocks handled through them and you can do filtering on those ports to reinforce the filtering that should be happening on the connected network.

Yes, it can lead to an arms race. The problem is that if you hold off and your enemy doesn't, you're a sitting duck. Avoiding the arms race is only possible if everybody involved holds off, and you don't/can't trust any of them to hold off so you have to proceed as if you're already involved in an arms race whether you want to be or not. Because the only thing worse than being in a Mexican standoff is being the one guy in a Mexican standoff without any guns.

With the consumerization of IT continuing to drive employee expectations of corporate IT, how will this potentially disrupt the way companies deliver IT?

It won't. Corporate IT and how it operates is driven by the people who sign the checks. That, BTW, is not the employees. The people who do have considerations other than employee expectations in mind when they decide on policies, and some of those things like compliance with laws and regulations aren't optional. Corporate IT will, as always, continue to be bound by what upper management decides on and the rest of the company will have to live with upper management's decisions. And no, IT isn't any happier about this than the rest of the company, because frankly their job would be a lot easier if upper management would stop telling them how to do things and just let them do whatever they needed to do to deliver what upper management needed. I don't see that happening any time soon.

Upstream verification won't help. The client has to verify that the image it received is the same one the server verified, otherwise someone can hack a router to silently redirect the client to a malicious server and serve up whatever image they want alongside a copy of the signed manifest for the official image and you're fsckd. What they need is:

1. The manifest has to be signed.
2. The manifest has to contain a secure checksum (cryptographic hash) of the official image the server has.
3. The client has to verify the signature of the manifest to confirm that the manifest hasn't been altered and comes from the official source.
4. The client has to verify that the checksum of the image it received matches the checksum for the image in the manifest.

5. Step 4 is apparently what's missing from the client.

For one thing, if North Korea was capable of this sort of hack they've got more tempting targets to use that capability on. And it's just a bit too convenient, coming on the heels of a disappointing performance by Sony, for SPE to suddenly get an excuse to get out from under another apparent flop. My bet is the hack's just another in a long string of breaches by the usual gangs of malcontents, aided and abetted by corporate obliviousness to security, and various parties are just taking advantage of superficial connections for their own reasons.

There should be more isolation, yep. When I handled POS the terminals had no local storage at all, they were network booted from images on the site server and the LAN they were on had no outside access at all. The site servers were on our own wide-area network that connected them to corporate, and there were only two network segments (Development and Support) that could connect to the site servers (sites couldn't even connect to each other). Access to the Dev and Support networks from the rest of the company was highly restricted, and any unexpected access from Dev or Support netted you a phone call and/or an in-person visit from the support manager to find out what had blown up.

I can think of ways to get malware out to the POS system through all that, but all of them involve physically being in the basement of the corporate headquarters where the Support and Development department offices were located and any unknown face would've had to avoid 2 managers and 3 secretaries before being grabbed by the scruff of the neck by Cory and hustled back upstairs (because if Cory didn't recognize you you were not supposed to be down there).

I'd note that the 3 points at the end of the article aren't unique to open-source software but apply to all third-party software you use in building your software. And those points are harder to address for proprietary third-party software than for open-source, because any software component may contain other components you aren't directly aware of and without the source code it's a lot harder to scan proprietary libraries to detect those included components (and it may be impossible if the included components are themselves proprietary because the people who wrote the scanner may not even know those components exist let alone have access to their code to create the necessary detection routines). Or they may be easier to address, if your license for the proprietary libraries doesn't include a right to redistribute then the answers become very simple if rather limiting and any less-restrictive licenses for other components become irrelevant.

Apple argues, and Schultz agrees, that its intentions were to improve iTunes, not curb competition.

I'd note that the two alternatives aren't incompatible. It's entirely possible to intend to improve iTunes while also determining that the best way to improve it is to block all competitors from accessing it (doing that would, among other things, eliminate bugs due to incorrect accesses and malformed music files and remove an inconsistent user experience due to badly-written software from other vendors). After all, when AT&T was banning all other vendors from connecting equipment to it's phone network it was only intending to protect the network from damage due to incorrectly-designed equipment (or at least so it's testimony went). In neither case do intentions alter the end result.

Times of stress/trouble usually mean a loss of population. The arithmetic's simple: one woman can bear one child every 9 months to a year, while one man can sire multiple children in that same time. That means that adding female offspring at the expense of male will make it easier to recover the population loss. And of course sacrificing the least resilient male offspring favors the ones that'll survive the longest and sire the most children. The fun question is how the mechanisms that've evolved to make this happen actually work. Figuring that out's going to keep researchers occupied for the next century or two.

The article's behind the curve. The class has a plaintiff for the suit and it will continue.