Greetings!

*** John Goerzen [2022-01-22 09:13]:
>- On the build instructions doc page - nobody has redo installed or
>really knows what it is.  Rather than the default being to show using
>redo, have the default be "./contrib/do" and mention alternatives
>below.

I would be glad people moving from *completely useless* Make to redo. I
am strongly convinced that Make has literally no pros at all, comparing
to redo. Unfortunately Daniel J. Bernstein does not do any "advertising",
but his redo (idea) was life-changing thing in my life (after moving to
Unix-based OSes).

If I leave "contrib/do", then I am sure most even won't notice anything
related to the "redo", thinking that is just yet another some shell
script. Actually it does not do much in NNCP at all, because NNCP is
just an ordinary Go program with vendor directory, so actually the only
running redo target is bin/default.do, that just assembles LDFLAGS (that
also can be omitted at all too). But it is at least some "advertising"
of the redo. I replaced Make from all my projects (both personal and
company's), from my life completely and convinced it is worth to everyone.
https://lists.suckless.org/dev/2012/34100.html

I understand that I boldly exploit the documentation for advertisements
and mentions of some not directly related to the store-and-forward
technologies :-). My denying to give any examples with IPv4 is another
example of that approach. As daemontools and ZFS. But I try not to
overstep ethical limits.

>- After figuring out contrib/do, he built it fine on a desktop but then
>had the 32-bit problem I mentioned building it on a Raspberry Pi and
>didn't know where to go with that.  This makes me think that if gvisor
>stays in NNCP, it should be disabled by default, or at least disabled
>by default on 32-bit systems.

I hope with latest released that problem is passed away.

>- It might be useful to have a sort of tutorial illustrating generating
>a config on two systems, copying the neigh/self blocks between them,
>authorizing them to do things, etc.  I could volunteer to write this.

Initially http://www.nncpgo.org/Workflow.html page was intended for
hinting for the first steps one should do with NNCP. But I agree that it
is too terse. It should be definitely expanded. If you wish to write
that -- I would be glad for that help!

>- Enabling multicast discovery by default could be a nice touch.

MCD is enabled through configuration file with explicit interface names
specifying. Unlike Yggdrasil, there is not regexp for them, so I can not
just write ".*" there. However I can call net.Interfaces() to get all
current interface names and set them uncommented in mcd-send entry with
some default (for example 30sec) intervals, during nncp-cfgnew creation.
I think it is ok.

>It might be nice to have nncp-call have a "wait for address" capability
>to wait for an address for a one-off call, similar to nncp-caller.

Agreed, could be useful. Will add that.

>- A default call configuration could also be nice for people playing
>around with nncp-caller for the first time.

nncp-cfgnew and "Call configuration" documentation's section
(http://www.nncpgo.org/Call.html) contain some examples. I can not
imagine what else can be added there? And I can not recommend anything
related to calls, like periodicity, onlinedeadline and similar things,
because people's need are too varying here in my opinion.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF