Reference NTP server is less complicated than entangled steaming pile of "let's
not" that is systemd. I trust the reference implementation more than I trust
the team behind systemd with regard to network communication.
systemd has a horrible security track record and should not be allowed on any server that is connected to the internet.
The last remote-root exploit from 2 months ago: https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dn...
The major distros urgently need to get rid of systemd and return to proven, modular init systems.
systemd was the biggest single mistake in UNIX history.
I don't want to return to a pile bash scripts with `sleep n` to get the system to boot, even if it's a proven method.
One of them should be adopted and fleshed out before systemd causes even more damage.
Simple, sane bash-like scripts, logging like you're used to and so easy to debug, and when you need to do your own custom stuff, simple and just works.
Gentoo showed me this tool a few years ago. So happy.
For years now I've heard loud stories about systemd +1 or -1. Same arguments over and over.
Meanwhile, dozens of my servers and desktops and laptops keep humming along, I've like just never had to fuck with it.
I should buy the OpenRC team some pizza. Thank you!
Or that they cling to "standard on paper" rather than "standard in use", and thus end up rolling back decades of real life usage in the process.
With systemd, perfect very much is the enemy of good. And both unix and Linux go where it is not by being perfect but by being good.
I didn't mean "standard" as in "POSIX 1003.1e", "SUSv3", or "RFC 3549", I meant it as in "whatever is currently most widely in use". Which actually reinforces your point.
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.
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.
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.