Gpsd bug may create a 1024 week time warp on October 23
gitlab.com
gitlab.com
FTA: “Will it be cherry-picked back to the 3.20, 3.21, and 3.22 branches?
gpsd does not have enough volunteers to maintain "branches". Some distros try to cherry pick, but usually make things worse.
This bug was announced on gpsd-dev and gpsd-users email lists. So the packagers for several distros already saw it. What they do is what they do.”
So, it seems gpsd is like the tz database, a few volunteers maintaining an essential part of our software infrastructure.
More than that. Software is now running the economy, controlling safety and security of the physical world.
gpsd, like Tz database, cURL, SQLite and the Linux Kernel, should be seen as critical planetary infrastructure, period. Safety of our economy and our physical well-being increasingly depends on them being operational.
And yes, it's worrying that we ended up in a situation, where the building blocks of our technological society are maintained by underpaid volunteers.
Just update.
> Android phones and tablets. "In addition, the Android smartphone operating system (from version 4.0 onwards and possibly earlier; we don't know for sure when the change happened) uses GPSD to monitor the phone's on-board GPS, so every location-aware Android app is indirectly a GPSD client."
Can someone explain how the patch for this will reach all Android devices (especially the large number of devices running older versions of the OS and not getting any updates at all)? What exactly are the consequences for these users?
From https://gitlab.com/gpsd/gpsd/-/issues/144#note_633612324
> Until last year, leap seconds had been very predicable. The effect of global warming on earth rotational speeds was only very recently seen, or even predicted. But, yes, going forward, that needs to change.
My mind is blown.
I've seen similar before and always thought it seemed error-prone to not write them the way they'd be spoken aloud, but happy to entertain other explanations.
(Which means I rarely use > and >= operators. It's always < or <=.)
Now, come to think about it, this might have something to do with my native language (Japanese). In Japanese, where the verb always comes at the end of a sentence, you can say "a < b" and "b > a" using the same order and same adjective.
a < b ... a -than b -toward bigger (a よりも b のほうが 大きい)
b > a ... b -toward a -than bigger (b のほうが a よりも 大きい)The `if (0==x)` style also makes it obvious that the check is correct when reviewing/reading code. Sure, a linter might catch this. But this way the reader doesn't need to rely on that. Besides many codebases allow variable assignment as part of conditional/loop expressions, and sometimes sadly it's easier to write code this way than to get a team to use a linter.
Regarding it being unnatural... you get used to it, and especially in C one needs to take care to check the return code the right way (0!=, 0==, -1!=, 0<, !, etc.), whereas the other side of the check is often more straightforward (a function call, a variable etc.), so it's nice to have the constant up front. It takes very little extra space at the front. As a bonus all the constants will visually line up nicely that way.
This technique was invented back in the 1980s, back then compilers have no static analysis capabilities that we take for granted today. I think the reason of keep using it in 2020 is a matter of habit.
Less so for most comparisons, but for equality, it'll throw an error if you're using the wrong operator instead of having unintended side effects.
week = 2180 will set the week to 2180 in a lot of languages.
2180 = week will always throw an error.
So if I want to compare, it's safer to use the form of 2180 == week because if I forget the second '=', the compiler will tell me before I make bigger problems.
In both Rust and Swift, this mistake doesn't compile, their assignment operators don't have a result and so it can't very well be true (or false) ‡
‡ Technically the result of Rust's assignment operators is the empty tuple, which is the closest to "doesn't have a result" in the type system. I don't know about Swift.
When said out loud, "null is not val" just feels wrong.
Sure, we could just admit that assignments in conditions are a permanently stupid idea. Instead, an entire industry backwards the conditions wrote.
if (@() -eq $null) { 'true' }else { 'false' } # false
if (@() -ne $null) { 'true' }else { 'false' } # false
$v = $null, $null, 1
($v -eq $null) -and ($v -ne $null) # True
Interestingly, it seems like PowerShell's operator overload resolution in general depends entirely on the type of the LHS. I say 'seems' because I couldn't find any sort of language specification when I looked into it a while ago like what C# and VB.NET have, and testing seemed to confirm that this was the case. Now, searching the PowerShell Core source, it seems from [1] that this is indeed the implementation.
This contrasts with C# [2] and VB.NET [3], where binary operator overload resolution is treated as if the candidate operator implementations were a two-parameter method group, making the resolution process 'commutative' (though not always commutative in practice as the operators themselves can still have different LHS and RHS types {Edit: example from the CLR [4]: +(Point, Size) but not +(Size, Point)}).
[0] https://blog.iisreset.me/schrodingers-argumentlist/
[1] https://github.com/PowerShell/PowerShell/blob/master/src/Sys...
[2] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
[3] https://docs.microsoft.com/en-us/dotnet/visual-basic/referen...
[4] https://source.dot.net/#System.Drawing.Primitives/System/Dra...
https://en.wikipedia.org/wiki/Yoda_conditions
> it seemed error-prone to not write them the way they'd be spoken aloud
It is written the way it'd be spoken aloud. If you're not speaking it that way then you need to change the way you think. Programming is another language after all.
To you perhaps. To me, I think "if I put both sides on the number line, which way is being questioned? and is that question answered true or false?"
And therefore I almost always do an equals or less-than comparison because that's how I think about the number line: 0 in the center with negatives on the left and positives on the right.
So `if (week < 2048)` is just as valid and easy to think about as `if (!(2048 <= week))`. But then `if (!(2048 <= week))` provides an additional guarantee: that I won't accidentally assign to `week`.
I have heard that the timing on gps is somehow delivered as weeks and that the bitsize of the variable keeping track of the weeks is to small. So every now and then the weeks reset and this is managed through overrides in the clients. Is this bug not just referencing that thing, the override of the week rollover?
This code is using the number of leap seconds that have happened to sanity group of 1024 weeks we are in. The assumption is that by December of 2022, we would have another leap second, so if we had fewer than 19 total leap seconds, then something has gone wrong. However due to incorrect arithmetic, this sanity check is looking at October 2021.
Further comments point out that the sanity check need not be in production code at all, but should be moved to test code.
This happened before in 2003 during the previous long gap in leap seconds (1998-2005).
"In addition, the Android smartphone operating system (from version 4.0 onwards and possibly earlier; we don't know for sure when the change happened) uses GPSD to monitor the phone's on-board GPS, so every location-aware Android app is indirectly a GPSD client."
Also I've had gpsd think some other non-GPS serial device was GPS, took up the port, and I got frustrated at its incompetency and apt-get uninstalled it.
And can't multiple applications read a /dev/tty device read-only with just e.g. "cat /dev/ttyACM0"?
"Ooops, 16 Oct, 2021, was supposed to b 31 Dec 2022. My calendar error. That needs to be fixed."
In other words, the heading is correct.
I work in a business where we do use serial and network connected GPS devices as stratum 0 timesources for NTP, and yes we have concerns about the implications of this bug on some of our remote devices. If the gpsd starts sending incorrect time/date to the local ntpd it will probably be marked as a false ticker. We have multiple GPS based NTP servers in our datacenters as fallbacks, however we will probably need to check for a firmware update from them for this issue from the vendor.
Just to put things into perspective: The elevation of the land surface at the Earth's south pole is over 2800m above sea level. The highest point in greenland is over 3600m above sea level.
The IERS https://www.iers.org/ is in charge of monitoring the spinning of the Earth. On the basis of their assessment a decision is made every six months whether to inject (or indeed remove) a leap second.
If we decided not to match UTC to UT and thus we did not care precisely how quickly or slowly the Earth is spinning, we could abolish leap seconds.
If you meant, "Why can't we precisely predict the motions of a vast rock floating in space years into the future" then I don't know what to tell you. We're not God?
IMO this feels like the more interesting one to explore: are leap seconds wholly from things that are within measurement error in existing rotation, or is the Earth's rotational rate actually changing? If we had leap minutes as the smallest increment, could we predict them out centuries in advance? etc
Leap seconds account for the accumulated difference in the rotational period from time to time.
Turns out the rotation speed of Earth varies. Things like tides, earthquakes, and climate change can affect it. There is no formula for that, the only thing you can do is measure and issue a leap second when required.
> I don't think gpsd has any reason to be predicting when a future leap-second is going to occu
Until last year, leap seconds had been very predicable. The effect of global warming on earth rotational speeds was only very recently seen, or even predicted. But, yes, going forward, that needs to change.
> And the code in question is clearly expecting only positive leap-seconds.
Yes, because until 2020, the thought of a negative leap second was unthinkable. I would welcome you testing that and seeing what falls out.
Interestingly enough we're finding out that a lot of our solar cycles are probably due to massive things in very long orbits in our solar system.
I mean sure it would be annoying but its a one time change and our generation has to endure the pain of upgrading our systems, but it would be worth it no?
It looks like it you would need to change the Earth's rotational energy by ~1.4*10^22 J to change the length of a mean solar day by 1/365 seconds (which would cause UTC to change by 1 second per year). If energy costs 1 cent per kilowatt hour, this is only around $40 trillion, which is much less than I was expecting.
If energy becomes a few orders of magnitude cheaper and someone knows a reasonable mechanism to put that energy into the earth's rotation, Google or someone similar might find it easier to keep days at 86400 seconds than to deal with leap seconds.
(The joke is, if your business workflow is different to their software, it's the business model that has to be adjusted.)
It will drift slightly over the centuries. Is that a big deal compared to even the variation inside a time zone?
Of course, the 'correct' way to fix it would be to use TAI rather than UTC just about everywhere, but that change would be hard to implement compared to just not adding more leap seconds.
Sonuds like "make it a problem that will not happen in my life time".
Why do you believe that?
> Either put them in or don't.
Sure, if you have a time machine we can go tell them not to add leap seconds.
Google already don't. But I think they had to patch their kernels etc. to achieve that.
Leap seconds were a bad solution and we should remove them from general-purpose computer systems (some very specialised systems may need them). But it's a massive coordination problem and most people just don't care enough to change anything.