I think their point is that by default, even with the "use recommended drivers" option enabled, Ubuntu uses the nouveau driver by default instead of installing and using the NVIDIA driver.

the nvidia driver is proprietary. If nvidia opens the source, maybe they would ship with that instead.

Well, installing recommended drivers on Ubuntu installs the Intel or AMD microcode, which is definitely proprietary, so I don't think that's a particularly reasonable argument.

The NVIDIA driver is the driver that yields the best performance and experience; AFAICT the only reason it's not shipped by default is because the kernel is then considered "impure" or something (because source isn't available to debug issues in the NVIDIA driver), hence bugs can't be filed upstream for any issues in the kernel if the NVIDIA driver is installed.

However, none of this is really the concern of the Chrome team. Their responsibility is to give the user the best experience, which they have defined as security, stability, and performance in that order. Since the nouveau driver is causing stability bugs, it's perfectly reasonable for them to fallback to software rendering and take the performance hit in order to preserve stability.

> the kernel is then considered "impure" or something

The term is "tainted".

> What else are they going to ship ?

Including Nvidia's binary driver by default. Obvs Debian, gNewSense, and GUIX can't do that, but since when have corps cared about them?

Like, don't get me wrong, I'm a FOSS or GTFO kind of guy, running Debian and Replicant, but shipping proprietary drivers by default is what chrome is hinting at obviously.

You can't, for the same reason you can't ship ZFS.

The combining of proprietary and GPL code has to be made by the user and the result is un-distributable. That's why distributions cannot ship it.

What they can do is to make the above step easy (which Ubuntu does).

It's way more complicated than that.

AFAIU, Nvidia's legal argument is that their driver can't be 'derived from' the Linux kernel even though it's linked into the kernel since it's older than their Linux port and only is linked against their GPLed (and if push comes to shove, dual licensed GPL and proprietary) kernel abstraction layer. Judges don't care about linkers and the GPL doesn't actually say anything about linking.

This is not the derivation argument (that would be forcing GPL on Nvidia, which they want to counter, of course).

This is about GPL infrigment; you can combine GPL licensed code with differently licensed code, but only in your privacy, without distributing the result to others. Once you would distribute the result, you would be breaking GPL, thus having no right to distribute.

The GPLv2 literally defines itself in relation to trees of derived works:

> The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.

The argument that I've is that even when linked together, the Nvidia binary driver isn't a 'derivative under copyright law' because it doesn't have Linux specific entry points, and is older than their Linux port, and therefore isn't part of "The 'Program'" as listed in the GPL.

GPL defines itself by four essential freedoms.

Your argument is, why some piece of software should (or should not) be relicensed to GPL.

My argument is, that since that piece of software is currently not GPL licensed; avoids the relicensing topics and explores how to solve the current situation wrt distribution of the combined work. Use by the end-user is non-issue, due to freedom 0.

Their argument is that even if linked and distributed, there is no GPL violation for the reasons above.

I thought you could just have the drivers be downloaded and installed during installation i.e. never technically shipped with the OS.

That's somewhat similar to what Ubuntu does, with the additional drivers applet.

This isn’t correct. WiFi router ships with GPL Linux and proprietary router software. The company / foundation creating the distribution just needs to have a license for the proprietary bits.

No, that's not entirely true either. Depending on where the proprietary bits are, it's the other side that is the problem. It is a violation of the GPL. So the usual workaround is to shift the responsibility to the user so that incompliant stuff is done by the user by the way of a script that runs on the user's behalf.

It's not incompliant when the user does it, as long as the user doesn't copy and distribute the results.

If the wifi routers are shipping with binary kernel modules, then yes, it they are breaking GPL. This problem is actually common with embedded devices.

I never understood why NanoBSD didn't take off after the Software Freedom Conservancy lawsuits.

