On Sep 3, 2014, at 6:59 AM, Alberto Ruiz <aruiz(a)redhat.com> wrote:
To be fair I mostly care about the graphics drivers, I/O is not a big
deal. The performance/experience of a GL enabled+autoresize guest vs. an
llvmpipe one is more than noticeable (specially if you're running on
battery).
Making them easier to install would be nice. But the experience it is to build them
manually is on the bottom half of my icky things list. Until just now I haven't even
bothered to go looking for it in rpmfusion, but it's there:
http://download1.rpmfusion.org/free/fedora/releases/20/Everything/x86_64/...
That's ancient. To support F21's Xorg we need to build from
VBoxGuestAdditions_4.3.15-95180 which is not available as part of the currently available
VirtualBox 4.3.14. But for that matter, VirtualBox doesn't even list Fedora 20 as
supported with vbox4.3.14. So it's kinda confusing.
The problem here is that they don't keep up with Fedora
Workstation
kernels so the user always ends up having to install all the build
dependencies and run their clumsy .run script and wait for everything to
be built, installed and then restart the vm. Which is a pretty terrible
experience.
As per the API/ABI stability, that shouldn't be an issue as long as we
provide it ourselves right?
I wasn't aware of the out-of-tree modules, is there somewhere I can read
about the rationale behind this policy?
I wouldn't want it to be any other way even if the policy could be changed. Tainted
kernels makes kernel testing almost pointless for half wits like myself. And besides
it's much simpler for user reporting and developer acceptance of kernel bug reports
that clearly indicate a not tainted kernel prior to running into a problem, rather than
having to deduce whether tainting is related to the problem. I think the effort is better
spent, even if it's a shorter dead end, to find out VirtualBox upstream's
rationale for not following proper in-tree development, the same kernel development
process their competitors comply with.
Chris Murphy