Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More Memory Safety for Let's Encrypt: Deploying ntpd-rs

letsencrypt.org

Post reply on HN
Print view View original

171–177 of 177 posts

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#171

Post by hcfman »

If you want to setup a chrony time server that maintains accuracy to within a microsecond and doesn’t do this with a network connection then you could try my sbts-aru project and just not use the audio recorder parts of it.

https://github.com/hcfman/sbts-aru

It installs with a single command on all Raspberry Pi versions and takes care of all the dependencies, configuration and startup order details to install and start working with one command.

It’s a sound localizing audio recorder platform and that’s why it also sets up accurate time.

It’s using GPS to get its time from.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#172

Post by hcfman »

rnijveld wrote: post #110
NelsonMinar wrote: post #7

I like the idea of NTPD in Rust. Is there anything to read about how well ntpd-rs performs? Would love a new column for chrony's comparison: https://chrony-project.org/comparison.html Particularly interested in the performance stats, how well the daemon keeps time in the face of various network problems. Chrony is very good at this. Some of the other NTP implementations (not on that chart) are so bad they shouldn't b…

In our internal testing we are very close to Chrony with our synchronization performance, some of our testing data and an explanation of our algorithm is published in our repository: https://github.com/pendulum-project/ntpd-rs/tree/main/docs/a... Given the amount of testing we (and other parties) have done, and given the strong theoretical foundation of our algorithm I’m pretty confident we’d do well in many producti…

Ah okay. Nice. Love to know whether you have plans to also provide gps time synchronisation? I guess if the point was to deal with security issues surrounding network communications I’d guess the answer is no.

But if the goals was also be a dominant player in time synchronisation then it might be a nice to have.

BTW. Letsencrypt certificates are the best. I install them with pretty much every installation of my other software. Thanks guys.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#173

Post by hcfman »

hi-v-rocknroll wrote: post #114
ComputerGuru wrote: post #20

Unlike say, coreutils, ntp is something very far from being a solved problem and the memory safety of the solution is unfortunately going to play second fiddle to its efficacy. For example, we only use chrony because it’s so much better than whatever came with your system (especially on virtual machines). ntpd-rs would have to come at least within spitting distance of chrony’s time keeping abilities to even be up for…

You might be doing too much work at the wrong level of abstraction. VMs should use host clock synchronization. It requires some work and coordination, but it eliminates the need for ntp in VMs entirely. Hosts should then be synced using PTP or a proper NTP local stratum (just get a proper GNSS source for each DC if you have then funds). https://tsn.readthedocs.io/timesync.html Deploy chrony to bare metal servers wher…

And by funds. That’s typically less than 100 euros with a Raspberry Pi

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#174

Post by another2another »

steveklabnik wrote: post #170
pjmlp wrote: post #169

Earlier quoted context omitted.

That wasn't the case of Modula-2, Ada or Object Pascal. Their problems was a mix of not being hieroglyph languages (too much text to type!), being much strongly typed (straitjacket programming with a famous rant post, wrongly), commercial offerings being expensive (more so against free in the box alternative), and not comming with an OS to make their use unavoidable. Note that for all the hype, Zig is basically Modul…

> not comming with an OS to make their use unavoidable. Early MacOS did use Pascal, though IIRC not Object Pascal.

You can still find documentation for Macos toolkit with Pascal bindings.

This is a bit of a nostalgia trip for me as I owned a copy of this book way back in the 90's

https://developer.apple.com/library/archive/documentation/ma...

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#175

Post by petee »

orf wrote: post #138
cozzyd wrote: post #86

Earlier quoted context omitted.

JSON is a terrible configuration format since it doesn't support comments.

Ok. Do you want to now add anything relevant to the comment you’re replying to?

Its an entirely relevant response...they are saying what you call a poorly thought out adhoc format is still better than json in any form or dependency.

Ironically your snark isnt relevant.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#176

Post by orf »

petee wrote: post #175
orf wrote: post #138

Earlier quoted context omitted.

Ok. Do you want to now add anything relevant to the comment you’re replying to?

Its an entirely relevant response...they are saying what you call a poorly thought out adhoc format is still better than json in any form or dependency. Ironically your snark isnt relevant.

Could be instead YAML or TOML. The point wasn’t specifically and only a JSON dependency, it was a dependency in general to do something useful and standardised

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#177

Post by petee »

orf wrote: post #176
petee wrote: post #175

Earlier quoted context omitted.

Its an entirely relevant response...they are saying what you call a poorly thought out adhoc format is still better than json in any form or dependency. Ironically your snark isnt relevant.

Could be instead YAML or TOML. The point wasn’t specifically and only a JSON dependency, it was a dependency in general to do something useful and standardised

> Would you rather it had a JSON dependency to parse a config file, or yet another poorly thought out, ad-hoc homegrown config file format

Ok, but you didn't write that, and thus they responded as such. Snark was still unnecessary; they made a simple statement in reply.

Post reply on HN