Lennart is controversial, but he usually provides more-or-less decent reasons for technical trade-offs. Here though? Complete copout.
...How does it not? That's the point of systemd: provide a GNU/Linux middleware with lots of policy decisions on the structure of distros to supposedly bring integration and uniformity benefits.
The fact that it's core infrastructure but heavily delves outside of mechanism is what makes it so controversial.
However, they should IMHO still get rid of the Google default and instead blow up on compilation or start up if the NTP server is not set.
Blowing up is better than silently running with wrong data, much less with unauthorized use of resources.
> Its up to the distros to register an ntp pool product. systemd is not a product. Its just some toolset people can build products from. We cannot use the ntp pool hence. If the googl time servers
In this post he says that systemd is not a product. In the context of whether they're allowed to use pool.ntp.org systemd is a product.
> Coreos should register its own product with the pool and use that. Systemd upstream is not a product, we shouldnt register it as one. distributions such as fedora have their own pool, debian has, ubuntu ha, arch hass. if downstream dont set the correct pool for their product then thats something to fix downstream.
Here he repeats the line that pools is forbidden:
> the ntp pool made very clear we cannot use them. As i read what is written above google just says the servers are crap but doesnt explicitly deny us to use them. Which is why id like to leave them in place because they are at least googd enough for testing purposes.
And here:
> We are an open source project, with no legal entity behind it and as such we are not the ones who can take responsibilty and not the ones who register as a vendor at the pool. [...] but right now the ntp pool is nothing we can use since the non-vendored pool is explicitly forbiddrn for us and the vendored pools dont apply to us since we arent a vendor.
He makes the claim several times in that thread.
But even if we accept that pools should not be used: that doesn't mean you can use Google's time servers. Google have asked systemd to stop using them and provided strong reasons.
I also somewhat agree with Lennart, that the reasons Google give don't really apply.
However, I also agree, that they shouldn't be used nevertheless :) Luckily, as I understand it, there seems to be somewhat of a concensus to not put a default and instead have fail the build if nothing was ./configure'd.
> Lennarts reasons for not using *.systemd.pool.ntp.org ("systemd isn't a distribution") makes sense to me.
But goes on to say:
> @crrodriguez If you kept reading you'd learn about getting a "vendor pool" setup specifically for your product/distribution.
...to provide a correction to someone saying pools can't be used.
abh also says:
> I'd suggest having no default NTP servers in the systemd code; leave it to distributors to provide their own (possibly via the NTP Pool).
That's something that LP appears to have considered. I'm not sure why that isn't done.
Yes. Someone claimed (correctly), that *.pool.ntp.org can't be used. abh ammended that by saying, that however, a vendor zone can be used. I don't think anyone ever doubted that point. Notably, Lennart seemed to be aware of that point in his earlier mail.
> That's something that LP appears to have considered. I'm not sure why that isn't done.
The reason given before was, that tests and similar need some values. However, a PR implementing exactly this solution is currently in discussion (and afaik Lennart has not respondet to that yet). I would wait until the dust is settled on that, before I continue this discussion. The bug report (which is afaik the first time anyone has indicated that the Google servers shouldn't be used for this) is half a day old, that's basically nothing in FOSS-development (especially for a non-critical issue like this). Give it some time, if this isn't solved in a week, that may be a more appropriate time for pointing fingers and being unpatient.
Set-theoretic: what exactly is meant by "the pool"?
Is it: a) the set of all NTP servers on the Internet which cooperate with those on .pool.ntp.org, b) the subset of NTP servers with hostnames [0-9]+.pool.ntp.org, c) the subset of NTP servers with (one or more particular) "vendor" subdomains under .pool.ntp.org, d) a particular intersection or union of any of these sets?
Technical: Does the perceived restriction on who may or may not use "the pool" apply to NTP servers which wish to participate in "the pool", or to NTP clients which simply wish to synchronize their clocks?
I've found several documents, from ntp.org as well as from other sources, with varying levels of vagueness and contradictory language.
Some examples:
Server configurations should not use .pool.ntp.org servers (why?): http://www.ntppool.org/join/configuration.html#management-qu...
Client configurations may use .pool.ntp.org servers (when?): http://support.ntp.org/bin/view/Servers/NTPPoolServers
IMHO it is urgent that at least ntp.org official documents use much more precise language, in particular defining what exactly is meant by "the pool".
I know that tech companies don't like to take calls from random customers, but we're talking about a major Linux project sponsored by Red Hat. Someone for sure knows someone who can get real answers from a human.
"missing the point" can equally be attributed to someone who disagrees (ie he disagreed that systemd is a vendor while missing pool.ntp.org's point that open source project's are welcome to register vendor IDs without themselves being vendors.
That doesn't mean that Poettering is ignorant nor malicious. Just that his political standpoint isn't relevant (in the OPs opinion) to the point that the NTP pool maintainers make about the usage of their time servers.
I disagree.
In regards to the rest of your comment: Note that the main maintainer of the NTP pool agreed with Lennarts reasoning: https://github.com/systemd/systemd/issues/437#issuecomment-1...
I kid.
What happens if distros don't change the default away from *.systemd.pool.ntp.org?
Because they forbid using the non-vendored pools as defaults and Lennart doesn't want systemd to be a vendor or product.
> What happens if distros don't change the default away from .systemd.pool.ntp.org?
Lennarts argument is not, that this might break, but that he doesn't want .systemd.pool.ntp.org to exist, because that would imply some kind of responsibility of systemd.
He's like the anti-Spider Man. With great power comes no responsibility.
I find it a reasonable position, that he wants to avoid such a situation.
Also note, that the reporter didn't write "don't use this, we can't handle the load", but "don't use this, weird stuff will happen to your server".
But yes, I agree, Googles NTP servers should be removed as a default. But a vendor pool also isn't a solution apparently. Luckily, there are people actively working on a PR to simply have no default. So everyone should just calm down and give the issue a while to resolve itself, instead of venting here on HN.
>Google doesn't provide timeX.google.com as a public service.
That's the end of the conversation. How Google handles rare time events, whether it's reliable or scalable are all irrelevant.
In other words, the people who would run into the error you propose are the same people who know fully well what systemd is and is not (and - I'd hope - would know how to read the rest of that hostname and surmise that the issue is with an NTP pool and not systemd itself).
But this has been pretty much his approach to systemd from the very start; which is why it's polarised the community so much.
> Even if the google servers dont provide time that
> is correct, its good enough to run testcases again.
> Products however of course shouldnt use it.
The only sane approach for me seems to be to discover the correct ntp-server in the scripts running the testcases, and leave the ntp-client in systemd unconfigured and untested if that's not possible.
Forcing developers to have a properly configured system is a much saner approach, because it affects way less people than potentially millions of users to whom a broken/wrong timesyncd.conf leaks caused by some snafu during configuration of the systemd timesyncd when packaging.
EDIT: Typos, wording.
Pot, meet kettle.