3 ms·

> Reference NTP server is less complicated than [systemd-timesyncd]. Reference ntpd source: ~130 kloc systemd timesyncd source: ~2 kloc Reference ntpd binary

> Reference NTP server is less complicated than [systemd-timesyncd]. Reference ntpd source: ~130 kloc systemd timesyncd source: ~2 kloc Reference ntpd binary: ~700 KB systemd timesyncd binary: ~38 KB I get that you don't like systemd, or trust that team. But it's hard to say that ntpd is less complicated than timesyncd with a straight face. Maybe it is better engineered, more correct, more secure, or something; but not less complicated.

kakwa_ 9y ago
Well, to configure ntpd as a basic client, the general workflow is the natural workflow of any daemon launched by init. 1) Install the package 2) Modify the configuration file if needed 3) Enable the service Taken alone timesyncd can be considered simpler to configure (no package to install, short configuration file), but it follows its own workflow, specially the command to enable or disable it (timedatectl set-ntp true), and to a lesser extent the location of its configuration file. For me it makes it harder to configure because, now, I must remember precisely all the steps where I could only remember a loss pattern, common with all other services, for ntpd. As itself, it's not that bad, it's a few commands, I can remember them, but it would definitely suck if every single service had its own pattern.
- LukeShu 9y ago
  You can do everything the common pattern way with timesyncd as well. 1) Install the package (it's probably part of the systemd package you already have) 2) Modify the configuration file if needed (/etc/systemd/timesyncd.conf) 3) Enable the service (`systemctl enable systemd-timesyncd`; the same as any other service) Sure, you can use timedatectl to enable it (which makes a D-Bus call to timedated, which then makes the same call that `systemctl enable --now` does). But you don't have to. It's a weird feature of timedated/timedatectl because they try to be the Swiss-army-knife of messing with time settings on the box.

kakwa_ 9y ago

Well, to configure ntpd as a basic client, the general workflow is the natural workflow of any daemon launched by init. 1) Install the package 2) Modify the configuration file if needed 3) Enable the service Taken alone timesyncd can be considered simpler to configure (no package to install, short configuration file), but it follows its own workflow, specially the command to enable or disable it (timedatectl set-ntp true), and to a lesser extent the location of its configuration file. For me it makes it harder to configure because, now, I must remember precisely all the steps where I could only remember a loss pattern, common with all other services, for ntpd. As itself, it's not that bad, it's a few commands, I can remember them, but it would definitely suck if every single service had its own pattern.

LukeShu 9y ago
You can do everything the common pattern way with timesyncd as well. 1) Install the package (it's probably part of the systemd package you already have) 2) Modify the configuration file if needed (/etc/systemd/timesyncd.conf) 3) Enable the service (`systemctl enable systemd-timesyncd`; the same as any other service) Sure, you can use timedatectl to enable it (which makes a D-Bus call to timedated, which then makes the same call that `systemctl enable --now` does). But you don't have to. It's a weird feature of timedated/timedatectl because they try to be the Swiss-army-knife of messing with time settings on the box.