Microsoft's head of marketing at the time posted about this on internal Yammer. He said there were two main reasons: first, "Windows 10" just did better in focus groups than Windows 9 or other alternatives; second, since the plan at the time was for all future changes to be delivered as updates rather than a newly branded Windows release†, it felt better to end on a round number.
† btw, what became Windows 11 started development as just another Windows 10 feature update, and what gets branded as a "new release" vs an "update" is mostly a marketing decision.
I'm not sure there's any crisply definable bright line separating them. Generally embrace/extend strategies do involve trying to make extensions that some people will consider valuable.
no, but they've introduced a bunch of versions of it under different names (WPF, Silverlight, Phone Silverlight, WinRT XAML, UWP), a few of which broke compatibility, so that's probably where you got that impression.
The meaningful difference is whether there are isolation and distribution/update mechanisms so that users can install and maintain apps with less risk and hassle. This doesn't have much to do with (in-app) UI per se, though.
These benchmark articles frustrate me because I rarely feel they tell me anything. What do the benchmarks actually measure? When one tested product benchmarks as better/worse than another, what specifically is happening to make it better or worse? I feel like a good technical reporter ought to be able to dig deeper, do some investigation and provide real insight.
the answer from "silverstorm" is correct. To elaborate a bit, if you add a feature or API to the underlying OS, but there's no corresponding browser feature that makes use of it, to someone who spends most of their time in a browser the OS feature may as well not exist. Microsoft's main reason for investing in IE has generally been to try to add to the perceived value of Windows by making new Windows features accessible through the browser and thereby more relevant to web-centric PC usage. Examples are taskbar integration in Win7, live tile support in Win8, the emphasis on hardware acceleration in IE9+ (which was designed to try to make the underlying Windows graphics system more relevant to web browsing), smooth touch panning/zooming in IE10+ (by being early adopters of the Windows DComp/DManip APIs), better font rendering on high-DPI displays via DWrite etc.
Note that if other browsers themselves adopt new Windows APIs in competitive response, that actually still benefits Microsoft because ultimately they don't care about the browser for its own sake, they care about increasing Windows API and feature usage across all browsers. But in practice competing browsers tend to be late adopters of new Windows stuff (e.g., even now nothing but IE supports DComp/DManip and Chrome is just very recently getting around to improving its Windows high-DPI and text rendering support), hence Microsoft funds IE.
even if you're "good at" hierarchical filesystems they have a few inherent problems:
1) there's overhead associated with coming up with a hierarchical file structure, keeping it updated whenever your problems or your understanding of them change, etc.
2) there's overhead associated with always remembering to put a file in the "right" place every time you save it, actually navigating there to save it, and then fishing it out of the "right" place every time you need a file (getting to a file with search can sometimes be faster than navigating to it even if you know exactly where it is)
3) there is no perfect hierarchical structure for information; there will always be situations where x/y makes as much sense as y/x and both are sometimes inconvenient
this is not to suggest that search, tags and other alternative mechanisms don't have their own problems.
certain core systems components are often developed by small teams or individuals even within large organizations. the .net GC was written/maintained by 1 dev for a long time (Patrick Dussud, later Maoni Stephens), the Windows thread scheduler was written and maintained by Dave Cutler over many releases, etc.
some development efforts are just really hard to scale out.
the ambiguity is that it's presented as something the host does in this particular instance, but the validity of the probability calculations depends on it being a protocol the host always follows (in particular, that the host will always reveal one of the goats not behind the contestant's first choice of doors).
thoughtlessness and callousness are far more common sources of evil than either incompetence or malice strictly defined. "People who don't care if I live or I die".
there is a separate, smaller "quality" team with a separate reporting hierarchy that is supposed to address this - that's where the reference to data scientists, etc. in the article comes from.
basically the idea is to split the SDET role into two - SE testing (closer to the code than SDETs used to be) and "quality" (further from the code than SDETs used to be). SDET testing, though not directly driven by the code structure, tended to be at a pretty low level driven by a detailed functional spec.
† btw, what became Windows 11 started development as just another Windows 10 feature update, and what gets branded as a "new release" vs an "update" is mostly a marketing decision.