Zero Perl is achieved

Eric S. Raymond esr at
Fri Sep 9 20:15:48 UTC 2016

This morning I converted the last of the useful Perl legacy code to Python.

This is a bigger victory than it might sound like, because Perl was the last
holdout of ancient and little-exercised code left in the production
part of the codebase after the massive cleanup of legacy C that took up
most of the last eighteen months.

A few oddities that we won't ship remain in util/, and the Windows
port code is still something of a mess, but at this point I am willing
to assert that the POSIX part of the codebase is in reasonably clean
and maintainable shape.  Or, to put it differently, there are still
some dusty corners (notably in the older clock drivers) but there are
no longer huge piles of bewildering moldy cruft.

Our total C line count is now down to 85KLOC from, originally,
227KLOC.  That's a 63% reduction (only a hair less than 2/3rds) and
pretty mind-boggling if you think about it.

There's much more work to be done, of course. Moving ntpq from a C
implementation to Python is a work in progress; that will allow
us to drop another 6KLOC.  I need to finish TESTFRAME. Daniel's
protocol-machine refactor needs to land.  Beyond that...NTS,
Gary's project to speed up convergence after restart, clock
daemon separation, and many other things.

But the character of the work is changing.  We're fighting the
friction of the codebase less, able to put more effort into actual
functional improvements. The new refclock configuration syntax was an
early move in that direction, as was ntpviz. Daniel's redesign of the
restriction language will be another.

While we still have security as a prime focus, I worry less about that
than I used to. We've made very serious gains there measured by evaded
CVEs against Classic, we know how to collect more, and as long as we
stick to the preventive C practices that we've documented I am
reasonably confident that we won't open new holes.

Now I'm off to push on TESTFRAME some more. That's moving again, though
slowly; it touches places where I have to be very careful in order not
to break things.  It's a prerequisite for testing Daniel's protocol-machine
changes, though, so it has to be the next thing to land.
		<a href="">Eric S. Raymond</a>

More information about the devel mailing list