Re: GSoC Proposal

Matthew Toseland wrote:
> On Tue, Mar 20, 2007 at 02:52:01PM +0000, Dave Baker wrote:
>   
>>>> [cut]
>>>>
>>>>         
>>>>> Benefits to the Freenet Community:
>>>>> With this project it will be much easier to start a Freenet Node
>>>>> in every QEmu supported Operative System.
>>>>>           
>>>> Why? Freenet already runs in Java, and half the point of Java is that
>>>> it's platform-independent. How will it being a QEmu image make it easier
>>>> than the current installer (or any hypothetical Freenet installer)?
>>>>         
>>> I think that with a QEmu machine it should be simpler because we can
>>> "pack" everything
>>> in a single executable that will start up a system that can be take care
>>> of everything involving
>>> a good functioning of a Freenet node.
>>>       
>> That's the idea of the installer - it comes as a single file. Granted, it ends 
>> up as a directory on disk (along with appropriate shortcuts and suchlike) but 
>> it essentially looks the same to the user. I can't really see as there's much 
>> of a benefit from it being in a single file (there's no shortage, after all); 
>> certainly not enough to outweight the enournmous overhead of running inside a 
>> virtualiser.
>>
>>     
>>> I mean it would be really easier 
>>> to perform auto-update
>>> for both the freenet code and the Java Virtual Machine.
>>>       
>> They both do that anyway.
>>     
>
> The JVM is auto-updated?
>   
Yes, the idea is to setup an auto-update for both the freenet code and
the JVM.
>>> For the user it is just "turning on a box" that will take care of
>>> everything. And I 
>>> think that is a good point for usability.
>>>       
>> Right now, the user doesn't have to do anything at all, on windows, anyway: it 
>> starts up on system start. On unix it's just a matter of './run.sh start' or 
>> whatever it is nowadays.
>>
>>     
>>> What is more there will be almost no security and crash problems for the
>>> hosting machine
>>> (as in every virtualized environment), probably in my application I
>>> should stress this point more.
>>>       
>> Again - Java. We're in a virtual machine anyway. We can't use up all the 
>> memory, and we get free protection against stack smashing and the like, so 
>> vulerabilities in Freenet are much less likley anyway.
>>     
>
> Now, putting it in a container - a chroot, MAC jail, whatever - and
> having the installer auto-config this and add an init script on install,
> that might be interesting, but probably very linux-specific.
>   
It can be very Linux specific inside the QEmu-Freenet, but outside I think
you can use this propreties even if you are in a Windows system
>>>>> Finally this QEmu instance could be used for studying pourposes,
>>>>> at user level too, on Freenet functionality (e.g. statistics,
>>>>> bandusage,...)
>>>>> even in a cluster of freenet nodes.
>>>>>           
>>>> Why do we need QEmu for that? We can set up an indefinate number nodes on
>>>> the same machine anyway.
>>>>
>>>> Essentially, the 'benefit' section leaves so many questions unanswered
>>>> that it doesn't actually explain the benefit at all, so I still don't
>>>> understand the point of the project. I'm sure there's a sensible aim
>>>> here, but I can't figure out what it is from reading the proposal!
>>>>         
>>> I think we should consider it from the point of view of a non-freenet
>>> developer.
>>> It could be really easier just to turn your n-virtual machines on and run
>>> classical system administration tools on it, than searching how to
>>> deploy n-nodes on
>>> the same machine. And they will have the same possibility as n-nodes
>>> connected to
>>> a virtual switch? I mean: it is like having n-computer to tests! :)
>>>       
>> Well the only thing you'd have to change to get several nodes running on the 
>> same host would be the port numbers, which you'd still have to change in 
>> qemu, I assume, otherwise your machine would have no idea which node you 
>> wanted to connect to if you pointed your browser at localhost:8888. I don't 
>> know how qemu handles multiple copies of itself all wanting to listen on the 
>> same port, but whatever you do, you still end up with the same problem.
>>     
>
> Running multiple nodes in the same VM with unnecessary layers disabled
> would be both interesting and fast enough to be useful.
>   
Maybe we can add in the GUI an option for the removal of unwanted layers.