public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* Suggestions for newbie accessibility
@ 2022-01-22 15:13 John Goerzen
  2022-01-23 18:17 ` Sergey Matveev
  0 siblings, 1 reply; 5+ messages in thread
From: John Goerzen @ 2022-01-22 15:13 UTC (permalink / raw)
  To: nncp-devel

Hi,

We've got a small group of people in the NNCP Matrix channel I mentioned
yesterday.  One of them is working on getting it set up, and based on
the questions he's had, I thought I might mention these suggestions:

- 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.

- 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.

- 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.

These two are more speculative but I suspect could also be helpful:

- Enabling multicast discovery by default could be a nice touch.
  Syncthing and Yggdrasil both do that and it seems to work well.  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.

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

Thanks,

John

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Suggestions for newbie accessibility
  2022-01-22 15:13 Suggestions for newbie accessibility John Goerzen
@ 2022-01-23 18:17 ` Sergey Matveev
  2022-01-23 21:38   ` John Goerzen
  0 siblings, 1 reply; 5+ messages in thread
From: Sergey Matveev @ 2022-01-23 18:17 UTC (permalink / raw)
  To: nncp-devel

[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Suggestions for newbie accessibility
  2022-01-23 18:17 ` Sergey Matveev
@ 2022-01-23 21:38   ` John Goerzen
  2022-01-23 22:45     ` Sergey Matveev
  0 siblings, 1 reply; 5+ messages in thread
From: John Goerzen @ 2022-01-23 21:38 UTC (permalink / raw)
  To: Sergey Matveev; +Cc: nncp-devel

On Sun, Jan 23 2022, Sergey Matveev wrote:

> 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

You have no trouble convincing me make has issues.  I started 
using scons about 20 years ago now because of that.

The comment in the channel was:

"Damn I am a bit lost 😆, this is quite the build system"

I finally told him to just run "contrib/do all" and that worked. 
(The usual go build he also tried failed with TLS errors from 
cypherpunks.ru due to the unknown CA)

Most people have no need for make, or things like it, anymore. 
Basically every language ecosystem except C/C++ have their own 
build tools now, which are widely used.  I still occasionally 
reach for make when I have a simple make-ish job, but that's not 
often.  I did a stint working on C code a couple of years ago, and 
that was using make, but aside from certain bits of Debian 
packaging scripts that use make for historical reasons, I haven't 
touched it or anything like it in anything resembling a serious 
way for over a decade (save that brief stint doing C work, and 
even that was soon transformed into work to migrate parts of the 
code base to Rust).

If somebody "just wants to install NNCP" and gets instructions 
that get in the way of that, it sours them on both redo and NNCP. 
Not beneficial for any goals.

I don't mind the advertisement, and sorted through it easily 
enough myself, but not giving a straightforward recipe by default 
can be detrimental.

>>- 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!

I am thinking I may write up something and post it somewhere, and 
give you permission to copy as much of it as you want for the NNCP 
manual, if that sounds good.

>>- 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.

The regexp in Yggdrasil is indeed nice.  I don't know how easy it 
would be to do that in NNCP.  An alternative might be a special 
token that would indicate "ALL".  Interface names are not 
particularly persistent these days and what is present when cfgnew 
is run may not be what's there later.

>>- 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.

That is fair.  Let me think about this some more.

