Someone on the gpsd-users list asked:
I was just wondering why gpsd doesn’t have a configuration file in /etc/gpsd.conf, like most other Unix/Linux software?
Because configuration files are evil, and not to be countenanced unless they become an absolutely necessary evil. Which in gpsd’s case is not yet, and I sincerely hope not ever.
Yes, I know this sounds like heresy coming from a Unix programmer. But the trouble with configuration files is that they too easily become an excuse for not doing the right thing. (The same is true of command-line switches; all of what I have to say here against config files applies to switches as well, which is why gpsd has so few of them.)
Can’t decide whether that new feature is a good idea or not? Create an option. Can’t settle a design issue? Create an option. Can’t be bothered to figure out how to autoconfigure your software properly? Create an option. Want to double your software’s test complexity? Create an option.
Lots of options and elaborate config files are sometimes necessary for Swiss-Army-knife-like system utilities; I implemented a boatload of them in fetchmail because I had to. But doing that made me unhappy and I junked a lot of delivery options when I figured out that forwarding fetched mail to SMTP was the right thing.
It’s better to design so you don’t need a configuration file. One of gpsd’s goals is to be zero-configuration; when it’s installed properly, you plug in a USB GPS and it just works. Nothing to tweak, nothing to configure, nothing you have to mess with.
While gpsd sometimes departs from this ideal, we treat those departures as bugs to be actually fixed rather than kluged around with an option. So the right question to ask youself is not “how might an option fix this?” but “how can we teach the program to figure out the right thing itself?”.