Are you referring to the small decade it took them to support KMS so that their driver behaved even remotely like a modern one?

Or perhaps their marvelous installation methods of running a random script as root that rewrites configuration files, and its configuration interface that likewise also rewrites configuration files in attempts to get multi-monitor setups working that until recently hardly ever worked?

Maybe you are referring to their magnificent support, forcing you to stay on outdated kernels as upgrading would break compatibility and render you without a functioning graphics adapter short of a VGA-resolution framebuffer console?

It could also be their fantastic backwards compatibility, requiring you to keep track of driver series compatible with certain adapters, where every other GPU in existence just works OOB.

I used NVIDIA up until a 2 years back. While you could arguably get things to work, claiming they had excellent support is laughable at best.

I think he refers to the fact that Nvidia's drivers provided excellent OpenGL support for multiple years compared to the absolute dumpsterfire that fglrx was. Before Valve decided to pay attention to Linux and thus prod AMD to improve their drivers, if you wanted anything approaching serious 3D performance on Linux, you had to use Nvidia. Anything else would be a waste of money.

Fair enough: That was indeed true many years ago.

Not that many, fglrx's replacement amdgpu was released in april 2015, that is just four years ago. And it wasn't until later that it got usable.

Most distros have a nvidia driver package that aligns with the kernel version shipped. This also means updating one updates the other automatically.

Furthermore lag time for supporting newest kernel normally lags what 30 days?

In brief what you are describing is self inflicted wounds.

Indeed, any problems spawning from using NVIDIA can be considered self-inflicted, which is why I left that dumpsterfire.

Expect supporting wayland properly, which all other major vendors have been doing for quite a while. I wouldn't call this excellent at all...

> Expect supporting wayland properly

Doing what everyone else does != doing it properly

> I wouldn't call this excellent at all

So far Wayland support is most further in Gnome and even there a lot of features are still missing/broken despite Wayland being well over a decade old at this point. A lot of very basic features (remote desktop, screen sharing, exclusive fullscreen, keyboard/mouse shortcuts) are still in their infancy. Not to mention both Gnome and KDE have implemented their Wayland compositor inside the shell process so now a compositor crash means you lose all your open apps which hasn't been a problem in Linux for decades.

> A lot of very basic features (remote desktop, screen sharing, exclusive fullscreen, keyboard/mouse shortcuts) are still in their infancy.

- remote desktop: good point. Considering that screen recordings work fine, I don't see a technical reason that a Wayland remote desktop setup couldn't work.

- exclusive fullscreen: what do you mean by this? Using Firefox, F11 and Super-F both work in Sway and F11 works with GNOME.

- keyboard/mouse shortcuts: maybe? The fact that a random process can no longer read all of your keystrokes seems like a plus, to me. Otherwise, just add a shortcut to your window manager or DE and run a command of your choice.

- losing all apps on compositor restart: Only an issue with GNOME and KDE. Pressing Super-Shift-C on Sway reloads the compositor and not your apps.

> The fact that a random process can no longer read all of your keystrokes seems like a plus

It is a plus, unless you write software that allows for global keyboard/mouse shortcuts (which I have done). In which case it is just a huge pain in the ass to not have it, and then hearing from some developers that you can just "add a shortcut to your window manager" is incredibly frustrating. It's not like you can trust an average end-user to actually do so, even the ones that do run linux. Then you will get complained at for not having functionality that existed at some point in the past.

Exclusive fullscreen = application runs directly on the screenbuffer, bypassing the compositor. Not just that a window happens to be taking up the whole screen.

This is never going to exist the same way it did in X, which was a hack around the X display model.

It doesn't matter how it is going to exist, what matters is for it to exist.

Well--no, not in the same way, but it can still be a hint passed along somewhere, to allow the compositor to swap out its root framebuffer for the program's.

Screen sharing is quite important in my workflow. Fellow developers and customers will send me buying Windows or a Mac if all screen sharing applications on Linux stop working. I'm using Slack and Meet. Skype is almost abandoned among my customers.

I would like to see the approach your pronning of "not doing like others" applied to some other protocols like TCP. Networking would be really fun and Internet a great success. The very concept of a protocol is that everybody does the same, the underlying implementation is different.

Wayland and its current limitations have nothing to do with, and does not excuse neither, nvidia's non-compliant implementation.

The protocol is over a decade old; the implementations of it are not.

How long did it take to get multiple monitors working with xrandr, again?

Funnily enough, this is exactly what I was talking about. Nvidia supported multiple monitors on Linux for decades using TwinView, they simply didn't add support for the open source xrandr for 4-5 years, but even that has been supported for ~7 years now.

> Nvidia supported multiple monitors on Linux for decades using TwinView

And Xorg supported them for decades before using Xinerama. Instead of collaborating with upstream, they just dumped something incompatible and broken, and said "Deal with it".

Multi monitor display worked perfectly for long time, long before "it works on intel, let's call it new standard" crew decided that flat shared framebuffer is the only way to go (apparently because of compositors and nothing else), something that also broke support for multi-gpu and especially heterogenous multi-gpu.

Zaphod mode is still available. nVidia pushed its TwinView solution while everybody else was using either the Zaphod mode or Xinerama. I don't think TwinView on Linux allowed any dynamic configuration. So, when the rest of the world switched to the RandR extension, every graphic card was able to dynamically add/remove monitors while nVidia users were stuck with a subpar solution.