gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?


From: ng0
Subject: Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
Date: Sat, 2 Feb 2019 12:18:14 +0000

Schanzenbach, Martin transcribed 8.9K bytes:
> Hi,
> 
> > On 2. Feb 2019, at 11:12, Christian Grothoff <address@hidden> wrote:
> > 
> > Signed PGP part
> > Hi Martin,
> > 
> > I'm honestly not sure about your idea, but mostly because I totally
> > don't see where to draw the line, or whether it would help or hurt.
> > Maybe you have a great idea here, but I just see issues:
> > 
> > For example, is GNS part of GNUnet "core" or an application? What about
> > gnunet-dns2gns? Is ReclaimID part of GNS?
> 
> 
> Yes, I see that problem. The line would have to be drawn more or less on  a 
> "best effort"/"least overhead" basis for existing applications.
> For _anything_ new, always default to a new repo and then, if consensus 
> and/or common sense agrees, merge it into the core package.
> For example:
> 
> I _should_ have built reclaim (src/reclaim) as a separate package. It would 
> have included the attribute-based encryption functionality as well (src/abe).
> This would have allowed the dependencies of the gnunet core package to stay 
> the same at first.
> If at any time in the future we think the ABE functions are useful to other 
> services/apps, we coult merge it into the core.
>  Regarding the dns2gns: as it requires little additional dependencies, I 
> would argue that it can sta part of GNS.
> However, the proxy might as well be a completely separate package.
> 
> Think:
> 
> $ apt install gnunet(-core)
> $ apt install gnunet-gns-proxy
> $ apt install gnunet-fs
> $ apt install gnunet-conversation
> $ apt install gnunet-gtk
> 
> Subjectively, this feels right to me.
> Is separation like this even possible with the current repo structure??
> 
> Now we also have to look at how devs look at this (see below).
> 
> > 
> > Similarly, Lynx's vision for SecuShare incluced file-sharing. How do you
> > manage such dependencies? It seems to be possible to split up the
> > sources into anywhere between 1 and 50 packages!
> 
> Yes, in particular the dependency management is a bit non-trivial. I see the 
> problem here.
> 
> > 
> > What do we do with gnunet-gtk? Already some people miss out on
> > gnunet-gtk because they don't get that it's a separate download. Do we
> > create a gnunet-fs with or without gtk? Do you then have to configure
> > and install
> > gnunet-core+gnunet-gtk-base+gnunet-conversation+gnunet-conversation-gtk
> > in that order? Or do we merge all gnunet-gtk stuff with gnunet-core
> > and/or the respective applications? But gnunet-gtk-common cannot even be
> > tested right now without some application.  Is splitting the sources
> > into 30+ sub-sources really going to make it _easier_ to install!??
> 
> The build order should not matter for the average user anyway, as he will 
> install packages. Not from source.

This is not always true, depending on the package manager[1], and we should
not think about binary packages taking priority over building those
artifacts in the first place. Getting the individual packages
build should not be more difficult than today or more difficult than
any other normal software.

1: gentoo, guix, nix, pkgsrc

> So let us think about the package scenario first.
> I think there are two different "pain points":
> 
> - Separation into tiny packages
> - Monolithic "one size fits all"
> 
> Now, the problem is that tiny packages also result in a lot of packages for 
> distributors, for example.
> The monolith, however, results in a _huge_ unreasonable dependency tree 
> (Think "apt-get install gnunet" on a headless server that pulls gstreamer for 
> conversation).#

Yes, I agree with you there, it would benefit small systems.

> Not all package managers allow dynamic dependencies like e.g. gentoo where 
> compiler flags are passed at installation time.
> We need to find a good balance. I am just saying that currently, the balance 
> is skewed towards the monolith.
> 
> The other side is when we think about the development scenarios.
> Why is development of completely unrelated functionality (reclaim, secushare) 
> done in a repository alongside the code functions?
> This is prone to lead to FTBFS situations and also makes me have sources I 
> never touch or use as a dev.
> My builds are triggered by unrelated code and maybe prevents my testing in a 
> CI.
> Those are not things a dev wants. Separation of concerns as much as possible.
> 
> 
> > 
> > 
> > My general feeling: it might be better to _reduce_ the number of
> > repositories, maybe merge gnunet-gtk.git with gnunet.git if we want to
> > make the installation _easier_.  End-users don't want to have to
> > download tons of repos with complex dependencies where they need to do
> > tons of steps in the right order.
> 
> End users to not care how the repo looks. At all.
> They need packages anyway. And as elaborated above, you do not want GTK as 
> part of the gnunet package if you have a server, for instance.
> 
> 
> > 
> > Now, as for the *documentation*, that might be a very different thing.
> > There, I can very much imagine that we try to organize it better by
> > audience, and say
> > * this is for GNUnet core devs
> > * this is for ReclaimID users
> > * this is for secuShare users
> > * this is for GNS users
> > 
> > But even there, interdependencies between the modules and the need to
> > avoid duplication (and duplicated installation instructions means
> > inconsitencies when devs update one but not the other document) suggests
> > that keeping the documentation in one place would still be a good idea,
> > we just need to provide _clear_ entry points based on what the user
> > wants to do!
> > 
> > 
> > Anyway, that's just my impression from the support questions we've been
> > getting over the years (and from trying to get students to install
> > stuff). Fewer steps == better.  Splitting up the sources may _seem_ to
> > make the structure more obvious for developers, but people who are
> > already hacking on the code are not the ones with usability issues.
> 
> See above. Users should be made to think in packages anyway.
> Only devs should care about repos.
> I agree with the docs, but my argument is that the docs will stay confusing 
> if they try to explain to a user that he needs to
> 
> 1. Build from source
> 2. Build in a specific way to add/remove functionality
> 
> BR
> 
> > 
> > My 2 cents
> > 
> > Christian
> > 
> > On 2/2/19 9:07 AM, Schanzenbach, Martin wrote:
> >> Hi,
> >> 
> >> over the past few months that I have spent building and trying to 
> >> deploy/release GNUnet based software I was hit more than once by its 
> >> significant size and complexity.
> >> What I mean by that is beautifully illustrated by what I call myself the 
> >> "GNUnet Spaghetti Monster": https://stage.gnunet.org/en/architecture.html .
> >> In my opinion, this conflation of low-level functionality (transport, DHT, 
> >> crypto, utilities) and applications/services (secushare/social/psyc, 
> >> voting, conversation, fs, reclaim and maybe even gns) is detrimental to 
> >> efficiently manage a GNUnet "product".
> >> 
> >> My proposal: Either with 0.11 or beyond but definitely after TNG is done 
> >> we should strive to separate the apps wrt code but also presentation (e.g. 
> >> website).
> >> First, by having gnunet-ext [1] style repos for the apps.
> >> Weather a GNUnet app lives @gnunet.org or somewhere else shouldn't really 
> >> matter that way.
> >> 
> >> My hope is that this will significantly simplify the code and build of 
> >> GNUnet "base" and allow users/packagers to cleanly separate dependencies.
> >> We might run into app dependency and GNUnet base build dependency which 
> >> might not be trivial. Hence 0.11 is probably not feasible.
> >> 
> >> WDYT?
> >> 
> >> [1] https://gnunet.org/git/gnunet-ext.git/
> >> 
> >> 
> >> _______________________________________________
> >> GNUnet-developers mailing list
> >> address@hidden
> >> https://lists.gnu.org/mailman/listinfo/gnunet-developers
> >> 
> > 
> > 
> > 
> 



> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers




reply via email to

[Prev in Thread] Current Thread [Next in Thread]