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: 1, Disagree) by Anonymous Coward on Monday September 26 2016, @03:00PM
Ignoring all the complaints that Microsoft deserves for patching, this confuses me
"except the time zone change. It still amazes me that Microsoft hasn't implemented a more elegant way to change time zones."
Is he implying that this patch is for allowing you to change the timezone of your local system? I thought those time zone change updates were to take into account the changing timezones and DST changes around the world (these change all too often), and other things that are unanticipated like leap seconds. These types of patches are common in any OS and have nothing to do with enabling you to change your computer's timezone.
(Score: 3, Insightful) by kazzie on Monday September 26 2016, @03:37PM
I would assume that there's some countries somewhere that have changed their daylight savings rules or swapped time zones, and this information is in the update.
(Score: 2, Informative) by kurenai.tsubasa on Monday September 26 2016, @03:44PM
I read something a bit different into that, but perhaps that's just because the way Windows handles time zones is a pet peeve for me. It's not the most retarded implementation of time zones I've come across, but I find it lacking. By and far the Olson/tz database and the number of milliseconds (or whatever precision you want) from an epoch is the way to go.
The trouble is when we fall back, and springing forward is also risky. If we're falling back, we experience 1 am twice on that date. The only way to pinpoint a specific moment is to know whether it was DST or not, which means one is stuck also storing the timezone such as EDT/EST. When we spring forward, any time during 2 am is not a valid time at all—it simply doesn't exist in the chronology.
Yes, we do need to make sure we keep the local copy of the Olson/tz database up to date due to constant changes, but because we're using the number of milliseconds since 1970-01-01 0:00, we don't have any ambiguous times due to falling back nor any invalid times due to springing forward. We simply ask the datetime library what the time and timezone was so many milliseconds since the epoch, and we can deterministically wind up with whether it was EDT/EST or if you're in Indiana even depending where even CDT/CST/EST.
Additionally this makes handling time in Arizona and Hawaii where DST is not observed a breeze on a system that happens to be in some other timezone. Think of the havoc data that was recorded on a system with obsolete zone definitions using the store the milliseconds and whether DST was in effect or not can cause. Not that it can't be corrected after the fact, but that's too much like work.
I mean, sure, for 99.9% of programs Windows datetime facilities are sufficient. It gets hairy when dealing data spanning decades that could be in multiple different changing timezones. Correctly handling times is hard [infiniteundo.com]. My preferred library is JodaTime [joda.org], which uses the Olson/tz database.
(Score: 3, Interesting) by darkfeline on Monday September 26 2016, @04:56PM
>because we're using the number of milliseconds since 1970-01-01 0:00, we don't have any ambiguous times due to falling back nor any invalid times due to springing forward.
Nope! Haha!
Do you know about leap seconds? They aren't accounted for in UNIX time at all, which means that we do have quite a few invalid times in UNIX time. Thankfully, we've only been adding leap seconds so far and not removing them, so we won't have any ambiguous times.
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.
Kids, don't do time arithmetic at home.
Join the SDF Public Access UNIX System today!
(Score: 2, Interesting) by kurenai.tsubasa on Monday September 26 2016, @05:29PM
You're right. Wrong unit. My bad. I think I had a system whose epoch is 1899-12-31 0:00 of all things and uses milliseconds confused with Unix time. No leap seconds there either.
(I have no idea what the logic behind choosing midnight on the last day of 1899 could be, but like I wrote, there are worse systems than Windows. That one in particular suffers from a chronic case of NIH syndrome on the part of the vendor.)
Leap seconds are included in the Olson/tz database, but I haven't worked with an application like communicating with GPS where leap seconds matter. At any rate, further [wikipedia.org] reading [wikipedia.org] for the peanut gallery. Time is hard!
(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.
(Score: 2) by captain normal on Monday September 26 2016, @05:42PM
The time zone update is for a small province in Central Russia that until July 24, 2016 had it's on little time zone. Now it's been shoved into the Krasnoyarsk Time Zone. Why this is a big deal in my computers in California is a mystery to me. I cannot image any circumstance that would have me visit Novosibirsk Oblast.
Instead of wasting so much time and energy on stuff like this, maybe MS should be cleaning up their messy OS.
Everyone is entitled to his own opinion, but not to his own facts"- --Daniel Patrick Moynihan--
(Score: 0) by Anonymous Coward on Tuesday September 27 2016, @09:07PM
They have, it's called Windows NT (New Technology).