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