[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
From: |
Schanzenbach, Martin |
Subject: |
Re: [GNUnet-developers] Proposal: Make GNUnet Great Again? |
Date: |
Sat, 9 Feb 2019 18:15:47 +0100 |
> On 9. Feb 2019, at 17:13, Christian Grothoff <address@hidden> wrote:
>
> On 2/9/19 5:04 PM, Schanzenbach, Martin wrote:
>> I have some inline comments as well below, but let us bring this discussion
>> down to a more practical consensus maybe.
>> I think we are arguing too much in the extremes and that is not helpful. I
>> am not saying we should compartmentalise
>> GNUnet into the tiniest possible components.
>> It's just that I think it is becoming a bit bloated.
>>
>> That being said, _most_ of what is in GNUnet today is perfectly fine in a
>> single repo and package.
>> For now, at least let us not add another one (gtk) as well?
>>
>> Then, we remain with
>>
>> - reclaim (+the things reclaim needs wrt libraries)
>> - conversation (+X)
>> - secureshare (+X)
>> - fs (+X)
>>
>> as components/services on my personal "list".
>> I suggest that _if_ I find the time, I could extract reclaim into a separate
>> repo as soon as we have a CI and I can
>> test how it works and we can learn from the experience.
>> Then, we can discuss if we want to do the same with other components, one at
>> a time, if there is consensus and a person that
>> would be willing to take ownership (I am pretty sure we talked about this
>> concept last summer as well).
>
> Maybe you could start with extracting the SecuShare components? That
> should do for a first "experience", and be a bit more effective at
> reducing bloat as well ;-).
Well, I could, but our secushare people are quite active so maybe there are
volunteers (if they agree with the proposal at all).
Regarding "bloat". If we want to effectively eliminate bloat than let's look at
numbers:
File Sharing:
src/fs: 36918 (!) LOC in .c files
src/datastore/cache: ~15k LOC in .c files
Conversation:
src/conversation: 10538 LOC in .c files
SecuShare:
src/psyc* : ~17000 LOC in .c files (altough I am not sure about this because
theoretically psyc is a general use protocol, no?)
src/social: 9447 LOC in .c files
src/multicast: 5633 LOC in .c files
Reclaim:
src/reclaim* : ~6500 LOC in .c files
Now, considering that fs is practically always built for everybody and
SecuShare and reclaim are experimental, it hurts the most for devs that
actually compile from source.
Everything combined are 110000+ LOC which is 22% of the codebase (~500k, oO).
Considering that there is a significant redundancy in transport/ (75k) at the
moment, this number is probably closer to 25%.
Granted, this is a lot less than I expected ;), but maybe illustrates the
dimensions.
>
> That said, splitting of reclaim seems also much less problematic than
> fs/conversation, and if you then integrate reclaim with the libgabe
> tree, the overall number of downloads/installation for reclaim wouldn't
> go up, so that would certainly kill my argument of making the
> installation more complex (might indeed simplify it, as one doesn't have
> to remember to install libgabe before GNUnet to get reclaim).
Could do, but libgabe has some nasty additional deps (libpbc and gmp) which we
_might_ eventually get rid of completely by implementing GNS-based encryption.
signature.asc
Description: Message signed with OpenPGP
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, (continued)
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Christian Grothoff, 2019/02/09
- Message not available
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Schanzenbach, Martin, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Christian Grothoff, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Schanzenbach, Martin, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Christian Grothoff, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Christian Grothoff, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Hartmut Goebel, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Christian Grothoff, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Schanzenbach, Martin, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Christian Grothoff, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?,
Schanzenbach, Martin <=
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Amirouche Boubekki, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Schanzenbach, Martin, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, ng0, 2019/02/09
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Schanzenbach, Martin, 2019/02/10
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Florian Dold, 2019/02/10
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Schanzenbach, Martin, 2019/02/10
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Schanzenbach, Martin, 2019/02/10
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Christian Grothoff, 2019/02/10
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Schanzenbach, Martin, 2019/02/10
- Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?, Schanzenbach, Martin, 2019/02/10