Just because the time limit has been raised, that doesn't incur a liability for the debt on the part of anyone who isn't already liable for it. And generally children aren't liable for their parent's debts unless their signature's on the contract. The parent's estate might be liable, but good luck collecting from that once the estate's finalized and closed out. I suspect this'll be what any competent attorney will raise as an issue if the victims get one: "Regardless of anything else, this is not my client's debt and the debt being collectible doesn't on it's own make my client liable for it.".

So, Zynga's racking in the bucks, then?

True, but I've noticed that the F2P games that use that model are now trying to entice players back into monthly subscriptions. I think it's inevitable: if all you can buy is cosmetic, there's no real incentive to spend much money at all and the company starts wondering where all the cash they were supposed to be getting is. I'm of the opinion that the whole "free to play, and we'll make our money off the cash shop" is right in there with "free site, and we'll make our money off the advertising" as a business model.

The attitude stems from something more basic. In conventional games, even bad ones, once you have the game you have everything and how well you do is then up to your own skill and ability. In many free-to-play games, though, the game itself is just the hook. Once you're in, you find that you can't, for all practical purposes, go beyond a certain point without spending money and how much further beyond that you can go depends on how much you can afford to spend. It's why the derisive term is "pay-to-win". In large part how well you do in that type of game doesn't depend on your skill or ability, it depends on how deep your wallet is. And a lot of gamers are offended by the idea that a skilled, knowledgeable player who happens to not be that well-off will by design be less successful in the game than an unskilled, not-very-good player who happens to have well-off parents who'll toss him a couple of hundred dollars a week to fund his entertainment.

How do you figure?

Well, the Federal courts ruled that Proposition 8 violated the Due Process and Equal Protection Clauses of the US Constitution. That sounds like "unconstitutional" to me. The 9th Circuit panel affirmed that ruling, and the en banc appeal was denied. The US Supreme Court heard the appeal and dismissed it on standing, and ordered the 9th Circuit to dismiss the appeal to them as well (which Prop 8 supporters should consider a good thing because had the SC left the 9th Circuit's affirmation in place it would've created binding precedent for the entire 9th Circuit, but the dismissal order reverts it back to a district court decision).

So, question: what does a company do with a senior executive who's harming the company because large numbers of valuable employees and executives don't want to work with him, or at a company where he's in charge, because of his political views? Nothing in California law requires individuals to ignore political views when deciding whether to associate with someone. And it seems to me that deciding to let someone go because he's causing too many other employees to leave is perfectly allowable. So what's a company to do in such a case?

As noted, it wasn't Linus that started the blow-up. It got to this point because Sievers was ignoring more professional, less blunt instructions about it. And yes I'd rather deal with Linus. Because if I pulled the kind of crap Sievers had I'd've expected to have my manager drop my final paycheck on my desk and tell me I had 5 minutes to pack my things and the nice gentlemen from Security would be escorting me out of the building, and no I wouldn't be receiving a separation package because I was being terminated for gross incompetence. I'd rather deal with a manager who'll chew an incompetent developer out for being incompetent, as opposed to one who'll just send off iteration after iteration of "professional" memos about the developer having a problem and never actually do anything about the problem. At least with Linus I could be pretty sure I knew exactly where I stood with him.

Then again, I've written code that did exactly the same thing Sievers' code did. But I did what Sievers should have done in the first place, hung it off on it's own specific enable flag so it couldn't be turned on inadvertently, because I knew it was going to bring the system to it's knees and that was something that should never be able to happen as a side-effect of something else.

Did you read the thread? This wasn't just Linus complaining, it was 2 other kernel developers that originated the complaint. And this wasn't a minor thing, this was Sievers introducing a bug that caused the system to fail to boot! by using a long-established kernel boot parameter ("debug") and having it trigger a data dump large enough to cause the boot process to fail, and then refusing to fix it on the grounds that the kernel didn't own the "debug" parameter (http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01327.html).

