The problem is that if you do this, you remove all your slack. If you cut it to just enough people to do the work if they work 100% of the time, the first time someone calls in sick you don't have enough people to do the work. If you get a sudden spike in business because of a holiday or special, you don't have enough people to handle the extra work. If something goes wrong, you don't have anybody to assign to handle it without leaving you short-handed. And that's before you even get to the need for workers to take breaks during the day to avoid burning out.
It's the same problem that's plagued just-in-time delivery of inventory. Sure it saves money to have stock and raw materials delivered just as they're needed. But the moment a storm or a port strike or anything delays deliveries, you're in a world of hurt because you don't have any inventory on hand to tide you over. Sure it's saved you money, but it's made your business much more fragile and the costs of even one shut-down can easily eat up any savings.
Technically they didn't leak private files, because the files weren't ever private. They were public with the URLs not published in an index anywhere, so you had to know the URL to access them. Dropbox and Box simply forgot that those URLs would appear in HTTP Referer headers, exposing them in the logs of any site linked to from within those "private" documents. Security by obscurity... isn't.
A document isn't private unless it requires at least some kind of authentication to access it, eg. setting up HTTP authentication, or using a system like Google Drive uses where you have to be logged in on your Google account to see documents shared with you.
I've had good luck with an Ion cassette-to-USB deck for ripping an old tape collection to digital on the computer. They've got a VHS-to-USB one as well: http://www.ionaudio.com/products/details/vcr-2-pc.
Any standard that's effective and easy to use will not be accepted by the advertising industry, so making the "success" of a standard contingent on that last is nonsense. The DNT standard does serve one useful purpose whether or not it's accepted: it provides a single, easy-to-interpret, unambiguous indication to advertisers as to whether or not the user has consented to tracking. It removes their ability to say "Well, they didn't say otherwise so we assumed they're OK with it.". It does that whether or not they honor it, and it gives us a good talking point when it comes to policy and regulatory discussions: "The DNT standard exists. It's in use. It's easy to interpret on their side. They're the only ones sticking their fingers in their ears going "Na Na Na Can't hear you!".". That makes regulation an easier sell.
There's a simple app to eliminate cel phone use while driving. It comes standard on every model of cel phone I know of, requires no sign-up and has a dead-simple user interface.
I think the fact that it's an American company being ordered to produce the data factors in here. The judge does have jurisdiction over the company, which makes it a different situation from ordering a company in another country to turn over data stored there. If you want to get out of a country's legal jurisdiction, you need to be out of their jurisdiction.
The problem is that you run into situations like one I ran into during the last security evaluation:
An e-mail from the company's HR e-mail address says that I need to click on a link within the e-mail to view information from HR that I'm required to review and respond to.
An e-mail from the company's HR e-mail address says that I need to click on a link within the e-mail to view information from HR that I'm required to review and respond to.
One of those is a legitimate message from an executive and failure to follow it's instructions will result in possible termination. The other is a fake from IT Security. I have described all significant differences in the messages. Now, tell me which one is which?
The above, in a nutshell, is the problem with most attempts to enforce security policy: the people making policy in the company ignore the security policies when deciding how to do things.
First off, stop worrying about passwords. Most malware doesn't get into systems by way of an attacker cracking passwords. It comes in in ways that bypass passwords entirely, either by getting a user to run it or by getting the user to give the attacker their password.
Second, look at your management culture. Do you expect your employees to routinely click on links in e-mail? Look for things like HR or IT sending e-mails that instruct people to follow links they've provided, or "secure" or "encrypted" e-mail systems that store the messages on Web servers and expect your employees to use a link to get at the contents of the "secure" or "encrypted" message. If you find such things, realize that you're training your employees to be insecure, because you're training them to expect to do as a normal part of their job exactly what the malware will need them to do to infect their systems. Start by removing such things from your management culture. If you need encrypted e-mail, do it within your own e-mail system so that users never need to follow links to read encrypted or secured e-mail. Outlook and Exchange offer this directly. If you need to give employees links to internal web applications or documents, create a Web page or site with a directory of links and train your employees to use a bookmark in their browser to access that site and navigate to the appropriate section where you'll put all the new links they need.
Third, look at your IT policies. Not the ones you wrote, the ones you expect employees to follow. If your policy manuals say "No user-installed software." but your actual policies require users to get and install software from outside, you have a problem. It can be as innocuous as sending zipped archives while not having a program to handle them pre-installed on user computers. It can be as pervasive as not having your IT able to support the myriad of tools your developers need, most of which will by definition not be the kind of thing most desktops would need. But every time you have a situation where what you expect of your employees requires software you didn't pre-install on their systems and where it'd negatively impact an employee's job performance and more importantly their performance evaluations if they refused to install that needed software themselves, you're creating security problems. Sit down and decide how you're going to address this, then address it. It can be as simple as a page of "approved" links to sites you know are safe and where employees can get all that useful software that gets used every day.
Fourth, evaluate your software update policies and IT budget and staffing. If your IT department doesn't have the staff or the budget to monitor the vendors of all the software in use in your organization, test changes and push updates out to your desktops and servers, you need to re-evaluate your IT budget and staffing levels. You need to get most updates installed within 30 days of their release, and you need to be able to get major critical security updates analyzed, tested and deployed within 24 hours. Your IT staff can't do that if security updates are a side item they're expected to handle in between doing everything else. If management wants security to be a priority, they need to back up their words with the resources and budget departments need to make it a priority.
Yes, a lot of that comes back to management. Attitudes towards security come from the top. More importantly, they come from what those at the top do and expect rather than from what they say.
I'm minded though of a saying: "The superior pilot uses his superior piloting judgement to avoid needing to demonstrate his superior piloting skill.". The study tends to bear that out too, as they comment that the decline disappears when you look only at the end results (the score). And in the end, if you're better at juggling dozens of things at once and react faster than your opponent and consistently lose to him, you're consistently losing to him.
That, though, is talking about the development environment itself. Yes, there the developers should be in control of the machines. DevOps, though, is about having developers actually doing operations tasks in the production environment. That's a bad thing, because what developers are good at is very very bad in production. You don't want developers alpha-testing code and fixes where a failed test brings all of your customers to a screeching halt while the developer does a few more iterations to get his fix working right. Plus, frankly most of Operations is boring and tedious (or at least it should be) and as a developer I have little or no interest in making it my day job. I want to solve the problem of making the deployment scripts bulletproof and go on to the next problem, not spend my day watching instances spin down and up (because if I did my job right, that's all the Ops people are going to need to do).
The difference is between developers knowing the operations side and being the operations side. Developers need to know the operations side to know how to write software that Ops can install and manage. And they should be involved in the development environment and installation in the testing environment so any gotchas can be addressed quickly and the developers know exactly what happened and can go back and make sure it doesn't happen again (especially in production). And of course when things really go pear-shaped during production deployments it never hurts to have the developers on tap to tell Ops whether there's a simple, quick workaround that'll salvage the deployment or whether it's time to roll back until they can fix the problem. But those are a far cry from developers doing Operations support and administration work on a daily basis. Frankly they're two radically different skill-sets. They're related, sure, but having a developer doing Ops as a regular job is like having Kelly Johnson keeping a fleet of Piper Cubs in shape. Sure he can do it, and technically he can probably do it better than a regular mechanic, but in a month or so he'd be bored to tears and walking out to go work somewhere where they'd actually let him do his job designing and building planes like the SR-71.
This doesn't really change it, because think how a proprietary SSL library would've handled this. The vulnerability was found specifically because the source code was available and someone other than the owners went looking for problems. When was the last time you saw the source code for a piece of proprietary software available for anyone to look at? If it's available at all, it's under strict license terms that would've prevented anyone finding this vulnerability from saying anything to anyone about it. And the vendor, not wanting the PR problem that admitting to a problem would cause, would do exactly what they've done with so many other vulnerabilities in the past: sit on it and do nothing about it, to avoid giving anyone a hint that there's a problem. We'd still have been vulnerable, but we wouldn't know about it and wouldn't know we needed to do something to protect ourselves. Is that really more secure?
And if proprietary software is written so well that such vulnerabilities aren't as common, then why is it that the largest number of vulnerabilities are reported in proprietary software? And that despite more people being able to look for vulnerabilities in open-source software. In fact, being a professional software developer and knowing people working in the field, I'm fairly sure the average piece of proprietary software is of worse quality than the average open-source project. It's the inevitable effect of hiring the lowest-cost developers you can find combined with treating the fixing of bugs as a cost and prioritizing adding new features over fixing problems that nobody's complained about yet. And with nobody outside the company ever seeing the code, you're not going to be embarrassed or mocked for just how absolutely horrid that code is. The Daily WTF is based on reality, remember, and from personal experience I can tell you they aren't exaggerating. If anything, like Dilbert they're toning it down until it's semi-believable.
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.".
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.
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.
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.".
Slashdot Mirror
The problem is that if you do this, you remove all your slack. If you cut it to just enough people to do the work if they work 100% of the time, the first time someone calls in sick you don't have enough people to do the work. If you get a sudden spike in business because of a holiday or special, you don't have enough people to handle the extra work. If something goes wrong, you don't have anybody to assign to handle it without leaving you short-handed. And that's before you even get to the need for workers to take breaks during the day to avoid burning out.
It's the same problem that's plagued just-in-time delivery of inventory. Sure it saves money to have stock and raw materials delivered just as they're needed. But the moment a storm or a port strike or anything delays deliveries, you're in a world of hurt because you don't have any inventory on hand to tide you over. Sure it's saved you money, but it's made your business much more fragile and the costs of even one shut-down can easily eat up any savings.
Technically they didn't leak private files, because the files weren't ever private. They were public with the URLs not published in an index anywhere, so you had to know the URL to access them. Dropbox and Box simply forgot that those URLs would appear in HTTP Referer headers, exposing them in the logs of any site linked to from within those "private" documents. Security by obscurity... isn't.
A document isn't private unless it requires at least some kind of authentication to access it, eg. setting up HTTP authentication, or using a system like Google Drive uses where you have to be logged in on your Google account to see documents shared with you.
I've had good luck with an Ion cassette-to-USB deck for ripping an old tape collection to digital on the computer. They've got a VHS-to-USB one as well: http://www.ionaudio.com/products/details/vcr-2-pc.
Any standard that's effective and easy to use will not be accepted by the advertising industry, so making the "success" of a standard contingent on that last is nonsense. The DNT standard does serve one useful purpose whether or not it's accepted: it provides a single, easy-to-interpret, unambiguous indication to advertisers as to whether or not the user has consented to tracking. It removes their ability to say "Well, they didn't say otherwise so we assumed they're OK with it.". It does that whether or not they honor it, and it gives us a good talking point when it comes to policy and regulatory discussions: "The DNT standard exists. It's in use. It's easy to interpret on their side. They're the only ones sticking their fingers in their ears going "Na Na Na Can't hear you!".". That makes regulation an easier sell.
There's a simple app to eliminate cel phone use while driving. It comes standard on every model of cel phone I know of, requires no sign-up and has a dead-simple user interface.
The app? The "silent" mode.
I think the fact that it's an American company being ordered to produce the data factors in here. The judge does have jurisdiction over the company, which makes it a different situation from ordering a company in another country to turn over data stored there. If you want to get out of a country's legal jurisdiction, you need to be out of their jurisdiction.
The problem is that you run into situations like one I ran into during the last security evaluation:
One of those is a legitimate message from an executive and failure to follow it's instructions will result in possible termination. The other is a fake from IT Security. I have described all significant differences in the messages. Now, tell me which one is which?
The above, in a nutshell, is the problem with most attempts to enforce security policy: the people making policy in the company ignore the security policies when deciding how to do things.
First off, stop worrying about passwords. Most malware doesn't get into systems by way of an attacker cracking passwords. It comes in in ways that bypass passwords entirely, either by getting a user to run it or by getting the user to give the attacker their password.
Second, look at your management culture. Do you expect your employees to routinely click on links in e-mail? Look for things like HR or IT sending e-mails that instruct people to follow links they've provided, or "secure" or "encrypted" e-mail systems that store the messages on Web servers and expect your employees to use a link to get at the contents of the "secure" or "encrypted" message. If you find such things, realize that you're training your employees to be insecure, because you're training them to expect to do as a normal part of their job exactly what the malware will need them to do to infect their systems. Start by removing such things from your management culture. If you need encrypted e-mail, do it within your own e-mail system so that users never need to follow links to read encrypted or secured e-mail. Outlook and Exchange offer this directly. If you need to give employees links to internal web applications or documents, create a Web page or site with a directory of links and train your employees to use a bookmark in their browser to access that site and navigate to the appropriate section where you'll put all the new links they need.
Third, look at your IT policies. Not the ones you wrote, the ones you expect employees to follow. If your policy manuals say "No user-installed software." but your actual policies require users to get and install software from outside, you have a problem. It can be as innocuous as sending zipped archives while not having a program to handle them pre-installed on user computers. It can be as pervasive as not having your IT able to support the myriad of tools your developers need, most of which will by definition not be the kind of thing most desktops would need. But every time you have a situation where what you expect of your employees requires software you didn't pre-install on their systems and where it'd negatively impact an employee's job performance and more importantly their performance evaluations if they refused to install that needed software themselves, you're creating security problems. Sit down and decide how you're going to address this, then address it. It can be as simple as a page of "approved" links to sites you know are safe and where employees can get all that useful software that gets used every day.
Fourth, evaluate your software update policies and IT budget and staffing. If your IT department doesn't have the staff or the budget to monitor the vendors of all the software in use in your organization, test changes and push updates out to your desktops and servers, you need to re-evaluate your IT budget and staffing levels. You need to get most updates installed within 30 days of their release, and you need to be able to get major critical security updates analyzed, tested and deployed within 24 hours. Your IT staff can't do that if security updates are a side item they're expected to handle in between doing everything else. If management wants security to be a priority, they need to back up their words with the resources and budget departments need to make it a priority.
Yes, a lot of that comes back to management. Attitudes towards security come from the top. More importantly, they come from what those at the top do and expect rather than from what they say.
I'm minded though of a saying: "The superior pilot uses his superior piloting judgement to avoid needing to demonstrate his superior piloting skill.". The study tends to bear that out too, as they comment that the decline disappears when you look only at the end results (the score). And in the end, if you're better at juggling dozens of things at once and react faster than your opponent and consistently lose to him, you're consistently losing to him.
That, though, is talking about the development environment itself. Yes, there the developers should be in control of the machines. DevOps, though, is about having developers actually doing operations tasks in the production environment. That's a bad thing, because what developers are good at is very very bad in production. You don't want developers alpha-testing code and fixes where a failed test brings all of your customers to a screeching halt while the developer does a few more iterations to get his fix working right. Plus, frankly most of Operations is boring and tedious (or at least it should be) and as a developer I have little or no interest in making it my day job. I want to solve the problem of making the deployment scripts bulletproof and go on to the next problem, not spend my day watching instances spin down and up (because if I did my job right, that's all the Ops people are going to need to do).
The difference is between developers knowing the operations side and being the operations side. Developers need to know the operations side to know how to write software that Ops can install and manage. And they should be involved in the development environment and installation in the testing environment so any gotchas can be addressed quickly and the developers know exactly what happened and can go back and make sure it doesn't happen again (especially in production). And of course when things really go pear-shaped during production deployments it never hurts to have the developers on tap to tell Ops whether there's a simple, quick workaround that'll salvage the deployment or whether it's time to roll back until they can fix the problem. But those are a far cry from developers doing Operations support and administration work on a daily basis. Frankly they're two radically different skill-sets. They're related, sure, but having a developer doing Ops as a regular job is like having Kelly Johnson keeping a fleet of Piper Cubs in shape. Sure he can do it, and technically he can probably do it better than a regular mechanic, but in a month or so he'd be bored to tears and walking out to go work somewhere where they'd actually let him do his job designing and building planes like the SR-71.
This doesn't really change it, because think how a proprietary SSL library would've handled this. The vulnerability was found specifically because the source code was available and someone other than the owners went looking for problems. When was the last time you saw the source code for a piece of proprietary software available for anyone to look at? If it's available at all, it's under strict license terms that would've prevented anyone finding this vulnerability from saying anything to anyone about it. And the vendor, not wanting the PR problem that admitting to a problem would cause, would do exactly what they've done with so many other vulnerabilities in the past: sit on it and do nothing about it, to avoid giving anyone a hint that there's a problem. We'd still have been vulnerable, but we wouldn't know about it and wouldn't know we needed to do something to protect ourselves. Is that really more secure?
And if proprietary software is written so well that such vulnerabilities aren't as common, then why is it that the largest number of vulnerabilities are reported in proprietary software? And that despite more people being able to look for vulnerabilities in open-source software. In fact, being a professional software developer and knowing people working in the field, I'm fairly sure the average piece of proprietary software is of worse quality than the average open-source project. It's the inevitable effect of hiring the lowest-cost developers you can find combined with treating the fixing of bugs as a cost and prioritizing adding new features over fixing problems that nobody's complained about yet. And with nobody outside the company ever seeing the code, you're not going to be embarrassed or mocked for just how absolutely horrid that code is. The Daily WTF is based on reality, remember, and from personal experience I can tell you they aren't exaggerating. If anything, like Dilbert they're toning it down until it's semi-believable.
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.
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.
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.".