> And to me, how could they anyway, I can't find "a Linux desktop". There are many, which one would they port to?

This was the very reason that prevented Google to release Google Chrome for Linux.

Maybe I'm missing your point, but Google Chrome is available on Linux and is available on pretty much any distro I've tried (and has been for many years).

If I remember right from years ago (2008-2010) the initial release of Chrome was just for Windows, and the Linux version was in beta for quite a while as just "Chromium" without much Google "cloud" integration.

Sarcastic or ignorant?

Both. GP knows Chrome for Linux exists but ignores that its need for auto-update doesn't play well with distros package management and it also statically-links or ships 3rd party libs. Clearly supporting diverse (fragmented) linux ecosystem is not easy at all.

> Chrome for Linux exists but ignores that its need for auto-update doesn't play well with distros package management and it also statically-links or ships 3rd party libs.

At least on Debian, it plays perfectly well with the Distro's package management. They use it to auto update google-chrome in preference to their roll their own on effort Windows. The same update system works perfect well on all Debian derived distro's. I'm not familiar with an rpm based distro to say for sure, but I imagine the situation is the same. So "fragmented" means supporting 2 very well tested distribution systems rather than rolling their own - and having the "take out all Macbooks" problems they did on OSX.

> ~ 2%.

2% of the human population are 154 million people. Sure, not everyone has a computer, so let's say 66 million people, this is the population of France.

> There are many, which one would they port to?

You don't actually need to support a specific desktop environment. Any UI program that you write will work just fine on KDE, GNOME, DWM, etc

>Any UI program that you write will work just fine on KDE, GNOME, DWM, etc

But which versions of which libraries do you target? Every distribution has its own menagerie. There is no well-defined "Linux platform" like there is with Windows (https://docs.microsoft.com/en-us/windows/win32/api/).

If your software is FLOSS, that's an integration problem for distro maintainers to solve and it hinges on said libraries being versioned properly. The bigger distros usually have 10,000+ packages and those are downloaded, installed and updated automatically which cannot be said of almost all Windows and OS X software. Really, only Android and iOS offer a similar experience.

If your software is proprietary (or not popular enough to be found in most repos), there's always container technologies like Snap/AppImage/FlatPak/etc.

As a Windows dev I find both of these to be vastly superior to the standard Windows practice of shipping every DLL that's not in system32 alongside your executable, on top of whatever VC++ redistributables and/or .NET framework might not be present on the system.

Just static link? Or do what windows software does, so ship dynamic libraries with your application. I do not see the issue.

> There is no well-defined "Linux platform"

There actually is! https://en.wikipedia.org/wiki/Linux_Standard_Base

Core libraries like glibc and Xlib are pretty well defined. You need to ship your own copy of the widget library of choice, but that isn't a big deal. You could even ship an Xlib copy and rely on the fact that there is an X server speaking the same protocol. It's all perhaps a bit messy, but it works.

That is only true on X. With the wayland protocol, the DE also becomes the display server. And because of barndoor sized holes in the standard wayland protocol, apps will either have enormous testing effort or be limited to a DE or two.

And that's why wayland will never replace X

Most programs use existing libraries like SDL, GTK, QT, etc, which handle wayland integration on their part.