GPSD has recently acquired some competition. In 2008 Iain Holmes began a project called Gypsy which intends to be a better GPS daemon. Holmes has written a citique titled Why Should You Use Gypsy over GPSD, to which this note is intended as a reply.

We'll start off by acknowledging that Holmes's critique raises one or two valid points. For the specific cases of interactive applications running on a Linux system, communicating via D-Bus signals makes sense. Holmes somehow misses the fact that GPSD has support for publishing fixes to D-Bus, and has for years. Nevertheless his idea of signaling applications on fix changes rather than requiring them to poll or use threading is clearly a sound one, and supporting the signal set he describes is going on GPSD's to-do list.

What of systems that don't have D-Bus, however? GPSD's mission is not confined to Linux desktops. We aim to be reliable GPS-handling infrastructure for the entire open-source community. This includes BSD machines and embedded deployments where D-Bus would be considered a frippery. The breadth of our mission should matter even to Linux users; it means the GPSD project is likely to outlast any individual, OS-specific component technology such as D-Bus.

Much of Holmes's other criticism seems misdirected to us, too concerned with how older versions (often much older — GPSD has a long history) used to behave, as opposed to what GPSD actually does now. Nor will we apologize for annotating the code so its correctness can be rigorously checked; we like our low defect rate, and we think our users do too.

But we think the most serious problem with Gypsy is that the designer is over-focused on how GPS information is delivered to applications, and is skating over the messy details of obtaining it from actual GPS devices. We are not surprised to find that Gypsy supports only NMEA devices and doesn't speak the native protocol of the chipset with 80% market share; dealing with the entire range of vendor GPS protocols (and autoconfiguring the service layer to do it) is a difficult job that took us years to get good at.

The odds that Holmes or anyone else could get ahead of GPSD on this learning curve are, frankly, minuscule. And the odds of anyone duplicating the infrastructure of regression tests, simulators, and other tools that we use to verify GPSD's behavior against that large range of devices and protocol types are even lower.

GPSD's principal developers (ESR and ckuethe, especially) enjoy focusing on the GPS and systems-architecture end of the problem. If Iain Holmes had ever shown up on our project list and said "I've got a better idea about reporting to Linux apps than libgps", our reaction would have been to cheer him and say "Go to it!".

In summary, we think that the improved D-Bus interface of libgypsy is a good idea, and we are open to adding those signals to our D-Bus support. But we also think the Gypsy daemon itself is pretty much doomed to remain an inadequate and shaky imitation of what GPSD does right. Finally we think that, given a choice, we'd prefer to cooperate with the author of libgypsy than fight with him over Gypsy.