> You're not speaking about desktop applications / games

Those apps aren't hard to develop because libraries or the environment or whatever; they're hard to develop because their developers want them to be closed, so recompilation and putting them into the real package management system is impossible. Starting with such a handicap makes things complicated :)

> If you think there are better paradigms that should be explored, then jump in and show the world how right you are

The better paradigms have been known and used for 20 years (such as the Unix paradigm of connecting multiple programs, the CLI, and so on). That it doesn't appeal to some end users is not our problem.

(also username post combo, but just kidding :)

> Those apps aren't hard to develop because libraries or the environment or whatever

They are hard to develop because it's difficult choosing libraries, the environment, whatever, and your choice for today may be deprecated in 6 months. Of course, with the proper abstractions you can painlessly rewrite your app to target the newest toys.

But there are always costs involved ... sure you could rewrite it in a couple of weeks, but quality assurance (if you're a professional that doesn't releases pieces of shit) takes as long as it did for the original target.

> they're hard to develop because their developers want them to be closed

Yeah well, it's their choice, and accommodating applications that aren't open-source should be a requirement of any OS because, you know, the majority of desktop apps in production are closed and that ain't changing because it's a valid business model.

> Starting with such a handicap makes things complicated :)

It's only a handicap on Linux. The other platforms, including Solaris, have been doing just fine. Which makes me wonder about which part is handicapped.

And getting new versions of your software out by trying to get X distributors to include your newest version in their repositories (which are completely outside of your control and each with it's own set of rules) is less complicated than just putting new stuff up on your own website? I don't think so. There is one advantage for users certainly - it's easier to find versions of software which are officially sanctioned by their distributor, although it might be outdated by months. Which does often not matter much for server-software, but for desktop software it's something which users don't really accept.

I think we can discuss if this central-control-by-distros model of software distribution has more advantages or disadvantages, but it's not all shiny throughout. As example when stuff go really wrong with that model - maybe you heard of the troubles with Debian, J.Schilling and the cdrtools. I didn't until I noticed I could no longer burn CD's(!) with k3b and had to spend a few hours on figuring out how to fix this (you have to get the Schilling versions of the tools - the official Debian-version simply does not work in some cases and that is known now for a long long time). So there is a well-working combination of k3b+cdrtools which fails to pass the distributor rules (which is certainly fine) and now the authors can't really get the working combination (of 2 open source packages!) in an easy way out to the users.

Their absolutely are reasons why GNU/Linux development is harder/more restrained than Windows at times. On Windows I can go with DirectX or OpenGL depending on my needs, with GNU/Linux I only have OpenGL. Say what you want about DirectX, it is ahead of OpenGL in some respects.