From the gpsd homepage (<a href="https://gpsd.gitlab.io/gpsd/index.html" rel="nofollow">https://gpsd.gitlab.io/gpsd/index.html</a>): <i>“GPSD is everywhere in mobile embedded systems. It underlies the map service on Android phones. It's ubiquitous in drones, robot submarines, and driverless cars. It's increasingly common in recent generations of manned aircraft, marine navigation systems, and military vehicles.”</i><p>FTA: <i>“Will it be cherry-picked back to the 3.20, 3.21, and 3.22 branches?<p>gpsd does not have enough volunteers to maintain "branches". Some distros try to cherry pick, but usually make things worse.<p>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.”</i><p>So, it seems gpsd is like the tz database, a few volunteers maintaining an essential part of our software infrastructure.
I saw in another comment here by offmycloud [1] that this affects:<p>> 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."<p>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?<p>[1]: <a href="https://news.ycombinator.com/item?id=28045191" rel="nofollow">https://news.ycombinator.com/item?id=28045191</a>
Global warming is breaking our software.<p>From <a href="https://gitlab.com/gpsd/gpsd/-/issues/144#note_633612324" rel="nofollow">https://gitlab.com/gpsd/gpsd/-/issues/144#note_633612324</a><p>> 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.
Somewhat unrelated: Can someone explain the rationale for writing comparisons in the ordering they're using (e.g., 2180 < week)?<p>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.
I don’t understand if this is an actual bug.<p>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?
Why do people use gpsd instead of just reading $GPGLL or $GPRMC from /dev/ttyACM0 or /dev/ttyUSB0 or whatever, which always seemed far more reliable to me?
This brings back so many nightmares at my old job. These kind of things would creep up on us all that time and we'd spend a week or so scratching our heads in how the hell did our systems would travel time.
Note the heading is an error. In the comments of the bug
:<p>"Ooops, 16 Oct, 2021, was supposed to b 31 Dec 2022. My calendar error. That needs to be fixed."