What's left to doo on NTS.

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> Eric said:
> >> I've been collecting major items in devel/TODO-NTS
> > Is there some reason this isn't just a section in nts.adoc?  (Which may need
> > some GC at this point.) The whole idea of that document was to be a planning
> > whiteboard. 
> 
> Only signal to noise.  I was trying to capture the big ideas without getting 
> bogged down in details.

Fair enough.  At some point in the near future I need to go through nts.adoc,
cull out the things we've done, and delete roads that won't be taken now.

*I* might merge those documents then. I'll give you a heads-up if I do.

> My big concern is that nobody else seems to be testing it.  There may be 
> dragons that I haven't poked.

Understood.  Unfortunately I myself can't be much help here - my
outside view of NTP is still weak, I have only limited ability to
recognize what normal operation should look like or spot deviations
from it.  Gary or Achim or Matt would be better for that end of
things.

> > Remember, I'm trying to get away from configure-time options.
> 
> There is a fundamental conflict between ease of use, ease of debugging, and 
> good security.  I don't know how to resolve that.  Mostly, I was trying to 
> raise the issue.  Configure-time issues are just a detail.

I don't know how to resolve it either, not in any global sense.  We'll
just have to muddle through.  I don't think we;ve done badly so far.

> For Go, can we build 2 versions by linking in different modules?

We can.  That's what build tags allows.  Getting the kind of fine-grained
control one has with #ifdefs would be complex, though - outside of regularly
structured cases like a driver table (which should really be handled by
code templating using "go generate") one could easily wind up in a
combinatorial tag explosion.

I strongly suspect that the weaker conditionalization support reflects a
deliberate choice on the part of the Go designers.  I think they'd say that
the kind of feature-option trickery we're used to in C builds is a defect
attractor - and  think they'd be right to say that.

> Has anybody looked at our configure time options?  How many of them make sense 
> in the context of Go?  (ignore refclocks)

It was on my list. Now is not a bad time to look deeper.

Eyeballing the output of ./waf configure help I see

 NTP configure options:
    --disable-droproot  Disable dropping root.
    --enable-early-droproot
                        Droproot earlier (breaks SHM and NetBSD).
    --enable-seccomp    Enable seccomp (restricts syscalls).
    --disable-mdns-registration
                        Disable MDNS registration.
    --enable-classic-mode
                        Strict configuration and log-format  compatibility with NTP Classic
    --enable-debug-timing
                        Collect timing statistics for debugging.

  NTP configure features:
    --enable-leap-smear
                        Enable Leap Smearing.
    --enable-leap-testing
                        Enable leaps on other than 1st of month.
    --enable-mssntp     Enable Samba MS SNTP support.

Refclock configure options:
    --refclock=REFCLOCKS
                        Comma-separated list of Refclock IDs to build (or "all")

That's not terrible.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.