Fedora's foundations meet proprietary drivers
we believe that advancing software and content freedom is a central goal for the Fedora Project, and that we should accomplish that goal through the use of the software and content we promote") and to providing leading-edge software, including current kernels. Given that the kernel project, too, is focused on free software, it is interesting to see a call within the Fedora community to hold back on kernel updates in order to be able to support a proprietary driver.
On September 5, Fedora kernel maintainer Laura Abbott announced that the just-released 4.13 kernel would be built for the (in-development) Fedora 27 release, and that it would eventually find its way into the Fedora 25 and 26 releases as well. That is all in line with how Fedora generally operates; new kernels are pushed out to all supported releases in relatively short order. Running current kernels by default is clearly a feature that many Fedora users find useful.
More recently, though, James Hogarth noted that the NVIDIA proprietary driver did not work with the 4.13 kernel. This kind of breakage is not all that unusual. While the user-space ABI must be preserved, the kernel project defends its right to change internal interfaces at any time. Any problems that out-of-tree code experiences as a result of such changes is deemed to be part of the cost of staying out of the mainline. There is little sympathy for those who have to deal with such issues, and none at all if the out-of-tree code in question is proprietary. Community-oriented projects like Fedora usually take a similar attitude, refusing to slow down for the sake of proprietary code.
In recent years, though, as part of an effort to attract more users, the Fedora distribution has been split into a set of "editions", each of which addresses a specific user community and has a certain amount of control over what is shipped. The "workstation" edition is the version that many Fedora users install. The developers behind that edition are, for obvious reasons, concerned with proper graphics support, and that concern, it would seem, has extended to support for proprietary drivers. Back in July, Christian Schaller wrote in an article about the Fedora 26 release:
The Fedora Workstation project, in other words, has decided that the NVIDIA driver, as found in the Negativo repository, as an important component in the workstation edition. That is a distinct change from the Fedora project's previous attitude toward such drivers, and the consequences of this decision become clear in the discussion on the 4.13 kernel.
Hogarth, in his message, asked whether the broken NVIDIA driver was a
sufficient reason to hold back the deployment of the 4.13 kernel. The response from Josh Boyer was clear:
"Absolutely not
". But Michael Catanzaro saw it differently:
He later added:
Boyer responded: "That's a completely
untenable position. There is only one kernel for all the Editions.
"
Therein lies the core of the conflict. The Fedora project as a whole is dedicated to free software and lacks the resources to maintain different kernels for each of its editions. The workstation working group, instead, would appear to be focused on desktop success, and is willing to compromise somewhat on both free software and current software if it seems necessary. According to Catanzaro, the working group has been given full control over the edition, extending to the kernel, and it will use that control if need be to ensure that an important proprietary driver keeps working. He suggested that the issue should maybe be immediately escalated to the Fedora Engineering Steering Committee (FESCo) since it seemed certain to end up there eventually anyway.
This conflict probably will indeed come to FESCo's attention, but that may not happen right away. The problem with 4.13 was evidently due to an exported symbol being marked "GPL only" by default; that has been changed and the NVIDIA driver works again. As a result, the immediate conflict has seemingly been resolved to everybody's satisfaction. Beyond that, there is a fallback in place that uses the free Nouveau driver should the NVIDIA driver fail, but it seems certain that Nouveau will not prove to be a satisfactory replacement for all users of the proprietary driver. In any case, nobody seems to want to carry this fight forward at this time, so it looks likely to fade away.
But it seems certain that this issue will come back; kernel changes that
break proprietary drivers are not all that uncommon. Future breaks will,
once again, highlight a conflict between the Fedora project's "freedom" and
"first"
foundations on one side, and its desire to increase its user base on the
other. Sooner or later, somebody will have to make a decision on which
goal truly comes first.
Posted Sep 26, 2017 21:58 UTC (Tue)
by cozzyd (guest, #110972)
[Link] (3 responses)
Posted Sep 26, 2017 23:08 UTC (Tue)
by pizza (subscriber, #46)
[Link] (2 responses)
(Hmm, maybe I should remove that sole comma..)
Posted Sep 27, 2017 0:49 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
It is not the repo on the whole. Just the Nvidia driver repo which is independent and doesn't have other packages
https://negativo17.org/nvidia-driver/
Posted Sep 28, 2017 20:39 UTC (Thu)
by mcatanzaro (subscriber, #93033)
[Link]
Posted Sep 27, 2017 2:34 UTC (Wed)
by mspevack (subscriber, #36977)
[Link] (1 responses)
That seeing today's article immediately made me remember an 11-year-old debate should be some measure of how difficult and controversial of an issue this was at the time, when Fedora was struggling to define its tenets, to grow a community of passionate contributors, and to attract and retain users.
I remember being very strongly of the opinion that taking an action that you know will break users is a cardinal sin, and I still feel that way. But it was not unanimous. The Fedora Board was split on the issue, and the community of most active and vocal contributors was as well. It was one of the most interesting challenges of Fedora's (then nascent) governing and decision-making structure.
Here's what LWN said 11 years ago:
The Fedora advisory board met to discuss the issue; the resulting decision was that Fedora Core 5 would not be updated to X.org 7.1. The conclusion was that the interests of Fedora users using proprietary NVidia modules outweigh the interests of other users who would benefit from this update.... distributors are acting in what they believe is the best interest of their users. Regardless of what one thinks of the outcome, it is encouraging that quite a bit of thought is clearly being put into the effects of changes on the user base.
TL;DR -- Fedora had this same argument 11 years ago and we chose not to break our users when we saw the breakage coming. Make the same choice again!
Posted Sep 27, 2017 16:27 UTC (Wed)
by smoogen (subscriber, #97)
[Link]
It isn't exactly the same issue this time
1. They can go back to the older kernel while they could not go back to the older X.
Posted Sep 27, 2017 3:31 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Sep 27, 2017 12:15 UTC (Wed)
by corbet (editor, #1)
[Link] (1 responses)
Posted Sep 27, 2017 13:26 UTC (Wed)
by pabs (subscriber, #43278)
[Link]
Posted Sep 27, 2017 4:54 UTC (Wed)
by lsl (subscriber, #86508)
[Link] (13 responses)
Posted Sep 27, 2017 14:46 UTC (Wed)
by mcatanzaro (subscriber, #93033)
[Link] (11 responses)
Posted Sep 27, 2017 15:04 UTC (Wed)
by mcatanzaro (subscriber, #93033)
[Link] (2 responses)
* The Workstation WG didn't even discuss the kernel 4.13 update yet, much less make any decision. This article describes my prediction as to what could happen if it were to come up on the agenda.
* I dropped my objection to the kernel update once it was determined that affected users will still be able to boot into a graphical environment successfully, since there's a working fallback to the noveau driver. So even I now agree that the kernel update is fine.
It should really not be controversial that a mid-release update that causes users' previously-working computers to no longer boot is unacceptable under any circumstances. If an update breaks users' computers, we lose those users to Ubuntu. And nobody honestly cares what kernel version they're running, as long as their hardware works. So if a new kernel *were* to seriously break users (and this one doesn't), then it really ought to wait until the next Fedora release: just like kernel upgrades have to wait in every other distro.
P.S. I *really* wish we could say that Nvidia's crap proprietary driver was not supported, but that's just not the world we live in... not if we want the Fedora community to continue growing.
Posted Sep 27, 2017 18:08 UTC (Wed)
by Otus (subscriber, #67685)
[Link] (1 responses)
That's not a solution unless the old kernel version gets updates from the distro.
I have not tried to maintain a kernel release, but I know that having to support multiple versions of any software will require multiple times the maintenance resources. So the resources would have to be there or else you'd be trading some users being unable to boot new kernels to *all* users being vulnerable to security holes.
Posted Sep 28, 2017 16:21 UTC (Thu)
by mcatanzaro (subscriber, #93033)
[Link]
One could argue that the solution is to just stick to LTS kernels. But in this case, it turns out that we have a working fallback to noveau when the proprietary driver breaks, so it's fine to just keep shipping the latest kernels.
Posted Sep 27, 2017 19:49 UTC (Wed)
by lsl (subscriber, #86508)
[Link] (7 responses)
Nowadays you really want to ship proprietary software. Instead of convincing the Fedora community to change its policies you come up with these "third-party repos" that are described as "supported" and feature prominently in Gnome Software. What is this other than circumvention of Fedora policy regarding the inclusion of proprietary software?
Also, the "but FESCo can always override" argument requires other people to act and bring it to FESCo. When any decisions by FESCo or other governing bodies are seen as a request to try the same bloody thing again with some inconsequential tweaks, people grow tired of constantly having to put up a fight. You're the ones wanting to change foundational aspects of Fedora, so you should be the ones required to put in the effort to convince the community that these changes are for the better. You haven't been able to do that. Yet, you proceed with the implementation of these changes.
This behaviour is highly toxic to the Fedora community and is certainly a significant ingredient to the frustration and disillusionment of many long-time contributors.
Posted Sep 28, 2017 0:26 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
That is entirely within the rights of the variants of Fedora and such changes are routinely done by them. They aren't merely a collection of packages in an image.
Posted Sep 28, 2017 9:08 UTC (Thu)
by lsl (subscriber, #86508)
[Link] (1 responses)
Posted Sep 28, 2017 11:56 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Fedora offers more than one thing to download and spins/editions etc follow the structure outlined by FESCo. If you believe that any particular issue is objectionable, you can file a ticket and get FESCo to review it.
The decision that was made by FESCo during that time about the MTA was just about the general default. If you want that default without any customization by the spins, you can download the generic "everything" installer (ie) the non live image. That is still available under
https://alt.fedoraproject.org/
Posted Sep 28, 2017 16:16 UTC (Thu)
by mcatanzaro (subscriber, #93033)
[Link] (3 responses)
* Do remember that the WGs are entirely subservient to FESCo. FESCo created the WGs and can dissolve any WG whenever it wants to. I doubt the current members would choose to do so, but they could if desired. If you really think the WG is "highly toxic to the community", then your endgame for ending us is to convince half plus one of FESCo members to agree with you.
* The decision to not include the standard comps group in the desktop spin kickstart, made after FESCo decided that sendmail should be included in standard, was actually *itself* approved by FESCo upon appeal! So please, don't accuse us of ignoring FESCo. I think this particular issue contributed to the understanding that the exact same set of defaults was just not going to work for both desktops and servers, and that creating separate products with product-specific defaults was the best way forward. The end result was that almost everyone was satisfied: nowadays Workstation ships without sendmail but Server installs it by default.
* I don't remember if the third-party repo policy was approved by FESCo or not. I thought it was approved by the Council instead (since this was a political issue rather than an engineering issue). It's true that most seats on the Council are not elected, but it operates on consensus where all members have a veto. Anyway, turns out it's not actually approved yet: https://pagure.io/Fedora-Council/tickets/issue/121. I didn't know that; and you have a point that implementation should have waited for Council approval. Anyway, you can go campaign against that if you want to. You might actually win, judging by the comments there. But please think hard about the issue first, because this is a really tricky problem: on the one hand, I hate Nvidia's crap and don't want to advertise it either; but on the other hand, I do want to grow the Fedora community. And if we don't have good support for nvidia users, that's a huge subset of users we cannot reach. :/ (The other piece of proprietary software that's desired is Google Chrome, but that one I don't really care about.)
Posted Sep 28, 2017 17:21 UTC (Thu)
by karkhaz (subscriber, #99844)
[Link] (2 responses)
I'm curious: why would people possibly care about wanting to install Chrome as opposed to Chromium? Surely the handful of extra features that Chrome provides are not anything that anybody cares about?
Posted Sep 28, 2017 18:18 UTC (Thu)
by mcatanzaro (subscriber, #93033)
[Link] (1 responses)
My understanding is there is work in progress on a legal solution for GStreamer, but Chromium doesn't use GStreamer, so there's not really any hope for it at this time.
Posted Sep 29, 2017 0:00 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Not entirely accurate. It is a hack but there is
https://admin.rpmfusion.org/pkgdb/package/free/chromium-l...
Posted Oct 4, 2017 16:58 UTC (Wed)
by sharms (guest, #57357)
[Link]
Posted Sep 27, 2017 8:55 UTC (Wed)
by cdamian (subscriber, #1271)
[Link] (2 responses)
And now I might not get the newest version of some free packages, because it blocks proprietary stuff. I can understand why people are upset.
Posted Sep 27, 2017 14:03 UTC (Wed)
by ayers (guest, #53541)
[Link] (1 responses)
Posted Sep 27, 2017 15:13 UTC (Wed)
by seyman (subscriber, #1172)
[Link]
My first thought was that this kernel should be maintained by the Workstation WG. Given that they're the group making demands, it's only fair that they do the work required.
Posted Sep 27, 2017 9:07 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (2 responses)
Posted Sep 27, 2017 14:38 UTC (Wed)
by jzb (editor, #7867)
[Link] (1 responses)
I'm not arguing for or against it, just noting that the scenario is different than what is suggested by your comment.
There's also a separate argument/discussion around the fact that many users of Fedora do _not_ get to choose their hardware at all. Whether it's because it's work-issued, hand-me-down, or simply a user who is trying to move away from Windows and purchased their hardware before looking to Linux. It is not always as simple as being "careful when selecting hardware."
Posted Sep 28, 2017 8:51 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
For instance, I run VMware Horizon on my F26 laptop for work. I understand that this setup may occasionally break. In fact, I had to put some library symlinks in place to get it running at one point. Such is life on the bleeding edge (almost).
Posted Sep 27, 2017 9:07 UTC (Wed)
by Priscus (guest, #72409)
[Link] (6 responses)
Would it be acceptable to keep a LTS kernel in Fedora (it may already be there, for all I know), and ask the packagers of the proprietary drivers to set a dependency on the LTS kernel specifically?
Would this work and be an acceptable compromise?
Posted Sep 27, 2017 9:23 UTC (Wed)
by seyman (subscriber, #1172)
[Link] (3 responses)
That was part of the discussion on the devel mailing list but LTS releases rarely align with Fedora's release schedule and the two kernel maintainers are too overworked to maintain their own.
Posted Oct 5, 2017 1:34 UTC (Thu)
by khm (subscriber, #108825)
[Link] (2 responses)
If you can't integrate updates to the foundational unit of the operating system, it sounds like your release schedule is what's broken, not the legal framework around a video card driver.
Posted Oct 5, 2017 1:56 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
Posted Oct 5, 2017 16:28 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Sep 27, 2017 16:54 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
Then users should be able to boot to the previous good kernel, which doesn't get uninstalled during the upgrade, so they can get their proprietary drivers back. They can then file bugs to get the Nvidia driver working on newer kernels.
The problem with LTS kernels is that there are a lot of things that depend on new kernels. For example Fedora/Redhat switched relatively recently to using overlayfs2 for docker... if that isn't supported in the LTS kernel (I don't know if it is or if it is not) then that means that users will be forced to configure docker-storage-setup differently depending on the video card driver they use, which is kinda insane if you think about it.
Other things could crop as well, such as bad or old Intel support for laptops that support dual video cards, wifi drivers being old, or a dozen other issues.
For a distribution like Fedora that is more 'cutting edge' I will happily take have to occasionally booting into the previous know good kernel and filing bug reports rather then having Fedora trying to manage a very old and a very new kernel in the same OS installs.
Posted Sep 28, 2017 13:52 UTC (Thu)
by mrshiny (guest, #4266)
[Link]
More recently, my F25 installation stopped working after a kernel update. Something to do with the proprietary nvidia driver I was using from rpmfusion - it wouldn't install or would but wouldn't load, or loaded but didn't work - I'm not really sure. Booting to the previous kernel didn't help. The desktop was super super slow - think 60s to move a mouse cursor half-way across the screen. I had to upgrade the entire distro to 26 to get a newer kernel which had working nouveau drivers for my graphics card (a 10-series nvidia card).
In short, relying on previous kernels is dubious at best when we're talking about dodgy drivers. It's a band-aid that doesn't always work and is only understandable by people with a developer's mindset. If Fedora aims to be useful to more than just developers, efforts to avoid breakage are always appreciated.
Posted Sep 27, 2017 15:10 UTC (Wed)
by TMM (subscriber, #79398)
[Link] (5 responses)
I select hardware specifically in such a way that I can do this with confidence (or in some cases delay hardware upgrades until hardware becomes available that has free, upstreamed drivers).
To me it would be a slap in the face if after the effort and money involved in purchasing and selecting this hardware that does the right thing I'm not getting the benefits.
I specifically chose Fedora because I believed it would NOT delay upgrades to appease non-free driver makers.
Posted Sep 27, 2017 17:49 UTC (Wed)
by patrick_g (subscriber, #44470)
[Link] (4 responses)
Sorry to ask the obvious but why don't you use Arch?
Posted Sep 27, 2017 19:32 UTC (Wed)
by karkhaz (subscriber, #99844)
[Link] (3 responses)
> The large number of packages and build scripts in the various Arch Linux repositories offer free and open source software for those who prefer it, as well as proprietary software packages for those who embrace functionality over ideology.
and also this from the comparison with other Linux distributions [1]:
> Debian has a more vehement stance on free software but still includes non-free software in its non-free repos. Arch is more lenient, and therefore inclusive, concerning non-free packages as defined by GNU
[0] https://wiki.archlinux.org/index.php/Arch_Linux#Pragmatism
Posted Sep 28, 2017 7:39 UTC (Thu)
by ssl (guest, #98177)
[Link]
[0](https://wiki.parabola.nu/Main_Page)
[1](https://www.parabola.nu/packages/libre/any/your-freedom/)
Posted Sep 28, 2017 7:42 UTC (Thu)
by jospoortvliet (guest, #33164)
[Link] (1 responses)
Posted Sep 28, 2017 22:21 UTC (Thu)
by TMM (subscriber, #79398)
[Link]
Posted Sep 27, 2017 17:10 UTC (Wed)
by AnimeLife (guest, #116014)
[Link] (2 responses)
Posted Sep 27, 2017 17:34 UTC (Wed)
by seyman (subscriber, #1172)
[Link]
Posted Sep 27, 2017 17:45 UTC (Wed)
by pizza (subscriber, #46)
[Link]
You recall incorrectly. Sometimes there is backwards-compatibility for certain types of drivers, but it's still not something one can really count on.
(Granted, since Win8 driver interfaces have been fairly stable, but that's more due to MS not actually changing all that much under the hood since then)
Posted Sep 28, 2017 2:08 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (6 responses)
Posted Sep 28, 2017 11:31 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (4 responses)
Many influential kernel developers, including Linus Torvalds, have no real problem with proprietary drivers as long as these stick to the interfaces which are declared available to them.
As a matter of principle, it would of course be nicer if all Linux kernel drivers were free (and ideally part of the canonical kernel tree) but the Linux kernel is somewhat removed from the idealist end of the free-software spectrum towards the realist end. If instead of Linus Torvalds, Richard Stallman was in charge of maintaining the Linux (RMX?) kernel, things might be different.
Posted Sep 28, 2017 12:36 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (1 responses)
http://www.youtube.com/watch?v=iYWzMvlj2RQ
Posted Oct 5, 2017 9:27 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Sep 29, 2017 10:19 UTC (Fri)
by tao (subscriber, #17563)
[Link] (1 responses)
Yes, things would indeed be different.
Posted Sep 29, 2017 22:26 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
I think the absence of proprietary drivers is the least of the HURD's problems. Absence of developers seems to be much more of an issue in practical terms. Also, I don't think that (a) rms is really working on the HURD these days, and (b) the HURD is high on the list of the FSF's priorities given that they can use Linux instead.
Posted Sep 29, 2017 10:20 UTC (Fri)
by gregkh (subscriber, #8)
[Link]
Or is there something else we should do other than making it very expensive to keep an out-of-tree driver working successfully?
Posted Sep 28, 2017 5:29 UTC (Thu)
by meyert (subscriber, #32097)
[Link] (3 responses)
Posted Sep 28, 2017 10:21 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
Older hardware works, but performance is rather lousy due to the trickery required to safely muck with clock/voltage settings that's all done in software.
Even older hardware works reasonably well, albeit not as fast as the proprietary driver.
For OpenCL, the F/OSS stack is behind the curve a bit in features, and is much slower.
For CUDA work, it's proprietary-or-nothing.
Posted Sep 28, 2017 13:54 UTC (Thu)
by mrshiny (guest, #4266)
[Link]
Posted Sep 28, 2017 13:28 UTC (Thu)
by kschendel (subscriber, #20465)
[Link]
So the "important functionality" that isn't reliably delivered by nouveau is the ability to use your machine for anything at all that involves the display.
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
This article brought me back to August 2006, when Fedora faced a similar debate that was covered by LWN (also by Corbet).
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
2. The system should fall back to the opensource nouveau driver if the nvidia doesn't work.
3. This breakage is going to occur all the time. That was a known risk at the time of acceptance of this feature. I think the confusion which caused the kerfluffle was that there wasn't a finished agreement on what happens when that breakage occurs. Some people thought it was that the Working Group would work out methods to help an affected user to deal with it. Others thought that it was the Working Group would have the power to stop other people from breaking their release.
Fedora's foundations meet proprietary drivers
To just changing the marking of a symbol would be highly questionable. This change was made upstream, though.
Exported symbols
Exported symbols
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
That way, the "free" community could work as intended, and the "proprietary" crowd would avoid breakage.
Of course, the "proprietary" machines would not have all the greatest and latest by default, but the knowledgeable users would still be able to force-install: whether that is a good idea or not would be their choice and responsibility.
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
[1] https://wiki.archlinux.org/index.php/Arch_compared_to_oth...
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
https://www.wired.com/2012/06/torvalds-nvidia-linux/
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
https://wiki.linuxfoundation.org/tab/kernel-driver-statement
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers
Fedora's foundations meet proprietary drivers