In this specific case we can split hairs, but in the end they are singling out genetics in a relatively large set of uncontrolled variables as the facet to focus on. Yes, like any good scientist the distinction is made, but pretending that aside from genetics a pair of fraternal and identical twins have *no other* fundamental different life experiences is a long shot that does strongly suggest the belief in a causative hypothesis and that they conducted this research with that assumption in mind. Identical twins raised together I suspect generally has more interesting distinguishing features than merely identical genetic reality compared to fraternal twins.

I personally suspect the hypothesis is true, that genetics plays a major role. However, *this* particular study is almost certainly full of non-genetic correlations that line up with the genetic correlations, making it difficult to say anything for sure on the genetic front versus another variation on the environmental front.

The problem is "all siblings presumably experience similar degrees of parental attentiveness, economic opportunity and so on" which is of course very unlikely to be a

I think the issue at hand is it isn't quite controlled well enough to trumpet the genetic component as *the* correlation of interest. Other factors are handwaved away by saying "all siblings presumably experience similar degrees of parental attentiveness, economic opportunity and so on". Anyone who has grown up alongside twins (there actually were a few sets of twins in my town growing up, two sets of them identical, one set mixed gender) knows this is too much to presume. When people look identical, there is a much stronger expectation that they *are* fundamentally identical. The identical twin sets both had rhymed names, but the other twins did not. Parents and teachers and fellow kids more naturally treat fraternal twins like any other set of siblings, but identical twins do not receive the same experience. People assume they like the same things, they should hang out together, they *should* be good at the same things. Many believe there is some mystical/telepathic link between identical twins. Fraternal twins are 'just siblings', to the extent that until explicitly mentioned no one may even realize they are *twins*. Identical twins are blatantly obvious from the moment you see them and trigger a large amount of preconception before anyone so much as utters a word. All these societal expectations undoubtedly have *some* impact on their development that shouldn't be so casually dismissed.

Basically, there is no reason to believe identical and fraternal twins receive a comparable life experience in aggregate when raised together. With that in mind, the study should be saying there is a correlation for identical versus fraternal twins rather than 'there is a correlation with genetics'.

If you are paying attention during boot, and the attack comes from within the OS. Of course, MS could have afforded the within the OS protection themselves by being very special in how they treated the system partition without requiring firmware to verify it. If you have full control of the console and/or device, you can do exactly what you describe, boot a valid OS using a malicious configuration designed to rootkit the OS that's there or impersonate the OS that was supposed to be there to gain information about accessing the presumably cloned disk.

Because it is actually pretty ineffectual against an adversary that physically controls your entire system or your disk contents, I think a different design would have been better. Secure boot is too open ended to afford sufficient protection and yet too much a pain by being not quite open ended enough to allow OS vendors without Microsoft blessing. I think Secure Boot should have been done by the key being installed to firmware at initial OS install time. The first OS install getting to 'take ownership' of the platform, and that key being *the* key to trust. This would have allowed Microsoft to put in a Microsoft key and say 'screw trying to certify things like grub'. Installing a different OS after a first would have required going into firmware to unclaim the platform to let the new bootloader claim it on the install of that system.

I'm actually ok with TPM and how things like Bitlocker leverage the TPM. The Secure Boot scheme reeks of too much inconvenience for inadequate security compared to what *could* have been done.

There's a few things that seem off in that statement...

IIRC, Secure Boot didn't actually hook into the TPM.

Another, I'm not sure what you imply with 'modify the TPM'. You can have perhaps the TPM bind some stuff that the legitimate user wouldn't want you to do but you couldn't defeat sealing to a sufficient set of PCRs by having os level control of the TPM facilities afaik.

Windows 8 Secure boot is a pretty flimsy facility that says 'yep, this code was blessed by microsoft'. It does nothing to vouch for whether the configuration leading up to or the configuration of the payload is what you actually want (e.g. a specific user expects they hve put in Windows 8, but instead Red Hat loading with malicious configuration would be a sort of misbehavior that SecureBoot does nothing for).

Of course, the proposed scheme isn't exactly nice. Notably handwaving about 'file is known safe'. In an open, diverse ecosystem this is highly impractical. SELinux errs on the side of letting some stuff slide and still gets enough false positives to frustrate a user trying to use some legitimate applications. These schemes start from a premise of 'if you know everything the system is ever supposed to do, then....' which is unlikely. Doing this from firmware to kernel may be feasible and a way to declare a 'known good state' to start some instrumentation in the common case, but going more into the wide open user space with overly specific restrictions and there will be difficulties. Maybe in some very specific special purpose applications, but in a general purpose system the universe of legitimate things to do is just not well defined enough.

Too early to try to measure 'success'.

