On Wed, 2012-11-07 at 05:33 -0500, Kamil Paral wrote: > > I don't think there's a conflict at all. All distros work hard to > > dual > > boot with Windows successfully because that's how you get people to > > try > > Linux: i.e., it's actually a key thing to have *in order to driver > > our > > philosophy*. > > > > > The current approach is that we don't care about problems with > > > VirtualBox, with nvidia drivers, with just about _anything_ that is > > > not included in Fedora. This test case doesn't really resonate with > > > it. > > > > I disagree, because there's a vital difference. The dual boot case is > > about having Fedora - fully 'philosophy compliant' Fedora - working > > _alongside_ a different proprietary operating system; a configuration > > that's important to support for 'ideological' reasons as much as any > > others (see above). What we don't support is proprietary components > > *inside our own operating system*. > > I also believe that the dual-boot support with Windows is important, > should be thoroughly tested, and should be in our criteria. What > annoys me is your reasoning being inconsistent with our past arguments > about VirtualBox. > > According to your explanation, VirtualBox support should be in a > completely same position as dual-boot support with Windows. It does > not change the Fedora platform, it just allows the project to run as a > whole inside a virtualized environment. I believe it's even more > important than dual-boot, because most of the newcomers don't install > Fedora into dual-boot, they are scared and unsure about what might > happen. They try it first in a VM, and #1 is usually VirtualBox. I > come across that in all my Fedora presentations, I even _recommend_ > people to use VirtualBox prior to installing Fedora into dual-boot! > > Yet, we don't give a damn about VirtualBox support. It's not in our > criteria. We don't care much about its issues. We care a bit, but not > much. Even though it's even open-source. (And it's very hard to find > reasons why it's not included in Fedora, except for a single sentence > here [1]). > > I understand there are issues that we can't fix, because VirtualBox > itself would have to be modified, and it's not under our direct > control. But there are many issues that we can fix, like bugs in > cirrus driver etc. And still we keep telling people "we don't support > VirtualBox, this is not a blocker", even when it's a showstopper and > we could fix it if we wanted. > > So if the philosophy should really be interpreted as you say, I still > find inconsistencies in our approach. Not with Windows support being > superfluous, but with other components being missing. VBox isn't unsupported for philosophy reasons exactly, but more for technical reasons. The main reason it's not packaged for Fedora is that it requires out-of-tree kernel modules. There appears to be little interest on either side for getting these upstreamed. Fedora does not accept out-of-tree kernel modules. I actually agree that your argument for supporting install as a VBox *guest* makes a lot of sense, really, it's a pretty common use case. It's probably true that we've applied the 'we don't support VBox' mantra too easily to the VBox guest case, where it doesn't entirely apply. It's more about using Fedora as a VBox *host*. I wouldn't be opposed to proposals to test or even block on the VBox guest case, as it is a common case. Though we'd need to consider the problem where it breaks because of something in upstream VBox, which we can't control; that might be a deal-breaker for making it a blocker. The other side of the 'VBox isn't supported' argument, btw, is a very pragmatic one: all the virtualization and kernel coders I've ever happened to discuss it with seem to be in agreement that, technically speaking, VBox is a pile of shit. There are reasons small-scale virt users - i.e. desktop users who use virt on a single box for testing and playing with new OSes - like it; it has a good UI for that use, and it has some features the Fedora stack doesn't yet, notably 3D passthrough. But looking at it in design and code quality terms, there appears to be a strong consensus among Fedora devs that it's terrible code which has fundamental problems that make them unwilling to commit too strongly to 'supporting' it. I don't know the details of this argument, though. Maybe someone following this thread does. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
