[systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service
arvidjaar at gmail.com
Tue Aug 26 10:44:58 PDT 2014
В Tue, 26 Aug 2014 19:19:01 +0200
Lennart Poettering <lennart at poettering.net> пишет:
> On Tue, 26.08.14 17:45, Miroslav Lichvar (mlichvar at redhat.com) wrote:
> > On Tue, Aug 26, 2014 at 07:50:23AM -0700, Marcel Holtmann wrote:
> > > and writing a good DHCP client was supposedly also really hard.
> > > Guess what we have done that twice now and both of our clients are
> > > better than everything else out there. And guess what, we did the
> > > same for NTP.
> > Are you saying timesyncd is already better than chronyd or ntpd? In
> > what criteria? To me it looks like the only advantage currently is the
> > integration with networkd.
> First of all, tiemsyncd is *very* new. timesyncd is supposed to be a
> minimal client side SNTP implementation. It's not suitable for
> super-accurate industrial time-keeping or anything like that, but it is
> simple, minimal, and supposed to *just work*. It focusses strictly on the
> client side of things, and doesn't lose itself in details RTC skews and
> whatnot. It's supposed to cover the 90% that the vast majority of
> devices need, and for the rest of 10% we want it to easily be replacable
> with a full NTP server solution. It's not supposed to be a fancy project
> of its own, it's supposed to just be that bit that is there, and is good
> enough, and unless you really need super-high precision there you don't
> need to install any additional package.
I suspect part of confusion stems from the fact that timedatectl states
"NTP is enabled", while it actually means "timesyncd is enabled". For
me "NTP enabled" really implies something different from "running sntp
client periodically". Rephrasing it as "time synchronization is
enabled" and "time synchronized" would convey the same information
without implying anything about implementation.
More information about the systemd-devel