And I'm a security guy. If I don't care enough to update every day, what do other people do? (There's not much reason to keep a personal laptop up to date when you're not interesting enough to be targeted and not in the habit of running random internet programs. Or rather, a few months of lag is fine, as long as you're paying attention to what the updates are for.)

I think we just don't like to acknowledge the fact that updates sort of suck, yet we bash people and shame them for not doing them. I mean, we don't have many other tools to force them to update, but surprise surprise when people are just concealing the fact that they don't update at all. Even in corporate settings.

I'd be interested to hear a heavyweight enterprise sysadmin's take on this, but my experience and read is that it's "toss it at the wall and see what sticks".

Which is crazy when MS knows all of the following things: (a) which files the patch changes, (b) how it changes those files, (c) which programs a customer uses, & (d) which MS files get loaded by which customer programs.

In days where we can do ISA-to-ISA conversion on the fly, you'd think it wouldn't be rocket science to be able to say "Warning! This patch may effect operation of commonly used programs X, Y, and Z". Or at least have an admin tool to provide that information.

This is part of what I do. We do a risk assessment -- SMB and Kerberos get patched no matter what, everything else depends on a test cycle and may be deferred for up to 6 mo.

What? With the large monolithic patches that Microsoft has moved to, they have got worse, much worse, recently. It does make it easier to patch everything at once quickly, but if one thing goes wrong, you have to back it off and lose all protections.

But my point was more towards MS programatically alerting customers as to what programs and subsystems patches might effect.

As far as I've seen, they give you a file list, some brief notes on what the patch is for, and assurance that they internally QA'd it.

But I can't see why there's any technical reason that my system can't warn me that an MS library called into frequently by a particular program I use every day is modified in this patch.

Which is something I care about almost as much as "MS QA passed this patch" (side note: thanks so much to all the unloved, unknown internal QA folks out there, keeping things from breaking!).

The LTSB version is designed to essentially stay the same with regards to applications/apis/etc while still proffering up security updates as fast they have them.

http://windowsitpro.com/windows-10/understanding-long-term-s...

Not to mention that also afterwards there were Windows 7 patches that kept one CPU core 100% busy for days!

Windows 7 is the new holdout, and people aren't eager to swallow 10.

https://www.engadget.com/2017/05/15/pirated-windows-china-ru...

Except when you are "updated" from a full, paid version to a spyware/adware-ridden version.

Seriously: I think Windows 10 is great, technically and usability wise.

But MS need to learn that they can't have it both ways:

Paid xor ads. (I can think of two exception: inside the store app and inside settings for onedrive.)

There is no good reason to excuse Microsoft for maliciously disguising updates as security patches in order to manipulate the non tech-savvy into switching to their new unprecedentedly invasive OS. Especially when, as you said, the UI is worse.

The entire UX of Windows 10 is worse, every time I have to use it for something I get physical anxiety from claustrophobia.

I really don't like that I have to install untrusted 3rd party software on my computer in order to prevent my operating system from automatically ruining my user experience and spying on me.

Then, not having learned their lesson, they pulled similar crap with the Windows 7->Windows 8 transition which pissed people off so badly that they refused to go to Windows 10 and are currently suing Microsoft for attempting to shove it down people's throats.

Insecure old version of Windows are Microsoft's own damn fault.

Moving them out of the kernel is a great engineering decision, infinite backwards compatibility isn't feasible. Sometimes breaking changes are needed.

The idea of non-privileged drivers is neat, but in general is not worthwhile because the driver has to somehow access the hardware, which for significant amount of device/platform combinations leads to access to arbitrary memory locations.

Edit: perfect example are GPU drivers, which are for a long time typically composed of small priviledged kernel driver and all the complex logic in userspace. In many cases the interface between these two components could be abused to get code execution in kernel context (in 2k/xp times there was even RCE in kernel context triggered by displaying properly crafted image in IE)

This means you aren't preventing drivers from having full access. You just need to prevent more unintended side-effects.

Suddenly, people can run that business critical, single, old driver as unsafe while running the other drivers safely.

Alas, some manager at Microsoft decided it was more important to get his numbers up this quarter so he could get his bonus. In so doing, Microsoft orphaned a bunch of people on XP just like they orphaned a bunch of people on VB6.

Microsoft made its own bed; now it has to lie in it.

There are plenty of companies where "most of the time it's not broken" is a big problem. Possibly bigger than the cost of a security issue (I don't know, because this is both hypothetical and I'm an outsider to the issues at play).

To not acknowledge that others would value a different part of the risk curve lacks perspective.

With all due respect, if that's the case you should not be running Windows.

I can't buy an Emerson control system for a small reactor getting reconfigured every other week, and LabView on an un-networked Windows computer is perfectly fine.

I would not use a PC (with any OS) to control a 10 kg reactor though. At least directly. I think it'd be okay to use a PC to coordinate discrete controllers as long as they couldn't change state without a command (i.e. latching valves and the like) and as long as there was a backup safety that didn't have a computer in the loop.

Safeties that do things like shut off furnaces if temperature sensors break or valves that shut off flow if it becomes too high or detect a flame are common, analogous to a fuse on a circuit board. You sure hope not to use them, but they'll suffice for unexpected situations.

But there's definitely a risk that has to be managed, and connecting infrastructure and industrial equipment to the internet is not managing it very well!