Go and Rust

2016-09-14 Thread Eric S. Raymond
Mark Atwood : > Go has a GC. the Go standard library and the complier implementation will > always be utterly controlled by Google, and will be full of Google magic. > Go's usecase is to solve Google's problems, and can basically be modelled > as "compiled Python that

Re: NTPsec's longer-term objectives

2016-09-14 Thread Mark Atwood
Go has a GC. the Go standard library and the complier implementation will always be utterly controlled by Google, and will be full of Google magic. Go's usecase is to solve Google's problems, and can basically be modelled as "compiled Python that forcefully avoids all of the kinds of typos that Dr

Re: How much do we care about high-load scenarios?

2016-09-14 Thread Eric S. Raymond
Dan Drown : > Quoting "Eric S. Raymond" : > >Achim Gratz : > >>…or move the refclocks out of ntpd altogether and use some shared memory > >>or mailbox system to have ntpd have a look at the timestamp stream from > >>each refclock. > > >

Re: How much do we care about high-load scenarios?

2016-09-14 Thread Dan Drown
Quoting "Eric S. Raymond" : Achim Gratz : …or move the refclocks out of ntpd altogether and use some shared memory or mailbox system to have ntpd have a look at the timestamp stream from each refclock. Yeah, this is one of my longer-term plans. It was in

Re: How much do we care about high-load scenarios?

2016-09-14 Thread Gary E. Miller
Yo Eric! On Wed, 14 Sep 2016 17:22:51 -0400 "Eric S. Raymond" wrote: > Gary E. Miller : > > Sadly, unless you have threading there is no way to A/B test it > > against no threading. So let us not rip out any existing threading > > until it gets tested. > >

Re: How much do we care about high-load scenarios?

2016-09-14 Thread Eric S. Raymond
Gary E. Miller : > Sadly, unless you have threading there is no way to A/B test it against > no threading. So let us not rip out any existing threading until it > gets tested. There isn't threading any there to rip out, except for the one hack to avoid stalls on DNS lookups.

Re: How much do we care about high-load scenarios?

2016-09-14 Thread Gary E. Miller
Yo Eric! On Wed, 14 Sep 2016 16:41:47 -0400 "Eric S. Raymond" wrote: > Eric S. Raymond : > > John D. Bell : > > > *If* I were the architect on this project (thankfully I'm not!) I > > > would get the code simplified and streamlined

Re: How much do we care about high-load scenarios?

2016-09-14 Thread Eric S. Raymond
Eric S. Raymond : > John D. Bell : > > *If* I were the architect on this project (thankfully I'm not!) I > > would get the code simplified and streamlined in single-thread mode > > as far as possible, and then design and code a > >

Re: How much do we care about high-load scenarios?

2016-09-14 Thread Achim Gratz
Eric S. Raymond writes: > Hal: > > But maybe we should have a separate thread per refclock to get the > time stamp. ... …or move the refclocks out of ntpd altogether and use some shared memory or mailbox system to have ntpd have a look at the timestamp stream from each refclock. Then you have

Re: How much do we care about high-load scenarios?

2016-09-14 Thread John D. Bell
Current professional systems administrator (former professional programmer) here. I hope I am adding light and not merely heat to this discussion. quoting Eric - > The underlying point is that blade and rack servers are cheap. Cycles > are cheap. This gives the option of implicitly saying to