On Tuesday 20 March 2007 14:03:11 Sback wrote: > Dave Baker wrote: > > On Tuesday 20 March 2007 13:15:54 Sback wrote: > >> Hi, > >> > >> I would like to apply this project for the GSoC. I would appreciate > >> your comments and suggestions! > >> > >> Thank you, > >> > >> Sback > > > > Thanks - I've included some comments below. > > Thank you very much for your time :) > > > [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. > 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. > If the node crashes there will be no problems for the hosting machine, > it is just "turn it off and on again". > Then it would be possible to specify even two differents subnet for the > host and the guest, > avoiding many security problems. > What do you think? > > >> It will increase > >> considerably the number of people trying this project and it > >> will be a gain for its potential too. > > > > Again, how? > > See above :) > > >> Furthermore this work could be available both as a stable > >> reference for tested freenet version and as a testing environment > >> for developers to deploy new functionality. > > > > Potentially, but again, it's Java - we're (theoretically) abstracted away > > from the machine anyway so the platform doesn't make much difference. The > > differences come from node configuration, net connection and how the node > > is peered. > > Maybe here I did not explained well. If you are developing something new > and you > want to try it. I think it would be really useful to try the changement > before on a > virtual machine than on your own PC. For instance Debian is looking for > someone > who could do something similar for their system upgrades : > http://wiki.debian.org/SummerOfCode2007/SystemUpgradeTesting Debian is an OS, so it's a rather different ball game. I can understand people wanting to test system upgrades on a virtual machine. If you want to to test potentially hazardous changes to Freenet, you just take a tarball of the directory first and restore it things go pear-shaped. > > >> 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. > > In my opinion these are a lot of interesting benefits. And I hope to have > explained it a little better. > > > Hope this helps, > > A lot! Particularlty on the part concerning the security (I left it away > > :( ) > > Thank you very much ;) > > > Dave > > [cut] > > > > Sback > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
