Not a well-written article, but some good points. Concerns of mine:

* We /still/ don't know the contents of the telemetry Microsoft sends back; hubbub seems to have died down. Do we just not care?

* Undocumented APIs. Remember when MS had hidden or secret APIs used by, eg, Office, they were forced to document? Those days are back. Consider the APIs for the Acrylic UI, which is implemented in the WinAPI (not .Net) but is only accessible from .Net applications. That's tie-in making it attractive for devs to use only MS products for development, too.

* Incomplete. There are still settings not in the new Settings app that are found in the Control Panel. Counting from Windows 8 in 2012, that's over five years of incomplete settings.

* Buggy. Creator's Update introduced a bug loading DLLs that made thousands of apps slower to start, and made debugging them close to impossible - all because they changed the module loading code. It looks like they only tested with modules built by Visual Studio, not third party dev tools, and so broke debugging for those developers for... how long? Six months. It wasn't fixed until the Fall Update.

I could go on. The first two are the most important to me, and I believe should be to other developers too.

> We /still/ don't know the contents of the telemetry Microsoft sends back

Documentation site: https://docs.microsoft.com/en-us/windows/configuration/windo...

> Consider the APIs for the Acrylic UI, which is implemented in the WinAPI (not .Net) but is only accessible from .Net applications.

The Acrylic controls are XAML controls built on System.Composition [1] and Windows.UI.Composition [2] APIs. C++ (and any language that can compile to it) has access XAML and System.Composition just like .NET, it just needs to speak WinRT. C++/WinRT was just released in the Windows SDK which just uses "real" C++ headers and no language extensions to interface with WinRT. [3] That should make it even easier for other languages to explore how to support WinRT applications, which for the most part if a language can support COM it can figure out how to support WinRT.

Complaining that you need WinRT to access modern UI effects seems a bit like complaining you need DirectX to access modern GPUs and can't just brute force VGA bit buffer your games anymore.

(My only complaint with the Fluent UI APIs is there doesn't seem to be access from the HTML/JS side of the fence, given that's the important "third platform" after C++ and .NET. I'd like to see PWAs have the ability to use at least some of the Fluent and/or Acrylic effects, but I haven't seen a useful sample of that yet.)

[1] https://msdn.microsoft.com/en-us/library/jj126278.aspx [2] https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Composit... [3] https://msdn.microsoft.com/en-us/magazine/mt745094.aspx

Unfortunately, that reply reflects many of the problems I highlighted in my comment. You have missed the point.

I'm aware that Acrylic controls are XAML only. I'm referring, though, to the UI support itself: glass, blending, the small amount of noise added, etc. In Windows 10, glass is not supported any more - except it is, because it is used in Acrylic. How? Well, using the same APIs as glass in Win7, but with small tweaks that are undocumented. Some people including myself have attempted to reverse engineer some of the new flags that are required. It looks likely that Acrylica can be completed done in a plain old WinAPI app using glass and a Direct2D canvas - except that some of that is undocumented.

If I'm wrong here, and you can point me at non-.Net API documentation, please do.

> Complaining that you need WinRT to access modern UI effects seems a bit like complaining you need DirectX to access modern GPUs

That's not what I said.

You do not need WinRT to access modern UI effects, but Microsoft seem to be requiring to you to use WinRT to access modern UI effects. That is, requiring you to use their libraries, their development tools, and so forth. It is not open, and it is anti-competitive.

WinRT is that "small tweak" combination of Direct2D and "WinAPI". It's turtles all the way down, WinRT is the modern COM and modern WinAPI, the WinAPI is now WinRT. The documentation site I pointed to defaults to C# (.NET) but is the exact same site supporting C++ and there is a dropdown in the sidebar to switch between views.

The C++/WinRT library I linked to started outside of Microsoft (as "moderncpp"), was acquired, and is still open source. Microsoft isn't requiring their own development tools to build WinRT (there's also open source React Native off the top of my head), it's just that so far not a lot of non-Microsoft developments tools have targeted/needed to target WinRT to date.

They aren't requiring you to use their libraries, they are requiring you to use their modern API (WinRT).

> We /still/ don't know the contents of the telemetry Microsoft sends back; hubbub seems to have died down. Do we just not care?

Don't you think there are large numbers of security researchers out there just dying to make a name for themselves and to give "M$" a black eye? Unless you believe they're all asleep at the wheel, the only reasonable conclusion is that they've pored all over the Windows telemetry and found nothing worth remarking about.

(... just like the telemetry in every web site, mobile phone, and other apps that we consumers now have to put up with. Telemetry is the rule of the day now.)

It doesn't matter. If you have an OS that can update itself arbitrarily without your permission and you have a culture and legal agreements that allow uploading ambiguous amounts of data through telemetry systems, that OS is not a viable choice for anyone who takes security and privacy seriously and deals with potentially sensitive data. It's really as simple as that.

