On Thu, Jun 9, 2011 at 23:37, Dave Jones <da...@redhat.com> wrote: > On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote: > > On Thu, Jun 09, 2011 at 08:01:06PM +1000, Chris Jones wrote: > > > > > I agree. As virtualization technology becomes more and more involved > > > and frequent on users systems, particularly with advanced Linux users, > > > I think there needs to be a strong focus on ensuring that all releases > > > run in virtualized environments without any major issues. ie. > > > Virtualbox. > > > > > > Perhaps a dedicated team among the developers who specialize in this > area. > > > > I don't think there are any developers working on this area, where "this > > area" is Virtualbox. We don't ship Virtualbox. We don't ship a kernel > > that has any knowledge of Virtualbox. There's a good argument for having > > this be part of the QA process and requiring that we boot in the common > > virtualisation environments as part of the release criteria, but I don't > > think we can realistically suggest that our virtualisation developers > > (who work on code that has nothing to do with Virtualbox) be responsible > > for that. > > I'm curious why virtualbox has gained so much inertia so quickly. > Based solely on the number of kernel bug reports we get that seem to be > related to it, I have almost zero confidence in it being reliable. > > Why are people choosing it over other solutions, and what can we change > in qemu/kvm to get users using that instead ?
I don't know about anyone else but i found in the days before processors had hardware virtualization support (i think i had an Athlon 64 x2 at the time) VirtualBox seemed to run most things i threw at it at quite a usable speed while all the other open source options seemed to work but the performance was on par with swimming through concrete. Things may have improved since but i only use virtual machines every now and again so i just stick to what's easy. -- There are 10 kinds of people in the world: Those who understand binary and those who don't...
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel