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

Ntimed – NTPD replacement

github.com

Post reply on HN
Print view View original

21–30 of 109 posts

Re: Ntimed – NTPD replacement

#21

Post by atoponce »

If Ntimed separates out the client from the daemon, so I can install just the client package only, IMO that will be a big win for computer time synchronization.

One thing that has always bothered me with the NTP project, is the lack of a separate daemon and client. If you want the NTP project's client, then you must also install the daemon, even if it is listening only on localhost, or if you opt to not start it up on boot. It still must be installed though.

On my Debian system, I only have the following "clients" available:

* libnet-ntp-perl

* openntpd (which also installs a listening daemon)

* python-ntplib

In most cases, such as on my laptop, workstations, and embedded systems, I don't want the complexities of a full blown daemon running, nor do I want to manage firewalling and configuring the daemon to listen on localhost to prevent remote queries. The only other two options are programming libraries.

As such, I'm looking forward to systemd-timesyncd. It implements a simple SNTP client to synchronize your clock. As such, the full NTP complexity is not a concern. This is very likely an attractive scenario for most GNU/Linux installations, as most users won't be interested in running an NTP daemon synchronizing other NTP client clocks.

Re: Ntimed – NTPD replacement

#22

Post by jeltz »

threeseed wrote: post #13
SrslyJosh wrote: post #9

Earlier quoted context omitted.

That sounds like you're implying that safety has no value, the only "overhead" worth considering is CPU cycles (what about the programmer's time/effort/sanity?), and that abstractions have negative value. I don't think that's how you're supposed to software.

It's a core operating system component not some web app. Overhead is important since Linux is designed to run on a whole spectrum of devices. Abstractions mean you are bringing in more code i.e. greater complexity, space, overhead. And frankly nobody could care less about programmer's time/effort/sanity in this case. It is a tightly focused, specific utility that shouldn't see too many changes after a certain point.

Overhead matters, but languages like Rust, D, and Nim add little overhead if any and should be perfectly possible to use as systems languages.

Re: Ntimed – NTPD replacement

#23

Post by StillBored »

zzzcpan wrote: post #11
SrslyJosh wrote: post #9

Earlier quoted context omitted.

That sounds like you're implying that safety has no value, the only "overhead" worth considering is CPU cycles (what about the programmer's time/effort/sanity?), and that abstractions have negative value. I don't think that's how you're supposed to software.

Yeah. Especially considering that CPU overhead has very little value for time syncing program.

but latency, and jitter, are important in this application. Two things that discount most of the "safer" languages. After ignoring inmature ones, the field is pretty barren.

Re: Ntimed – NTPD replacement

#24

Post by rab_oof »

lazyjones wrote: post #3
ams6110 wrote: post #2

According to the OpenNTPD web page, "The portable version is outdated and in need of a maintainer." Why another from-scratch rewrote, instead of helping with that project, especially when it was also motivated by an aversion to the "100,000 KLOC" in the ntp.org ntpd?

> Why another from-scratch rewrote, And why oh why in C with so many safer options available today ..

The Rust and Go clones popping up as Show HN will predictably follow.

Re: Ntimed – NTPD replacement

#25

Post by cbd1984 »

[deleted] wrote: post #19
cbd1984 wrote: post #18

Earlier quoted context omitted.

Abstractions are what make it possible to reason about complex systems. Being able to ignore parts of your codebase is the only way to make changes to it once it gets beyond a trivial size. The whole of the Unix philosophy is enforcing this policy of strong abstractions by making each part of a complex overall system its own binary, such that they can only communicate using the file I/O abstraction, possibly via pipe…

[deleted]

Even if your comment both made sense and was factually accurate, it wouldn't have much relevance to the kind of C programming I'm talking about: For example, mmap(2) isn't defined in the C standard but in POSIX, but it's universal in the Unix and Unix-like OS world to the extent programs can safely rely on it.

Standards are good and useful things, but they're only fully written down in retrospect.

Re: Ntimed – NTPD replacement

#26

Post by swinglock »

atoponce wrote: post #21

If Ntimed separates out the client from the daemon, so I can install just the client package only, IMO that will be a big win for computer time synchronization. One thing that has always bothered me with the NTP project, is the lack of a separate daemon and client. If you want the NTP project's client, then you must also install the daemon, even if it is listening only on localhost, or if you opt to not start it up o…

Debian has a chrony package as well, another alternative ntpd.

Re: Ntimed – NTPD replacement

#27

Post by rab_oof »

cbd1984 wrote: post #18
nwmcsween wrote: post #14

Earlier quoted context omitted.

Safety has value it just doesn't imply overhead. Abstractions are a negative, they make reasoning burdensome.

Abstractions are what make it possible to reason about complex systems. Being able to ignore parts of your codebase is the only way to make changes to it once it gets beyond a trivial size. The whole of the Unix philosophy is enforcing this policy of strong abstractions by making each part of a complex overall system its own binary, such that they can only communicate using the file I/O abstraction, possibly via pipe…

Lifting up constants into defines/consts and DRYing up C code makes for shorter, less error-prone and easier-to-understand codebases. Eg there's no reason to continue writing code like it's 1960's because we can steal good software eng and maintainability lessons from everything that has come since. (If one must maintain absolute portability.)

PS: I would like to see a toolchain for Go that emits portable C instead of statically linking in a giant runtime... Lightweight camping vs. YAGNI hoarding. Seriously, the weight of runtimes would be the biggest barrier to serious systems deployment, outshining the slowdown, productivity and safety tradeoffs. (Eg Go would need to play nice with embedded constraints including memory usage as well.).

Re: Ntimed – NTPD replacement

#28

Post by asveikau »

stonogo wrote: post #8
lazyjones wrote: post #3

Earlier quoted context omitted.

> Why another from-scratch rewrote, And why oh why in C with so many safer options available today ..

The appropriate systems language for use on UNIX and Linux is C. The entire interface is based on C conventions. Sometimes, when all you have is nails, you really ought to reach for a hammer.

I seriously think the C-hater crowd on HN is just disappointed that they can't reason well about pointers. They can't write good C so no one can! It needs, like, more javascript, man.

(Preemptive response to downvoters: please have a sense of humor about yourselves. :P)

Re: Ntimed – NTPD replacement

#29

Post by vertex-four »

threeseed wrote: post #12
dezgeg wrote: post #10

Earlier quoted context omitted.

Rust. Some of it's design goals (as stated on their webpage) are among the exact things you mentioned: zero-cost abstractions, minimal runtime, guaranteed memory safety, threads without data races.

Rust isn't even at version 1.0 yet and is probably a year away from being in a "suitable for production" state. System time is far, far too critical to take chances with.

On the other hand, this program is going to take a year or so before anybody seriously considers using it, simply due to the fact that few people are going to do something other than their distro default for such a small part of their system.

Re: Ntimed – NTPD replacement

#30

Post by function_seven »

tedunangst wrote: post #20
[deleted] wrote: post #19

Earlier quoted context omitted.

[deleted]

Section 7.19.3.

I'm getting 7.21.3, reading here[1], but that's the draft spec for C11. I couldn't find the official one anyhere.

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Post reply on HN