Hacker News Reader

Comment by vezzy-fnord | Hacker News Reader

Linked email from Lennart has some interesting reasoning for this: http://lists.freedesktop.org/archives/systemd-devel/2014-Aug...

View on HN

I basically read that as "this isn't our responsibility so we don't have to do anything" which is sort-of true.

I think if they didn't configure ANYTHING by default, well, in that case the distro HAS to figure something out or else it won't work. OK, that's legit.

I think if they wanted to pick an officially blessed config option then they should go through the necessary steps to have it be official and blessed. Whatever that means.

But this seems to be the worst of both worlds; we're going to pick something for you so it'll work without intervention, but then we'll tell you that you're idiots for not fixing a thing which isn't obviously broken to begin with.

Ship it broken, or ship it working but don't ship it working poorly and then tell people it's their own fault.

It's simpler than that. Knowingly hardcoding someone else's timeservers without even speaking with the operator of said timeservers is Internet hostility, particularly when your project is popular enough to be deployed on potentially millions of machines. D-Link hardcoded PHK's timeserver many years ago:

https://people.freebsd.org/~phk/dlink/

Netgear hardcoded the University of Wisconsin even earlier than that:

http://pages.cs.wisc.edu/~plonka/netgear-sntp/

The best part about the Netgear one was it hit upwards of a quarter million packets per second and actively resisted mitigation by admins. Seriously, don't hardcode. Ever.

Companies won't learn until the time servers they shipped on hundreds of thousands of products stop working from one day to the next because the operator of the server didn't feel like offering them a free service.

I seem to recall reading about a French made program that had hardcoded the Linux source FTP server. Apparently it was used as part of a bandwidth test. And it got so popular that the server admins had to ban the French IP range...

What I take away from the link is:

  > Distributions usually have a full NTP client installed by default, why
  > should GNOME try to enable/disable an SNTP client that happens to be
  > distributed with systemd?

  Well, "usually" means right *now*, little else.

And:

  > > This is really about being a *client*, and
  > > not trying to outsmart servers.
  >
  > Outsmart servers how exactly?

  By not trusting them...

To me, this provides insight into Poettering's mindset of systemd creating a fool's paradise[1] regarding coexistence with anything outside of its walled garden[2]. For an example supporting this, the not-too-subtle hint of system clients outside the systemd ecosphere (NTP in this quote) being slated for elimination in distributions should be sufficient.

BTW, love your use of the phrase "interesting reasoning".

1 - http://www.phrases.org.uk/meanings/138800.html

2 - https://en.wikipedia.org/wiki/Closed_platform

Poettering's projects has basically turned into lightning rods for a group of devs that want Linux to have a one true way to do everything, as they see the bazaar way of doing things as a failure and something that is holding Linux back from wider adoption.

Linux is widely adopted.

You know it, i know it, but as best i can tell they don't see it as "wide enough".

Damn it, GregKH has basically admitted that one big reason for pushing kdbus is that the automobile industry wants to adopt embedded Linux as a replacement for QNX.

And for some oddball reason they have adopted dbus as their replacement for whatever QNX RPC they used before. Except that said QNX RPC was higher performing than current dbus, in part because it was in kernel...

He hasn't explained why they chose Google in that thread, yet.

Moreover, his argument that it isn't their responsibility became invalid when they set a default preference. Same applies if they change it to ntp.org. That project, however, is explicitly intended for such purpose and is generally accepted by the majority.

Still doesn't explain why Google instead of ntp.org.

As someone on the issue notes: You cannot use pool.ntp.org either.. "You must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance." that's according to the pool's website...

And Ask Bjørn Hansen, the primary developer of the NTP pool, corrected that user. Keep reading, because that's not correct.

Actually my comment is correct. You can't use the standard public time servers. Systemd has expressed that they do not want to apply for a vendor pool, for good or for ill.

>they do not want to apply for a vendor pool

So apparently there's a super good reason for this. What exactly is it?

"systemd is not a distribution."

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.

>"systemd is not a distribution."

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.

"Not being allowed to" is a pretty good reason to not use ntp.org I think.

They are allowed to use pool, they just have to apply to use them.

The linked thread has someone from Google telling systemd that systemd should stop using Google's time servers.

> They are allowed to use pool, they just have to apply to use them.

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

This doesn't address why not just leave it unconfigured.

Unconfigured is better than a bad default.

This doesn't address why not just leave it unconfigured.

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.

I think the worst issue here is that the result will be on the surface correct, unlike some other test settings that will show that the protocol/code works but that the settings needs to be changed to be useful.

Something akin to the blinking 0:00, that shows the time circuit is powered up but with no time set.

We've been over why that's false once already.

(I accidentally downvoted you while I was trying to upvote you. Sorry.)

That's irrelevant, however. If systemd is going to ship with a default nameserver then it should be using the correct and public NTP pool, rather than servers from a random company who hasn't made any commitment to providing reliable UTC time to a public audience.

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 settings is according to the developers only for testing purposes, like using ipsum lorem or example.com.

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.

Except that isum lorem and example.com will both stand out as "working, but nonsense". If whatever time server they aimed the code at would constantly resolve to a date in the 1700s or something, it would be blatantly clear that setting has to be changed. But as it stands, it will give a correct response out of the box and thus give a false sense of nothing more needed being done.

That is not the case, you misread that response. What he rather is saying is: a) > Lennarts reasons for not using *.systemd.pool.ntp.org ("systemd isn't a distribution") makes sense to me. b) > If you kept reading you'd learn about getting a "vendor pool" setup specifically for your product/distribution.

i.e. he corrects, that pool.ntp.org can not be used, without applying for a vendor pool but that Lennarts reason for not doing that makes sense to him.

Yes, but you can use [0-3].$vendor.pool.ntp.org. You simply request a "vendor zone" once, beforehand, and use it all you want. Apparently Lennart is opposed to that part of the process, however.

So ntpd is a dns server?

>The Network Time Protocol daemon (ntpd) is an operating system program that maintains the system time in synchronization with time servers using the Network Time Protocol (NTP).

Lennart says the following though

> But quite frankly, we added timesyncd because we believe that installing a full DNS server like ntpd/chrony on all client machines is absolute overkill

Nobody else mentioned it because it is incredibly obvious that it's a typo or slip. Debate the technical merits, don't nitpick stuff that's completely inconsequential.

He mentions typing this on his phone so it's possible it's the autocorrect (and "corrections" that kinda make sense are the worse.)

I wasn't nitpicking I thought I could learn something.

They also have a proxying DNS client in the systemd code somewhere.

One susceptible to a decade old vulnerability no less...

What degree of access does such a vulnerability afford you though?

Reply on news.ycombinator.com