Hello everyone
I wanted to get some feedback as to whether it would be acceptable/desirable to add whatever available graphics and IO drivers available for the most common hypervisors out there other than KVM/Spice.
My idea is that it should be possible to run Fedora Workstation in any desktop virtualization solution out of the box as long as the drivers are acceptable for us in terms of licensing. So VirtualBox is the easiest shot, and a pretty popular one on Windows and Mac users as it's (mostly) FOSS and free of charge, but it'd be nice if we could add others like Parallels or VMWare (I am investigating the availability/licensing situation of those as we speak).
I would appreciate any feedback or concerns about this proposal.
On Wed, Sep 3, 2014 at 2:30 PM, Alberto Ruiz aruiz@redhat.com wrote:
Hello everyone
I wanted to get some feedback as to whether it would be acceptable/desirable to add whatever available graphics and IO drivers available for the most common hypervisors out there other than KVM/Spice.
My idea is that it should be possible to run Fedora Workstation in any desktop virtualization solution out of the box as long as the drivers are acceptable for us in terms of licensing. So VirtualBox is the easiest shot, and a pretty popular one on Windows and Mac users as it's (mostly) FOSS and free of charge, but it'd be nice if we could add others like Parallels or VMWare (I am investigating the availability/licensing situation of those as we speak).
I would appreciate any feedback or concerns about this proposal.
-- Greetings, Alberto Ruiz Engineering Manager - Desktop Applications Team Red Hat, Inc.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Hi Alberto.
We already ship open-vm-tools by default, that should be good for VMWare users. I don't know about open source implementations of guest tools for any other hypervisors, but if we can find some that have good enough quality (and won't clash with other guest tools such as the spice one) and have no legal issues I see no reason why we wouldn't want to include them.
Keep in mind that if the guest tools / drivers you want require out-of-tree kernel modules it'd be problematic to include them in Fedora even if they are appropriately licensed.
----- Original Message -----
Hello everyone
I wanted to get some feedback as to whether it would be acceptable/desirable to add whatever available graphics and IO drivers available for the most common hypervisors out there other than KVM/Spice.
My idea is that it should be possible to run Fedora Workstation in any desktop virtualization solution out of the box as long as the drivers are acceptable for us in terms of licensing. So VirtualBox is the easiest shot, and a pretty popular one on Windows and Mac users as it's (mostly) FOSS and free of charge, but it'd be nice if we could add others like Parallels or VMWare (I am investigating the availability/licensing situation of those as we speak).
I would appreciate any feedback or concerns about this proposal.
Are they packaged in Fedora already?
They need to be in Fedora, and following the licensing guidelines before we could add them to the Workstation builds.
On Wed, Sep 3, 2014 at 7:30 AM, Alberto Ruiz aruiz@redhat.com wrote:
Hello everyone
I wanted to get some feedback as to whether it would be acceptable/desirable to add whatever available graphics and IO drivers available for the most common hypervisors out there other than KVM/Spice.
My idea is that it should be possible to run Fedora Workstation in any desktop virtualization solution out of the box as long as the drivers are acceptable for us in terms of licensing. So VirtualBox is the easiest shot, and a pretty popular one on Windows and Mac users as it's (mostly) FOSS and free of charge, but it'd be nice if we could add others like Parallels or VMWare (I am investigating the availability/licensing situation of those as we speak).
I would appreciate any feedback or concerns about this proposal.
We don't allow out-of-tree modules in Fedora. Also, VirtualBox is pathologically broken. They refuse to have a stable userspace<->kernel ABI so whenever they do a new release it can wind up breaking things and requiring a rebuild of everything. Lastly, the drivers aren't of great quality to begin with and crash rather often. The kernel team has been asked to carry VB before and we refuse to do so.
VMWare and Microsoft actually did things properly for their hypervisors and got the kernel drivers in the upstream kernel.org tree. I believe we already enable them in the Fedora kernels.
josh
On Wed, 2014-09-03 at 07:52 -0400, Josh Boyer wrote:
On Wed, Sep 3, 2014 at 7:30 AM, Alberto Ruiz aruiz@redhat.com wrote:
Hello everyone
I wanted to get some feedback as to whether it would be acceptable/desirable to add whatever available graphics and IO drivers available for the most common hypervisors out there other than KVM/Spice.
My idea is that it should be possible to run Fedora Workstation in any desktop virtualization solution out of the box as long as the drivers are acceptable for us in terms of licensing. So VirtualBox is the easiest shot, and a pretty popular one on Windows and Mac users as it's (mostly) FOSS and free of charge, but it'd be nice if we could add others like Parallels or VMWare (I am investigating the availability/licensing situation of those as we speak).
I would appreciate any feedback or concerns about this proposal.
We don't allow out-of-tree modules in Fedora. Also, VirtualBox is pathologically broken. They refuse to have a stable userspace<->kernel ABI so whenever they do a new release it can wind up breaking things and requiring a rebuild of everything. Lastly, the drivers aren't of great quality to begin with and crash rather often. The kernel team has been asked to carry VB before and we refuse to do so.
Sure, I understand and concede that VBox does a shitty job wrt their drivers, but on the other hand it is one of the most popular desktop virtualization solutions, it is pretty much the only way to test a Linux desktop OS on top of Windows and Mac that doesn't require a license.
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).
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?
VMWare and Microsoft actually did things properly for their hypervisors and got the kernel drivers in the upstream kernel.org tree. I believe we already enable them in the Fedora kernels.
Yup, so we're fine for VMWare Fusion/Workstation, and hyper-v doesn't bother me too much from a Workstation POV as it's only available on Windows Server.
josh
On Wed, Sep 3, 2014 at 8:59 AM, Alberto Ruiz aruiz@redhat.com wrote:
On Wed, 2014-09-03 at 07:52 -0400, Josh Boyer wrote:
On Wed, Sep 3, 2014 at 7:30 AM, Alberto Ruiz aruiz@redhat.com wrote:
Hello everyone
I wanted to get some feedback as to whether it would be acceptable/desirable to add whatever available graphics and IO drivers available for the most common hypervisors out there other than KVM/Spice.
My idea is that it should be possible to run Fedora Workstation in any desktop virtualization solution out of the box as long as the drivers are acceptable for us in terms of licensing. So VirtualBox is the easiest shot, and a pretty popular one on Windows and Mac users as it's (mostly) FOSS and free of charge, but it'd be nice if we could add others like Parallels or VMWare (I am investigating the availability/licensing situation of those as we speak).
I would appreciate any feedback or concerns about this proposal.
We don't allow out-of-tree modules in Fedora. Also, VirtualBox is pathologically broken. They refuse to have a stable userspace<->kernel ABI so whenever they do a new release it can wind up breaking things and requiring a rebuild of everything. Lastly, the drivers aren't of great quality to begin with and crash rather often. The kernel team has been asked to carry VB before and we refuse to do so.
Sure, I understand and concede that VBox does a shitty job wrt their drivers, but on the other hand it is one of the most popular desktop virtualization solutions, it is pretty much the only way to test a Linux desktop OS on top of Windows and Mac that doesn't require a license.
There are other repos that provide it. People are already enabling those repos for everything else that is highly useful but not provided by Fedora.
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).
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.
It's also a pretty terrible experience when they do get it to build and load and it crashes their kernel.
As per the API/ABI stability, that shouldn't be an issue as long as we provide it ourselves right?
Um... if you're ignoring the fact that it's crappy and crashes a lot on it's own even when it is kept up to date that might be somewhat true. However, with my kernel maintainer hat on, I'm asserting we aren't going to provide it.
I wasn't aware of the out-of-tree modules, is there somewhere I can read about the rationale behind this policy?
http://fedoraproject.org/wiki/Packaging:Guidelines#No_External_Kernel_Module... is the guideline, but it's short on rationale.
Briefly, 1) we aren't staffed for it, 2) it encourages crappy behavior on the part of the module authors by providing disincentive to getting it upstream, 3) it's a maintenance hassle, 4) we typically already have alternatives (this is particularly true in the case of virt), 5) it's yet another entry in an already rapidly expanding test matrix that has to be checked off (which goes back to item 1), etc etc.
I consider myself to be fairly open to many things. Carrying virtualbox modules out-of-tree when the authors refuse to even submit them upstream for review and have no intention of ever doing so is not one of those things. This is one of the few items where I simply say no.
josh
On Wed, 2014-09-03 at 09:21 -0400, Josh Boyer wrote:
Briefly, 1) we aren't staffed for it, 2) it encourages crappy behavior on the part of the module authors by providing disincentive to getting it upstream, 3) it's a maintenance hassle, 4) we typically already have alternatives (this is particularly true in the case of virt), 5) it's yet another entry in an already rapidly expanding test matrix that has to be checked off (which goes back to item 1), etc etc.
I consider myself to be fairly open to many things. Carrying virtualbox modules out-of-tree when the authors refuse to even submit them upstream for review and have no intention of ever doing so is not one of those things. This is one of the few items where I simply say no.
Do I sense a possible conflict of interest here ?
I think Alberto's argument that including such drivers will make it a lot easier to try the workstation on popular virtualization solutions carries some weight and deserves to be discussed, instead of rejected out-of-hand.
On Wed, Sep 3, 2014 at 4:34 PM, Matthias Clasen mclasen@redhat.com wrote:
On Wed, 2014-09-03 at 09:21 -0400, Josh Boyer wrote:
Briefly, 1) we aren't staffed for it, 2) it encourages crappy behavior on the part of the module authors by providing disincentive to getting it upstream, 3) it's a maintenance hassle, 4) we typically already have alternatives (this is particularly true in the case of virt), 5) it's yet another entry in an already rapidly expanding test matrix that has to be checked off (which goes back to item 1), etc etc.
I consider myself to be fairly open to many things. Carrying virtualbox modules out-of-tree when the authors refuse to even submit them upstream for review and have no intention of ever doing so is not one of those things. This is one of the few items where I simply say no.
Do I sense a possible conflict of interest here ?
I think Alberto's argument that including such drivers will make it a lot easier to try the workstation on popular virtualization solutions carries some weight and deserves to be discussed, instead of rejected out-of-hand.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Well, I have used VirtualBox guest additions before, they break every time VirtualBox is updated (and you need to update and rebuild them) and they are extremely unstable. I honestly think they provide *worse* experience for users. And I remember someone in an other thread here said their 3d acceleration is not stable enough to use with gnome-shell.
On Wed, 2014-09-03 at 16:42 +0300, Elad Alfassa wrote:
On Wed, Sep 3, 2014 at 4:34 PM, Matthias Clasen mclasen@redhat.com wrote:
On Wed, 2014-09-03 at 09:21 -0400, Josh Boyer wrote:
Briefly, 1) we aren't staffed for it, 2) it encourages crappy behavior on the part of the module authors by providing disincentive to getting it upstream, 3) it's a maintenance hassle, 4) we typically already have alternatives (this is particularly true in the case of virt), 5) it's yet another entry in an already rapidly expanding test matrix that has to be checked off (which goes back to item 1), etc etc.
I consider myself to be fairly open to many things. Carrying virtualbox modules out-of-tree when the authors refuse to even submit them upstream for review and have no intention of ever doing so is not one of those things. This is one of the few items where I simply say no.
Do I sense a possible conflict of interest here ?
I think Alberto's argument that including such drivers will make it a lot easier to try the workstation on popular virtualization solutions carries some weight and deserves to be discussed, instead of rejected out-of-hand.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Well, I have used VirtualBox guest additions before, they break every time VirtualBox is updated (and you need to update and rebuild them) and they are extremely unstable. I honestly think they provide *worse* experience for users. And I remember someone in an other thread here said their 3d acceleration is not stable enough to use with gnome-shell.
They quickly fixed their drivers the first time GNOME Shell was out to enable it (in fact it was used as an example of how requiring OpenGL forced improved drivers).
As long as you don't update your guest tools usually things are fine across upgrades (I tend not to upgrade VBox that I am not sure if other people do).
The problem from my POV is that we're out there competing for mind share with other distros, Ubuntu packages the ose (open source edition) drivers and I've never had an issue with guests running on different versions of the hypervisor, maybe some people have, but I'm pretty sure that situation is not that common. So solving this is certainly doable without a crazy amount of resources (I know because I'm pretty sure those packages didn't suck that much time from the maintainers), that said they were not included in the installer so you have to install them manually, but that's certainly a much better situation than having to run the .run script and make sure that you have build dependencies available.
At that point it seems to me that people will just rule out Fedora when trying Linux in the only free of charge/almost-FOSS hypervisor that you can use from Mac and Windows (which is what most people use), and that means that they'll try something else that works instead...
Yes VBox sucks and we call can use Boxes and virt-manager instead... but for a lot of people out there, VBox is the only available option, keep that in mind.
On Sep 3, 2014 9:44 AM, "Elad Alfassa" elad@fedoraproject.org wrote:
On Wed, Sep 3, 2014 at 4:34 PM, Matthias Clasen mclasen@redhat.com
wrote:
On Wed, 2014-09-03 at 09:21 -0400, Josh Boyer wrote:
Briefly, 1) we aren't staffed for it, 2) it encourages crappy behavior on the part of the module authors by providing disincentive to getting it upstream, 3) it's a maintenance hassle, 4) we typically already have alternatives (this is particularly true in the case of virt), 5) it's yet another entry in an already rapidly expanding test matrix that has to be checked off (which goes back to item 1), etc etc.
I consider myself to be fairly open to many things. Carrying virtualbox modules out-of-tree when the authors refuse to even submit them upstream for review and have no intention of ever doing so is not one of those things. This is one of the few items where I simply say no.
Do I sense a possible conflict of interest here ?
I think Alberto's argument that including such drivers will make it a lot easier to try the workstation on popular virtualization solutions carries some weight and deserves to be discussed, instead of rejected out-of-hand.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Well, I have used VirtualBox guest additions before, they break every time VirtualBox is updated (and you need to update and rebuild them)
For guests we control the versions via installs (not counting the recomposes that were talked about to keep new installs up to date). All we'd need to do is support ONE version of vb, and provide a dl link to THAT version. As for these anecdotes about vb not working, the fact is ANY users we acquire via this method are new users we may not have gotten otherwise. The question is whether or not the work to support that single version of vb is so great as to outweigh the potential of new users.
On Wed, Sep 3, 2014 at 9:34 AM, Matthias Clasen mclasen@redhat.com wrote:
On Wed, 2014-09-03 at 09:21 -0400, Josh Boyer wrote:
Briefly, 1) we aren't staffed for it, 2) it encourages crappy behavior on the part of the module authors by providing disincentive to getting it upstream, 3) it's a maintenance hassle, 4) we typically already have alternatives (this is particularly true in the case of virt), 5) it's yet another entry in an already rapidly expanding test matrix that has to be checked off (which goes back to item 1), etc etc.
I consider myself to be fairly open to many things. Carrying virtualbox modules out-of-tree when the authors refuse to even submit them upstream for review and have no intention of ever doing so is not one of those things. This is one of the few items where I simply say no.
Do I sense a possible conflict of interest here ?
Sure, possibly. I'm happy to remove myself from my WG seat on this topic. That doesn't mean my concerns as a kernel maintainer are invalid though.
I think Alberto's argument that including such drivers will make it a lot easier to try the workstation on popular virtualization solutions carries some weight and deserves to be discussed, instead of rejected out-of-hand.
By all means, discuss it. However, it's already been discussed several times and not a single person or group has made a case that it's worthwhile to carry drivers out-of-tree that while being open source licensed are actually not very open source friendly at all. Let alone offer to provide the resources to handle that. This is something that everyone says "oh, this sounds good" and then expects the kernel team to pick up just because. I'm saying we can't do that.
Ease of use and popularity do not always win out. If they did, we'd ship a heck of a lot more than we already do.
josh
On Wed, 2014-09-03 at 09:44 -0400, Josh Boyer wrote:
On Wed, Sep 3, 2014 at 9:34 AM, Matthias Clasen mclasen@redhat.com wrote:
On Wed, 2014-09-03 at 09:21 -0400, Josh Boyer wrote:
Briefly, 1) we aren't staffed for it, 2) it encourages crappy behavior on the part of the module authors by providing disincentive to getting it upstream, 3) it's a maintenance hassle, 4) we typically already have alternatives (this is particularly true in the case of virt), 5) it's yet another entry in an already rapidly expanding test matrix that has to be checked off (which goes back to item 1), etc etc.
I consider myself to be fairly open to many things. Carrying virtualbox modules out-of-tree when the authors refuse to even submit them upstream for review and have no intention of ever doing so is not one of those things. This is one of the few items where I simply say no.
Do I sense a possible conflict of interest here ?
Sure, possibly. I'm happy to remove myself from my WG seat on this topic. That doesn't mean my concerns as a kernel maintainer are invalid though.
I think Alberto's argument that including such drivers will make it a lot easier to try the workstation on popular virtualization solutions carries some weight and deserves to be discussed, instead of rejected out-of-hand.
By all means, discuss it. However, it's already been discussed several times and not a single person or group has made a case that it's worthwhile to carry drivers out-of-tree that while being open source licensed are actually not very open source friendly at all. Let alone offer to provide the resources to handle that. This is something that everyone says "oh, this sounds good" and then expects the kernel team to pick up just because. I'm saying we can't do that.
For what's is worth, I'm hearing your concerns, and perhaps with the exception of "we want to encourage people to submit their modules upstream" (people may have valid reasons not to) I think all of them are perfectly valid.
The other thing I want to note is that I'm not suggesting that we should do it if it means carrying a considerable amount of time. I am going to reach out to the VBox guys and see if there's any common ground that can be achieved.
Ease of use and popularity do not always win out. If they did, we'd ship a heck of a lot more than we already do.
josh
----- Original Message -----
On Wed, 2014-09-03 at 09:21 -0400, Josh Boyer wrote:
Briefly, 1) we aren't staffed for it, 2) it encourages crappy behavior on the part of the module authors by providing disincentive to getting it upstream, 3) it's a maintenance hassle, 4) we typically already have alternatives (this is particularly true in the case of virt), 5) it's yet another entry in an already rapidly expanding test matrix that has to be checked off (which goes back to item 1), etc etc.
I consider myself to be fairly open to many things. Carrying virtualbox modules out-of-tree when the authors refuse to even submit them upstream for review and have no intention of ever doing so is not one of those things. This is one of the few items where I simply say no.
Do I sense a possible conflict of interest here ?
I think Alberto's argument that including such drivers will make it a lot easier to try the workstation on popular virtualization solutions carries some weight and deserves to be discussed, instead of rejected out-of-hand.
I think we can reject it out-of-hand if there's been no work on getting said drivers upstream so that they would be integrated (or integratable) into Fedora.
On Sep 3, 2014, at 7:21 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Sep 3, 2014 at 8:59 AM, Alberto Ruiz aruiz@redhat.com wrote:
Sure, I understand and concede that VBox does a shitty job wrt their drivers, but on the other hand it is one of the most popular desktop virtualization solutions, it is pretty much the only way to test a Linux desktop OS on top of Windows and Mac that doesn't require a license.
There are other repos that provide it. People are already enabling those repos for everything else that is highly useful but not provided by Fedora.
Ancient support from what I've seen so far. I suppose if I were more sane I'd go back to the pleistocene of color and btrfs testing, ~2 years ago.
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).
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.
It's also a pretty terrible experience when they do get it to build and load and it crashes their kernel.
For me not even once in 4 years has linux crashed as a result of vbox guest drivers. Once in 4 years has xnu crashed due to vbox kernel extensions. Maybe it's because xnu isn't exactly the most bleeding edge of kernels or kernel development.
I consider myself to be fairly open to many things. Carrying virtualbox modules out-of-tree when the authors refuse to even submit them upstream for review and have no intention of ever doing so is not one of those things. This is one of the few items where I simply say no.
I agree with this. In for a penny, in for a pound.
I'm only in favor of a narrow carving for improving the Fedora-VirtualBox experience, i.e. VirtualBox on Windows/OS X with Fedora as the guest, that's my interest. When I run Fedora bare metal I haven't considered using it.
Chris Murphy
Alberto Ruiz (aruiz@redhat.com) said:
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?
(Intentionally ignoring the general question about out-of-tree modules to address this specific point; I agree with Josh on that issue in general.)
Not really - given that the ABI required at any point in time is tied to VirtualBox's schedule, not Fedora's.
At any point, upstream VBox can put out a new release requiring a new ABI, which would mean that:
a) any user that upgrades VBox would be broken until Fedora puts out an update for all supported releases to match b) any user that hasn't upgraded VBox but upgrades Fedora with the new modules from a) would be broken until they upgrade VBox
If you have two tightly-coupled components of a shifting ABI, the best solution will alway be for users to get both components from the same place, not to split them across distribution channels; since we obviously can't ship the VirtualBox app, that means the best way to ensure existing vbox users is to have them get the modules from vbox. Shipping the vbox modules in Fedora would be optimizing the onboarding experience for some vbox users at the expense of the ongoing user experience of using vbox.
It's a similar situation for why Firefox just started bundling xulrunner.
Bill
I wasn't aware of the out-of-tree modules, is there somewhere I can read about the rationale behind this policy?
VMWare and Microsoft actually did things properly for their hypervisors and got the kernel drivers in the upstream kernel.org tree. I believe we already enable them in the Fedora kernels.
Yup, so we're fine for VMWare Fusion/Workstation, and hyper-v doesn't bother me too much from a Workstation POV as it's only available on Windows Server.
josh
-- Greetings, Alberto Ruiz Engineering Manager - Desktop Applications Team Red Hat, Inc.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Wed, 2014-09-03 at 09:45 -0400, Bill Nottingham wrote:
At any point, upstream VBox can put out a new release requiring a new ABI, which would mean that:
a) any user that upgrades VBox would be broken until Fedora puts out an update for all supported releases to match b) any user that hasn't upgraded VBox but upgrades Fedora with the new modules from a) would be broken until they upgrade VBox
Exactly.
Other hypervisors (vmware for instance) have the common engineering discipline (and, you know, taste) to version their interfaces. We have drivers for those and I'm told they even work. Getting that level of support for vbox would require that _we_ discover their interface changes and figure out how to not merely package compatibility with them all but pick the right one at runtime.
If someone really wanted to do all that typing, and if those interfaces are discoverable from the guest, then certainly that's a goal one could accomplish. Personally that's not a workload I find at all interesting, particularly when it's work vbox are shirking in the first place. Maybe whether I find it interesting isn't a concern, maybe it's a goal we decide to have anyway, but if we do so we might want to consider what we're willing to sacrifice to get it, or alternatively, how we're going to staff the role.
- ajax
Okay, fair points overall, perhaps we should look at the problem the other way around and allow for hypervisors to deploy their drivers/guest tools in a more user friendly manner without requiring clumsy steps and building stuff.
Maybe we can work with them ahead of time with them before each Fedora release and convince them to have their drivers ready for each Fedora Workstation/Cloud kernel. I used to work with them when at Sun, let's see if the people I knew are still around...
On Wed, 2014-09-03 at 09:45 -0400, Bill Nottingham wrote:
Alberto Ruiz (aruiz@redhat.com) said:
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?
(Intentionally ignoring the general question about out-of-tree modules to address this specific point; I agree with Josh on that issue in general.)
Not really - given that the ABI required at any point in time is tied to VirtualBox's schedule, not Fedora's.
At any point, upstream VBox can put out a new release requiring a new ABI, which would mean that:
a) any user that upgrades VBox would be broken until Fedora puts out an update for all supported releases to match b) any user that hasn't upgraded VBox but upgrades Fedora with the new modules from a) would be broken until they upgrade VBox
If you have two tightly-coupled components of a shifting ABI, the best solution will alway be for users to get both components from the same place, not to split them across distribution channels; since we obviously can't ship the VirtualBox app, that means the best way to ensure existing vbox users is to have them get the modules from vbox. Shipping the vbox modules in Fedora would be optimizing the onboarding experience for some vbox users at the expense of the ongoing user experience of using vbox.
It's a similar situation for why Firefox just started bundling xulrunner.
Bill
I wasn't aware of the out-of-tree modules, is there somewhere I can read about the rationale behind this policy?
VMWare and Microsoft actually did things properly for their hypervisors and got the kernel drivers in the upstream kernel.org tree. I believe we already enable them in the Fedora kernels.
Yup, so we're fine for VMWare Fusion/Workstation, and hyper-v doesn't bother me too much from a Workstation POV as it's only available on Windows Server.
josh
-- Greetings, Alberto Ruiz Engineering Manager - Desktop Applications Team Red Hat, Inc.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Sep 3, 2014, at 6:59 AM, Alberto Ruiz aruiz@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/os/...
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
On Sep 3, 2014, at 5:52 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Sep 3, 2014 at 7:30 AM, Alberto Ruiz aruiz@redhat.com wrote:
Hello everyone
I wanted to get some feedback as to whether it would be acceptable/desirable to add whatever available graphics and IO drivers available for the most common hypervisors out there other than KVM/Spice.
My idea is that it should be possible to run Fedora Workstation in any desktop virtualization solution out of the box as long as the drivers are acceptable for us in terms of licensing. So VirtualBox is the easiest shot, and a pretty popular one on Windows and Mac users as it's (mostly) FOSS and free of charge, but it'd be nice if we could add others like Parallels or VMWare (I am investigating the availability/licensing situation of those as we speak).
I would appreciate any feedback or concerns about this proposal.
We don't allow out-of-tree modules in Fedora.
Good.
Also, VirtualBox is pathologically broken. They refuse to have a stable userspace<->kernel ABI so whenever they do a new release it can wind up breaking things and requiring a rebuild of everything.
That sounds like just about anything on Linux, though, not unique to VirtualBox. Somehow they have this stability for Windows and OS X hosts such that a single binary works across ~8 years of Windows and 5 years for OS X. The current singular binary runs on OS X versions 2009 to present, including the same kernel extensions. On just Ubuntu there are 8 different install binaries. There are ~30 installers for Linux, four of which are for Fedoras 17-19 only one of which isn't EOL.
But what a can of worms this particular observation is. You're talking about one app, but the same basic cultural dilemma the Linux world is facing is API/ABI instability. It surprises me nil that yet another app does it. There are much bigger penalties than this to be found. How many fads has udev gone through? It manages to confuse and annoy devs, distros, and end users alike. Don't like VirtualBox? Don't use it. Don't like udev? FreeBSD, Illumos, or hmmm maybe just move to a higher altitude. And then user space APIs/ABIs are as stable as children (or drunk adults) playing pin the tail on the donkey. This is a systemic problem, it's not just a VirtualBox anomaly.
Lastly, the drivers aren't of great quality to begin with and crash rather often.
Weird. I only ever use it on OS X as host, and there its kernel extensions have been implicated in one KP in 4 years. The linux guest drivers haven't ever caused me a problem, other than just not performing as well as some alternatives.
VMWare and Microsoft actually did things properly for their hypervisors and got the kernel drivers in the upstream kernel.org tree.
In some ways this is worse than being pathologically broken. Not following the process their typically proprietary peers are willing to follow, is weird.
Chris Murphy
desktop@lists.fedoraproject.org
-
Adam Jackson -
Alberto Ruiz -
Bastien Nocera -
Bill Nottingham -
Chris Murphy -
Elad Alfassa -
Josh Boyer -
Liam -
Matthias Clasen