In trying to write tests for nts_client.c I have run into a problem I do
not know how to solve, as it involved much of the structure of the
codebase as well as the build system.
Some of the code in nts_client.c calls the dns_take* series of
functions. These functions are defined in ntp_proto
The hack worked.
On 4/23/19 9:31 PM, Hal Murray via devel wrote:
There is at least one other place where the test routines have a routine to
keep the linker happy, but I can't think of what it is.
When it was mentioned I remembered seeing that in the nts.c tests.
Ironically I had to disabl
On 4/23/19 9:47 PM, Gary E. Miller via devel wrote:
And that is how cruft grows...
I only disabled them at the time of my test push because I didn't
understand what they were. With that understanding I can now remove them
entirely.
--
/"In the end; what separates a Man, from a Slave? Mone
On 6/16/19 7:47 AM, Eric S. Raymond via devel wrote:
Yes, a triage run is near the top of my to-do list. Expect to see some results
on that by midweek.
Do you cansider the NTS documentation to be in good shape?
I have a branch with a large number of NTS tests that has been sitting
in limbo
On 6/19/19 5:28 PM, Eric S. Raymond via devel wrote:
I'd like to see two different kinds of responses to this provocation.
1. Are there blockers on the road to Go?
2. No, there's something else more important to do first.
Before any general push to Go happens there needs to be either a gene
While working on the NTS test code I have reached a point where I know
that I am misunderstanding *something*, but do now know what.
According to the RFC the AEEF "ciphertext" field looks like it is a
generally usable data blob for extension data. Variable size, no
specific data, etc.
Acco
On 6/23/19 4:09 PM, Daniel Franke wrote:
The translation of the AEEF ciphertext into corresponding plaintext is
given by the negotiated AEAD algorithm; for AES-SIV, by RFC 5297. The
structure of the plaintext is defined in the draft, as a concatenation
of RFC 7822 extension fields.
This mat
Nevermind: I figured out what I failed to understand.
The handlers that use CMAC and are size locked are on the client to
server path. The server to client path *does* allow for additional data.
Nothing to see here, move along.
--
/"In the end; what separates a Man, from a Slave? Money? Powe
I have been trying to write tests for the NTS packet extension code in
nts_extens.c. Almost all of the functions end up needing to encrypt or
decrypt something. It is simple enough to feed in random data for
encryption, but for decryption the various keys and other data needs to
match up.
T
Question obsolete; I was mixing up some details.
On 6/30/19 12:35 PM, Ian Bruene wrote:
I have been trying to write tests for the NTS packet extension code in
nts_extens.c. Almost all of the functions end up needing to encrypt or
decrypt something. It is simple enough to feed in random data
On 8/28/19 1:26 PM, Hal Murray wrote:
Merge Request !1026 was merged
The Subject says "Converted stat_count struct to a module level global"
The code looks like it is un-struct-ing things.
Was that "a module level global" supposed to be "module level globals"?
!1026 moves the variables fro
The other day I determined that the flag disable_dynamic_updates
(currently in the io_data struct) is either not properly initialized, or
is blocking off a large chunk of dead code. After reading through the
relevant code and looking through the history I think it is the former:
The flag is
On 8/29/19 3:46 PM, Eric S. Raymond wrote:
By "floating", you mean uninnitialized? In C that's going to mean it's false
Yes. My understanding of C is that anything not explicitly set has
whatever random value happens to be in that memory location. Possibly
changed if certain unknown compil
On 8/29/19 4:36 PM, Gary E. Miller via devel wrote:
Hal you are corect. Page 140, section 6.7.9 Initialization.
"If an object that has static or thread storage duration is not initialized
explicitly, then:
[...]
-- if it has arithmetic tye, it is initialized to (positive or unsigned)
zero;"
On 11/20/19 5:44 PM, Hal Murray via devel wrote:
Part of the problem is that there is a lot of cruft in that area. For
example, grep for CERR_
There is a clump of signals defined as part of a ControlSession, none are ever
raised, a few are caught. Looks like somebody decided to rename things
After a great deal of refactoring, digging, confusion, and generalized
wrestling with the surprising number of tentacles that comprise the
mrulist system I can now make a report of sorts:
*Error handling expected by the protocol:*
* If there is no overlap between the requested entries and wh
assert: the daemon name should be ntpsnmpd
assert: both ipv4 and ipv6 should be implemented
assert: if both exist, they should be bound at the same time
assert: the port(s) should be choosable
=
SNMP version / security
Accord
assert: if both exist, they should be bound at the same time
If yu bind to the IPv6, you get the IPv4 for free. No need to bind both.
TIL
assert: the port(s) should be choosable
Yes, but default to the snmp port in /etc/services.
Knew it had a specific default, TIL /etc/services
asser
Forwarded Message
Subject:Re: More SNMP dependency questions, also assertions.
Date: Mon, 1 May 2017 21:08:17 -0500
From: Ian Bruene
To: Matthew Selsky
On 05/01/2017 08:50 PM, Matthew Selsky via devel wrote:
Hey Ian,
Do you intend to make this an snmp age
Currently the tests follow a general format of a comment line describing
what a particular test is attempting to test, followed by the test. I
propose that the first line of each test_* function be the assignment of
a shorter name for the function being tested. For examples see a number
of the
At ESRs request I've trawled through the C sources to see how debug
logging is handled. First, by way of summary let me present you with a
couple bits of code:
# define DPRINTF(lvl, arg)\
do { \
if (debug >= (lvl))\
mpr
On 05/30/2017 06:36 PM, Eric S. Raymond via devel wrote:
Sometime there are couple of tiers of easy cases, so you'll loop back
to step 2. The point, be lazy. Don't spend more attention on the easy
cases than you have to, so you can avoid spending less than you should
on the tricky ones.
As yo
After consolidating the relevant macros into ntp_debug.h and cleaning up
all of the simple if(debug)s I have done another grep through the
codebase. It appears that there aren't anymore cases where it is worth
creating a macro for debugging. What's left is either blocks of custom
computation,
Currently ntpq has -d and -D flags which function much like the ones for
ntpd. Except that the -d flag also sets ntpq to log to a file instead of
stderr because, um, reasons?
Proposed interface change:
-d/-D remain, but *only* affect the debug level
Add flag -l / --log-file (alt: -f, etc)
On 06/08/2017 03:22 AM, Hal Murray wrote:
If you are looking at ntpq, it would be nice if there was a simple way to see
the packets sent/received and not much else.
A few of the packets have binary data. It may be as simple as only assoc IDs
are in binary. Everything else is raw ascii so it
On 06/08/2017 02:48 PM, Eric S. Raymond via devel wrote:
Gary E. Miller via devel :
Well, more to be learned, my getopt(3p) is not the same as what I see on
unix.com. The online copy did not include the snippet I quoted. You
can confirm on the POSIX site for getopt(3P):
http://www.unix.com/
On 06/08/2017 05:18 PM, Gary E. Miller via devel wrote:
So, what do you think is still unresolved?
At this point I think we have solved it, simply by eliminating the
alternatives. It's all part of the ntpq flag discussion.
--
In the end; what separates a Man, from a Slave? Money? Power?
N
On 06/08/2017 05:29 PM, Gary E. Miller via devel wrote:
NTPsec does not use Python's getopt(). It uses argparse().
So the real alternatives here are:
1. Have the dual -l/-L flags
2. Convert ntpq from getopt to argparse
--
In the end; what separates a Man, from a Slave? Money? Power?
No. A
First: I am not considering performance here *whatsoever*, even if there
were a meaningful difference, which I doubt, option parsing happens once
during program startup, and ntpq doesn't need high speed anyway.
Advantages of getopt
getopt is simpler, it only needs argv + some definitions fe
On 06/14/2017 01:39 AM, Matt Selsky via devel wrote:
Only new NTPsec programs use argparse. Everything that's replacing NTP Classic
C code uses getopt, so that we can support python2.6 (RHEL 6 default python)
Well that settles that. I'll get the getopt version up and running.
--
In the end;
On 06/14/2017 02:30 PM, Eric S. Raymond wrote:
Yeah, I thought I recalled that this was an issue.
But wait! There's more!
argparse works just fine on Python 2.6: pip install argparse
So which is it? Is requiring argparse installation acceptable?
The conversion tradeoff was marginal enou
Think Kobayashi Maru, and you are Captain.
I concur. Time admins would not thank us for the additional dependency.
Nice timing; in testing the getopt version I think there is an
assumption that needs to be examined.
Does there need to be a default logfile name in the first place?
The o
It. Is. Done.
--
In the end; what separates a Man, from a Slave? Money? Power?
No. A Man Chooses, a Slave Obeys. -- Andrew Ryan
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
On 06/15/2017 08:24 AM, Eric S. Raymond wrote:
Good argument. The only question is whether the semantics you propose
would create a confusing difference from ntpd.
The only difference between ntpq -l and ntpd -l is that ntpd has a
default in the system logfiles. ntpq can't have optional val
Library for encoding and decoding agentx packets has been merged into
NTPsec (!506).
The code still has some flaws and inconsistencies, but the tests are
solid, the code is way overdue, and further modifications before
commiting run the risk of entering the Rewrite Timeloop.
--
In the end;
Note to self: check the reply address in the future.
Forwarded Message
Subject:Re: Time to plan for 1.0
Date: Mon, 7 Aug 2017 14:59:14 -0500
From: Ian Bruene
To: Eric S. Raymond
On 08/07/2017 11:58 AM, Eric S. Raymond via devel wrote:
If anyone thinks my a
This morning on #ntpsec:
07:45 <@esr> ianbruene: I knew the snmpd project would lead to much yak
shaving. This is actually part of the reason I viewed it
it as a
good training opportunity. When you're not under time
pressure
and can thus afford to get th
Oh, and I can confirm that the code in agentx.py (also ntpsnmpd but I
haven't merged that) is completely separate from everything else.
agentx.py can be ripped out for 1.0 without problems, it could be
shipped in a perfectly broken state without problems outside of being
/incredibly/ bad for
On 08/08/2017 09:01 AM, Eric S. Raymond wrote:
Strictly speaking you can't do that. It's the PM's decision whether
we want to drop the feature or change the schedule. We're pretty informal
here, but you need to know where those lines of authority are, because
many other projects (especially i
On 08/08/2017 11:16 AM, Eric S. Raymond wrote:
Thank you, that is correct procedure. Acting in Mark's absence I
concur; we'll slip it if you don't have it done. Mark has the
privilege to override this decision but I will be quite surprised if
he does.
Well now I'm increasing this to Officia
On 08/09/2017 01:13 AM, Gary E. Miller via devel wrote:
I find leaving ntpmon running is smoking out a bunch of hard failure.
In hindsight (yeah) we should have thought of this - *I* should have
thought of this - a long time ago.
--
In the end; what separates a Man, from a Slave? Money? Po
On 08/19/2017 08:54 AM, Achim Gratz via devel wrote:
I've updated to ntpsec-0.9.7+1104 ten days ago and just realized that
the peerstats logging has changed format: if I use the new refclock
syntax, then instead of the 127.127.. in the address
field, I now get the driver name like NMEA(0). I h
On 09/14/2017 11:46 PM, Eric S. Raymond via devel wrote:
A fair point. But...on the other hand, a major platform. Not by our
criterion, which is more or less "Are flocks of these going to be
running in $J_RANDOM_HUMONGOUS_DATACENTER?" Part of our strategy is
to optimize for the toughest, hig
A few months ago when I added unit display to the python tools I created
the devel/units file to document what the assorted Important Variables
in NTPsec represent, and more importantly how that representation
changes as the data moves through the programs. Because of my lack of
knowledge of
Running tests on the new build changes:
Build and run tests:
=
standard build (python 2.7): runs normally, uses the correct libraries
from the build (this worked for me without any thingamijiggery anyway)
python3 build: tests run and use the correct libraries without
install
I pushed a fix for both of these.
On 09/26/2017 11:48 AM, Ian Bruene wrote:
python3 build: fails, can't find ntp module, after installing p3
version it runs but crashes with a type conversion error (I'll get on
this right away)
python3.6 build: ditto, but also crashes with a "ModuleNotFoundEr
The python 3 build appears to work. However it has a unicode bug in ntpq
(but not ntpmon! Yay consistency!), and I can not say that I *trust* any
of it.
This is partially my fault, as I failed to test the software in Py3 as
much as I should have. As an excuse I will note that I fixed several
On 09/26/2017 01:21 PM, Hal Murray via devel wrote:
Should we be using ntpsec rather than ntp?
If so we need to know *now*. Because every python file will need its
imports changed.
--
In the end; what separates a Man, from a Slave? Money? Power?
No. A Man Chooses, a Slave Obeys. -- Andrew
On 09/26/2017 03:19 PM, Eric S. Raymond wrote:
Can you get enough verificaion in a week? We may have to push back the release
for other reasons.
I can hammer on it, if nothing serious shows up it should be fine.
Post-1.0 I'd like to take a systematic look at how data is flowing
through the
On 09/26/2017 04:20 PM, Fred Wright via devel wrote:
I also notcied that test_agentx.py doesn't work with Python 3, but my
impression is that the agentx stuff is still a WIP, anyway.
This is true.
Indeed. When I started looking at the ntpq bug, I noticed that there
seemed to be some incons
On 09/26/2017 05:28 PM, Fred Wright via devel wrote:
[error snipped]
I have no idea whether this affects anything real or whether it's just a
test artifact. If the latter, it's clearly not a release blocker.
This error does not effect the program itself. It is part of a test jig
which is sp
On 09/26/2017 05:02 PM, Eric S. Raymond via devel wrote:
Huh? If so, why has this not shown up in the results from the FreeBSD buildbot.
Two reasons:
1. python tests still not run by the build script
2. subsequent reports are inconsistent on whether FreeBSD has a problem
or Fred's system i
On 09/26/2017 05:53 PM, Gary E. Miller via devel wrote:
Yo Ian!
On Tue, 26 Sep 2017 12:40:52 -0500
Ian Bruene via devel wrote:
Under these circumstances I strongly suggest that there be a note in
the README to the effect that python 3 compatibility is not
guaranteed.
I have been
On 09/27/2017 01:41 PM, Eric S. Raymond via devel wrote:
Hal Murray :
Are you doing anything interesting? Is anybody else getting them?
No. I've actually been asleep. :-)
I'm not seeing duplicates.
I have been, seeing duplicates that is.
--
In the end; what separates a Man, from a Slave?
Since my initial complaint about Py3 compatibility some bugs have been
fixed, agentx tests work, and I've poked at it with a stick.
Panic-mode rescinded.
--
In the end; what separates a Man, from a Slave? Money? Power?
No. A Man Chooses, a Slave Obeys. -- Andrew Ryan
Several months ago when I added the unit display feature there was a bug
that caused ntpq to crash with a unicode error for no apparent reason.
The crash was never replicated, but I added some debugging statements in
hope of catching it. Someday.
In the last week during the release delay Gar
On 10/06/2017 06:52 AM, Eric S. Raymond wrote:
In fact, all this test code is subtly wrong, and it is just blind luck
nothing went sproing sooner. Any of those assertions could have gone
toes-up at any time. The tests in posixize() are wrong, too.
The problem here is that float representation
On 10/06/2017 10:15 AM, Eric S. Raymond wrote:
This is why the minimal-change alternative is worth considering at this
point in our release cycle. It means you don't have to do that research
project.
Done, functions that can be simply changed to assertAlmostEqual have
been, problematic one
Please take a look at bug #404 at the earliest opportunity. I hate to
raise such an alarm over a test bug but we are running out of hours
before release.
Relevant problem is my final comment on the bug thread.
--
In the end; what separates a Man, from a Slave? Money? Power?
No. A Man Chooses
On 10/17/2017 05:37 AM, Eric S. Raymond via devel wrote:
Other possibilities welcomed.
Someone who understands waf: make the build run the python tests.
Note to whoever does it: you need to run them directly, python discover
requires pip.
--
In the end; what separates a Man, from a Slave?
I have pushed the prototype SNMP AgentX daemon to the repo. In it's
current state it implements the basic data retrieval packets (get,
getnext, getbulk), returning dummy values for most items. At this point
others banging on it is probably more useful than preventing commit clutter.
I make n
On 10/29/2017 02:13 PM, Eric S. Raymond wrote:
Eric S. Raymond via devel :
So what's missing? The Mode 6 transactions to get the read data?
Er, I meant *real* data.
Currently all of mode 6, much of the AgentX protocol.
Reason for merging now is that ntpsnmpd has hit the level of basic
fu
On 11/04/2017 04:54 PM, Eric S. Raymond via devel wrote:
* I would like us to plan on a short-cycle 1.1, to land early January,
with SNMP support as the big new feature. Ian: is this a realistic
timeframe?
Current tasks that I see are:
* Filling out the MIB.
* Implementing the rest of
In my report during last night's mailing list storm I mentioned needing
to change the architecture of ntpsnmpd slightly. This email is a
description of how it works now for
updation/clarification/documentation/sanity checkification purposes.
In ntpsnmpd there is a class which manages the MIB
To process the TestSetPDU the sub-agent must validate each varbind
through a series of steps detailed here
https://tools.ietf.org/html/rfc1905#section-4.2.5
There are a number of steps that I do not understand, my
summary/questions about the steps follow:
1 Denied access because not in MIB
I'm trying to fill out the MIB for ntpsnmpd and have several items that
I do not know how to get data for. This also effects ntpq as so far my
primary method of discovering what to poke mode 6 with to get what I
need has been to see how ntpq does it. A side effect of ntpsnmpd will
probably be
First issue (blocker)
I have succeeded in getting the unit testing scripts for python code to
run as part of the build on my machine, however when uploaded to GitLab
the pipelines fail with an import error in the test scripts. The test
modules cannot import the library modules they are meant
On 11/29/2017 04:17 PM, Hal Murray via devel wrote:
That link lets you test python code using the new libraries.
In a previous version of that code, the link was in ntpclients and you could
run things by cd-ing there. Now the link is in $build/main/ntpclients so you
have to cd there. Are you
The first issue has been solved, I stopped blanking out on the relevant
build code for creating symlinks and figured out what did what.
The second issue remains.
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
Man Chooses, a Slave Obeys."/ -- Andrew Ryan
/"Utopia c
On 12/01/2017 08:44 PM, Hal Murray via devel wrote:
The "uptime" variable is used to by snmp clients to do "count per time"
calculations, and also to notice how long after boot that that that daemon
started, or if its restarting. If you need to, insert into your subagent
code when it first ru
On 12/05/2017 08:24 AM, Eric S. Raymond via devel wrote:
* "Install failure on gentoo Stable" (#417) and "Python site packages
installed in wrong location" (#414). Ian has a WIP patch to fix this;
it needs to be finished and landed.
I currently do not have any handle on #417. I know where the
On 12/05/2017 02:33 PM, Mark Atwood, Project Manager via devel wrote:
Please make sure that whatever you have pushed to master is ready for
release, andor let me know if there is any good reason not to do a
release this weekend.
Only thing I have in master that doesn't match the requirement
On 12/05/2017 06:47 PM, Eric S. Raymond via devel wrote:
I'm OK with this plan - codebase seems to be in pretty good shape -
except it might make the cooldown period after Ian lands his
install-path fix a little short. Can we hold off three days or so?
I have something already. WIP MR
On 12/05/2017 11:57 PM, Richard Laager via devel wrote:
From my reading of that wiki page, the distro-packaged Python uses
dist-packages whenever stock Python would use site-packages. This way,
if you install the distro Python package *and* Python from source, you
can install modules for each
On 12/06/2017 09:11 AM, Richard Laager via devel wrote:
Probably? The behavior was already correct for the distro package. Was
anything else broken?
For installs the only remaining problem is that for unknown reasons it
sometimes doesn't follow the PREFIX when installing the python libs.
-
On 12/06/2017 04:03 PM, Hal Murray via devel wrote:
Many years ago, a friend showed me an article in a bicycle magazine about how
to get ready for a race or big ride. It had all the expected things about
getting your bike ready. It also included ironing your shirt. ??? The idea
was that if
On 12/07/2017 07:43 AM, Eric S. Raymond via devel wrote:
How important is your individual way of doing things? Would you be willing
to tolerate some inconvenience if that made the rest of us more productive?
In principle, yes. I'd need to be persuaded that the net was positive -
that the res
After reading over the discussion regarding the recent /issues/, I have
come to a side: Revert Fred's fix and throughly document the import
breakage.
Reasoning:
The standard method means that on some systems the ntp module can't be
seen by python without modifying PYTHONPATH.
The fix resu
On 12/10/2017 10:52 AM, Eric S. Raymond wrote:
Ugly, but simple. I'd like to hear counterargument from Gary and Fred before
we make a final decision. Keep it succint, guys.
Agreed. My main concern is that trying to be clever here has many ways
to go wrong, and few ways to detect them before
On 12/10/2017 04:26 PM, Ian Bruene wrote:
On 12/10/2017 10:52 AM, Eric S. Raymond wrote:
Do you understand the problem well enough that you could specify an upstream
fix?
I'm not yet certain whether python or the distributions have
jurisdiction here. Earlier comments from rlaager suggest that
On 12/12/2017 08:04 PM, Hal Murray via devel wrote:
Something broke in my setup and I can't figure out what's going on.
Er, whoops! I broke that as part of my fix for improperly generated
files. Should be fixed now.
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
I have started implementing notification support in ntpsnmpd, however I
have been unable to get it working so far. I do not believe there is an
error in the packet encoding, but there must be a problem somewhere in
my code as the master agent only ever returns responses with error 268
(proces
Never mind.
I finally tracked down the problem.
I am an idiot.
I was using the wrong OID value.
On 12/27/2017 03:36 PM, Ian Bruene wrote:
I have started implementing notification support in ntpsnmpd, however
I have been unable to get it working so far. I do not believe there is
an error i
We are on track to merging the solution in !615, if you have objections
please state them *soon*, together with a patch that fixes the problem.
We are rapidly approaching the planned mid-January 1.1 date.
To snip one large set of objections in the bud: Yes, this solution is
/hideous/. Unfort
Uh, news to me that any solution was agreed to. Last I heard this
group was in no way on the same page.
Rather than having me misread your code, can you put a plain summary here?
It's rlaager's code, the bash sys.path in each program one.
Not sure how that makes me feel better. Exactly t
First: Gary, you keep mentioning that there are "still issues with PATH"
and all of these solutions only take care of part of the problem.
What are these other issues? The only issues I know of are the Python
sys.path issue, and fallout from various attempted fixes.
As for the solutions on
On 01/04/2018 11:44 AM, Richard Laager via devel wrote:
I'm not convinced it's actually bad form. Can you elaborate on why you
see this as hideous?
My understanding is that embedding paths into code like this is
something that Shouldn't Be Done unless absolutely necessary. It also
adds the
On 01/04/2018 12:54 PM, Gary E. Miller via devel wrote:
[*SNIP* long description of why path embedding is Not Done]
RGDS
GARY
Ah. This was rattling around in the back of my head but I had forgotten
the details. !615's fix can be removed from consideration.
--
/"In the end; what separates a
On 01/04/2018 01:21 PM, Gary E. Miller via devel wrote:
What are these other issues?
The FHS, Gentoo, and AFAIK all distros, do not include /usr/local/XX
in any enviroment PATHs.
Ubuntu does. Did people just not usually use /usr/local/ much in the
Eldar Days? That would explain it not being
Oy Gary!
I think on a a couple of your responses we may be talking about
different things. However that is moot at this point, as it is clear
that we have our last solution standing: rip out the "fix" that started
this whole debate and revert to the old method.
--
/"In the end; what separa
On 01/04/2018 10:48 PM, Richard Laager via devel wrote:
Can you submit an actual merge request for review?
Currently waiting for the pipeline to finish on !641.
This changes the build back to how it used to work, it builds and
installs on my system, it has passed the build phase of the pipe
How can I get a detailed report on the new python test coverage check?
And how robust is it: does it only count the percentage of functions
tested, or can it tell what parts of a function are being exercised?
91% is higher than I expected.
--
/"In the end; what separates a Man, from a Sl
This is a summary of the last few months of intermittent arguing over
the build system. I am glossing over most details as the specifics are
not important to the summary, and I'm too lazy to track down every post
on the matter.
Just before the 1.0 release Fred Wright submitted a patch to sol
On 01/08/2018 05:30 AM, Hal Murray via devel wrote:
This smells like a Gitlab glitch, probably transient.
Is there a simple way to say "Please try again?" (without adding clutter to
git's log)
Click the pipeline icon, there will be options from there.
--
/"In the end; what separates a Man,
On 01/08/2018 03:55 PM, Matthew Selsky wrote:
report -m shows exactly which lines are missing coverage.
Ah, thanks.
We should be able to use that information to get our python test coverage to
100%.
Agreed.
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
Man Ch
I have nearly finished filling out the MIB tree for SNMP. What gaps are
left involve data I do not know how to get:
* Time Resolution (not to be confused with Time /Precision/, which is
one of the first entries I implemented)
* Time Distance
* Validation for the TestSet sequence. According
On 01/09/2018 09:58 AM, Jason Azze via devel wrote:
At the risk of sounding like a drop-out from a Scrum Master training
camp, could you explain briefly what the "story" is for this tool?
I use SNMP every day to monitor the health of lots of servers and
services, but, to be honest, I haven't b
On 01/09/2018 11:42 AM, Eric S. Raymond wrote:
Third way: there's a reference to get_resolution() ntp_systime.c at
line 147 ("After default_get_precision() has set a nonzero sys_fuzz")
that implies two things; (1) get_resolution() used to be called within
ntpd, and (2) its role has been taken o
First proposal: For cases where a piece of code needs to embed brittle
assumptions, in addition to the comment block explaining said
assumptions it should also include a HAZARD tag with a one line summary
(not unlike a git summary line). While this standard will only help to
catch instances o
Accidentally replied to ESR directly instead of the list
Update on previous status.
On 01/09/2018 11:42 AM, Eric S. Raymond wrote:
Heads up, Hal! I'd like your opinopn on these.
Ian Bruene via devel:
* Time Resolution (not to be confused with Time /Precision/, which is one of
the
1 - 100 of 166 matches
Mail list logo
