How Windows turned months of inactivity into a 7-hour update hostage situation

Microsoft has a problem not entirely of its own making: The time it takes to bring a system back up to date after a few months of slumber. The company is keen to talk up how efficient it plans to make Windows. Not a day goes by without either a Microsoft representative or a fan insisting that Windows 11 is a lot snappier now than it used to be. (Usually they skirt the unfortunate truth that the Windows of yesteryear generally flies on modern hardware compared with the lumbering of today's software). Microsoft recently claimed that it is working to shrink Windows' footprint to the point where 8 GB would be enough to run things acceptably. We can only hope that one shard of light piercing the gloom of today's memory shortages and rising prices is that developers might prioritize efficient RAM use alongside slinging more ads or adding features few users require. However, this vulture's experience this week indicates that there is another area that needs addressing, and that is the number of updates slung out by vendors, and not just Microsoft. A few days ago, I wrote a story about a new way to skip the Microsoft account requirement during setup for the Home edition of Windows 11. At The Register, we like to test these claims thoroughly, so I fired up an x64 Windows laptop to check them out on real hardware, which is where the problems began. We've written before about the curse of updates, but this machine was running Windows 11 and had been up to date less than a year ago. How long could it take to get to the point where it would boot without Windows Update bleating about missed patches? The answer: about seven hours. Along with the huge array of updates for Windows components and the inevitable insistence that a new version of Microsoft's flagship operating system was needed, there were multiple firmware and driver updates and plenty of restarts. And, of course, there was the progress bar of lies and the percentage counter of deceit. In the decades since Microsoft first inflicted progress bars on Windows users, it has singularly failed to make them accurately reflect the, er, progress. "Yeah, so I'm going to stick at 65 percent for about an hour and then jump to 98 percent in 30 seconds before hanging there for another hour. Lol." That this behavior has endured for decades is beyond disappointing. Redmond is far from the only offender, but Windows' ubiquity makes it one of the most visible. To be clear, this was an ordinary Windows device, running a production version of the operating system. It just hadn't been turned on for a few months. The experience highlights a challenge Microsoft and its vendors must address. It's great that, at long last, people are considering code efficiency rather than simply flinging more hardware at badly written applications to make them run acceptably. But attention must also be paid to the constant flow of updates that seem to stem from an "ah well, we can always fix it in production" attitude that pervades the tech industry. Several years ago, the chief of a DevOps project was baffled when I asked him about testing and validation before release. Surely unit testing was sufficient? And the joy of modern development practices meant that if problems arose, an update could be swiftly rolled out. All of which assumes customers will tolerate continual updates, and a potential hours-long wait if, for some reason, they give it a few months between updates. The tech industry is waking up to the need for efficiencies, or at the very least Microsoft is. It also needs to deal with the scourge of update tsunamis. It's all well and good to brag about making your software run on limited resources until an interminable wait undermines the boast while the various widgets and components of a device insist on spending hours giving themselves a thorough update. Shaving a few seconds off the startup time means nothing if there are pages of updates awaiting the unwary. ®