For application developers there is a consistent set of APIs that are expected to exist in each version of Windows, Mac OS X, Android, iOS, Windows Phone...
On GNU/Linux one needs to bundle the libraries with the application, preferably static linked. But no one is going to do with with GNOME or KDE applications, for example.
Then there are the deviations each GNU/Linux distribution does from UNIX daemon management and paths.
So application developers are forced to choose a set of gold distributions and let everyone else to figure out how the application might, compile and run on their own system.
I thought we're talking about users here, not developers.
Steam, Mathematica, Mendeley Desktop etc. have long proven that stable API for GUI toolkit doesn't have to be an issue for users.
> For application developers there is a consistent set of APIs that are expected to exist in each version of Windows, Mac OS X, Android, iOS, Windows Phone...
This problem you're referring to isn't something inherent in or specific to Linux.
On Windows, the very same problem exists and is known as DLL hell.
Android is another Linux distribution, and you're talking about Java programs running on top of a VM on top of it. Java programs work just fine on Linux too.
I belive you're talking about Cocoa and Win32 API.
On Unix, there is POSIX and X11 which go way back. And there are many GUI toolkits (including but not limited to Qt and wxWindows) that allow you to statically ship your program, with the added bonus of being cross-platform.
API isn't an issue that can't be solved for developers either.
> On GNU/Linux one needs to bundle the libraries with the application, preferably static linked. But no one is going to do with with GNOME or KDE applications, for example.
Yes, they can and they do ship statically linked binaries. While they don't generally use Qt or GTK, both promise binary compatibility with a major version.
They don't need to make it a GNOME or KDE apps to run it under X11.
> Then there are the deviations each GNU/Linux distribution does from UNIX daemon management and paths.
Can you be more specific about the problem you're referring to? Are you talking about a particular closed-source daemon program that uses something other than /etc/init.d or systemd (which has sysv init compatibility layer)?
"DLL hell" doesn't have anything to do with the built-in GUI API calls. The part of the API that pertains to the GUI is built-in, standard, and has been since the 90's. I can take an application written today and run it on Windows XP-10 and it will work as long as I take care to not use any API calls that are specific to later versions of Windows (very few for most apps).
If you want to criticize the GUI aspect of Windows, you should target the lack of any standard modern GUI API calls that don't involve using Direct2D or GDI+ (by modern, I mean full support for transparency and anti-aliasing, among other things). The old API, plain GDI, was standard and well-understood, whereas the newer improvements are completely different types of layers built on top of GDI. That's the real mess.
Comparing X11 to Win32 is just laughable. X11 is ANCIENT. It also provides no widgets or anything other than windows and drawing primitives (which are ancient). You can't do anti-aliased fonts for example, you have to render then with freetype2 into a pixmap buffer and put that in your window. Practically every GUI toolkit does it that way - allocate window, do the drawing yourself, present final pixmap.
Win32 is more like Qt and if we could just fucking standardise Qt as THE API to target, everyone would be much happier. But of course then the Gnome devs won't be happy. The Linux desktop would be in a much better place if Gnome was dead.
Win32 is also ancient. It is the model of programming with handles and window message loops, that was inspired by MacOS (Classic) and that the OSX abandoned 15 years ago.
To consider you example with text, in Windows, you also have to use GDI+ or Uniscribe to have at least passable text (without shaping, that is). Or use DirectWrite, which is about as old as Pango.
Even OSX went through changes, AAT/OpenType wasn't available when QuickDraw GX was all the rage.
For application developers there is a consistent set of APIs that are expected to exist in each version of Windows, Mac OS X, Android, iOS, Windows Phone...
On GNU/Linux one needs to bundle the libraries with the application, preferably static linked. But no one is going to do with with GNOME or KDE applications, for example.
Then there are the deviations each GNU/Linux distribution does from UNIX daemon management and paths.
So application developers are forced to choose a set of gold distributions and let everyone else to figure out how the application might, compile and run on their own system.