So far there isn't anything particularly different about his time there as far as degree of success in the 'cloud' market. In terms of Azure, it's a tricky proposition for a company that is ostensibly a high-margin company. Going toe to toe with Amazon, a company that has repeatedly shown it is not shy about operating on margins so thin they are at high risk of actually operating at loss in a given quarter (I would say the same thing about IBM's foray into the space).

I suspect Windows is there to stay for the foreseeable future (it is about the only product they have with a pretty proven market acceptance that is also consistently profitable). Devices I think will go away, as it should. They let Google and Apple get ahead in the broad ecosystem strategy and the vertically integrated strategy respectively, leaving no room for MS really. MS has to figure out how to somehow undercut Android cost for partners or give up on owning the underlying platform. Either way making devices in house will not be winning them any favors, Apple has shown the most success and the most loyalty and yet their share still is going down in the face of the huge ecosystem of android vendors.

xBox would make more money as something sold to a third party, who probably would do better with it than microsoft has.

The investors might have made profit but the company itself is operating in the red. This just means the perceived value is higher than it was in 1998. Which makes sense, we are talking about a company that had 19 billion dollars flow through it in a quarter, which suggests a high likelihood they could be profitable at least for some time if they chose to.

Basically amazon has been saying they are investing and in the very long term the bets will pay off. AS it stands, amazon has not opted to proceed to '3) profit' and are firmly in the '2) ???' phase of their plan.

It remains to be seen how long their investments will pay off should they decide to back off. They have effectively been buying market share and for all the investors know, they have built no 'stickiness' and that share could evaporate the moment amazon decides it needs to be profitable and stops undercutting everyone else who needs to make a profit.

In my experience, that is the heart of what is wrong with a lot of software projects: it's considered taboo to do both architecting and developing.

The theory is obvious enough, but in practice an architect that is not implementing overlooks some very significant issues. The implementer has his hands tied because 'the architect said so' and the implementer trudges on also blindly unaware of anything beyond his little island.

The best teams I've been in have had everyone participate in architecting and development, with healthy amounts of communication.

The thing about construction projects is that they are simply so massive you need a horde of construction workers. In software development, we often like to *think* we are making something equally massive when in practice if we do need that many people working on it to get to the goal then it 99% of the time means we are doing something wrong in the first place. If we put hubris aside and realized that the scale isn't so grand as to require a trillion little dependencies and components, we produce good code. This doesn't mean the opposite situation of a gigantic monolithic blob is good, but there is a reasonable middle ground.

My point was that in MS world, you don't have a compiler until you get the SDK (which most people don't even know exists), and most think you only get a compiler through visual studio, whereas in linux it is commonly already there or a 'yum install gcc' or 'apt-get install gcc' away. A *whole* lot of people assume visual studio is a hard requirement to develop with microsoft first-party toolchain and as such you end up with project files for really stupid crap.

Yes, if a project gets to be large, then you need careful process. There are a few flaws though:
1. A large proportion of the time, you are doing something far less complex and/or dangerous than bridge building. There are people who insist that for something akin to 'hello world' test cases must be written, everyone must use a bloated IDE, all code must be in version control managed by some project hosting site with issue tracking, wiki, code review, and continuous integration. Sure, there can be value in that stuff, but there is cost. Frequently the cost outweighs the value for simple utilities (git and test cases are generally tolerable, but venture far into mandates about IDEs and project management and it can get nasty).. One example for me was for a quick 2 or 3 line C program people might fire up visual studio, and end up with a 'project' with a lot more metadata than the application itself, when using the microsoft SDK by itself with notepad would have been just as good (in linux the 'just run gcc' can be taken for granted, in MS you don't have a compiler and most laypersons don't even realize you can get SDK without visual studio, so I used that example since I see visual studio project files for the dumbest stuff).

2. A great deal of the tools are frankly half-assed. Particularly when it comes to deploying the tools. Once deployed they work about 80% of the time, but then fall over and block progress while someone figures out why the tooling fell over. A lot of these development tools got to the point where the authors of them could use it and that was about it. One who understands every nook and cranny and can quickly recover given a stack trace doesn't feel as strongly about doing the other '1%' of work to make it easy for others to deploy and administrate.

Actually, at least for a lot of Amish this isn't the case. For example, many Amish communities will have phones. They may relegate them to emergency and/or communal space use because they don't think it's good for private family time to be disrupted by a phone call. They reject grid power but do use batteries and generators. They use LED flashlights and buggy lights rather than burning lamps in many cases. They use cash registers, alarm clocks, and even power tools to some extent.

Sure, they are a lot more reluctant about technology and they believe a lot of family and social values are threatened by wanton use of technology, but they do partake of some key technology benefits.

It's not really 'credit' in that time frame. We are talking about simple price stability. Having 30 days to pay your metered electric bill is not really credit, it's just allowing for reasonable delay on the part of the billed individual for the logistics of allocated and spending money. post-paid metered stuff works like that all the time. If post-paid really bothers you, then wait until a product announce is willing to state MSRP in BTC.

I don't think anyone can claim that bitcoin cannot have inflation. It has hyperinflation and hyperdeflation in pretty frequent intervals.

They can claim that the inflation/deflation is not within the reach of government manipulation, but it definitely does happen in very chaotic unpredictable ways. One's tinfoil hat has to be on very tight to see that as an improvement.

That's a low bar to set. If you can get a price or invoice in BTC that gives you a month to pay it off, then I'll start considering it a viable 'currency'. Accepting bitcoin with just-in-time pricing is very low risk and it's cheap for a company to do that for publicity with no downside. A company need not believe in bitcoin in all to do it. A company believes in bitcoin if it will commit to a long term price for anything it supplies or purchases.

If 'at some point' is 'when tax laws and reporting make it most effective' it is a bit different than 'at some point' being seconds after the sale, with quotes longer than 15 minutes being considered invalid.

Notably dell will announce products with MSRP in dollars, euros, pounds, etc. They will not do the same in BTC, they will instead do a just-in-time quote that is invalid about as quickly as they can get away with. There is no even vague assumption about BTC value from one hour to the next, unlike the other currencies.