Re: Determining whether gnunet is connected

[Bob Ham]

On 01/03/2022 16:54, Schanzenbach, Martin wrote:

> The pages were made in an effort to generate interest in the hope that
> helping hands arise that help us with documentation, website maintenance and 
> coding.

If you want people to help, don't mislead them.  It leaves a bitter taste.

> We know that the system is not
> in a good state at this time. Nobody is claiming otherwise.

The website gives the impression that you are claiming otherwise.

> This project is over 10 years old. A lot of stuff has accumulated.
> Entropy is a bitch.

> Instead it has strong foundations in academia. Almost all components are
> built and designed by (under)grad students and PhDs. Hence most
> components have publications surrounding it.
> While this has benefits (such as peer reviewed algorithms) it also has
> severe drawbacks: The churn of people working on the components.

Might I suggest adopting a policy that new components are never added to
the main GNUnet repository but must live separately in a different
repository until such time as they are mature and proven to be well
maintained over time?

> Have you actually tried downloading and running it?

Yes.  A number of times.

> There are packages as well for some distributions to try.

I use Debian.  The packages in Debian stable are version 0.13.x, in
other words ancient and I presume incompatible with the current network.
 Also they don't work.  The packages in Debian testing are 0.15.x and
are now incompatible with 0.16.x.  Also they don't work.

> So yes, you can download and try it.

I couldn't.  I tried packages and they didn't work.  I also tried
extensively to build from source.  I tried both 0.15.x and git, and had
major problems in both instances.

> How would people build newer applications
> (such as reclaimID or messenger) if it would not work at all?

A question I wondered myself.  Let me quote from IRC:

13:26 < dvn> GNUmoon: gnunet is useless until transport (and connected
layers) are fixed/rewritten
13:26 < dvn> that's the fact of the matter
13:27 < dvn> how can you debug CADET when the layers beneath have bugs
which make it unreliable
13:27 < dvn> it's a fools errand
13:28 < dvn> i mean no offence by saying this -- especially not to you
for trying -- but i get sad seeing people try to use this and running
into the same walls
13:28 < dvn> (over and over)

> What were the problems you encountered?

Numerous and varied.  Incorrect dependency information.  Incorrect build
instructions.  Documentation that only gives bare instructions with no
explanation of what a particular command does, how it operates, what it
interacts with, what its expected behaviour is, etc., etc.

With Debian packages, systemd units that don't and could never work.
Incorrect paths in configuration files.  Incorrect paths in calls to
binaries.

> Which application did not work?

gnunet-arm, gnunet-core, gnunet-transport, etc.

> Did you open a bug?

No.  I would have filed a bug if I had intended to make use of GNUnet.
The reason I was trying to get GNUnet running was to determine whether I
would make use of it.

> How would you improve it?

I would improve the GNUnet project by firstly setting some policies on
what is accepted in both the main software repository and the
documentation.  The aforementioned churn should be explicitly barred.
Anything that makes the documentation situation worse should be
explicitly barred.  Any documentation that duplicates existing
documentation should be barred (I'm looking at you, sections 4.8.28, 5.4
and 5.8).  Any documentation that adds more instead of fixing what's
already there should be barred.

I would improve the GNUnet project by setting an explicit goal of
producing a suite of software which is of high quality, usable and well
documented.  Such a goal has direct implications for how the project is
managed.  For example, having a goal of high quality means that you
cannot allow experimental software into the main repository.  Wrap your
head around that one.

> This is a Free Software project. We rely on everyones help.

The problems I see are not a lack of manpower but mismanagement of the
project.  You don't need to rely on other people's help in order to say
"no" when the next student comes along with a new project and wants to
add it to the main GNUnet repository, or when someone comes along and
writes their own version of a Wikipedia page and expects it to be
accepted into the GNUnet handbook.

The main problem I see is not a lack of manpower to make things better
but a lack of determination to stop making things worse.