Deciding what modes to keep.

Gary E. Miller gem at
Fri Sep 30 21:43:43 UTC 2016

Yo Eric!

On Fri, 30 Sep 2016 17:10:39 -0400
"Eric S. Raymond" <esr at> wrote:

> Gary E. Miller <gem at>:
> > Yo Daniel!
> > 
> > On Fri, 30 Sep 2016 14:50:12 -0400
> > Daniel Franke <dfoxfranke at> wrote:
> >   
> > > An empty specification in my new language has different semantics
> > > than an empty specification in the old language so at some point
> > > there will have to be a flag day as to which way it is
> > > interpreted, but I don't think this is as big a deal as you've
> > > made it out to be.  
> > 
> > I think it is a big deal.  UNtil we have our own rabid base of
> > followers the only way NTPsec grows is by taking NTP Classic
> > users.  They will want a drop in replacement.
> > 
> > So any upward extensible is fine, but trivial back-compatibility is
> > essential.  
> I've carefully maneuvered to give us some wiggle room on that.  The
> --enable-classic-mode build option produces bug-for-bug compatibility
> (with one unavoidable minor exception near the generic clock driver).

I don't advocate for bug compatibility, I advocates for ntp.conf
file compatibility.  And old ntp.conf should work on a new NTPsec

Any new options that do not break old command line/config file should
be in the --enable-classic-mode.  And it should likely be a command
line switch, most distros ship just one binary.  That binary needs to
be able to drop-in to an old host and work, yet have optionns for
the new/better modes.

> I think the predicate "drop-in-replacement" is actually slightly less
> important than "I could build it to be bug-for-bug compatible if I
> wanted to", especially when we can justify behavior changes in the
> default build on security grounds.

((% of UNIX users never build anything.  They drop in a binary from
apt/rpm, etc.

> That is, as long as we early give adopters the psychological
> reassurance of knowing we're conscientious about offering full
> backward compatibility for people who *really want that*,

That is not what they want, they want drop-in compatibility, at least
for the firat year for two.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the devel mailing list