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

[Schanzenbach, Martin]

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

One other thing to this comment:
This dependency hell is a result of the bad/horrible architectural design 
choice. It should have been avoided in the first place.
And yes, a separation of gnunet-<service> and gnunet-<service>-gtk is perfectly 
reasonable.
As I said, the build order does not matter. If we want to offer a 
"gnunet-util-gtk" package, so be it.
The shared gtk implementations of subsystems is questionable anyway unless the 
"main" gtk UI allows some kind of
plugin mechanism for services and does not hardcode them.

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

signature.asc
Description: Message signed with OpenPGP