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.
