Use NTS for NTP time sync

[smira]

See https://github.com/beevik/nts

Our default time.cloudflare.com supports NTS, probably should be optional.

[sanmai-NL]

Why don't you use an existing, vetted, modular, modern and performant NTP client implementation to fix this and #8771, etc.? Such as https://github.com/pendulum-project/ntpd-rs.

[DmitriyMV]

@sanmai-NL what Go library you propose exactly?

[sanmai-NL]

Why must it be a Go library? I suggest a native executable that runs as daemon and adjusts the clock.

[sanmai-NL]

To be clear, ntpd-rs has been audited professionally and is under active development.

[DmitriyMV]

@sanmai-NL

Why must it be a Go library? I suggest a native executable that runs as daemon and adjusts the clock.

The core idea of Talos is to keep minimal (as much as we can) amount of dependencies (and binaries). You may notice that we try to implement things immem, when they could probably be implemented using separate applications. This lowers both the potential attack surface and the amount of support of things which we don't own. You are free to disagree with those decisions but it's too late to change the spirit of the project.

The main idea — we only add new binaries if there is truly no other way.

[sanmai-NL]

Have you thought about how to calculate attack surface? A big library adds more instructions than a small executable. Indeed, executables with separate virtual address spaces for services that do little (or in this case, no) interfacing provide excellent isolation barriers.

But it's also possible to use ntpd-rs as a library, it's modular. That's just an inefficient use of development time.

[sanmai-NL]

And as for your second point, reducing support load: developing your own software means you're the one party who can support it and it will cost you more time to triage issues into upstream then when you use a small interface to a dedicated outsourced service.

[DmitriyMV]

A big library adds more instructions than a small executable.

With dead code elimination optimization that's not true.

But it's also possible to use ntpd-rs as a library, it's modular.

We would rather not bring additional CGO bindings where we don't need to.

developing your own software means you're the one party who can support it and it will cost you more time to triage issues into upstream then when you use a small interface to a dedicated outsourced service.

I'm looking at it from another perspective: we know Go, we love Go, we have a very long history writing Go. We can fix the library and fit it to our requirements if the need arise. We can't do the same with Rust.

[sanmai-NL]

With dead code elimination optimization that's not true.

That's a claim you really can't make without specific measurements. Why would there be a lot of dead code in a big time syncing library, at all? Dead code is eliminated similarly for binaries. Moreover, these are built with only the features you want, a compile time control (in Rust). And if that's still not enough for you, it’s easy to add a custom binary based on the modular library. It looks like you haven't studied the included client libraries in ntpd-rs at all, as they are obviously very minimal already.

I'm looking at it from another perspective: we know Go, we love Go, we have a very long history writing Go. We can fix the library and fit it to our requirements if the need arise. We can't do the same with Rust.

That's the real reason ... I think rational arguments should be considered and the product's quality should be optimized, not the satisfaction of developers who fancy a language. You can't, or you don't want to? That's a difference. You're actually saying you consider developing in-house customizations of an OSS library, rather than working with upstream people who know better about these protocols. That goes counter to your earlier argument about minimizing support cost. Unless you don't count development cost. (Support is cheaper from a business standpoint than development, by the way.)

As a user, I prefer product teams who stick to their core product and choose vetted, professionally audited components over self-tweaked Go libraries.

[andrewrynhard]

@sanmai-NL Ultimately we want Talos to be controller based and everything reactive. A big reason we try to keep everything in Go is because we can integrate it more deeply into our PID1 and make things controller based. Running a daemon in another language doesn’t quite work for that goal at the moment. Eventually we want to have other projects implement our COSI spec but that is going to take quite some time because Talos introduces an entirely different paradigm when it comes to user space.

You have fair points but I also don’t see why it matters if we use a Go library and integrate it in a way that we decide. To imply that we aren’t sticking to our core product is completely inaccurate. Implementing Talos in the way we are is everything to us. The company behind Talos is betting on API managed Linux so it’s crucial that we make that happen.

By knowing the user space well our team can provide better and faster support. My team knows the code and can navigate it quickly in those times when a customer needs support. Often times my engineers already know a fix before they have even seen the code. Point is that there is value in owning the code.

To put it bluntly, we are sticking with the Go library we have chosen and at this point your comments aren’t helping. If there is something specific to the UX we can help with we would be more than happy to address it but please allow us to work the way we decide to. We have been at this for many years now. We have a vision and will bring that vision into fruition in the best way we think possible.

If you know folks behind ntpd-rs I would be happy to chat with them. If we could get a strong commitment from them to use COSI then maybe we could integrate it.