The implication that systemd is not a product strikes me as odd given that a core aspect of systemd's marketing and leverage was precisely that it supplied a ton of policy decisions as to how distributions should operate, as opposed to simply mechanism.
Lennart is controversial, but he usually provides more-or-less decent reasons for technical trade-offs. Here though? Complete copout.
You are comparing apples to oranges. systemd takes policy decisions but it doesn't provide infrastructure and a set of ntp servers is infrastructure. Likewise, a web server encodes a lot policies (most of which aren't set in stone by any standard) on how http requests should be handled but it doesn't come with a default cdn.
...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.
I meant physical server infrastructure. Not the allegorical infrastructure formed by Linux packages communicating. Yes, I know the infrastructure word is horribly overloaded.
He has added further clarification which makes sense to me. Just like other pieces of NTP clients don't register for a vendor name in the pool (there's no chrony.pool.ntp.org), systems also doesn't need to.
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.
It appears that LP has an incomplete grasp of English (no insult, it is not his native language) and is simply misunderstanding both NTP.org and Google's instructions regarding how to use their systems. NTP welcomes usage, Google does not, and LP misunderstood them both backwards.
I speak the same native language as Lennart and apparently I have the same misunderstandings of the language. I agree with his reading, that NTP welcomes usage (as a default in your open source project) iff you apply as a vendor. Can you point me to a better clarification on why this reading is wrong?
Lennart said in the linked thread that systemd was not allowed to use pool.
> 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.
That doesn't look at all like a language barrier problem. That looks like Lennart understood perfectly well, that usage of the pool is conditional on registering a vendor pool and that he has perfectly sound reasons not wanting a systemd vendor pool. And note, that the main Maintener of the NTP pool agreed with his reasoning.
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.
They're Google's servers. If they aren't meant for your use they can ask you to stop using them without any reason at all. The fact that they provided reasons at all is simply to inform people how they're systems are not going to operate normally.
To me it reads like a soft rule, especially amenable to something as big as systemd. Any decent project leader honestly looking for a solution in such a situation, would reach out to ntp.org and explain the problem. If he cared, of course.
> ...to provide a correction to someone saying pools can't be used.
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.
I think the problem is not a language problem but rather both a set-theoretic and a technical issue specific to how NTP works.
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.
Why are people trying to parse written language on a website? Why doesn't someone at Red Hat just pick up the phone and call someone at the Network Time Foundation and ask them what they need to do in order to use ntp.org? Or call someone at Google and talk to them?
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.
"Someone at Google" has created GitHub issue (that is discussed in this thread), asking systemd project to stop using Google servers. No need for a call here.
I think a) the snark is unnecessary and b) you are mistaking disagreement with ignorance. From what I read in that issue, he did understand the point pretty well (from a technical standpoint), he just disagrees with the proposed solution (from a mainly political standpoint). You should be able to disagree with people without claiming malice or ignorance.
The former poster didn't say Poettering was ignorant nor malicious.
"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.
Yea that was kind of crazy. Especially with a really straight forward fix already there. Now CoreOS is jumping in to possibly get the vendor registration for systemd so they can use pool.ntp.org correctly.
> Is there a good reason for systemd to not use those pool servers?
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.
I find it utterly reasonable, to avoid being made responsible for something, that is essentially a test-domain. Imagine, for example, that some domain server in .systemd.ntp.org would stop responding (for pretty much any* reason, including a cut cable in someones basement). Imagine some User™ gets an error message, saying, that 0.systemd.ntp.org wasn't reachable, googles systemd and creates bugreports against systemd for a broken ntp-server that a) isn't run by the systemd-folks, b) was never supposed to be used by anything else than the systemd test-suite, c) was registered by some third-party (CoreOS) and d) not one of the systemd-maintainers wanted.
I find it a reasonable position, that he wants to avoid such a situation.
So instead, he makes it google's problem. This is an even more unreasonable and irresponsible decision. If he doesn't feel his project has the manpower to handle support requests for default servers, then he shouldn't list any default servers.
Lennart has stated very clearly, that if someone where to propose some other publicly available server, that he would be happy to put that down instead.
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.
Except that the only time that vendor pool would be used outside of tests is when folks build systemd from source on their own. Each GNU/Linux distro overrides those defaults when building/packaging systemd, so the vast majority of users would be entirely unaffected.
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).
That doesn't mean he wasn't still dismissive. For one not to be considered "dismissive", one would have at least considered anothers arguments - even if the one sticks to his original conclusion. Poettering was anything but receptive to other opinions - he's already decided his method was the best regardless of the T&C's of the services he's using nor the feedback from the community.
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.
So, it seems that he wants to run out-of-the-box with some timeservers so that the developer/compile/testing machine doesn't have to specify them manually for tests. On the other hand he wants to require vendors to add a custom configuration so that they abide by the rules of, e.g. pool.ntp.org, by registering a vendor pool and configure systemd.
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.
I love how in one sentence he accuses Poettering of being "convinced he has all the answers for everyone", and in another he states anyone who approves of systemd must be "naive or lazy or just plain clueless developers" lured by "the promise of making their lives easier".
