HN user

bztzt

160 karma
Posts0
Comments112
View on HN
No posts found.

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.

eBPF on Windows 5 years ago

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.

On Rust and Nim 11 years ago

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).

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.

Windows Phone is some shared core components from Windows desktop (which RT is basically just an ARM build of) + its own stuff on top. The shared core has been growing with each release.

They had to block native code on WP7.x because they were on the CE kernel, knew they were going to move to the NT kernel in WP8, and native apps wouldn't have ported over.

Firefox Hello 11 years ago

imo the browser is just a better navigation model for a wide range of apps than typical OS GUI shells. so it's natural that either native apps get hosted in the browser (the plugin model) which has gone out of fashion, or APIs to do whatever an native app wants to do get added to the standard web API.

Win8 does implement fuzzy touch targeting (looking at the geometry of your entire finger contact region instead of a single point, and picking a best-match UI element) on the desktop. Office 2013 (desktop) also invested in a bunch of touch improvements. It hasn't been enough. (plus, they already tried this approach with touch on win7 and it didn't seem to be working - which, among other reasons, was why they changed tack for win8 in the first place.)

You're right that there's nothing inherent to the tablet form factor per se that makes it less vulnerable to malware. It's just that the different input mechanism and smaller screen size makes backward compatibility less useful, and it's easier for platforms (including Windows RT) to build security into their app models if they don't have to worry about compatibility.

Definitely agreed. Another interesting problem for the near? future is multi-device window management - can you use the collection of devices and screens (whether phone/tablet/desktop/whatever) on hand at a given moment as a kind of ad hoc multimonitor workstation? What about when multiple users are involved? (of course all of this is a systems/OS and privacy/security challenge, as well as an interaction design challenge)

I sometimes get the impression most people now think of window management as either a solved problem and/or one rendered irrelevant by the rise of "mobile", but it's quite the opposite IMO.