So apparently there's a super good reason for this. What exactly is it?
Which is a fair point, probably one of the few I agree with in the response. Systemd is just a software component. When you install ntpd and similar you'll find it almost always comes configured with a vendor pool for the distribution e.g. 0.ubuntu.pool.ntp.org
The same should be applying for systemd. That said, they really shouldn't be setting defaults like this, especially not broken ones.
I'd buy this if they explicitly didn't set a default ntp server at all, but that's not a good reason to set it to Google rather than ntp.org.
The linked thread has someone from Google telling systemd that systemd should stop using Google's time servers.
Which has unclear (non-technical) implications. Which Lennart Poettering doesn't want to tolerate. Which I would consider a valid opinion.
> The linked thread has someone from Google telling systemd that systemd should stop using Google's time servers.
For technical reasons, that Lennart Poettering doesn't agree with (i.e. these defaults won't be used in production and if you use an unconfigured self-build of systemd in production, it's your own fault).
Unconfigured is better than a bad default.
He addressed that in another post. Basically from a testing and development POV he believes it's important to ship with some default that at least works out of the box, even if the default is completely unsuitable for production.
Something akin to the blinking 0:00, that shows the time circuit is powered up but with no time set.
And if it's using a service like the NTP pool, it needs to have a vendor prefix. Not because this has anything at all to do with the notion of being a "distribution", but because the prefix provides a means for the pool to identify traffic originating from default-configured systemd instances, and cut it off if it suddenly starts to behave in a way that would degrade the rest of the network.
Or they can simply ship with no default. But you can't have it both ways, both setting a default server and claiming not to be a vendor in every sense meaningful to an NTP server operator.
The choices being debated seems are to have no settings by default, require that people who want to run test suites configures the software before testing, register a "vendor pool" for this purpose, find a better ntp server than google, or do nothing.