chrony as default NTP client?
atkac at redhat.com
Thu May 6 12:21:50 UTC 2010
On Thu, May 06, 2010 at 01:10:36PM +0200, Miroslav Lichvar wrote:
> On Wed, May 05, 2010 at 09:39:52PM -0400, Tom Lane wrote:
> > Mail Lists <lists at sapience.com> writes:
> > > On 05/05/2010 09:35 AM, Miroslav Lichvar wrote:
> > >> With the latest improvements in the chrony package related to
> > >> NetworkManager and name resolving I think it is now good enough to
> > >> replace ntpd in the default configuration and the configurations
> > >> supported by system-config-date.
> > > I think this is a terrible idea.
> > Yes. I certainly wouldn't use it, and especially object to the proposed
> > strong-arm tactics of eliminating all configuration support for ntpd.
> > The case for making chrony default is weak enough, and the case for
> > throwing roadblocks in the way of people who prefer ntpd is nonexistent.
> I'm not suggesting to remove the ntp support from s-c-d, just to add a
> support for chrony and change the dependency to a name provided by
> both packages and marking chrony as default in the comps.
I would suggest to have only one NTP client in the s-c-d. In my
opinion users which use s-c-d won't know what is different between
ntpd and chrony. Selection will be only confusing.
In my opinion complains about security bugs and stability are quite
invalid. It will mean that we should automatically reject all new
alternative programs as suspicious and full of bugs. They might be
less stable that their widely used friends but they also might be
more stable. I don't see this as a valid argument.
Maintainer's decisions should be respected in this cases because he is
generally the person who knows the package, in this case NTP, well.
Especially when he actively maintains it for more than four years. It
of course doesn't mean he should drop ntp from distro. It will be here
for people who prefer it. "Default" means "this is generally the best",
not that "this is the fastest" or "this has the most features" of
"this is the most accurate".
Adam Tkac, Red Hat, Inc.
More information about the devel