If I worked for you and you canned Linus over this, the very next day my resume would be being shopped around and I'd be spending my off time perusing every job-lead source I could think of because you're the kind of manager who causes projects to go down in flames and I'd much rather get out while I can do it on my own terms.

Whenever I see one of those overblown handles that seem designed to intimidate and impress people, my first thought is that the player isn't good enough to do it on his own merits. I prefer names along the lines of how Ian Banks' Culture ships named themselves. To borrow a comment. "Let's see you explain to your admiralty that your fleet was wiped out by the Bureaucracy and the Red Tape, and when you tried to disengage you found yourself trapped by the Complete Lack of Morale and the High Command's Total Incompetency.".

There isn't a purely technical solution to this problem. The only solution is legal: first define a standard do-not-track header for HTTP (done), then impose a legal penalty for anyone who fails to honor it. And by all that's holy, learn from the errors of the Do Not Call list. The ability for individuals to go directly to small-claims court to recover was a good thing, but there's a couple of corrections that need to be made. First, have the law make the penalties mandatory. Don't give the judge the option of not imposing them just because he feels it isn't reasonable to demand that much from the advertiser. He should have the discretion to decide whether the DNT header was sent and whether the defendant tracked the user, but if the header was sent and the user was tracked then it is an abuse of discretion to not impose the stated penalties. Second, dump the exceptions for political and charitable stuff and surveys and the like. Any exceptions that are made should be limited to the site being visited only, even something as benign as "technically necessary" shouldn't apply to third-party sites.

Non-EBS-backed instances aren't good for test systems. To run them you need to have an AMI built with everything you need, and you need to keep that AMI updated with current test cases and so on. That's more work than just maintaining an EBS-backed instance would be. Especially considering that you're going to need the test instance to persist for anywhere from several days to several weeks while testing is in progress. We aren't talking unit tests, remember, we're talking about a complete release test of the entire system end-to-end. Even for unit tests, you've got too many test cases that need to be maintained so they can be used every run, plus all the special test cases developers need while diagnosing and debugging issues. Having all of that evaporate when the instance is shut down defeats the whole purpose of testing, you're losing everything you'll need for the next test iteration. Unless of course you go to the trouble of taking everything in the instance and transferring it back to the AMI so that it'll be there the next time the instance is spun up, in which case why not just leave the instance on EBS and be done with it?

Amazon charges for instances by the hours they're running and the type of instance. Think of an instance as a server, because that's what it is: an instance of a VM. You can find the prices for various services at http://aws.amazon.com/pricing/. What you want are EC2 pricing (for the VM instances) and EBS pricing (for the block storage for your disk volumes. For EC2 pricing figure out what size instances you need, then assume they'll be running 720 hours a month (30 days at 24 hours/day) and calculate the monthly cost. For EBS pricing take the number of gigabytes for each disk volume (each EC2 instance will need at least one volume for it's root filesystem) and multiply by the price (in dollars per gigabyte per month) to get your cost. You can manage instances the same way you would any other machine, other than usually needing to use SSH to get access and having to worry about firewalling (these are publicly-accessible machines, you can't shortcut on security by having them accessible only from within your own network).

The cost isn't actually too bad. For generic Linux, the largest general-purpose instance will, for a reserved instance on a 1-year commitment, cost you $987 up front and $59.04/month for runtime in the US West (Oregon) data center. An 8GB regular EBS volume will cost you $0.40/month for the space and $50/month for 1 billion IO requests. And not all instances need to be running all the time. You can, for instance, use on-demand instances for your testing systems and only start them when you're actually doing release testing, you'll need to pay for the EBS storage for their root volumes but you won't have any IO operations or run-time while the instance is stopped.

