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?

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

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

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

>>>> 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? You could also simply work towards being more friendly to 
people, you know... I don't know with everybody else, but I didn't come 
here to annoy people. I actually write here in the hope that I might in 
some way or another support this project and its goals. If I am not, 
please say so, and I will simply leave you all alone.

>> Documentation and easier methods of messing around with the code is on  
>> the list too, yea. If none is available, people probably won't even ask  
>> for it (I wouldn't!).
>>     
>
> OAHHH!
> That's productive behaviour.
>
> In case it exists and you missed it you won't ever know...
> In case it doesn't it's obviously the best way to ensure there won't be
>  any anytime soon.
>
> Yeah, you might be right, people have different ways of working and we
> don't seem to work the same way. I did write one installer so I
> obviously know how it works and how it's supposed to... If I don't hear
> that someone else is interested by some documentation, why exactly shall
> I write any? The code speaks for itself after all.
>
>   

Random example: Do you think Counter-Strike would ever have been made if 
Valve hadn't released the HL-SDK? As far as I remember, nobody asked 
Valve to, yet they did, and one of the most popular games ever were 
created by random fans. In general terms, I strongly believe that supply 
often creates demand. We might disagree on that too, I guess. Not worth 
the discussion.

I didn't ask you to write any documentation. I didn't ask for you to do 
it. I just support the proposal...

- Zero3

Reply via email to