SoylentNews is people
SoylentNews
The convoluted method Microsoft used to fix the MS16-098 double-printing bug is a harbinger of screw-ups to come with the new all-or-nothing approach to patching
Microsoft finally acknowledged yesterday that it has fixed the bug that breaks certain kinds of print jobs. The problem was created by a security patch issued on Aug. 9, and in the intervening six weeks the company offered a rat's nest of partial fixes, preferential treatment, and botched communications that don't bode well for Windows 10 forced patching. It's also bad news for the anticipated October patchocalypse, when Windows 7 and 8.1 customers will start being treated to a new all-or-nothing approach to patching.
The double-print bug was distributed to every version of Windows. Those users who updated earlier versions of Windows (Vista, Windows 7, 8.1, RT 8.1, as well as Server 2008, 2008 R2, 2012, and 2012 R2) got bit by the patch known as KB 3177725. If those users wanted to get rid of the bug, they only had to uninstall KB 3177725. Of course, Microsoft has dire warnings about uninstalling security patches, but if you fell victim to this particular bug (as was the case if you use, among many, the Seagull Scientific bar-code printing package BarTender), you could back it out by uninstalling the faulty patch. When the patch went away, the bug did, too.
That's been pretty much standard procedure for a decade or two.
Windows 10 users weren't so lucky. With Windows updating-as-a-service, the only option for uninstalling the buggy patch was to unwind all of the Aug. 9 patches -- all of the security patches and all of the other patches -- then use wushowhide to hide the bad patch until a bug-free version rolled around. That's not an easy task.
And from http://www.infoworld.com/article/3122260/microsoft-windows/gwx-swept-away-as-pattern-emerges-in-windows-updates.html there is this snippet:
All of the patches are optional and will thus appear in Windows Update as unchecked -- except the time zone change. It still amazes me that Microsoft hasn't implemented a more elegant way to change time zones. Guess they've been too busy with GWX.
There's a pattern emerging ... a harbinger, if you will. KB 3185278 and KB 3185279 -- the two September update rollups -- follow the pattern that I expect we'll see starting in October. Microsoft has released the September update rollups this month as Optional/unchecked, so they won't be automatically installed. My guess is we'll see those patches changed to Recommended in October.
-- submitted from IRC
(Score: 2) by bob_super on Monday September 26 2016, @09:15PM
> That also means, strictly speaking, UNIX time is not the number of milliseconds since 1970-01-01 00:00 UTC,
> but rather the number of seconds since 1970-01-01 00:26 UTC, because UTC does account for leap seconds.
Also, strictly speaking. incorrect, because until 1972, the UTC second did not match the TAI second. You really need to count starting in 1972 if you want precise UTC timing, because any UTC time before that will be wrong.