Fedora's foundations meet proprietary drivers

By Jonathan Corbet
September 26, 2017

The Fedora project's four "foundations" are named "Freedom", "Friends", "Features", and "First". Among other things, they commit the project to being firmly within the free-software camp ("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:

We do plan on listing the NVidia driver in GNOME Software soon without having to manually setup the repository, so soon we will have a very smooth experience where the Nvidia driver is just a click in the Software store away for our users.

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:

If it breaks the Negativo repo, then yes it is. The Nvidia driver from that repo is supported and it needs to not break. We've been super super lenient with allowing kernel updates in the Workstation product, since it seems to be working well for everyone involved, but that would need to be reconsidered if a kernel update intentionally breaks an important subset of our users.

He later added:

But if Negativo users start complaining that their computers don't boot anymore, then we'll definitely need to stop doing major kernel updates ("taking the entire distro hostage" I guess) as the Negativo support is important for product strategy.

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.

to post comments

Fedora's foundations meet proprietary drivers

Posted Sep 26, 2017 21:58 UTC (Tue) by cozzyd (guest, #110972) [Link] (3 responses)

Can't this problem be solved by having the nvidia package in the negativo repository depend on the maximum kernel version that is known to work? Not ideal from a security standpoint, but I imagine NVIDIA doesn't usually take so long to support new kernels anyway.

Fedora's foundations meet proprietary drivers

Posted Sep 26, 2017 23:08 UTC (Tue) by pizza (subscriber, #46) [Link] (2 responses)

I have a *very* hard time seeing RH Legal blessing use of the negativio repo, given their considerable historic wariness of even appearing to acknowledge the existence of software that is known to infringe on a large pile of patents held by extremely litigious organizations who would have no problem attempting to sue Red Hat out of existence for contributory patent infringement.

(Hmm, maybe I should remove that sole comma..)

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 0:49 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> I have a *very* hard time seeing RH Legal blessing use of the negativio repo,

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/

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 20:39 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

And that's important: we're actually not allowed to point to third-party repos that contain more than one package, it has to be one single package for legal review.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 2:34 UTC (Wed) by mspevack (subscriber, #36977) [Link] (1 responses)

This article brought me back to August 2006, when Fedora faced a similar debate that was covered by LWN (also by Corbet).

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!

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 16:27 UTC (Wed) by smoogen (subscriber, #97) [Link]

Hi Max!

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.
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

Posted Sep 27, 2017 3:31 UTC (Wed) by pabs (subscriber, #43278) [Link] (2 responses)

How legal is it for Fedora to just mark a symbol as not GPL any more?

Exported symbols

Posted Sep 27, 2017 12:15 UTC (Wed) by corbet (editor, #1) [Link] (1 responses)

To just changing the marking of a symbol would be highly questionable. This change was made upstream, though.

Exported symbols

Posted Sep 27, 2017 13:26 UTC (Wed) by pabs (subscriber, #43278) [Link]

Ah, thanks for the clarification. The article didn't really make that clear.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 4:54 UTC (Wed) by lsl (guest, #86508) [Link] (13 responses)

The workstation WG's shenanigans to undermine the normal Fedora community processes are almost unbelievable. This bullshit is going on for years now and the tactics are as underhanded as ever.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 14:46 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (11 responses)

Really? We exist entirely within the normal Fedora community process. FESCo can override any decision we make if it wants to.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 15:04 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (2 responses)

Additionally:

* 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.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 18:08 UTC (Wed) by Otus (subscriber, #67685) [Link] (1 responses)

> 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.

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.

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 16:21 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

That's true.

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.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 19:49 UTC (Wed) by lsl (guest, #86508) [Link] (7 responses)

Even when FESCo makes some decision, you guys tend to interpret it as applying to "Fedora" with different rules of your own choosing applying to the Workstation variant. Nothing new here, this kind of stuff already happened back then with the Gnome spin. Like when after weeks of arguments and flamewars FESCo decided that Fedora is going to ship an enabled MTA/sendmail for one more release. You didn't like that decision, so you chose to interpret it as not applying to the Gnome spin and just reverted it in the Kickstart.

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.

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 0:26 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

>. You didn't like that decision, so you chose to interpret it as not applying to the Gnome spin and just reverted it in the Kickstart.

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.

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 9:08 UTC (Thu) by lsl (guest, #86508) [Link] (1 responses)

What's the point of on elected body making decisions when they're irrelevant to the thing you get when you go to the Fedora website and click "Download"?

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 11:56 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

"What's the point of on elected body making decisions when they're irrelevant to the thing you get when you go to the Fedora website and click "Download"?

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/

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 16:16 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link] (3 responses)

It's clear that you have been following Fedora politics fairly closely. But here are some things I think you missed:

* 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.)

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 17:21 UTC (Thu) by karkhaz (subscriber, #99844) [Link] (2 responses)

> The other piece of proprietary software that's desired is Google Chrome, but that one I don't really care about

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?

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 18:18 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link] (1 responses)

Fedora Chromium ships without ffmpeg support, for legal reasons, so there's no way to e.g. play MP4 videos. And it's not extensible, so there's no way to e.g. install extra codec packages from third-party repos.

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.

Fedora's foundations meet proprietary drivers

Posted Sep 29, 2017 0:00 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

>Fedora Chromium ships without ffmpeg support, for legal reasons, so there's no way to e.g. play MP4 videos. And it's not extensible, so there's no way to e.g. install extra codec packages from third-party repos.

Not entirely accurate. It is a hack but there is

https://admin.rpmfusion.org/pkgdb/package/free/chromium-l...

Fedora's foundations meet proprietary drivers

Posted Oct 4, 2017 16:58 UTC (Wed) by sharms (guest, #57357) [Link]

I am thankful for their push towards making typical workstations usable. There are 17 million hits on Google for 'linux nvidia', instead of pretending they don't exist this helps further adoption.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 8:55 UTC (Wed) by cdamian (subscriber, #1271) [Link] (2 responses)

If I want proprietary drivers support I can always go to another distribution. I am using Fedora because they are not following this easy way out.

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.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 14:03 UTC (Wed) by ayers (guest, #53541) [Link] (1 responses)

Indeed, IMHO if the driver is so important, then someone who it's important to, needs to maintain an LTS kernel for Fedora as suggested in another thread. Ideally that someone should be Nvidia since they are the ones blocking nouveau from working correctly.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 15:13 UTC (Wed) by seyman (subscriber, #1172) [Link]

> Indeed, IMHO if the driver is so important, then someone who it's important to, needs to maintain an LTS kernel for Fedora [...]

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.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 9:07 UTC (Wed) by bojan (subscriber, #14302) [Link] (2 responses)

I hope Fedora never does this. I don't want proprietary driver soup that is Android, if it can be avoided. I'd rather be careful when selecting hardware.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 14:38 UTC (Wed) by jzb (editor, #7867) [Link] (1 responses)

I sympathize with this, but it's not Fedora forcing "proprietary driver soup," it's a question of whether we would push an update we know is incompatible with a common user setup.

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."

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 8:51 UTC (Thu) by bojan (subscriber, #14302) [Link]

I know people cannot always pick their hardware, but by installing Fedora, you are basically saying that you want latest free software that works with current Fedora release. If someone wants to jam square pegs into round holes by depending on proprietary drivers, that's their own business.

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).

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 9:07 UTC (Wed) by Priscus (guest, #72409) [Link] (6 responses)

(This comes from someone who does not use Fedora, and may say obvious or stupid things)

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?
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.

Would this work and be an acceptable compromise?

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 9:23 UTC (Wed) by seyman (subscriber, #1172) [Link] (3 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?

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.

Fedora's foundations meet proprietary drivers

Posted Oct 5, 2017 1:34 UTC (Thu) by khm (subscriber, #108825) [Link] (2 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.

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.

Fedora's foundations meet proprietary drivers

Posted Oct 5, 2017 1:56 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

Um, the ones having problem integrating updates to "foundational units of the operating system" are the makers of said proprietary video driver.

Fedora's foundations meet proprietary drivers

Posted Oct 5, 2017 16:28 UTC (Thu) by nix (subscriber, #2304) [Link]

Also, there are lots of "foundational units", and they have distinct release schedules. You can't align to kernel releases *and* X.org releases *and* glibc releases *and* GNOME releases *and* KDE releases *and* Firefox releases *and* LibreOffice releases without releasing every other day.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 16:54 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

The way it should work now is that if you boot to a kernel that can't support Nvidia proprietary drivers it should default to the nouveau driver so that users don't get a useless system.

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.

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 13:52 UTC (Thu) by mrshiny (guest, #4266) [Link]

Booting previous kernels doesn't always work properly though. In the Fedora 10 timeframe (I forget which Fedora release... it was years ago) my notebook constantly had problems with new kernels and Fedora was removing the old kernels. Basically, every 4 out of 5 releases broke my network or graphics. Old kernels weren't kept around and I had to finally figure out that a yum option would let me keep all old kernels forever... that option isn't set by default.

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.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 15:10 UTC (Wed) by TMM (guest, #79398) [Link] (5 responses)

I don't know how much this matters but I moved to Fedora because I want the best free software currently available. Recent kernels all the time was a major factor for me to migrate.

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.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 17:49 UTC (Wed) by patrick_g (subscriber, #44470) [Link] (4 responses)

> I want the best free software currently available. Recent kernels all the time was a major factor for me to migrate.

Sorry to ask the obvious but why don't you use Arch?

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 19:32 UTC (Wed) by karkhaz (subscriber, #99844) [Link] (3 responses)

Users who only want to run free software might avoid Arch Linux as it ships blobs and proprietary software in the official repositories, with no automated way to distinguish them from free software. See "Pragmatism" principle in Arch's philosophies [0]:

> 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
[1] https://wiki.archlinux.org/index.php/Arch_compared_to_oth...

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 7:39 UTC (Thu) by ssl (guest, #98177) [Link]

If properitary software in arch bothers you, you can use Parabola[0]'s overriding package[1], (or just migrate to it.)

[0](https://wiki.parabola.nu/Main_Page)

[1](https://www.parabola.nu/packages/libre/any/your-freedom/)

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 7:42 UTC (Thu) by jospoortvliet (guest, #33164) [Link] (1 responses)

I guess openSUSE Tumbleweed would be the choice that fits the requirements best then... more up to date than fedora (frequently beating Arch) and non-free stuff separated out. And no fscks given for NVIDIA compatibility of newer kernels...

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 22:21 UTC (Thu) by TMM (guest, #79398) [Link]

Thanks, I may look at tumbleweed if delaying updates for Nvidia becomes the norm for Fedora.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 17:10 UTC (Wed) by AnimeLife (guest, #116014) [Link] (2 responses)

Noobie question here, but on Windows we have compatibility option to run software as on previous version which IIRC also works for drivers. Can't we do same thing for linux kernel abi?

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 17:34 UTC (Wed) by seyman (subscriber, #1172) [Link]

We could but the kernel maintainers aren't interested in doing this.

Fedora's foundations meet proprietary drivers

Posted Sep 27, 2017 17:45 UTC (Wed) by pizza (subscriber, #46) [Link]

> Noobie question here, but on Windows we have compatibility option to run software as on previous version which IIRC also works for drivers.

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)

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 2:08 UTC (Thu) by pabs (subscriber, #43278) [Link] (6 responses)

Why doesn't the Linux kernel community take any deliberate action against proprietary drivers?

Fedora's foundations meet proprietary drivers

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.

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 12:36 UTC (Thu) by pabs (subscriber, #43278) [Link] (1 responses)

Um, I don't think Linus likes NVIDIA either :)

http://www.youtube.com/watch?v=iYWzMvlj2RQ
https://www.wired.com/2012/06/torvalds-nvidia-linux/

Fedora's foundations meet proprietary drivers

Posted Oct 5, 2017 9:27 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

IIRC, this was mostly about their Tegra boards rather than their video card engineers.

Fedora's foundations meet proprietary drivers

Posted Sep 29, 2017 10:19 UTC (Fri) by tao (subscriber, #17563) [Link] (1 responses)

As it happens you don't even need to think in terms of "if". If you want to see what happens when Stallman's way of governance decides how a kernel should be maintained, just look at the stellar speed at which Hurd development moves forward, what blazing performance that kernel provides, and the amazing hardware support it provides.

Yes, things would indeed be different.

Fedora's foundations meet proprietary drivers

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.

Fedora's foundations meet proprietary drivers

Posted Sep 29, 2017 10:20 UTC (Fri) by gregkh (subscriber, #8) [Link]

You mean like this following statement from back in 2008:
https://wiki.linuxfoundation.org/tab/kernel-driver-statement

Or is there something else we should do other than making it very expensive to keep an out-of-tree driver working successfully?

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 5:29 UTC (Thu) by meyert (subscriber, #32097) [Link] (3 responses)

So what important functionality can't be covered by the Noveu driver that is covered by the Nvidia driver?

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 10:21 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

If you have modern (ie current-gen) hardware, it pretty much doesn't work at all due to a lack of signed firmware.

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.

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 13:54 UTC (Thu) by mrshiny (guest, #4266) [Link]

My current-gen nVidia card works now with the nouveau driver, at least for desktop work, since Fedora 26. For gaming though, I wouldn't even bother trying nouveau.

Fedora's foundations meet proprietary drivers

Posted Sep 28, 2017 13:28 UTC (Thu) by kschendel (subscriber, #20465) [Link]

Nouveau can't be counted on to work, as in at all. I'm running a completely ordinary nvidia card, a GT120 which is hardly new, and while it's been working with most of the recent 4.x kernels, there were several 3.x kernels which were completely unusable with nouveau (garbled screen).

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.