A bug fix bake-off

1 2 Page 2
Page 2 of 2


When it comes to the first phase an operating system update, determining what needs to be updated, there are clear winners and losers. iOS 9, OS X Yosemite and Chrome OS determine this very quickly. In contrast, Windows 7 and 8.1 are not only slow, they seem archiac.

While Windows 7 and 8.1 deal with individual operating system fixes, the other three systems only deal with groups of them, which makes it trivial to determine the needed updates. In part, they can get away with this because they support a much more limited range of hardware compared to Windows.

Windows is also dis-advantaged by the very nerds that handle its care and feeding. Windows 7 and 8.1 are updated on a fixed monthly schedule, a decision made for the convenience of Windows administrators. In contrast, Chrome OS and iOS are updated whenever Google and Apple think it is necessary.

I am not familiar with Apple's update schedule for OS X.

Windows loses points for complexity. It is the only system that differentiates "recommended" vs. "important" updates. No doubt, many Windows users don't understand the difference, which Microsoft exploited as part of their campaign to trick people into upgrading to Windows 10. And, if that weren't enough, there is yet another class of bug fixes, "optional".


With many devices, interrupting a software update ruins the thing, rendering it a paperweight. Windows 7 and 8.1 clearly warn you, both during the shutdown prior to installing bug fixes and the startup just afterwards, not to turn off the computer. None of the other systems issued a warning.

iOS 9 did, however, warn before installing updates that the battery was too low, which I take to mean that an interrupted software update would be very bad. If so, Apple should issue the same warning as Windows. Likewise, if an interrupted update would brick an OS X machine, it too should issue the same warning that Windows does.

It's hard to figure how Chrome OS would react to an interrupted update.

On the one hand, it seems an impossible situation, as there is no standalone, modal update process. The system updates itself as it's running, and, only when this process has completed, does it indicate that a restart will activate the updated software. I assume that Chrome OS does this by maintaining two copies of the operating system, which is the approach Google uses with the Chrome browser, which also updates itself as its running.

On the other hand, the procedure for dealing with a broken copy of Chrome OS does not involve rebooting from a previous copy of the system. Instead, a copy of the operating system can be downloaded on another machine to a bootable USB flash drive which is then used to install a fresh copy of Chrome OS. Go figure. 


Finally, there is the issue of software validation. That is, what does the operating system do to validate that the software it just downloaded is legit? Not only does it need to verify that the bits received are exactly the bits that were sent, but also that they were actually sent from the right place.

We have to assume that spy agencies have looked into attacking software updates. A computer that phones home for updates may get tricked into communicating with a spy agency computer rather than the home office.

Only Apple, Microsoft and Google know how much checking they do to insure the validity of downloaded software. Don't expect them to say much about it and be skeptical of anything they do say. Smartphones are even worse, as the phone companies are also involved.

The only system in my tests that said anything about verifying the downloaded software was iOS 9.

Linux users have no reason to gloat about this. According to a recent article, The sad state of Linux download security, it is the wild west when it comes to ISO downloads. 

Update: August 6, 2016. Just after this was published the article above about downloading Linux ISOs disappeared. For now at least, it is still available in the Google cache.

Update. August 14, 2016. There is no relief for Windows 7 users, installing the August bug fixes was still slow as heck. The first phase, where it determines which patches to install, took 1 hour and 42 minutes. It found 6 patches and, again, detected KB971033 as missing but opted not to install it. The patches were 69MB, and it took 6 minutes to download and install them. The mandatory reboot took a minute.
TOTAL TIME: 1 hour 49 minutes 

Copyright © 2016 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Download: EMM vendor comparison chart 2019
Shop Tech Products at Amazon