The downside, of course: if Amazon has an outage, you have an outage and you won't be able to do anything about it. This isn't as uncommon an occurrence as the sales guys would like you to believe. Your management has to accept this and agree that you guys aren't responsible for Amazon's outages or the first time an outage takes everything down it's going to be a horrible disaster for you. Note that some of the impact can be mitigated by having your servers hosted in different regions, but there's a cost impact from transferring data between regions. Availability zones... theoretically they let you mitigate problems, but it seems every time I hear of an AWS outage it's one where either the failure itself took out all the availability zones in the region or the outage was caused by a failure in the availability-zone failover process. This all isn't as major as it sounds, outages and failures happen running your own systems after all and you've dealt with that. It's more a matter of keeping your management in touch with the reality that, despite what the salescritters want everyone to believe, there is no magic AWS pixie dust that makes outages and failures just vanish into thin air.

That's pretty much unthinkable these days.

No, it's pretty much routine these days, just like it has been for the last... well, 34 years that I've been dealing with computers personally. Management doesn't see any reason to spend the (to be honest, fairly large chunks of) money to do a truly bullet-proof deployment that can tolerate things going pear-shaped without loss or interruption of service, because the salesman who sold them the tech swore on his mother's grave that it was bullet-proof and you didn't need to worry (his mother's still alive and running a three-card Monte scam in the Bronx, BTW). Murphy, being Murphy, puts his two cents in, and deployments go pear-shaped. And the users get to suffer for it.

Of course, I wouldn't buy WD's service anyway. Residential Internet's not suited for heavy upload, which is what you'll be doing fetching files from your drive at home, and that's on top of having to depend on a cloud service run by a company that's not a heavy-duty cloud service provider. Instead I'd buy a NAS box for the local network that doesn't depend on someone else's servers, and use Dropbox or Google Drive or the like for cloud storage. I'd also consider the cloud storage ephemeral and never ever put 100% trust in it, if I really have to have the data available then it goes on CD/DVD or thumb drive or a laptop's hard drive. Trust not in someone else's servers, for you can do nothing about any problems on their end and you are not a large enough chunk of their business that you can force them to jump when you say "Frog.".

The biggest problem here isn't the question of software patents. It's patents on things that are obvious, or are an obvious progression from something that's already common (eg. taking the manual process of balancing a checkbook and having a computer perform the exact same steps). It's just that software is the field where it's taken root the most, I think because people treat computers as some sort of magic that transforms the ordinary into something extraordinary.

The most straightforward way to deal with it might be to take computers out of the picture. Start by asking the question "If we replaced the computer with a trained monkey who could slavishly follow instructions, would this be patentable?". If the answer is "Yes.", then the patent's valid. If the answer's "No.", then the burden should be on the patent-holder to explain why the application of a computer to this problem is so non-intuitive, so non-obvious, that someone familiar with the problem and computers would not think of letting a computer handle the chore. And "Because nobody's done it before." is not a valid response. Someone always has to be the first one to try to solve a problem. Counter-intuitively, the patent-holder should have to show that they were not the first, that doing this was so non-obvious that there's a large number of other people who knew what they were doing who tried this and could not figure it out. That the first person to try it immediately found this solution should be considered support for the idea that this was an obvious solution and thus not eligible for patent. That is, after all, almost the dictionary definition of "obvious": the first thing you think to try when faced with a problem?

Only a couple of conditions:

1. All government services must be accessible at no cost via a method which is guaranteed to be available to any person. IOW if landline phone service isn't required to be universal then all government offices must have in-person hours and be staffed at a level sufficient to get everyone who shows up on any given day served before the office closes, or all services must be available via mail (postage pre-paid). Online-only services are not allowed, since the government isn't guaranteeing that everyone will receive Internet access. Phone-only services are not allowed since the government isn't guaranteeing everyone will receive cel phone service. Online-only or phone-only would only be allowed if the government mandated that everyone would be able to receive either Internet access or cel-phone service regardless of location. Which the service providers won't go for, since their whole goal is to avoid being legally required to provide service in unprofitable areas.

2. Any person must be able to get basic (local calling and 911 service) phone service at any address, regardless of where that address is, upon request at no more than the previous cost of equivalent landline service. Whether it be via cel or VOIP, the service must be available. Note that this doesn't completely get around requirement #1, since the basic service isn't guaranteed to provide access to government numbers. To the extent that it does, it would satisfy #1.