Recent trends in the codebase size

[Eric S. Raymond]

Here are the full current stats:

all            71320 (100.00%) in 298 files
c              60694 (85.10%) in 152 files
python          7472 (10.48%) in 48 files
shell           1444 (2.02%) in 7 files
yacc            1255 (1.76%) in 1 files
waf              455 (0.64%) in 11 files

We're down to a hair over 26% of the original bulk of C.  The main
possible place to cut that's left is the ntp_io.c code; removing
interface scanning and going with one wildcard socket seems likely
to cut a couple KLOC.  Past that, we're running out of crap to clean
up unless we decide to drop more obsolete refclocks or Hal is
able to rewrite the async-DNS code and seriously shrink it.

Accordingly I've recently done a pass through the reclocks. The
dumbclock driver should probably go - it's an obvious dorm-room stunt
that doesn't correspond to any production hardware anywhere.
Otherwise it's hard to see what else to cut without a policy change.

A couple other interesting points:  

* The size of the waf recipe has been dropping recently. The crypto
  cleanup helped with that.  More needs to be done here; it's still
  overcomplicated and somewhat buggy.

* 10% of the code is now Python.  That's better than I thought we
  would do in terms of moving from C to a memory-safe language (that
  is, shy of a rewrite in Go or something). It would be good to
  increase that further, but this is unlikely; what's left in C either
  needs to be there for performace reasons (ntpd) or would be
  difficult to shift out of all proportion to its size(ntptime,
  ntpfrob, sht).

* Most of the shell code (975 lines) is autorevision.sh.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Live free or die; death is not the worst of evils.
	-- General George Stark.