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

81–90 of 109 posts

Re: Ntimed – NTPD replacement

#81

Post by asveikau »

MaulingMonkey wrote: post #47
asveikau wrote: post #28

Earlier quoted context omitted.

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)

> They can't write good C so no one can! This is an accurate parody of my opinion. I'm unable to say "good C" with a straight face. > I seriously think the C-hater crowd on HN is just disappointed that they can't reason well about pointers. Let's be (hopefully) pessimistic and assume I'm a bottom 10th percentile programmer, and assume (I believe optimistically) that every programmer half an iota better than me is phy…

I take slight issue with talking too cavalierly about ranking programmers [what are we, the HR department at a big company? ;-)], but let's reverse it and say the top 10th percentile of people working in C write very few overflows and pointer bugs (but never zero, since we're all human). Should you therefore mistrust by default the software written by those folks, due to being burned by output from the lower 10th working in the same language? And all this despite the fact that we have some mitigations these days, such as address randomization, fewer pages being executable, privilege separation, safer coding styles and practices being pretty well known in some circles, etc.?

And where would that lower 90th be if it weren't for the fact that these days people are primarily being taught in memory safe languages? A key difference here, and one of the reasons I would resist percentile ranking for this discussion, is simple exposure and practice.

Re: Ntimed – NTPD replacement

#82

Post by digi_owl »

phkamp wrote: post #77
easytiger wrote: post #72

Earlier quoted context omitted.

That simply won't do for OP as he seems to want solely client only mode implementation of NTP. chrony supports both. He seems to think the authors of these daemons don't have his best interests at heart by adding functionality he doesn't want personally yet many other people will use.

I fully agree with him that client-only mode deserves its own program, given that less than 1% of all computers ever need to be NTP servers.

And yet he wants to go systemd...

Re: Ntimed – NTPD replacement

#83

Post by vertex-four »

lttlrck wrote: post #62
vertex-four wrote: post #29

Earlier quoted context omitted.

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.

waiting for rust to hit production readiness will not avoid that.

The point is simply that if one started a project now with the idea that it would probably only be a serious competitor in a year, Rust will most likely be ready by then - it doesn't really matter if Rust's ready right now if your project's not going to be used by anybody right now.

Re: Ntimed – NTPD replacement

#84

Post by feld »

easytiger wrote: post #46
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…

> One thing that has always bothered me with the NTP project, is the lack of a separate daemon and client. > In most cases, such as on my laptop, workstations, and embedded systems, I don't want the complexities of a full blown daemon running Pretty confused. Why would you care about a code path that isn't executed? Are upset about losing a few kb of disk space? What is the alternative to "a full blown daemon". Can y…

Have you met BIND?

Re: Ntimed – NTPD replacement

#85

Post by feld »

zimbatm wrote: post #60

The biggest annoyance with NTPD is that it will give up synching if the time delta is too large. It just shows that the software was primarily coded to be a server. If you just use NTPD to keep your machine times in sync `chrony` is a better solution for now.

There's a setting for that.

  tinker panic 0

Re: Ntimed – NTPD replacement

#86

Post by nullc »

zimbatm wrote: post #60

The biggest annoyance with NTPD is that it will give up synching if the time delta is too large. It just shows that the software was primarily coded to be a server. If you just use NTPD to keep your machine times in sync `chrony` is a better solution for now.

Giving up is also a security feature.

Whats more likely? your system clock sped up by a factor of 2 and everything kept working, or some guy on your network is trying to dork around with your time so he can bypass some time limited authentication?

Of course, the software needs to correctly handle cases like suspend where the time may honestly need to step. If it doesn't thats a short coming of the software, not a reason to eagerly make "presumed impossible" leaps just because some unauthenticated packets on the network tell you to.

Re: Ntimed – NTPD replacement

#87

Post by kolev »

perlgeek wrote: post #53
kolev wrote: post #35

Earlier quoted context omitted.

I think Rust should be the default choice from projects like this going forward.

