Florent Daigni?re skrev:
> * Zero3 <zero3 at zerosplayground.dk> [2008-11-26 23:33:47]:
>
>   
>> Florent Daigni?re skrev:
>>     
>>> * Zero3 <zero3 at zerosplayground.dk> [2008-11-26 22:39:58]:
>>>
>>>   
>>>       
>>>>>> Will there be one available within reasonable time perhaps,  or will 
>>>>>> we have to depend on the non-free one later on?
>>>>>>         
>>>>>>             
>>>>> Ensuring that the code works reliably on other jvms takes dev's time
>>>>> we'd rather spare somewhere else. It's all a matter of priorities, like
>>>>> usual.
>>>>>   
>>>>>       
>>>>>           
>>>> We all know? That didn't quite answer though:
>>>>
>>>>     
>>>>         
>>>>>> Will there be one available within reasonable time perhaps,
>>>>>>         
>>>>>>             
>>> Go and ask people who write free jvms, not me.
>>>   
>>>       
>> Could be that you had some knowledge about the "jvm market", since you 
>> know that they at least do not provide the features Freenet needs?
>>
>>     
>>>   
>>>       
>>>> and
>>>>
>>>>     
>>>>         
>>>>>> will we have to depend on the non-free one later on?
>>>>>>         
>>>>>>             
>>> Why would we have to depend on something? To get our packages included
>>>  into the main repository of some distributions (that includes debian),
>>>  yes, we would have to get rid of our dependancy on non-free software.
>>>
>>> But that's not our problem: that's the packager's one, isn't it? There
>>> is no reason to make it *our* problem.
>>>
>>>   
>>>       
>> You said we did, not me? Surely it is the devs problem if Freenet can't 
>> be made available in linux distro repositories because of depencies to 
>> non-free software?
>>
>>     
>
> No it's not. We do provide sources, and we do provide a cross-platform
> installer: everything else isn't our problem... That's the point of
> outsourcing it: sparing our dev's time.
>
>   

I guess I just don't follow you very much. It seems plain stupid to me 
to code something that only works on a specific jvm platform and not 
caring about which jvm platform the users actually use. No wonder 
Freenet isn't larger if that's the general development philosophy.

>>>>>>>>> The idea is to minimize the amount of data to download in order 
>>>>>>>>> to both spare bandwidth and reduce the overall installation 
>>>>>>>>> time.
>>>>>>>>>                   
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> Not worth the trouble/annoyances/extra download time/... IMHO.    
>>>>>>>>          
>>>>>>>>             
>>>>>>>>                 
>>>>>>> That's your view, not mine. Come back with figures and real arguments if
>>>>>>> you plan to be convincing. Last time I checked I am the one who wrote
>>>>>>> that part of the code... So I am the one who decides how it's done.
>>>>>>>
>>>>>>>         
>>>>>>>           
>>>>>>>               
>>>>>> That seems like an awfully closed-minded attitude for a collaborative 
>>>>>>  open-source project like Freenet.
>>>>>>
>>>>>> Being hosted at SourceForge, I can't see bandwidth being a problem?
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> We left SourceForge years ago because of their chronical unreliability.
>>>>>   
>>>>>       
>>>>>           
>>>> Oh. What's http://sourceforge.net/projects/freenet/ all about then?
>>>>
>>>>     
>>>>         
>>> Nothing.. PR I guess... I told toad to get rid of it. Did you see that
>>>  there is only a README downloadable over there?
>>>
>>>   
>>>       
>> Look closer: 
>> http://sourceforge.net/project/showfiles.php?group_id=978&package_id=973
>>
>>     
>
> Yeah... all I see below "current" is a README file.
>
> Why don't you tell me what I should be looking for?
>   

All the files under the 0.7.0 branch, for example?

In any way, we are kind of off-track here. Topic was whether the 
"overhead" by packing plugins into the installer actually matters.

>>>>>> But since you want some figures: I just did a test install. 
>>>>>> Downloading  and setting up the plugins took the installer ~10 
>>>>>> seconds on a 2 year  old mainstream laptop with Windows XP. The 
>>>>>> plugins take up 383 KB. I  don't know how many people that uncheck 
>>>>>> any or all of the plugins before  installing, but I doubt it's a 
>>>>>> large part. Even if *everybody* unchecked  all plugins in the 
>>>>>> installer and we assume nobody will ever install them  later on, the 
>>>>>> overhead would be less than 4% of the ~10 MB that was  downloaded 
>>>>>> during the install. In reality, that number will be *much*  smaller 
>>>>>> as many people *will* install the plugins. If SourceForge can't   
>>>>>> keep up with that little extra bandwidth, I'll be glad to donate.
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> We did call for mirrors a while back, and we usually do before we
>>>>> announce any new release.
>>>>>
>>>>> Right now we have 6 working ones and 13 configured.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> What are the requirements, besides standard HTTP access to the actual 
>>>> files?
>>>>
>>>>     
>>>>         
>>> Being able to run a gnu/rsync client to get the files on a regular
>>> basis. We do ask mirrors to pull updates very frequently.
>>>
>>>       
>> I've got an account on dreamhost.net with virtually unlimited bandwidth 
>> and shell/cron access, so if you can provide me with whatever command 
>> line arguments rsync should use, it shouldn't be a problem. It's not 
>> enterprise-level uptime, but I haven't had more than a single or two 
>> outages in the years I've been with them. Server is physically located 
>> in USA.
>>
>>     
>
> Cool. I might contact you soon to set a new mirror up then.
>   

Feel free to.