First, if you're talking about the lawsuits over wireless routers, that wasn't Conservancy, that was the Software Freedom Law Center (SFLC) working with the FSF. (And some feel those lawsuits were poorly timed, preempting active negotiations in progress and being largely responsible for Cisco ceasing large Linux-based projects in progress.)

And second, to answer your question, partly because Linux is sufficiently good and has wide enough hardware support that it's still easier to use Linux legally under the GPL than to use another operating system, and partly because if you're going to use another operating system with narrower hardware support you might as well use a tinier embedded one and ship cheaper hardware (which is what Linksys/Cisco did with the WRT54G, shipping VxWorks and less RAM, and then selling the more-Linux-capable WRT54GL as a higher-end product).

Beyond the whole foss aspect, there are good technical reasons too. For instance, blob won't work with wayland (at least right now AFAIK), and ubuntu was (is) debating switching to wayland as default.

If Nouveau isn't working all that well, then clearly a switch to a new graphics stack that would require it is waaay premature, given how prevalent NVIDIA graphics hardware is.

It does actually work fairly well for non gaming uses.

> blob won't work with wayland (at least right now AFAIK)

AFAIK it works with Gnome's Wayland Implementation, but not with the one from KDE.

My impression was that the 17.10 Weyland stuff was kind of a mess so the switch is probably premature at this point.

Fedora is Wayland-by-default for several releases already.

I had a handful of laptops at work that were briefly on 17.10 (because 16.04 had a showstopping bug for them) and the graphics were a complete headache until I switched them to X. Luckily 18.04 reverted to X and made my life easier.

I've never had problem with it; but then, my laptops have all Intel GPU and my only desktop with AMD GPU handles it nicely too.

Chances are, that you are using modesetting X driver anyway (i.e. the KMS driver, the same driver/backed, that is used by Wayland).

Fedora is a bleeding edge distribution whose sole purpose is to test out new features.

Sort of. It falls back to X for drivers that don't support Wayland, which has included nvidia for a long time. (Maybe there is some progress there more recently.) And the proprietary nvidia driver is widely used.

Does it really? I had grotesque lag when installing Fedora on a System76 laptop with an Nvidia card and had to switch to X manually.

Wait until they join up with Yutani.

I think what they mean is "it's now enabled and used by default even for the clic clic clic through the menu (non technical) users", not that the driver is technically present.

The VESA driver?

How does llvmpipe do these days? I remember being excited about it ~5 years ago and I can only imagine both LLVM performance and CPU speeds have gone up.

llvmpipe is the gpu part, not the display part of the graphic card.

Otherwise, when using it in KVM VM, it can run the desktop compositor quite nicely.

But that's the part that's crashing. I'm suggesting Chrome use llvmpipe to do whatever they needed hardware acceleration for, generate a single boring texture on a single big rectangle, and pass that through to the graphics driver. That way Chrome itself isn't loading the Nouveau libGL and is much more insulated from incompatibilities between Chrome and Nouveau, whosever fault it might be.

WebGL requires far more than just blitting onto a single boring texture.

That's why you go through llvmpipe - you use the Mesa OpeGL implementation in LLVM-JIT-accelerated but pure software mode to implement WebGL, get the results onto a texture, and pass that texture onto your actual graphics card.

https://www.mesa3d.org/llvmpipe.html

That seems like something you'd prefer not to do if your OpenGL driver wasn't broken.

That's what swiftshader does.

Whoa, I totally missed that! https://blog.chromium.org/2016/06/universal-rendering-with-s... So is it the case that you get decent (though perhaps not great) WebGL performance even if you have no GL-compatible graphics driver at all?

Then are Nouveau users only losing performance and not functionality as a result of this Google decision?

I didn't look at the bugs at issue, but I rather doubt mode switching is what Chromium cares about. It's sure to be video decode or GPU output.

> What else are they going to ship ?

That's not the point. The point is that it results in brokenness, and the easiest way to mitigate that for the bulk of non-technical users is to use software rendering instead (i.e. blacklist it). They're open to more refined solutions, but these will take some effort.