Developers should grossly outnumber operations. If it doesn't, your ops people probably aren't doing enough automation. Depending on how important that scalability and automation is, you might want more "devops" types in your operations team than other companies. Truly large tech companies call this SRE and don't have a traditional ops role at all. So I'd say having your three-way split would be OK for some companies, but a two-way split between non-ops developers and dev-ops operations works well for others. Really anything that minimizes the rigid wall between the two sides and gives each visibility and influence into the other is good.

I think the idea is to *find* good people that already have interests and skills that encompass the union of the two, and supplement the "good developers doing development" and "good operation guys doing operation stuff".

To be honest, I think a developer that has no interest in infrastructure is a developer that can't design a scalable, supportable service (you need to know how the infrastructure works in order to effectively use it). An ops person that has no interest in programming is an ops person that can't scalably support a service (who's going to build the automation and monitoring?). In my eyes a good balance is to have your "good developers doing development" supplemented with some "developers that know operations" to make sure they're designing things well. On the operations side, supplement "developers that know operations" with "operations people that know how to code" so they can work together to scale up automation, not staff, as a service grows. This is essentially how SRE works at many large tech companies.

For a better idea of why "reversible" matters, and experimental evidence suggesting that if you do reverse the effect of the interaction, you can restore quantum behavior, check out http://en.wikipedia.org/wiki/D....

You're misunderstanding the OP's point, I think. You and I don't think to ourselves, "let's store a history of our journey in our spin!" We just remember it. We perceive ourselves to be macroscopic classical systems. We have learned, however, that quantum effects can apply to macroscopic objects (as the OP points out, the C60 molecule most recently). Since your mind is simply a product of the arrangement of the molecules and energy in your brain, the implication is that while you would perceive yourself behaving classically (moving through one "slit"), if you were sufficiently isolated from outside observers to prevent decoherence, you would actually be behaving non-classically from their perspective. We just can't perceive that because decoherence is a local thing and our brains are a classical arrangement of matter.

Another way to think about it: decoherence is the process of the observer becoming entangled with the system being observed. Since perception is classical, a classical result is observed and the observer reacts accordingly. But if the system + local observer are isolated from a second observer, the pair are just another quantum system and decoherence occurs a second time when the second observer interrogates the first. Until the second decoherence happens, the observer is in a superposition of states--each state being a classical observer who has just observed different things, unaware of the other state.

Taking this back to the post the OP is responding to, "consciousness" doesn't matter. The nature of the "observer" doesn't matter. That it's even an observation is a concept we made up to relate our perception to the world we perceive. It's just fundamentally thermodynamic interaction.

I think for the most part you are right. However, if the customer knows he is exploiting an error on their web site to get a product at an unreasonably low price (bad faith), I believe the merchant would have grounds to contest the transaction and could be entitled to reverse it, even if it's completed and even if the customer has a receipt in hand. That being said, "Merchant Makes Error, Sues Customers" isn't a flattering headline.

He is still obligated to deliver them, at the price he charged

I don't believe this is true; the merchant can issue a refund pretty much at any time and cancel the deal. If the merchant was paid, but hasn't performed his obligation, he can't really be *compelled* to. That's essentially slavery. You always have the right to breach a contract. If the other party was harmed by your breach, they also have the right to sue you to get compensated for that harm. It's unlikely that the average person is going to be harmed much more than the money they sent the merchant, so a refund is entirely reasonable compensation.

That's not how I read it, but that would make more sense, I suppose. I'm thinking of situations where you have a multi-pronged attack, and one prong accesses one set of sensitive data, and the other prong accesses another. One access may be discovered, the clock starts, and 72 hours later they may not even be far enough into their forensics to find out about the other prong of the attack. But if you're defining each as its own "breach", even though it's part of the same larger complex attack, I suppose it's a little more reasonable than I interpret it.

But what if you're investigating something like this:

1. Breach of data A occurs
2. First breach of data B occurs (small set of data accessed)
3. Second breach of data B, by the same attacker from a different attack vector, occurs (accessing more data)

1 is discovered, clock starts, but you're able to get a full report out after 72h.
2 is discovered, separate clock starts, and you're able to get that report out after 72h.
3 is discovered. Should that have been part of (2)? What happens if you don't notice this during your investigation of (2)?

Your post suggests you've never done this before. Consider:

1. Spear phishing attack nets the credentials of employee A.
2. A's credentials are used to access sensitive data B. A normally has access to B so this doesn't set off any alarms.
3. A's credentials are used to plant malicious code on an internal web site.
4. Malicious code nets credentials of employee C and D and E (and a dozen others).
5. A separate attacker probes C's access, digs through source code repository.
6. Source code review yields an exploitable vulnerability in an internal system.
7. Staging from D's workstation, internal system F is cracked using discovered vulnerability. This gives them access to credentials that are trusted by system G.
8. Staging from E's workstation, sensitive system G is accessed using credentials stolen from F.
9. An administrator on G notices that something is amiss.

So now that you've discovered the breach, the clock starts.

10. G contacts E to ask what's going on, but E's at home asleep.
11. E's workstation is taken offline and forensics begins.
12. The credentials stolen from F are used on several systems because the developer re-used them, so it takes a while to figure out that F was where they were stolen from. The attackers covered their tracks, but a sharp-eyed engineer found access attempts in an unrelated daemon's logs from D.
13. D is contacted, and has no explanation. It's possible he would have accessed that system, but he can't remember. But your guys are smart, so you check his system for malware just in case.
14. Malware found on D. How did it get there? He exchanges software with a 3rd party all the time, so you spend some time scanning what he's downloaded, turning up nothing, so then you go through his e-mail, and find a short e-mail with a link from a colleague that seems out of place. The URL doesn't look suspicious (the vulnerability was removed by the attackers after it was used), so you set it aside.
15. You get stuck, so you go back to that e-mail again, one item of many presumed false leads, and realize that A didn't remember sending it.
16. Malware found on A, spear phishing e-mail found.
17. Logs of systems scoured for activity from A, sensitive access to B found.
18. A's outbound e-mail checked, e-mail to C (and dozens of others) found that looks similarly suspicious.
19. Logs of systems scoured for activity from C, accesses to source code repository found.
20. The dozens of others also affected are investigated to see what systems they accessed, just in case there's more.
21. What did you miss? Was there anything else? Keep looking. Are you sure that's it? Keep looking.

This is all "best-case" and you haven't even started trying to identify the attackers yet, much less assembling a report.

It's easy to play the armchair security consultant and talk about "proper log handling and log analysis" as though that's the magic bullet. Do you think that every company subject to this law has "proper log handling and log analysis" covering every component of every internal system on their network? Do you think even a majority of companies have this?

Do you think it's typical that every system in this chain of investigation will have all of the logs needed to proceed to the next step? Do you think those doing the investigations will always have easy access to these logs? That they will spot patterns that look like normal accesses but really came from an unauthorized attacker? Do you think they will even have access to the systems in question without having to track down an administrator?

There are companies that have the forethought (or experience) to make such a forensic exercise relatively fast and accurate, but these companies are the exception, not the rule, and even for those that have their shit together, investigations like this could take WEEKS to reach a meaningful conclusion about what data was compromised. You might know *something* after 72 hours, but in many cases this will be far from a "full report".

Do they really expect every massive, multi-part intrusion to be investigated to completion so that a full report can be made after only 72 hours? What am I missing?

Think this through, for a moment.

The advertiser and content provider are working together. The content provider wants ads on their site, and they want you to click on those ads, because the advertiser makes money, and shares that money with the content provider. The two parties have an incentive to cooperate. Both parties want those ads to be relevant to you, because that increases the chances you'll click on them.

Today, if you are known to the advertiser, but unknown to the content provider, you get shown relevant ads, but the content provider has no knowledge of who you are or what ads you were shown. This works because the content provider can embed content from the advertiser, and your browser identifies itself to the advertiser independently of the content provider by way of these cookies.

Without third-party cookies, advertisers and content providers are going to look for other ways to keep their ads relevant. The easiest way to do this is to work together to implement these as first-party cookies served by the content provider instead of the advertiser, and have the content provider share these identifiers with the advertiser, and be aware of the ads served to you. Do you think this is better or worse for privacy?

So I mostly agree with your sentiment, but the facts you're using to justify your sentiment are suspect.

Farmers aren't sued because their crops are tainted. Farmers are sued when they utilize the patented genes. If their crops are contaminated, but they don't actually change their approach to dealing with pests, or change how they harvest their crops, they aren't getting any of the benefit of the genes and so they aren't infringing on the patent and would prevail in a lawsuit.

You're probably alluding to the Schmeiser case here. The key thing to remember here is that Schmeiser (a) suspected that his crop was contaminated, (b) tested the contaminated plants to confirm his suspicions, (c) saved and isolated the seed in question, and (d) used that "contamination" seed to produce something like a thousand acres of crop. That was what got him in hot water, and that's why he lost against Monsanto. That wasn't about the contamination, it was about the exploitation of the (patented) traits of that crop.

GMOs aren't forced onto farmers. Farmers, at any time, can decide to buy "public domain" seed and produce non-GMO crops all they want. Seed from most every conceivable crop is banked and can be purchased trivially from universities and governments. Farmers choose GMO seed because GMO seed produces more profitable crops, either because the traits sell better in the market, or because the crops have higher yields. This isn't about GMOs and patents, except to the degree that these (superior) crops wouldn't exist but for the patents that allow companies to be profitable researching and producing them.

This has nothing whatsoever to do with Monsanto or GMOs. Glyphosate-resistant weeds exist because they evolved to exist, exactly the same way that antibiotic-resistant bacteria exists, and being a customer of Monsanto does not mean you don't have to deal with herbicide-resistant weeds. The problem is one of poor weed control practices by the farmers. If you kill all of your weeds, with a variety of herbicides, the problem doesn't exist. If you rely entirely on a single herbicide, and allow some of the weeds to survive, you end up breeding herbicide-resistant weeds. It doesn't matter if the herbicide is Glyphosate or something more typical.

There is a spectrum of competency among H1B workers just as there is among non-H1B workers. If you are a tech company trying to hire only the smartest candidates (without regard to H1B status), more H1B candidates means a larger pool of exceptional candidates. Don't think that a difference in "averages" says anything about people in the top percentiles.

This isn't necessarily representative of all companies trying to hire STEM people. I work at a large tech company and do a tremendous amount of interviewing. The problem is not finding people with STEM backgrounds, it's with finding good people with STEM backgrounds. While "good" is subjective, and the bar may be different for different companies, if my bar is set so high that I can't hire as many people as I want to, that's still a shortage in my opinion, and one that can be addressed by more STEM education and letting me hire more H1Bs. People can be cynical all they want about hiring cheap H1B workers, but you can't argue with the fact that allowing yourself access to more candidates means you can cherrypick more superstar workers.

Yes, this is absolutely the case. I do a lot of interviewing for a major tech company, and while there is no shortage at all of STEM candidates shoving resumes in our face, very few of them meet our (admittedly high) acceptance bar. So, for us, there is indeed a shortage of qualified workers. More/better STEM education would allow smarter people to enter the industry, as would allowing more H1B visas.

If someone with proven CEO skills has a choice between companies, they're probably going to choose the one willing to pay 400x, leaving the one paying 10x-20x to take a risk on someone unproven. Even if it works out, and the cheaper CEO turns out to know what they're doing, how long are they going to stick around and work for your "intelligent" shareholders when his resume now puts him in the same league as the 400x CEOs?

Lots of people seem to be missing the point here. It's easy to be cynical and point out that companies must be doing it so they can get away with paying less for desperate H1B workers. These people do not work for tech companies trying to hire good people. There is no shortage of candidates with STEM backgrounds and education, which is all this study seems to say. I have done literally hundreds of interviews at a large tech company for software/systems engineers, and meet an endless supply of STEM candidates all the time. The problem is that the vast majority of them do not meet our hiring bar. If you need to hire 100 software engineers, but can only 50 that meet the company's high hiring standards, that kind of sounds like a shortage to me. Sure, we can hire 50 mediocre software engineers to get to 100, but why would I want to do that? I'd much rather see better STEM education and H1B flexibility (in that order) so that I can fill those other 50 positions with good people.