My businesses have legal obligations under things like data protection legislation (for handling personal data) and our contracts with clients, suppliers, etc. (for handling trade secrets and other commercially sensitive information, as well as compliance with industry rules in areas like payment processing). Hand-wavy arguments about how everyone is using telemetry now do not relieve us of those obligations.

That article doesn't even pass the standards of a college newspaper.

"Windows 10 is no more secure than Windows 7 — which is to say it is a profoundly insecure operating system. "

You are going to back up your statement with some proof, right?

"but just because Microsoft didn’t botch things as badly as Apple did doesn’t get it off the hook. I mean, what do you call it when Microsoft fixes security holes in Windows 10 that it doesn’t patch in Windows 7?"

Ah, so it's more secure than Windows 7, you mean? And maybe, Apple?

"I’m sticking with Windows 7 on my Windows machines, and I recommend you do too"

You still haven't told me why?

--- That said, I hate Windows 10 for one thing: its update process. I am one of those people who almost never shut down their machines, they are either on, or sleeping. That means, I leave my apps open, and I expect them open when I come back. If freakin' windows decided to reboot my computer without my permission, it means it will shut down my VMs dirty, and potentially cause me to lose data in some apps. By far, this is my biggest annoyance with Windows 10.

"Windows 10 is no more secure than Windows 7"

Two paragraphs later.

"what do you call it when Microsoft fixes security holes in Windows 10 that it doesn’t patch in Windows 7? I call it really, really stupid."

So Windows 7 has security holes that Windows 10 doesn't, but Windows 10 is no more secure than Windows 7. Right.

He is most likely saying that Windows 10 does not have a more significantly inherently secure design. That is, Win10 is not less likely to have security issues than Win7.

Whereas what you are pointing out is that when issues are found, they are left unfixed in one of those OSes. That's a different thing.

But Win10 _does_ have an inherently more secure design[1], so much so that sometimes you have to turn them off in order to install stuff like VMWare.

[1] https://docs.microsoft.com/en-us/windows/threat-protection/o...

Built-in anti-virus and Edge as the default instead of IE are pretty big improvements themselves, for the average user.

> So Windows 7 has security holes that Windows 10 doesn't, but Windows 10 is no more secure than Windows 7. Right.

Windows 7 was released in 2009 and has received free support for years. In contrast, when did Ubuntu 9.04 (also released in 2009) lose security backports?

Perhaps Ubuntu 9.04 isn't a "fair" comparison, since most Ubuntu releases aren't designed for long support and the community recognizes this fact. But even then, the Ubuntu 10.04 LTS release (long-time support) was in 2010, and its support ended in 2015.

The mindset of "blame Microsoft" is quite annoying, when every darn Linux user is basically subjected to the "forced upgrade cycle" way faster.

CentOS 5 was released in 2007 and had maintenance updates till march this year[0].

Nobody forces gnu/linux users to upgrade. I know of happy CentOS 4 users; atleast they have the source to their os.

You are only forced to upgrade if you want the latest features and support for security fixes.

Microsoft is getting "blame" because it leaves you with binaries and a broken upgrade path.

[0]: https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule

If you care about long support times, you'd use an "enterprise" distribution and get exactly the same support periods (about 10 years) as with Windows or Solaris. This is no coincidence.

'99 little bugs in the code, 99 littles bugs. Take one down, patch it around, 117 little bugs in the code'

i prefer Win10 over Win7, btw

If you want to stay on a prior product version, I see no reason why you should be prevented. But, to expect continued support and development for it? How much are you offering to pay for that? Is it a number that grows faster than the adoption rate of the new product shrinks the userbase supporting continued development of the old?

Ongoing support for software-based products is an area where I don't think we have good answers yet. On the one hand, it's unreasonable to expect indefinite support and continued development of a product when it's not generating additional revenue to pay for those activities. On the other hand, when it comes to security issues, usually we're not talking about continued development so much as fixing defects in the original product.

If you bought a car or a refrigerator and it was found within a reasonable period after the sale that the car would break down suddenly under certain conditions or the fridge wouldn't keep food inside chilled properly, you would expect the manufacturer or vendor to make the product good at their own expense or to compensate you in one way or another; indeed, at least for consumer products, the law in many places would require them to do so.

Software companies have been given a bye on this one for a long time, but partly because we've also had a culture where they fixed their mistakes voluntarily. If they're no longer willing to participate in that informal arrangement, maybe it's time for statutory rules about minimum support levels and standardised, transparent disclosure of how long something will or won't be supported for, how updates will be handled, data privacy and portability including after the end of the minimum support period, and so on.

If the machine is properly firewalled off, and only accessing the internet using apps which are up-to-date, I think the realistic risk is pretty minimal.

Ha ha ha we'll see how long he lasts on win7. MS will pull support.

I'm not a fan of regular win10 (using LTSB myself) but blogging about it isn't going to change anything. Windows 10 won.