[0]: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
[0]: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
How about the day when Nvidia releases a buggy (system-crashing?) implementation of the required APIs? How well will your code work without changes, and which course of action will you take?
Chromium chooses to prioritize users' experience over scoring ideological points. That means attempting to work around known external bugs instead of letting things blow up and sending users to pound sand on some unresponsive third-party mailing list.
I'm not sure how you can fault them for that, especially since pretty much all successful large-scale projects take the same approach -- including the Linux kernel.
Deleted comment
In simple terms, sway+wlroots DOES NOT have this line of code:
if (nvidia proprietary driver) {
suck();
}
Rather, it looks like this: do_important_gpu_stuff(); // Nvidia does not implement this
The Nvidia proprietary driver doesn't support the APIs necessary to run Sway. This is the correct relationship: the driver is responsible for implementing APIs and the software is responsible for consuming them. Nvidia didn't hold up their end of that bargain and thus does not work.In Chromium, the following line of code DOES exist:
if (nouveau driver) {
suck();
}
Nouveau implements the necessary APIs, but Chromium explicitly blacklists it. Nouveau holds up their end of the bargain here and Chromium does not.This is not correct. They may have methods that match the required signatures, but the APIs do not do what they are supposed to do. "Crashing my computer" is not a documented feature of any webgl API I'm aware of.
From an API perspective, Nouveau lies (perhaps not intentionally, but in reality) to its consumers. Nouveau isn't holding up any part of the bargain. Having correct method signatures doesn't mean you implement an API if you return wrong results.
Crashing is a wrong result.
And don't be ridiculous. All software has bugs, including Chromium. Should I detect Chromium and blacklist it on my sites in preparation for future bugs? Just a few weeks ago I found a Chromium bug when I was working on a website. I did not blacklist the browser, naturally.
>All software has bugs
If those bugs crash the system and the software is made the default, and the change is a performance degradation, yes. Degraded WebGL performance is superior to the system locking up for nontechnical users.
>Just a few weeks ago I found a Chromium bug when I was working on a website. I did not blacklist the browser, naturally.
Did they fix it in less than 2 years? Did it crash the end-user's computer? Did people navigating to your website report the bug to you?
Did you perhaps work around the bug? For example by using a polyfill that would provide degraded performance but still allow the end user to access your content? Because that's almost exactly analogous to this situation, and exactly what everyone does.
Crashing on a page designed to exhaustively test GL features is one thing. How about crashes which actually affect end-users? I expect that the volume of users who will be negatively impacted by blacklisting is far higher than the volume of users impacted by serious nouveau bugs like this. The difference is that the former user hasn't been annoying Chromium devs in their bug tracker yet.
>Did they fix it in less than 2 years?
No. The bug turns 2 next month and shows no signs of being fixed.
>Did it crash the end-user's computer?
No, but like I said I don't think many nouveau users are actually affected by bugs of this scale. The bug which prompted the blacklisting and being discussed today is not such a bug.
>Did people navigating to your website report the bug to you?
Yes.
>Did you perhaps work around the bug?
Yes
>For example by using a polyfill that would provide degraded performance but still allow the end user to access your content
No. If the workaround caused severe performance degredation and encouraged users to switch to proprietary software, I would have patched Chromium.
The bug being discussed today is just one of "some bug reports on other rendering issues with Nouveau". It fails the conformance tests, a quick search showed that same bug about crashing having been reported to chrome. Let me say that one more time:
There is a set of conformance tests to verify API compatibility. Nouveau fails them. It's not just buggy, it is literally non-API-conformant. You can't keep pretending its API conformant when it fails the API conformance tests. When Nouveau is actually API compliant, perhaps it will get un-blocked.
Until then, Chrome is doing exactly what you'd do if Nvidia claimed to implement the APIs but just made the system crash instead: block a nonconformant API implementation that lied to its clients and degrade gracefully instead.
It doesn't matter. Nouveau is a buggy implementation but an implementation nevertheless. No one is going to blame Chromium for their desktop freezing up. It's the user's decision to buy Nvidia and Ubuntu's decision to use a buggy driver. They've weighted the tradeoffs and come to a decision which is theirs to make. It's NOT Chromium's place to make that call.
These bugs are not causing daily issues to Chromium users, or even frequent issues, for nearly all users. The blacklisting does affect all users, daily.
It is not Chromium's place to decide which driver their users will use. It's not okay to write vendor specific code. It is not okay. You write code for the APIs and if the implementation of those APIs is buggy, it's their bug, not yours. Changing your code to fix someone else's bug is the objectively incorrect thing to do. Fucking over an important upstream Linux driver in favor of a proprietary driver from a bad actor is outright morally wrong.
Do you honestly think that it's reasonable or acceptable for Chrome to allow an arbitrary website to hard lock a user's machine?
That being said, you're right, but a more appropriate response than blacklisting nouveau would be blacklisting this particular WebGL feature on nouveau.