5 ms·

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

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.

Sanddancer 11y ago
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.
- Merovius 11y ago
  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.
  - wang_li 11y ago
    The reporting wrote, in his first paragraph: >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.
yellowapple 11y ago
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).

Sanddancer 11y ago

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.

Merovius 11y ago
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.
- wang_li 11y ago
  The reporting wrote, in his first paragraph: >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.

yellowapple 11y ago

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).