anchor.diff:  $ go-camo -k "somekey"
   ----
   
  -Go-Camo does not daemonize on its own. For production usage, it is recommended to launch in a process supervisor, and drop privileges as appropriate.
  -
  -Examples of supervisors include: {link-damontools}, {link-runit}, {link-upstart}, {link-launchd}, {link-systemd}, and many more.
  +Go-Camo does not daemonize on its own.
  +For production usage,
  +it is recommended to launch in a process supervisor,
  +and drop privileges as appropriate.
  +
  +Examples of supervisors include:
  +{link-damontools}, {link-runit}, {link-upstart},
  +{link-launchd}, {link-systemd},
  +and many more.
   
   For the reasoning behind lack of daemonization, see {link-daemontools-why}.
   In addition, the code is much simpler because of it.
  
positive.code: 
  There are {link-containers} built automatically from version tags.
  
  These containers are untested and provided only for those with specific containerization requirements.
  When in doubt, prefer the statically compiled {link-releases}, unless you specifically need a container.
  
  == Alternative Implementations
  
  *   {link-mrsaints}' go-camo {link-arachnys-fork} -- supports proxying additional content types (fonts/css).
  
  == Changelog
  
  
negative.code: * `--filter-ruleset`
  +
  --
  If a `filter-ruleset` file is defined,
  that file is read and each line converted into a filter rule.
  See link:man/go-camo-filtering.5.adoc[`go-camo-filtering(5)`]
  for more information regarding the format for the filter file itself.
  
  Regarding evaluatation: The ruleset is NOT evaluated in-order.
  The rules process in two phases: "allow rule phase" where the allow rules are evaluated,
  and the "deny rule phase" where the deny rules are evaluated.
  First match in each phase "wins" that phase.
  
  In the "allow phase", an origin request must match at least one allow rule.
  