On Tuesday 20 March 2007 16:43:49 Sback wrote: > 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.
I think the question was relating to generally, rather than your proposal. It is on Windows (or at least I've seen little things pop up on windows machines telling me that Java wants to be updated). Obviously Linux and OS X have their own software update mechanisms. > > >>> 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.
