So you install 186 updates on a fresh install. This includes .NET 4.5 (or 4.5.1 or 4.5.2), and requires a reboot.

  Now you're done right? You just installed 168 updates, how many updates can there be? On your next reboot, you get another 60 updates, of which 20 are .NET 4.5 updates and security updates. Another is the OS SP1, which needed a reboot before install.

  Now you're done right? You just installed 228 updates, how many updates can there be? On your next reboot, you have another 168 updates, most of which are patches for OS SP1. 

  Now you're done right? You just installed 396 updates, how many updates can there be? On your next reboot, you have another 12 updates, including...

I don't see why they cant 'look ahead' to say; Oh- this update X depends on update Y, but it's going to be installed, so we could just add it in the queue anyway.

On the other hand, with the current system people upgrade from Windows 1.0 to 8 (e.g. https://www.youtube.com/watch?v=8WP7AkJo3OE).

Thoroughly agree that a more simplified method would be awesome though.

No idea why Windows insists on installing individual updates before the Service Pack that includes them all anyways...

it's ugly as sin and requires many many reboots (and is slow as fuck) but at least it gets them all installed.

Every time I do Windows Updates, I need to reboot. This is highly annoying and IMO makes Windows Server YYYY completely unsuitable for servers.

Plus I can schedule this restart at any hour, on any day, I wish. And do. For example I restart mine on Thursday morning at 1 am.

If that really makes Windows Server "unsuitable for servers" then your downtime requirements must be so high that any single server wouldn't be able to meet them (i.e. even with Linux you'd need two or more servers to provide that level of uptime).

For the sake of this example, let's assume you have customers that depend on your server being up, for the product/service they're paying you for.

Tell the customers that you plan on rebooting once a month, and see how they feel about it.

Being in a situation where you're completely unable to restart a machine without losing money, is being in a situation where you're living on a knife edge regardless. A single hardware failure and you're in deep trouble.

I've been in exactly that situation (the entire company rested on a single Ubuntu server), it was really unpleasant and management didn't do a thing about it until we started getting sector errors which the RAID controller's error handling was struggling to cope with (after that incident and the downtime, management shelled out for four physical boxes, a SAN, VMWare licenses, and a setup with 15 minute rollbacks and dynamic migrations if a physical server died).

No, it isn't untenable, yes you can work around it, but that's a problem that shouldn't need to be worked around.

Maybe Linux doesn't need to restart the OS as often, but you're still going to have down time, right?

https://www.youtube.com/watch?v=p_vUZR2RtRs

https://www.youtube.com/watch?v=xkKoggifsE4

(And you don't need to log in for your background services to start.)

Worse, the conversation was actually about the time needed to install updates. Now that Windows logs out before installing updates, you have a fairly sizable time delay – tens of minutes after a large update even on an SSD – while the service is unavailable but before the system starts rebooting.

How does Fast Boot work? Well, it's actually not booting at all – it's logging out all active users and hibernating:

http://blogs.msdn.com/b/b8/archive/2011/09/08/delivering-fas...

That's a really nice bit of work in normal usage but it means that you have to do the standard cold boot process when you're getting a system update. That means that a sysadmin would need to review each update to know whether it would trigger a fast or slow boot, assuming that a patch for e.g. SQL Server wouldn't always trigger a cold boot to be conservative.

The alternative is what everyone's been saying, namely that you have to assume that a reboot is slow and have n > 1 servers if uptime matters.

However, if people are going to make irrelevant points about "not having downtime with Linux" then I am going to fuck with them.

BUT if Windows patches came out as often as CentOS patches do, I'd been rebooting every other day.

Look it up, it's awesome. (Please don't.)

In most Linux distributions, an update simply unzips a tarball somewhere and runs some bash scripts. Unless it's a very large package, each update usually only takes a fraction of a second on SSD, and maybe few seconds on HDD.

Windows, on the other hand, often takes minutes installing each update. Going from freshly-installed to fully-updated can easily take several hours, even on an i7 with SSD and a very fast connection (so the download speed is not a factor). It's even worse on an older computer; I've seen a smallish .NET update taking over 10 minutes to finish, and there were several such updates. What the hell is it doing behind the scenes that takes so much time?

This isn't going to happen. MS is tied deeply into restarting due to how it loads libraries and other issues. Unless they write a new OS from scratch and give up on legacy compatibility, well, don't hold your breath.

If the updater software could just plan out a patch-graph ("once I do X, then Y will be available, so I'll do Y, and that means Z will be available"), then apply all the updates it had recursively discovered and only restart at the very end, everyone would be happy.

Even though the resulting mechanism wouldn't be very similar at all to Linux's idempotent "just install the latest version of the package, you don't have to take the steps in-between" system, it's the UX that matters.

Shouldn't a real OS and filesystem be capable of removing something in use?

IRIX always could. So can Linux a whole lot of the time, if not all the time, as can BSD and Mac OS.

Here's something:

Once I upgraded a pile of IRIX boxes to a new version of some CAD software. A few of them had the older version running...

Didn't matter!

The files got cached, and those versions continued running the next day, until shut down. Next launch, the new version popped up.

One could just run a program, then delete the program right out from under the running process, and that process didn't know. IRIX just cached it all, and when the process was done, cleaned up the cache.

It's a choice. Windows specifically uses DLLs as non-dirty swap, i.e. if the memory manager want's to free up pages it may free memory pages used for mapping a least recently used DLL because it will not require it to write any "dirty" memory. A DLL page can never be dirty. Windows knows that it really easy to read in the image again (from the DLL) - so it can just kill the page and reuse it immediately. But then it has to know that it can get the exact same memory page back from the DLL. If the DLL has been deleted or changed that would lead to some strange errors.

When you install(1) a new version of a file, the old one is deleted and the new one written in its place. The file handle in existing processes continues to point to the original, and the filesystem will wait until everything's closed it before actually discarding the file data.

It's one reason I liked service packs, new service pack comes out, generate a new install image.

I currently have Jenkins build an OS image every two weeks, just so our Deployment Server has an up to date image.

Ya, lots of tools have made this easier recently, but thinking about it, doesn't WSUS handle this?

I haven't been a Windows admin for a while, but I thought with WSUS it was install, join and forget while it did it's thing. Maybe it's been too long ...

It's a GPO that points your domains to the WSUS server. And I've only used Octopus to automate WU installs.

New updates do supersede others though, if they're marked to do so from Microsoft. That should cover at least some of the .Net point release updates and the like.

It is the second Tuesday of the month, not every Tuesday. They've only broken that pattern a handful of times in the years that they have been doing it when an "emergency" patch was required.

>It is the second Tuesday of the month

that's exactly what "every patch tuesday" means (notice the "patch" adjective).

    Your mouse pointer has moved. 
    Please restart Windows for this change to take effect.

My usual workflow for setting up a Windows machine goes like this:

  1. Install Windows
  2. Download updates
  3. Reboot
  4. Download updates
  5. Reboot
  ...
  28. Download updates
  29. Reboot
  30. Download updates
  31. Reboot
  32. Install software

MS is rebuilding a lot of essential utilities in their "modern" app framework (including the start menu), but as far as I know, the lower level system updates still get distributed the same way as before, and frequently have long chains of prerequisites.