One of the advantages of breaking VBox into a GUI and Service is it allows for the possibility of other GUIs over time, such as a web interface.
On Fri, Jan 23, 2009 at 10:31 AM, Pablo Sanchez <[email protected]> wrote: <snip> > Ah, I see where you're going with it ... for me, it'd depend on how > `heaviness' of the daemon/service. <snip> I don't see any performance difference either way. The service shouldn't use any more resources than running in user space. I'd suspect either no difference or better performance as the GUI and the Service, each being more focused could be better optimized. In some aspects this is the difference between the Windows monolithic programming model and the UNIX/Linux incremental model, smaller programs that do one thing and do it well, systems are created by putting together these smaller programs, the components are available for reuse in ways that were not foreseen by the original developers. On Fri, Jan 23, 2009 at 1:50 PM, fcassia <[email protected]> wrote: <snip> > Running VirtualBox is user space has a lot of advantages, ie you can run it > without having root access. > > If you change it to work as a service then the user must first make sure he > has administrator privileges to launch a new service. The setup of the service happens at installation time, which requires atleast power user privs. The service starts at system boot, it is up to the service to decide which processes it will interact with. I'd postulate there are more advantages than disadvantages running a service than strictly in user space, I don't see this as a valid argument. I think running as a service would better support your argument as the service and Guest VM would run as administrator without requiring the GUI to do so. Isn't this the security model being adopted by Vista and Windows 7 (from Unix) as generally accepted as being more secure? > Plus, I have seen instances (I admit on old NT4, not recently) where a > service refused to stop, or refused to launch, and the only solution to such > hosed machine was rebooting thesystem. Whereas on a process-based > architecture, you just kill the process and restart it. With a service you can still just kill the process. This is a quality of software issue that exists regardless at to it being a service or not, if the service hangs trying to shutdown, there is something wrong with the code not the architectural model. The question seems to come down to how one intends to use VBox. Running in user space limits it to a user tool. For someone contemplating using it for production, its current architecture is a limitation. I'd contend the GUI/Service model serves both uses better than the current model. I can see that I'm looking from a different view point, coming from the Xen world, the limitations jump out, but I can understand it might not be as obvious from other view points, but I suspect that it will over time. Brett _______________________________________________ vbox-users mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-users