While I agree with the motivation behind your statement, I don't think Rust has proven itself yet to the degree that it should be a default choice for anything. Remember that compilers and runtime libraries can have bugs too, and new ones tend to have more bugs than those maintained over some time.

Yes, runtimes and libraries can have bugs, too, agreed, but at least you will have to just recompile with the patched version vs having to fix and test your code as fast as possible. It's more efficient as well as fixing the core will benefit many (well, of course, that would have compromised many as well... to start with).

Re: Ntimed – NTPD replacement

#88

Post by cnst »

Well, so far -- this is only a client, so, it's not really much of a unique replacement of anything just yet.

Apart from OpenBSD's ntpd (OpenNTPD) -- http://bxr.su/OpenBSD/usr.sbin/ntpd/ -- which is a compete ntpd client/server solution done the OpenBSD way since some 2004, there's also DragonFly's dntpd -- http://bxr.su/DragonFly/usr.sbin/dntpd/ -- a client-only ntpd, originally written by Matt Dillon in 2005 -- http://lists.dragonflybsd.org/pipermail/commits/2005-April/2... -- e.g. nearly concurrently with OpenNTPD development and polish.

Oh, yeah, and PHK hates OpenNTPD. I'm surprised he apparently has recently used such nice words about OpenNTPD! One of the main reasons he was against OpenBSD's sensors framework going into FreeBSD was the timedelta sensor support, a type of sensor which basically tells you the offset of your system clock compared to some other clock source (e.g. http://mdoc.su/o/nmea.4 / http://bxr.su/OpenBSD/sys/kern/tty_nmea.c), and these timedelta hardware sensors are used by OpenBSD's ntpd to set the correct time, which seems to do the job just fine.

Re: Ntimed – NTPD replacement

#89

Post by zanny »

flogic wrote: post #78
zanny wrote: post #68

Earlier quoted context omitted.

I'm not saying a language must die because its old. Modern C++ is not bad - but you have to restrict your development into the "good" subset, and avoid the bad stuff from before. IE, use references and smart pointers rather than news and deletes. With C, there is no alternative. It is still malloc and free, still buffer overflows and integer overflows galore, and the C language standards group is not moving to make t…

I'm not going to pass myself off as a C++ expert. That said, I think it's very telling that we haven't had an unsuccessful pwn2own yet.

And most C++ is written insecurely and poorly, especially since good C++ is literally a new invention in the last three years.

It is why Rust and Go are better in general, because they force you to be safe, whereas C++ gives you all the tools you want to stab yourself in the foot in the same toolbox as all the stuff that makes sense.

Re: Ntimed – NTPD replacement

#90

Post by dbaupp »

asveikau wrote: post #79
jnbiche wrote: post #40

Earlier quoted context omitted.

You realize that the most vociferous of those decrying this language choice come from the proponents of a language that has 3 different types of pointers, right? You should check out Rust and Go. Their users are most definitely among those who fail to understand C pointers.

Rust seems interesting, though when I read about it I often think "sounds good, but why not just use C or C++?" These are, after all, already working well for a lot of people, and working just about everywhere. And you don't have issues that come with an experimental language: like on day x GC is a good idea, and on day x + 1 reference counted pointers are the way to go. The benefits range from overstated [bounds che…

Memory safety is a huge problem: every large C++ has vulnerabilities caused by memory safety problems. E.g. web-browsers get pwned because of memory unsafety. Apparently, all (or close to all) critical security bugs in Firefox were problems that Rust compilers will catch. I believe pcwalton went through Mozilla's bugzilla to check this.

In any case, bounds checking is a tiny side street in how Rust ensures memory safety: ownership and lifetimes are the important novel things (lifetimes especially are novel, only research languages have had anything similar until this point, and I don't know if any have had exactly the same system).

In Rust the story is totally settled: in order from most to least preferred/recommended: use references, no pointers, owning pointers and then start thinking about reference counting/other shared ownership.

Rust doesn't solve race conditions: it solves data races, which are also problematic (they cause memory unsafety). It is impossible/very hard to avoid arbitrary race conditions, but data races are the only ones that can cause memory unsafety directly.

Post reply on HN