diff options
| author | Eric S. Raymond <esr@thyrsus.com> | 2009-12-04 08:17:12 +0000 |
|---|---|---|
| committer | Eric S. Raymond <esr@thyrsus.com> | 2009-12-04 08:17:12 +0000 |
| commit | 948df957b324f1ebfe49fa24eed48034569c94bf (patch) | |
| tree | f0e4f5f0392f90f8aaead8cc7ff868d043e44a8e /www | |
| parent | 6dfd528f4cedef57cb2122a7a90da5327ff8cfaa (diff) | |
| download | gpsd-948df957b324f1ebfe49fa24eed48034569c94bf.tar.gz | |
Add "GPSD and Code Excellence" essay to white papers.
Update the future roadmap (our schedule slipped by 5 days).
Update the TODO file with driver bugs we probably won't be
able to fix before 2.91.
Diffstat (limited to 'www')
| -rw-r--r-- | www/excellence.html | 246 | ||||
| -rw-r--r-- | www/future.html | 12 | ||||
| -rw-r--r-- | www/index.html.in | 6 |
3 files changed, 258 insertions, 6 deletions
diff --git a/www/excellence.html b/www/excellence.html new file mode 100644 index 00000000..f1bcfb9b --- /dev/null +++ b/www/excellence.html @@ -0,0 +1,246 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta name="Author" content="Eric S. Raymond"> + <meta name="Description" content="Essay for the Alliance for Code Excellence."> + <meta name="Keywords" content="GPS, translator, GIS"> + <link rel="stylesheet" href="main.css" type="text/css"/> + <title>GPSD and Code Excellence</title> +</head> +<body> + +<div id="Header"> +GPSD and Code Excellence +</div> + +<div id="Menu"> + <img src="gpsd-logo-small.png"/><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="hacking.html">Hacker's Guide</a><br/> + <a href="compatibility">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> </div> + + <a href='http://www.catb.org/hacker-emblem/'><img + src='http://www.catb.org/hacker-emblem/glider.png' + alt='hacker emblem' /></a><br /> + + <hr/> + <script type="text/javascript"><!-- + 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 type="text/javascript" + src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> + </script> + <hr/> + + <a href="http://validator.w3.org/check/referer"><img + src="http://www.w3.org/Icons/valid-xhtml10" + alt="Valid XHTML 1.0!" height="31" width="88" /></a> +</div> + +<div id="Content"> + +<p>There's a wonderfully tongue-in-cheek project called the +<a href="http://codeoffsets.com/">The Alliance for Code Excellence</a> +("Building a better tomorrow — one line of code at a time.") that +sells Bad Code Offset certificates. They fund open source projects to +produce good code that will, in theory, offset all the bad code out +there and mitigate the environmental harm it does. They've asked +software authors to write essays on how their projects drive out +bad code, offering $500 dollar prizes.</p> + +<p>I sat down to write an essay about GPSD in the same vein of high +drollery as the Alliance's site, then realized that <a +href="http://gpsd.berlios.de/">GPSD</a> actually has a serious case to +make. We really do drive out bad code, in both direct and indirect +ways, and we supply examples of good practice for emulation.</p> + +<p>GPSD is a service daemon and device multiplexer that is the +open-source world's basic piece of infrastructure for communicating +with GPS receivers, and it's everywhere Linux is - running on PCs, on +embedded systems, and on both OpenMoko and the entire line of Maemo +cellphones. We're directly relied on by dozens of applications, +including <a href="http://www.pygps.org">pyGPS</a>, <a +href="http://www.kismetwireless.net/">Kismet</a>, <a +href="http://www.gpsdrive.de/">GPSdrive</a>, <a +href="http://qpegps.sourceforge.net/">gpeGPS</a>, <a +href="http://www.gnustep.it/enrico/position/">position</a>, <a +href="http://roadmap.digitalomaha.net/index.html">roadmap</a>, <a +href="http://roadnav.sourceforge.net/">roadnav</a>, <a +href="http://www.navit-project.org/">navit</a>, <a +href="http://viking.sf.net">viking</a>, and <a +href="http://gaia.serezhkin.com/">gaia</a>. If you're doing anything +with GPSes on an open-source operating system, GPSD is your +indispensible tool.</p> + +<p>GPSD's quality is up to the standard required when you're that +ubiquitous. In March 2007 a <a href='http://coverity.com'>Coverity</a> +scan turned up only two errors in over 22,000 LLOC. In more detail: it +flagged only 4 potential problems, and two of those were false +positives. This is <a href='http://lwn.net/Articles/115530/'>three +orders of magnitude cleaner</a> than typical commercial software, and +about half the defect density of the Linux kernel itself at the +time.</p> + +<p>We get, on average, about one defect report every 90 days, and +there are just five on our tracker as I write. Given what we know +about the size of our userbase, our low rate of incoming bug reports +tells us we've maintained a similar level of code quality since the +Coverity audit. This hasn't happened by accident. Good practice +matters, and I'll describe how we systematize ours in a bit.</p> + +<p>First, though, I want to explain how we drive out bad code. The +reporting protocols used by GPS sensors are a <a +href="http://esr.ibiblio.org/?p=801">hideous mess</a> — the kind +of mess that tends to nucleate layers of bad code around it as +programmers with insufficient domain knowledge try to compensate for +the deficiencies at application level and wind up snarling themselves +up in ever-nastier hairballs. Part of what GPSD does is firewall all +this stuff away; we know everything about the mess so you don't have +to, and we present clean data on a well-known port in a +well-documented wire format. We then provide client-side service +libraries that will unpack GPS reports into native C, C++, Python, or +Perl structures so you don't even have to know about our wire +format.</p> + +<p>If our client applications had to deal with the back-end mess of +poorly-specified NMEA 0183 and seventeen different vendor-specific +binary protocols, I for dead certain <em>guarantee</em> that the total +community bug load from GPS-related problems would go up by an order +of magnitude. And I'd bet more than any of the $500 prizes the Alliance is +offering on the bug count going up by <em>two</em> orders of +magnitude.</p> + +<p>We also try to drive out bad code indirectly in the same way we +keep our defect level low — by providing an example of good +practice that extends all the way up from our development habits to +the zero-configuration design of the gpsd daemon.</p> + +<p>The most important thing we do to ensure code quality is maintain a +rigorous test suite. Our "make testregress" runs about fifty-five +regression and unit tests. Forty-four of those exercise the daemon's +logic for recognizing and processing device reports; the remaining ten +to a dozen exercise the rest of the code, all the way out to the +application service libraries.</p> + +<p>We actively collect device logs and metadata from users through <a +href="https://www.mainframe.cx/cgi-bin/gps_report.cgi">this form</a>, +which we use to update a device-capability database and our collection +of test logs. Almost every time a user fills out one of these, the +number of devices for which we can guarantee good performance in the +future goes up. Currently it's 87 devices from 39 vendors.</p> + +<p>We also routinely audit our code with <a +href="http://www.splint.org/">splint</a>. Not many people do this, +because splint is very finicky and a pain in the ass to use and +requires you to litter your code with cryptic annotations. But I +believe accepting that discipline is the main reason the Coverity scan +went so well. After hacking through the underbrush of false positives, +I generally find that splint heads off about two potentially serious +bugs per release cycle, averaging out to about one every 17 weeks.</p> + +<p>We have a policy of not using C where a scripting language will do. +Python is what we mostly use, but not the actual point here (though I +do like it a lot and use it in preference to other scripting languages). +The point is to get away from the fertile source of bugs that is +memory-management in a fixed-extent language. The core daemon is +written in C because it has to be; a significant part of our customer +base is embedded and SBC developers who need to run lean and mean. +But our test tools and some of our test clients are Python, and we're +gradually working to retire as much of the C as possible from outside +the daemon in favor of scripting languages.</p> + +<p>We have copious documentation, not just of the <a +href="libgps.html">interfaces to the code</a> and the <a +href="gpsd.html">wire protocol</a> but also to the internals and of +our project practices. We have a <a href="hacking.html">Hacker's +Guide</a> to the project philosophy, design, and code internals. We +have <a href="writing-a-driver.html">Notes on Writing a GPSD +Driver</a> by someone who did it. Because everything is documented, +the project doesn't forget things even if the individual members +do.</p> + +<p>No account of good practice can leave out the human element. In +the best open-source tradition, GPSD combines the benefits of a small, +highly capable core group (three developers: Chris Kuethe, Gary +Miller, and myself) with about a half dozen other semi-regular +contributors and a halo of casual contributors numbering in the +hundreds. GPSD teaches by example about the kinds of specialization +that produce good code. Here is what the core group looks like...</p> + +<p>Chris Kuethe is our GPS domain expert. He knows the devices, the +mathematics of geodisy, and where all the bodies are buried in this +application area to a nearly insane level of detail. I am the systems +architect — I neither match Chris's depth of domain knowledge +nor want to, but it's my been my role to give the GPSD codebase a +strong modular architecture, design and implement our test suites and +tools, design and implement our wire protocols, and push +autoconfiguration as far as it could go. Gary Miller is more of a +generalist who owns some particularly tricky areas of the core code +and device drivers, and is extremely good at detecting bad smells in +other code; he backstops Chris and myself admirably.</p> + +<p>If this sounds like a description of a classic "surgical team" +organization straight out of Fred Brooks, that's because it is. Open +source changes a lot of things, and the outer circle of contributors +brings huge value to the GPSD project — but some things about +software development never change, and the power of teams that include +a domain expert, a master architect, and a bogon detector is one of +them. GPSD reinforces a lesson that is old but never stale; if you +want the kind of good code that improves the whole software ecology +around it, that kind of human constellation is a great place to +start.</p> + +<p>Finally, we drive out a lot of potentially bad code by eliminating +configuration options. The <cite>gpsd</cite> daemon is designed to +autobaud and recognize GPS or AIS reporting packets on any serial or +USB device that it's handed, no questions asked. And normally, at +least on Linux systems, those devices are handed to it by udev when a +hotplug event fires. Though arranging this took a lot of work, there +are many fewer combinations of code paths in <cite>gpsd</cite> to test +(and to accumulate bugs) than there would be if the daemon had the +usual semi-infinite array of knobs, switches, and config files. +Because client applications don't have to give users any access to +those nonexistent knobs and switches, thousands of lines of +application code have never had to be written either; the simplifying +effects of autoconfiguration ripple through dozens of +application-development groups and all the way up the software stack +to the end-user.</p> + +<p>Finally, the RFP for these essays asked software authors to explain +what they'd do with a $500 prize. That's easy; we'd use it to <a +href="wishlist.html">buy test hardware</a>. Because GPSes are wacky, +idiosyncratic devices with poorly documented interfaces, testing on +real hardware is vital to fully learn their quirks.</p> + +</div> +<hr/> +<script language="JavaScript" src="datestamp.js" type='text/javascript'></script> +</body> +</html> +<!-- +Local Variables: +compile-command: "(scp excellence.html shell.berlios.de:/home/groups/gpsd/htdocs)" +End: +--> diff --git a/www/future.html b/www/future.html index 665e186e..c1625b90 100644 --- a/www/future.html +++ b/www/future.html @@ -75,24 +75,26 @@ poses some significant deployment challenges as well.</p> new protocol.</a>. Here is our tentative release schedule:</p> <dl> -<dt>2.40 — Before end of October</dt> +<dt>2.90 — 4 December</dt> <dd><p>New client API freezes. Wire protocol still considered unstable.</p></dd> -<dt>2.41 — Before end of 2009</dt> +<dt>2.91 — Before end of January 2010</dt> <dd><p>Wire protocol freezes (no incompatible changes going forward from this point). Old protocol support will be removed from the daemon, but not from the library.</p></dd> -<dt>2.42 — Jan-Feb 2010</dt> +<dt>2.92 — Jan-Feb 2010</dt> <dd><p>Cleanup release, if needed.</p></dd> -<dt>3.0 — Some time in the first quarter of 2010</dt> +<dt>3.0 — Some time in the first or second quarter of 2010</dt> <dd><p>Old protocol support will be removed from the library.</p></dd> </dl> +<p>For more on specific tasks planned, see our <a href="TDO">file</a>.</p> + <h2>Changing hosting sites</h2> -<p>We're presently (September 2009) hosted at <a +<p>We're presently (December 2009) hosted at <a href="http://developer.berlios.de">berlios.de</a>, but find that it has become extremely flaky of late (logins failing due to broken SSL certs is the most recent symptom). We plan to change sites before diff --git a/www/index.html.in b/www/index.html.in index 951d99d7..76146d28 100644 --- a/www/index.html.in +++ b/www/index.html.in @@ -214,7 +214,7 @@ features of the repository tip (development version) rather than the latest stable version.</p> <dl> -<dt><a href="gpsd.html">gpsd.1</a></dt> +<dt><a href="gpsd.html">gpsd.8</a></dt> <dd>The <code>gpsd</code> daemon.</dd> <dt><a href="xgps.html">gps.1</a></dt> @@ -324,6 +324,10 @@ design of <code>gpsd</code> and vendor claims about binary protocols.</dd> <dt><a href="writing-a-driver.html">Notes on Writing a GPSD Driver</a></dt> <dd>A guide for the perplexed by the author of the Jupiter-T driver.</dd> +<dt><a href="excellence.html">GPSD and Code Excellence</a></dt> +<dd>An essay written for the <a href="http://codeoffsets.com/">The +Alliance for Code Excellence</a> omn how GPSD drives out bad code.</dd> + </dl> <h1 id='recipes'>Recipes and related resources</h1> |