can mine this for more material:
https://gitlab.com/esr/autodafe/-/blob/master/de-autoconfiscation.adoc?ref_type=heads
--
http://www.catb.org/~esr/";>Eric S. Raymond
in detail here:
https://gitlab.com/esr/autodafe/-/blob/master/configure.adoc?ref_type=heads
> Thanks,
>
> Joshua
>
>
> 1) https://www.phoronix.com/news/Autodafe-1.0-Released
>
> 2) https://gitlab.com/esr/autodafe/-/blob/master/hacking.adoc
--
http://www.catb.org/~esr/";>Eric S. Raymond
ms (vs 5s for .NET), and 99.99% of pauses are shorter than
7ms (92ms for .NET)!"
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
?
I've learned by hard experience not to try to do a language translation and
a rewrite at the same time, so this is a question I wouldn't want to broach
while doing a lift.
That said, I think the structure of pylib is basically sound.
--
Gary E. Miller via devel :
> > Maybe it's time to switch to Go?
>
> Please, no. Go is a garbage collected language. Just what NTPsec does
> not need, random, unpredictable delays.
We're only takling client-side as yet.
--
http://www.catb.or
be OK with your second alternative.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
y be utterly
> infeasible.
Alas, no. The downstream hashes would all change.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Checking to make sure I've resubscribed.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
tage.
>
> This should be an interesting experiment. The same info that is a
> complication also tells you what is going on.
Maybe. Or it could *obscure* what's going on in a surfeit of syntax. I've
used and read languages that have that tendency.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
erience is that my experiment of similar trivial size was a
> success. Was that because I picked a problem area that was easier
> in some measure, or maybe I just got lucky and all the library
> support I needed was already there.
My money would be on the latter.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
ot;zero-overhead abstractions". Rust may have a more expressive type system
than Go, too - there are some tricky issues around evaluating that.
Unfortunately, I found the price for these virtues too high. I wish it had
been otherwise.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
ual any more
115K 90-byte packets/second will fill a GB in about a tenth of a second.
Drop N terabytes of RAM on the problem and now you're looking at memory-full
intervals of about N * 100 seconds. It's not going to take a large N
to make latency spikes a rare
bout you, but I expect phase 2 (stupid Go to properly idiomatic
Go with fully exploited concurrency) to be a helluva lot of fun.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
ual benchmarks showing frequent GCs before I'd believe it was necessary,
though.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
step in order to keep
> up
> with a gigabit link.
Interesting. OK, then the critical-region goroutine needs to manage
some subthreads of its own.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
ted with making a packet fra,e for he send, thn
dealing with a response that comes bacl less than 100ms later.
> One area to keep in mind is the MRU list.
Good point, that is a source of allocations I hadn't thought of.
--
http://www.catb.org/~esr/";>Eric S. Raymon
Richard Laager via devel :
> On 7/5/21 8:38 AM, Eric S. Raymond via devel wrote:
> > > There is a close-to-RFC to handle this area. "Interleave" is the
> > > buzzword. I
> > > haven't studied it. The idea is to grab a transmit time stamp, then
&g
g than you are. That would be unsurprising, as in my past
experience I have been more willing to handle that kind of novelty
than almost anybody around me.
No, I'm pushing Rust away - and determined to exit from C - because of
reasons in the larger context. We need to get to a memo
ject spin between the recvfrom and sendto.
> The idea is to simulate the NTP computations and/or crypto. Do you want
> graphs?
Yes, but it's not just me that neds them. Anyone working on this code
needs to know where the bottlenecks are.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
t; > hostile client or server any way to force hitting that window.
>
> I'll work up some numbers if you think that will be interesting. (It will
> take a while. I have to put a system back together.)
Any possibility of a DDoS being feasible is interesting.
--
ut the begin/end of line timing by
> counting characters and doing the arithmetic with the baud rate.
>
> But is that worth the effort? Are there any serial devices with timing good
> enough to notice?
Good question. Certainly a Macx-1 gets nowhere n
irciumnstances, treat GC-induced latency spikes as though
they're just another kind of network weather.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
crypto
> stuff.
>
> Converting that that sort of code to Rust seems reasonable.
I want to stay away from mixing languages if at all possible. The
joints between them are always *serious* defect attractors and major
sources of maintainence complexity.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > Talk to me about what you think the effect of very occasional
> > stop-the-world pauses of 600 microseconds or less would be on sync
> > accuracy. By "very occasionally" let's say once every ten
Achim Gratz via devel :
> Matthew Selsky via devel writes:
> > On Tue, Jun 29, 2021 at 04:41:30PM -0400, Eric S. Raymond via devel wrote:
> >
> >> Well, first, the historical target for accuracy of WAN time service is
> >> more than an order of magnitude higher
Richard Laager via devel :
> Not particularly. Presumably it's just because of GPS PPS + good network?
Having a good local clock can explaiin it, yes.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel ma
he NTP packet
format would need to be redesigned.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
ave occured during refclock sampling and cause a that sample to
get tossed out.
I say "once in a great while" because a program with ntpd's memory
usage pattern is not going to trigger GCs very often. Most of the passes through
critical regions won't colli
; config file, just some command line stuff.
That's a big jump. Backward config compatibility would go out the window.
> Even if we don't split refclocks out into a separate program, we should run
> them as a separate thread so we still need an API between a refclock and ntpd
Richard Laager via devel :
> On 6/29/21 3:41 PM, Eric S. Raymond via devel wrote:
> > Well, first, the historical target for accuracy of WAN time service is
> > more than an order of magnitude higher than 1ms.
>
> My two NTP servers are +- 0.1 ms and +- 0.2 ms as mea
Matthew Selsky :
> Our target is < 1 us, even for WAN time service. We would want to
> keep/improve this accuracy target.
One *microsecond*? Has any version of NTP achieved that kind of accuracy?
I don't think we're there.
--
http://www.catb.org/~esr
the data promptly.
I'd like to hear more about this. It sounds like a separate issue from
the damon split.
> More background...
>
> I'd like to move the current kernel mode PLL to user space. I think modern
> CPUs are fast enough for that to make sense. I haven&
resulting sample.
I don't think we'll ever need to go to that third level, but we can
deal with it if we need to.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
tailed
dependency chart.
> I think the open 'issue' count would be lower if people actually
> tended to close issues.
Agreed. I occasionally do a triage pass to catch these. I guess we're
due for one.
--
http://www.catb.org/~esr/";>Eric S. Raymond
__
w.catb.org/~esr/";>Eric S. Raymond
"Today, we need a nation of Minutemen, citizens who are not only prepared to
take arms, but citizens who regard the preservation of freedom as the basic
purpose of their daily life and who are willing to consciously work and
sacrifice for that fre
been on this project, and there was GPSD before that. In
truth, we've already done most of the best practices. More effort
would have rapidly diminishing returns.
But the real problem is at a deeper level. C is fundamentally unsafe;
hardening - either as we've achieved it or as a hypoth
still the state of play, alas.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
ions to gety at things the Go
API doesan't suppport.
I don't knpw of anuy direct support for things like recv time stamps
in Rust. But Rust also has a facility to call C extensions.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Developers, please weigh in on what you think the NTPSec project's
goals for the next year ought to be. These goals can be coding
projects ("Move the Python code to Go") process goals ("Halve the size
of the issue list") or project infrastructure goals ("Build a hardware
lab so we can live-test sup
aking me actual money.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
that you lose the ability to do structured markuo of command synopses.
--
http://www.catb.org/~esr/";>Eric S. Raymond
t to continue this thread take it off the
> GCC mailing list.
>
> Thanks.
>
> Ian
Welcome to the consequences of abandoning "You shall judge by the code alone."
This is what it will be like, *forever*, until you reassert that norm.
--
http://www.catb.org/~esr/";>Eric S. Raymond
aling of no help to anyone.
If I needed more evidence that many Americans lead pampered,
cossetted, hyper-insulated lives that require them to make up their
own drama, this whole flap would be it.
--
http://www.catb.org/~esr/";>Eric S. Raymond
e as a whole to treat the profit-centered parts of the
economy as allies rather than enemies.
I won't say that a *majority* of us were resistent to this, but I
did have to work hard on the problem for a while, between 1997
and about 2003.
--
http://www.catb.org/~esr/";>Eric S. Raymond
a
galloping moral panic that somehow justifies stoning RMS and driving
him out of the village?
*grumble* Get *over* yourselves. You want to be "welcoming" to
women? Don't patronize or infantilize them - respect their ability to
tell off RMS for themselves *and then keep working with him*!
--
http://www.catb.org/~esr/";>Eric S. Raymond
Adrian via Gcc :
> Eric S. Raymond :
> > there is actually a value conflict between being "welcoming" in that
> sense and the actual purpose of this list, which is to ship code.
>
> Speaking as a "high functioning autist", I'm aware of the diff
hipping good code.
Complaints need to be discounted accordingly, to a degree that would
not have been required before the development of a self-reinforcing
culture of complaint and rage-mobbing around 2014.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Joseph Myers :
> On Wed, 14 Apr 2021, Eric S. Raymond wrote:
>
> > I'm not judging RMS's behavior (or anyone else's) one way or
> > another. I am simply pointing out that there is a Schelling point in
> > possible community norms that is well expressed as
of natural equilibrium in a two- or molti-player game, such that
when you move away from it all parties' decision costs go way up.)
--
http://www.catb.org/~esr/";>Eric S. Raymond
s clear that the amount of social friction
oroduced by attempts to eject the jerks will be far higher than if
you simply continued to tolerate them.
--
http://www.catb.org/~esr/";>Eric S. Raymond
u face a choice between being a community that is about shipping code
and one that is embroiled in perpetual controversy over who gets to
play here and on what terms. Choose wisely.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Amnon :
> An exciting announcement from the Go team this morning!
PK, that was a pretty good AFJ. You actually achieved weak level 2 on me.
Explanation of level 2 (and others) here:
http://esr.ibiblio.org/?p=3084
--
http://www.catb.org/~esr/";>Eric S. Raymond
--
Y
ete the old/unused stuff?
Yes.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
gt;
> What is the idea for USE_xxx? Is there some interesting history I've
> forgotten?
No, just boring history. I think those are old conditinal macros we
no longer use; likely they have been renamed to something else.
--
http://www.catb.org/~esr/";>Eric S. Raym
Branko Čibej :
> On 22.01.2021 05:23, Eric S. Raymond wrote:
> > Notably: dump-load-format.txt does not describe the delta format. I
> > have since seen hints in the SVN Book that version 3 uses some kind of
> > binary delta compression. But the SVN book does not describ
er invocation.
>
> I intend to merge 1207 and 1213 Tuesday. Also 1207 and 1213 the following
> Saturday.
>
> Are there any obvious (or not so) reasons why I should not go ahead?
>
> [1] https://gitlab.com/jamesb_fe80/ntpsec/-/tree/21A31-twinsock
No objection from her
a
couple of other moderately hard parts, but the project-killer is
interpreting directory copies correctly.
--
http://www.catb.org/~esr/";>Eric S. Raymond
gger issue for me right now is a whether Subversion devs
understand that Version 2 has real uses and dropping it because you
think v3 is better would cause a lot of unpleasant ripple effcts.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Julian Foad :
> Eric S. Raymond wrote:
> > Reposurgeon can't handle the Version 3 format with deltas, and there
> > is no realistic possibility that this will change because the format
> > is not documented anywhere.
>
> Isn't format 3 documented in the
I have a (possibly confused) use who says on reposurgeon's IRC support
channel "we have trouble with broken history in one of our repos and I
can't create a mirror for it via svnsync, but can create a dump file
via svnrdump. when I try to load it though, it complains about file
format version"
On
ee a very strong and specific
case for splitting up ntpd before I'd agree.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
groups, shouldn’t that same
> principal apply to platforms like AWS and Twitter?
Yes, it would. This was an astonnishingly stupid move on AWS's part;
I'm prett sure their counsel was not conmsulted.
--
http://www.catb.org/~esr/";>Eric S. Raymond
this been fixed?
It'd be nice if we could dispose of these.
I will continue to update notes/dump-load-format.txt with the things
that working on reposurgeon requires me to learn.
--
http://www.catb.org/~esr/";>Eric S. Raymond
As war and government prove, insanity is
/~esr/";>Eric S. Raymond
To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
-- Lazarus Long
be mergeable.
Annoying, but recoverable.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Sanjeev Gupta :
> As of 20 minutes ago, I can now pull from the repository unauthenticated.
Yes, and the visibility is now :Public" in the settings.
Looks like the problem is solved.
--
http://www.catb.org/~esr/";>
umber at Gif:ab.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
ad-bearers to support who aren't me.
--
http://www.catb.org/~esr/";>Eric S. Raymond
he hell did it figure *that* out?"
effects. Doclifter does this a lot. Sometimes it surprises even me.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Hal Murray :
> Please do and/or please fix our local copy. I'm focused on the
> restrict/unrestrict tangle.
Bug fixed, but I cant finf any way to subnutt uissues on ther
bugracker. Yes, I have a validayed account ob the site.
Sill looking.
--
http://www.catb.org/~es
eturn]
> 1794 | void UnityIgnore(const char* msg, const UNITY_LINE_TYPE line)
> | ^~~
>
Yes. I'll do it if yiu have not alreadsy idebtified upsrream.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
he free list was what I haf in mind.
> We should make a pass through devel/TODO.adoc and devel/TODO-NTS
Agreed,
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
lling to make
cimparibility-breaking changes to the configuration grammar, but I
have not been presented with any good reason to do that.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lis
h as goyacc that are fine for new projects, but
guaranteeing that you get the same accept grmmar from specifications in
two different generators is so difficult that I'd rather retarget
Flex and Bison than deal with that problem.
--
http://www.catb.org/~esr/";>Eric S. Ray
wouldn't want to try doing anything deeper
this close to a release. None of it's user-visible.
After we ship I''ll get off my butt about the recvbuff cleanup.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
rong case this has already occurred, and that case will
be closed when RHEL 6 goes EOL.
--
http://www.catb.org/~esr/";>Eric S. Raymond
signature.asc
Description: PGP signature
___
devel mailing list
devel@ntpsec.org
http:/
Gary E. Miller via devel :
> Yo Eric!
>
> On Thu, 3 Sep 2020 14:13:05 -0400
> "Eric S. Raymond" wrote:
>
> > Gary E. Miller via devel :
> > > Say what? This has zero to do with libraries.
> >
> > Sure it dies. Use different versions of
Gary E. Miller via devel :
> Say what? This has zero to do with libraries.
Sure it dies. Use different versions of Python, require different
library paths.
--
http://www.catb.org/~esr/";>Eric S. Raymond
signature.asc
Description: PG
t.
It will come time to end Python 2 support in GPSD soon.
--
http://www.catb.org/~esr/";>Eric S. Raymond
signature.asc
Description: PGP signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
he space personally, but
> we can use the space if you want to be pedantically correct.
I just fixed all of those.
This will probably never matter, but part of our project style is supposed
to be standards conformance so tight it squeaks.
--
http://www.catb.org/~esr/";>E
upon us, and I'm pretty certain it will arrive before
2020 ends.
--
http://www.catb.org/~esr/";>Eric S. Raymond
signature.asc
Description: PGP signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
lready a fan of LGTM - it picks up Python issues none of the rest of our
validators do
and seems at near parity on the C stuff.
I'll take a look at Codasy.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
de
call
> out to big complicated libraries written in c. You would have to rewrite
> them
> in Go.
Fair point. That changes my to-do list.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
s as well as RedHat and
>derivatives. Ubuntu 20.04 optionally allows python to point to
>python3, but always still has python3. I use Debian, Ubuntu, and
>RedHat, so I have personal knowledge here.
Yes. To the best of my knowledge every current Unix-like thing
does righ
poduced by
buffer-overrun and stack-corruption attacks, and its utility drops off
sharply for other kinds of attacks that are better foiked in different
ways.
--
http://www.catb.org/~esr/";>Eric S. Raymond
signature.asc
D
oot wasn't clear. There will be a few more
> syscalls needed by the code between early and normal droproot. Since we
> aren't processing packets during initialization there is low risk of bad guys
> getting in. But if they do
ere's no pointer arithmetic and
array accesses are all bounds-checked. Thus the utility of blocking
unexpected system calls pretty much vanishes.
Is there something wrong with this reasoning?
--
http://www.catb.org/~esr/";>Eric S. Raymond
signature.asc
Descr
Sanjeev Gupta :
> They support *any* git repository.
Huh. Their docs are out of date, then.
> Please see: https://lgtm.com/projects/g/ntpsec/ntpsec/?mode=list
That's excellent. I'll chew through some of these today.
--
http://www.catb.org/~esr/&q
hey interface with github and bitbucket.
>
> https://lgtm.com/help/lgtm/getting-started
Unfortunately, thast's a blocker. We're on gitlab.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
ked by 'lgtm.com'? They also do all kinds of
> verifications on source-code.
First I've heaerd of it. Can you point me at a tutorial on how to use it?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
en it advances our security mission by decreasing
attack surface and improving auditability/maintainability.
Proposed: We should drop support for Python 2 and use a python3
shebang in all our scripts.
Discuss.
--
http://www.catb.org/~esr/";>Eric S. Raymond
"Say what
tired. I'm continuing tio work on this.
As usual, I don't see anything really serious on the issue list.
Good work, everyone!
--
http://www.catb.org/~esr/";>Eric S. Raymond
If a thousand men were not to pay their tax-bills this year, that would
... [be] the defini
e from scratch if
> you understand the above description.)
I'm going to say drop it, and here's why.
We've already seen the frequency of seccomp bugs drop over time, and that's
to be expected. There should be fewer in the fture than there have been
in t
Hal Murray :
> > I'll do a bug-triage pass.
>
> I've seen a couple of changes go by. Thanks.
>
> Please let me/us know when you are finished so I can test things.
Will do.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
website.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Daniel Franke :
> clock_gettime is. Adjtimex isn't in any standard except for an obscure RFC
> that nobody follows.
>
> On Tue, Aug 25, 2020, 20:47 Eric S. Raymond via devel
> wrote:
>
> > Hal Murray via devel :
> > >
> > > When was clock_gettime
Hal Murray via devel :
>
> When was clock_gettime and struct timespec introduced?
>
> We can cleanup some cruft if we assume it exists.
Assune it. These are in the Single Unix Standard.
--
http://www.catb.org/~esr/"
s have to think about things we would rather not think about.
Quite. And we can do it off-list.
--
http://www.catb.org/~esr/";>Eric S. Raymond
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe fr
1 - 100 of 7786 matches
Mail list logo
