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.

Except that, as these companies make abundantly clear when you're hired, you are not in an employment contract. You are an at-will employee who can leave at any time and who can be terminated at any time for any or no reason. Companies like that because it lets them just fire people whenever they want, and these agreements are simply to let the company have all the advantages of having at-will employees without having to suffer any of the consequences of having at-will employees.

Necessary to keep teams together? I don't think so. How about, maybe, paying well enough that people people aren't tempted to jump ship in the middle of a project? Or putting people under contract instead of having them be at-will employees? Sure you can't just fire them any time you want (unless you've got good cause, like failure to do their jobs), but you don't have to worry about losing them at any time either.

These hiring collusions aren't necessary to keep employees. They're only necessary to keep employees without the company doing anything to actually keep employees.

I do know that even as a non-disabled user, the behavior Peter describes as "per spec" (that is, mouse buttons are not keys for the purposes of releasing the sticky keys) is counter-intuitive since the modifier keys interact with mouse buttons the same way they do with non-modifier keys (ie. Control modifies selection with mouse clicks the same way it modifies selection with the keyboard). Given that normal interaction with both non-modifier keys and mouse buttons, I'd expect instructions about how modifier keys behave to also apply analogously when both non-modifier keys and mouse buttons (but not mouse movements) are involved. Either that or I would expect modifier keys to not interact with mouse clicks the same way they do with regular keys.

If the password was set by the system, either during a password reset or initial account creation, the first thing I do is change the password to a random one my password manager program's generated. Why were these accounts still using the system-created password? Also, the article seems to conflate two uses of the term "salt": the random nonce used to insure the stored hash value isn't the same for two different accounts that picked the same password, and the random string used in the plaintext of the initial password to avoid a trivially-guessable "password same as username"-type case. The two aren't at all the same.

The answer to why Netflix keeps DVDs around should be obvious if you take more than 10 seconds to think: Netflix wants to offer as many movies as they can to be as attractive to customers as possible, and the studios won't license most recent releases for streaming. As a second reason, there's probably customer demand: a significant number of customers may have bandwidth caps low enough, or connections slow/laggy enough, that streaming high-quality video isn't feasible.

Making the IMEI physically unalterable doesn't help. If you can re-flash the baseband and firmware, you can make it ignore the burned-in IMEI in favor of a programmable one stored in the phone's non-volatile memory.

Making a jammer, yes, but buying radio hardware isn't quite that simple. For anything operating in unlicensed or open-access spectrum (eg. CB radio), it's easy to buy hardware that won't exceed the allowable limitations. Buying gear that can transmit on any channel and/or at any power usually requires having your license recorded as part of the sale. No license = no gear.

As for the IMEI, as far as I know it's not used to authenticate to the cel network. That's done via the IMSI which is on the SIM. The IMEI's mostly used for locating hardware (eg. a lost/stolen phone). Authentication is done using a challenge/response system, and the key used to generate the response from the challenge is in secure storage in the SIM (can't be read short of direct physical access to the internals of the SIM). Unlike other systems, GSM treats the phone as just an interchangeable accessory, the subscriber identity and everything critical to network authentication is carried in the SIM. That's why I can pop the SIM out of one phone and pop it in another (or pop another carrier's SIM in my phone, if the phone isn't locked) and things Just Work.