>>>>>>>>> I don't get what you mean here. Are you seriously suggesting 
>>>>>>>>> that  multi-user computers should run multiple, concurrent 
>>>>>>>>> nodes? It's not like running a freenet node was overhead 
>>>>>>>>> less... nor like we wanted to maximize churn.
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> Not at all! I'm suggesting that users share the program files and 
>>>>>>>>  machine settings (which should be equal for all users) but *do 
>>>>>>>> not*  share identities and user-specific settings (privacy and  
>>>>>>>> customization concerns). Atm., everything is shared on Windows 
>>>>>>>> and nothing is shared on Linux.
>>>>>>>>             
>>>>>>>>             
>>>>>>>>                 
>>>>>>> That's because there is no easy way of "sharing" stuffs on Linux. There
>>>>>>> is a bug ticket for it and it's a long-overdue. I just didn't get 
>>>>>>> around to
>>>>>>> implement it yet.
>>>>>>>
>>>>>>>         
>>>>>>>           
>>>>>>>               
>>>>>> I'm not sure I understand you. Doesn't most applications do this? 
>>>>>> Keep  the program files in the "public space", and the settings 
>>>>>> inside the  users' home folders (in hidden subfolders)?
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> You are not comparing similar applications... Freenet is different from
>>>>> emule/bittorent... you should compare it to servers: Apache/Mysql... or
>>>>> even MLDonkey if you want to stay in the field of what is called "p2p
>>>>> software" by users... Like for them, we do require a high uptime... and
>>>>> like for them there is no per-user settings.
>>>>>   
>>>>>       
>>>>>           
>>>> Freenet has user settings, yes? Darknet friends, fproxy bookmarks,  
>>>> fproxy theme and misc settings, ... Or am I misunderstanding you?
>>>>
>>>>     
>>>>         
>>> That's not user-settings. Darknet friends definitely aren't; And each
>>> application can have its own private download queue (hidden from other
>>> users).
>>>
>>> Bookmarks might be at a later stage but aren't either right now.
>>>
>>>   
>>>       
>> I know they are not at the moment, but they *should* be, right? Multiple 
>> users shouldn't share those things?!?
>>
>>     
>
> What are you doing here? Stating the obvious?
>   

Yes, I was stating the more or less obvious in my original response to 
Ian, by pointing out that Freenet needs the separation.

> I am tired of people saying what should and shouldn't be done. If you
> want to express your views do it using the appropriate channel: fill in
>  enhancement requests on the bug tracker!
>
>   

I thought you usually discussed things and came to agreements before you 
added them to the bugtracker - but if you'd rather have me fill it in 
there, I'll do so instead.

>>>>>> I totally agree with you - that the devs should make all the 
>>>>>> decisions.  All I ask for is that the users aren't flamed to death 
>>>>>> because they  kindly spend their freetime trying to improve the 
>>>>>> project by writing  down their thoughts and opinions.
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>>> Some people (myself included, indeed) have different opinions. 
>>>>>>>> (It was discussed on this mailing list a while ago I think - and 
>>>>>>>> on IRC on multiple occasions). Both sides have supporters. I'm 
>>>>>>>> not aware of when Freenet was a service and when not. Atm. I can 
>>>>>>>> just comment on how Freenet works today.
>>>>>>>>             
>>>>>>>>             
>>>>>>>>                 
>>>>>>> I don't intend to be rude here but that's what you are missing here:
>>>>>>>  history and experience. Most of what you have been suggesting has
>>>>>>>  already been tried or is on the TODO list.
>>>>>>>
>>>>>>> We had packages, we had a MSIS installer, ... and the list goes on.
>>>>>>>
>>>>>>> If you really think it's important and you're willing to make things go
>>>>>>> forward, gets your hand dirty and get on coding :)
>>>>>>>
>>>>>>>         
>>>>>>>           
>>>>>>>               
>>>>>> I'm trying to, actually. The barriers for actually getting a chance 
>>>>>> to  do something are kind of... tough... for Freenet though. Have 
>>>>>> been for  me, at least.
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> We can work towards easing that... writing documentation. But as far as
>>>>> I know no one asked for it so far (except Ian in a former email on this
>>>>> thread)
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> Actually, the greatest barrier seems to be the people, IMHO.  
>>>>     
>>>>         
>>> Alright... fork then.
>>>
>>>   
>>>       
>> Surely that wouldn't benefit Freenet as a whole, or the general shortage 
>> of dev power?
>>     
>
> Hmmmm. Once more I fail to understand the logic here:
>
> Either:
>       - you don't like the people => you don't contribute (what
>         happens according to what you were saying)
>       - you fork and then you actually start doing something
>
> How can it be less productive than doing nothing?
>
>   

Yes, I believe that if the developers are not friendly to newcomers, 
many of them will simply leave without contributing. I doubt many 
members of this group will fork instead (since they most likely won't 
even know much about the project yet). Just like people change jobs when 
they don't like their colleagues. Only it's much easier to find another 
project to spend time on, than it is to change jobs. Isn't that obvious, 
or am I missing your point?

>> You could also simply work towards being more friendly to 
>> people, you know...
>>     
>
> So the problem is not about "the people" but me? I might consider
> leaving you know... If I'm the problem. That's the last reply you'll get
> from me if that's what you want.
>
>   

Yes, right now, you are a barrier for me to actually support this 
project in other ways than my monthly donation. I really think this 
project is a great idea, but it seems like in no matter what angle I try 
to give a hand, you completely refuse to cooperate or even discuss 
possible solutions/improvements and instead throws a "do it yourself then".

If I'm misunderstanding you, then I'm deeply sorry, but that is simply 
how I feel about this. I have no desire for you to leave the project 
(hell, I don't even know you) - as far as I know you've done quite a bit 
of good work for Freenet through the years?

- Zero3

Reply via email to