ademant
/
gpsd


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130
							<!DOCTYPE HTML>
<html lang="en">
<head lang="en">
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <meta name="Author" content="Eric S. Raymond">
   <meta name="Description" content="Evaluating the competition">
   <meta name="Keywords" content="GPS, gpsd, gypsy">
   <meta name="Revised" content="9 April 2015">
   <meta name="robots" content="index,follow">
   <title>Why You Should use GPSD over Gypsy</title>
   <link rel="stylesheet" href="main.css" type="text/css">
</head>
<body>

<div id="Header">Why You Should use GPSD over Gypsy</div>

<div id="Menu">
    <img src="gpsd-logo-small.png" alt="Small gpsd Logo" height="126"
    width="105"><br>
    <a href="index.html">Home</a><br>
    <a href="index.html#news">News</a><br>
    <a href="index.html#downloads">Downloads</a><br>
    <a href="index.html#mailing-lists">Mailing lists</a><br>
    <a href="index.html#documentation">Documentation</a><br>
    <a href="faq.html">FAQ</a><br>
    <a href="xgps-sample.html">Screenshots</a><br>
    <a href="index.html#recipes">Recipes</a><br>
    <a href="index.html#others">Other GPSDs</a><br>
    <a href="hardware.html">Hardware</a><br>
    <a href="for-vendors.html">For GPS Vendors</a><br>
    <a href="wishlist.html">Wish List</a><br>
    <a href="hall-of-shame.html">Hall of Shame</a><br>
    <a href="troubleshooting.html">Troubleshooting Guide</a><br>
    <a href="hacking.html">Hacker's Guide</a><br>
    <a href="protocol-transition.html">Application Compatibility</a>
    <a href="references.html">References</a><br>
    <a href="history.html">History</a><br>
    <a href="future.html">Future</a><br>

    <div>&nbsp;</div>

    <a href='http://www.catb.org/hacker-emblem/'><img
    src='glider.png' alt='hacker emblem' height="55" width="55"></a><br>

    <hr>
    <script><!--
    google_ad_client = "pub-1458586455084261";
    google_ad_width = 160;
    google_ad_height = 600;
    google_ad_format = "160x600_as";
    google_ad_type = "text";
    google_ad_channel = "";
    //--></script>
    <script src="https://pagead2.googlesyndication.com/pagead/show_ads.js">
    </script>
    <hr>

    <a href="https://validator.w3.org/check/referer"><img
          src="https://www.w3.org/Icons/valid-html401"
          alt="Valid HTML 4.01!" height="31" width="88"></a>
</div>
<div id="Content">

<p>GPSD has recently acquired some competition.  In 2008 Iain Holmes
began a project called <a
href="http://gypsy.freedesktop.org/wiki/">Gypsy</a> which intends to
be a better GPS daemon.  Holmes has written a citique titled <a
href="http://gypsy.freedesktop.org/why-not-gpsd.html">Why Should You
Use Gypsy over GPSD</a>, to which this note is intended as a
reply.</p>

<p>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.</p>

<p>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 <em>entire</em> 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.</p>

<p>Much of Holmes's other criticism seems misdirected to us, too
concerned with how older versions (often <em>much</em> older &mdash; 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.</p>

<p>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.</p>

<p>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.</p>

<p>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!".</p>

<p>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.</p>

<hr>
<script src="datestamp.js"></script>
</div>
</body>
</html>