- John

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Suggestions for newbie accessibility
  2022-01-23 21:38   ` John Goerzen
@ 2022-01-23 22:45     ` Sergey Matveev
  2022-01-24  1:46       ` John Goerzen
  0 siblings, 1 reply; 5+ messages in thread
From: Sergey Matveev @ 2022-01-23 22:45 UTC (permalink / raw)
  To: nncp-devel

[-- Attachment #1: Type: text/plain, Size: 6951 bytes --]

*** John Goerzen [2022-01-23 15:38]:
>Most people have no need for make, or things like it, anymore. Basically
>every language ecosystem except C/C++ have their own build tools now, which
>are widely used.

Make and redo are used not only for development. Actually I used make
(now redo) a magnitude times more for non-programming tasks. Those tasks
are not disappeared. So the claim about "no need for make" (I interpret
"make" as some kind of dependency tracking, build automation tool) sounds
strange for me. For example Go has *some* built-in build automation
capabilities, but they are definitely not enough for very many things,
so likely you will have "external" build automation anyway. gVisor has
Bazel targets in its Go code -- that is one of the reasons I moved to
inet.af/netstack that automatically "applied" it.

>If somebody "just wants to install NNCP" and gets instructions that get in
>the way of that, it sours them on both redo and NNCP. Not beneficial for any
>goals.

What kind of instructions and what kind of detalization people expect?
Should I write about "apt install make go whatever", "yum install ...",
"pkg ...", etc? Should I write about adding new third-party repositories
for old OS distributions, what millions of people may still have installed?
I doubt that.

I saw two kind of extreme solutions: one is just to be completely silent
about anything how to build the program, just leave CMake and expect
that user has enough knowledge how to invoke and use it. Another is to
create several hundred shell (often actually bash) script to execute it
via curl ... | sudo bash, for maximal user's convenience (as they
claim). I find that solutions not good at all. Golden mean is better.

In most cases, if someone uses Make, then he just writes "make target"
in its installation documentation. In most cases people write on GNU
Make dialect. In all that most cases it won't work on BSD systems, where
"make" is not "gmake". And I think it is ok not to bother about that
kind of differences -- you just have to only mention what exact Make
implementation/dialect you use, and then it is user's problems how to
satisfy that requirement. If software uses CMake, it does not have to
describe how to use OS'es package manager. It is too much wasted time.
Note "if you are not on GNU OS, then probably you should additionally
install GNU Make and invoke it through gmake command" is enough.

I did the same: I describe what build commands you need to do. I do not
know if person has redo installed, what kind of redo and how he can
install it in his OS of choice. I added note about implementations I
have touched and seen them working. I even added some kind of dummy
fallback variant if someone does not want to install anything
additionally to his system (like m4 or other libraries/utilities go
inside many GNU tarballs too). You should use "redo" -- that is all.
What exact implementation -- it is user's choice.

"I do not want to read anything, I just want to copy-paste and press
Enter" -- I won't help that kind of users, who just ruin their and
others security, with permanent blind curl|bash-ing/docker-run-ing and
not knowing anything happening with their computer.

>not giving a straightforward recipe by default can be detrimental.

I quote the part from "Build instructions":

    $ [fetch|wget] http://www.nncpgo.org/download/nncp-8.3.0.tar.xz
    $ [fetch|wget] http://www.nncpgo.org/download/nncp-8.3.0.tar.xz.sig
    $ gpg --verify nncp-8.3.0.tar.xz.sig nncp-8.3.0.tar.xz
    $ xz --decompress --stdout nncp-8.3.0.tar.xz | tar xf -
    $ cd nncp-8.3.0
    $ redo all

    After that you should get various bin/nncp-* binaries and
    bin/hjson-cli command (only for your convenience, not necessary
    installation). For example, documentation for nncp-bundle command
    can be get with info doc/nncp.info -n nncp-bundle.

    It uses redo build system for that examples. You can use one of its
    various implementations, or at least minimalistic POSIX shell
    contrib/do (just replace redo with contrib/do in the example above)
    included in tarball. [...]

    There is install target respecting $DESTDIR. It will install
    binaries and info-documentation:
        # PREFIX=/usr/local redo install

Are not they enough? Someone has neither fetch, nor wget out-of-box.
Someone has no GnuPG. Someone may lack "xz". Someone will lack "redo".
There are many distributions, many operating systems, many setups, that
you can never fully cover. Current documentation in my opinion
explicitly hints about download, signature verification (with separate
page how to get public key. If person does not know what is it, then
probably he should not bother about its verification), decompression,
running build command, what output is expected (binaries, .info), what
build system is used, what implementations of it can be used, how you
can try to install them under root. And before all of that note about
Debian/Ubuntu "apt ... golang" and FreeBSD "pkg install", which at least
give hints how the package can be named in real life (however personally
I do not use binary packages downloaded from the Internet at all). And
there is explicit mention that you can just "replace redo with
contrib/do" as a fallback variant, that at least will be built
sequentially, without utilizing multiple CPUs. I even believe that "tar
xf nncp.tar.xz" will work in practice everywhere, but write about robust
xz|tar. What next? We should write people that they have to start shell
interpreter by running terminal emulator, that can be found through some
"Start" button?

>I am thinking I may write up something and post it somewhere, and give you
>permission to copy as much of it as you want for the NNCP manual, if that
>sounds good.

Would be good! Similarly like I copied your instructions about Exim+NNCP
setup some time ago, that was valuable.

>The regexp in Yggdrasil is indeed nice.  I don't know how easy it would be
>to do that in NNCP.

Well, it is trivial to add (you need just to add regexp applied to
net.Interfaces() output :-)), however seems it is useful only for using
as a default option. But I do not mind against it -- it won't break any
existing configuration files.

>An alternative might be a special token that would
>indicate "ALL".

".*" as in Yggdrasil is more than enough.

>Interface names are not particularly persistent these days
>and what is present when cfgnew is run may not be what's there later.

Actually I saw non-persistent interface names only on GNU/Linux boxes.
All *BSDs I touched have them more than immutable even when changing
hardware in most cases :-). But agreed that, especially various
tun/tap/bridge/vtnet/etc, are dynamic.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Suggestions for newbie accessibility
  2022-01-23 22:45     ` Sergey Matveev
@ 2022-01-24  1:46       ` John Goerzen
  0 siblings, 0 replies; 5+ messages in thread
From: John Goerzen @ 2022-01-24  1:46 UTC (permalink / raw)
  To: Sergey Matveev; +Cc: nncp-devel


On Sun, Jan 23 2022, Sergey Matveev wrote:

[ snippage ]

> sequentially, without utilizing multiple CPUs. I even believe that "tar
> xf nncp.tar.xz" will work in practice everywhere, but write about robust
> xz|tar. What next? We should write people that they have to start shell
> interpreter by running terminal emulator, that can be found through some
> "Start" button?

Fair point.  I guess I saw someone struggling, but can agree to disagree
on this.  I'm working to make it apt-get installable on a lot of distros
as well, so that's another angle that can help.

>>I am thinking I may write up something and post it somewhere, and give you
>>permission to copy as much of it as you want for the NNCP manual, if that
>>sounds good.
>
> Would be good! Similarly like I copied your instructions about Exim+NNCP
> setup some time ago, that was valuable.

OK!  I'll let you know when I've got it.

>>Interface names are not particularly persistent these days
>>and what is present when cfgnew is run may not be what's there later.
>
> Actually I saw non-persistent interface names only on GNU/Linux boxes.

It is an annoying fix for a real problem, but I think the fix is worse
than the problem.  The problem being that on multi-NIC devices there can
be some indeterminancy in the order in which the NICs are brought up,
and things like moving them to different PCIe slots can change their
interface names.  So clearly that's not good.  So the "fix" was to tie
an interface name to its MAC.  But of course then if you replace a NIC
in the common case of a system having just one, your system won't bring
up its network stack after the reboot because the name has changed.  I'm
not a fan of this either.

> All *BSDs I touched have them more than immutable even when changing
> hardware in most cases :-). But agreed that, especially various
> tun/tap/bridge/vtnet/etc, are dynamic.

Yep, those too.

- John

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-01-24  1:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-22 15:13 Suggestions for newbie accessibility John Goerzen
2022-01-23 18:17 ` Sergey Matveev
2022-01-23 21:38   ` John Goerzen
2022-01-23 22:45     ` Sergey Matveev
2022-01-24  1:46       ` John Goerzen